Showing results for 
Search instead for 
Did you mean: 

CPU usage at 100%


I'm rather new to all this, but I seem to gobble up my CPU usage when I use the 'call library function' to call a dll.

I am using a Velleman K8055 USB interface board, a kit that you assemble which gives you 5 digital channels in, 8 digital channels out, 2 Analogue in and 2 Analogue out etc. It comes supplied with a dll for controlling it. I have sucessfully called the dll to control the digital out channels. I had a problem with cpu usage but then discovered that the presence of a wait (even only value 1) in the VI would drop the cpu usage way back.

When I try to read in one of the digital channels (or analogue for that matter) the CPU usage shoots up even if there is a wait in the VI (except when the wait is greater than 500 - but that's too long for me).

I'm using XP and its a USB interface. I've included the VI to see if that might enlighten things.

Any help gratefully recieved.
0 Kudos
Message 1 of 8
What is happening is that your loop is running really fast and it is making calls to your dll.

CPU usage at 100% for your code is normal.

What you need to consider is your loop wait. Is it necessary to go as fast as your computer can? Try a small delay. This will make your UI more responsive.
0 Kudos
Message 2 of 8
I'm trying to use the same board, but LV7 bombs out every time I try to call the dll, with a message about exceptions in an external function .
 I haven't got past OpenDevice yet! 
My LV program has an OpenDevice call with display of card number, and a CloseDevice call.
Task manager shows that the dll is not open after the LV program bombs.  I presume this means that the dll doesn't open or it is closed properly.
The board (with the same dll) works OK in Visual Basic (Yuk!).
Do I need a different dll?
My data types appear correct ie reporting as "long" in the function line during setup of the call.

John Y
0 Kudos
Message 3 of 8
Hi John,

I am interested that someone else is trying to use labview to control this board. My LV seemed to work ok. I haven't done anything with it recently mind.

Why don't you post your vi and i'll see if it works on my machine.

Have you downloaded the latest dll's from Velleman?



0 Kudos
Message 4 of 8
Hi John,
I've just had a thought. I had the same problem that you had - LV bombing out. It was because in the Call Library Function settings i had Calling Conventions set to C not Stdcall(WINAPI). See if that is the problem.
I am having trouble getting the digital out to behave. I can turn individual channels on and off, but if i do it too much they get confused and start switching on and off other channel numbers. Any help on this would be great.

Best of luck

0 Kudos
Message 5 of 8
Hi Phil

It worked with stdcall (WINAPI) selected!!  Thank you so much.

Also, your original comment about 100% CPU use reminds my ...

I was building an industrial control system around a set of GPIB instruments and needed a single switch input to the program.  I used the (old fashioned) joystick port switch, on the assumption that this had hardware interrupts and would be essentially invisible to the processor.  This worked well.  The program is still working after 2 years and > 60,000 tests 
The second model had a PC without a joystick, so I hacked a really cheap USB joystick for the same function.  While it worked, it appeared that the processor was very busy and was not running my program as it should.  The joystick regularly disappeared and required re-inserting.  I gave up and used a digital line in on the NI card that we then purchased, with no problems.  I didn't investigate at the time but maybe the USB interface was gobbling up the processor time.

I will need to consider this with the Velleman card.

Cheers and thanks again.

John Y
0 Kudos
Message 6 of 8
Hi John,

Glad it worked. Would you be interested in sharing code that you write for the K8055? I have written a few different programs for turning on and off the digital channels, analogue out, analogue in etc. I am keen to see how other people write software for it.

I have got to the source of my problem with it randomly turning on an off channels. The problem was that i ran the vi for controling it several times without closing the previous sessions. Thus there were several instances of the K8055E0.exe program running in memory. I guess this then meant that they were all trying to control it leading to conflicts. It works fine now that i open and close the k8055D.dll everytime.

Also, i have been looking at my memory usage. I think it is just the fact that i am making repeated calls to the dll. The only way to reduce the usage is to slow down the rate of calls.

Best regards,


0 Kudos
Message 7 of 8
Phil: as regards the problem of multiple instances of the dll:
I did notice that your example code didn't open or close the dll, although it still appeared to work (!)  Also, during my experiments, I tried the Velleman VB example code after my LabVIEW code didn't work, and noticed eratic output.  Task manager showed 2 instances of the dll operating and closing one allowed the correct operation of the VB program.
There was also a comment that came with the upgrades on the CD supplied in the kit that the early version of the dll didn't release memory correctly when choosing another card.  I am still operating with that version and haven't looked at memory usage yet.
I am still developing the application for this card (remote operation of an electric motor test bed) and will post something later.
Thanks for your assistance
John Y
0 Kudos
Message 8 of 8