LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

dll slows down parrellel while loop

Solved!
Go to solution

Hi,

 

I'm modifying a VI i've written, to work with another piece of hardware. The communication used to work directly through labVIEW. My new hardware came with a dll library/driver  and now I have several layers before reaching the hardware (LabVIEW -> driver -> some software -> the measurement hardware). I have a while loop that counts down seconds running next to my subVI that handles my measurement method. Since I have implemented the VIs that call the dlls the counting-while-loop slows down in the same frequency I call the dlls. I changed the 'Run in UI thread' setting to 'Run in in any thread' option in the call library function node. That actually got rid of my problem to about 90 %. But my counter still comes in a few seconds to late. I am puzzled in which way the library function node call is delaying a seemingly parallel thread ?

 

Any suggestion on where to keep looking for a fix ?

 

Greets

/Lorenz 

0 Kudos
Message 1 of 6
(3,425 Views)

Hi Pi-Control,

 

how do you poll? Is there a wait function in your While Loop? how often you you call the dll ?

Can you post a snapshot of the concerning part of the VI, it can be several reason why this happens, e.g. racetime conditions.

 

Kind Regards,

Thomas

Kind Regards,

Thomas Gimpel
Application Engineer Intern
National Instruments
0 Kudos
Message 2 of 6
(3,380 Views)

Hello Thomas,

 

thx for your answer. To be honest I don't know how I poll, since the communication with the device is handled by the seperate program running simultaneaously. I call a library function node that calls a drive that talks to that program which talks to the device. I havent used a set up like this before and I dont know how common this is or why anyone would chose this over other solutions. 

 

I do have a wait function in my while loop. 

 

I call the dll about every 200 ms. Sadly this is how long it takes for one call to deliver the results through the whole chain.

 

I attached the while loop as a png. The vi I call in there is just making a very basic calculation. I only hid that to have a tidy diagram.

 

Again. I use the same VI with a nother device where it works smothly.

 

Greets

 

/Lorenz

 

 

0 Kudos
Message 3 of 6
(3,338 Views)
Solution
Accepted by topic author PI-Control

It's hard to say what could work without knowing more about your DLL and what it actually does, but I see one thing in your loop which will force LabVIEW to switch to the UI thread! The property node to update the text of th start_method button will ALWAYS force a context switch to the UI thread. If you can avoid that there really shouldn't be any possibility for the DLL to block your loop anymore. At least try to only update that property if it needs to be changed in respect to the previous value and not at every loop iteration.

 

One guess is that the DLL actually interfaces to some ActiveX code somehow. LabVIEW intializes its ActiveX environment to run in the UI thread, since that is the only safe threading system in LabVIEW to run many single threaded ActiveX components or when data marshalling is involved. If your DLL also tries to connect to an ActiveX interface it will be forced to run through that UI thread which would explain way the property access in your loop may get delayed.

 

And another problem you have is the software timing. you count down the loop with 10ms interval but Windows will be hardpressured to guarantee hard realtime performance. While you do use the "Wait Until Next Multiple ms" to account for some jitter, if the loop gets blocked for more than 10ms through an external resource you will actually skip an interval.

 

Better would be to calculate the elapsed time directly by reading the timer tick before entering the loop, then use the timer tick output from the "Wait Until Next Multiple ms" to calculate the difference. Dividing that difference by 10 and then adding your initial count value to that result would give you the same value as you feed into your calculation VI, but in respect to the actual system timer, not an asynchronously running loop counter with questionable interval.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 6
(3,320 Views)

rolfk is right about his points. PI_Control did you try to change your VI in this matter and did it take an noticeable effect ?

Kind Regards,

Thomas Gimpel
Application Engineer Intern
National Instruments
0 Kudos
Message 5 of 6
(3,278 Views)

Hi,

 

yes, I use the system time now to count down. This makes my count down taking the right amount of time. So I guess the problem is solved. When I display the while-loop iteration I still see the periodical slow down. So the issue itself is not really solved. But that doesnt seem to disturb the function of my VI. Since I dont really know what the dll does and I am not sure how to find out, I guess the real problem is hard for me to investigate further. Thanks a lot for your help.

 

Greets

/Lorenz

0 Kudos
Message 6 of 6
(3,267 Views)