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.
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
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.
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.
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
I will need to consider this with the Velleman card.
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
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.
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.