Optimizing Timed Loop running in a separate thread

[Daniel_Chile]

Hi. I am performing simultaneous buffered continuous data acquisition from a 6624 timer/counter board and a 6052E board. I am using a timed loop to read the data. The timing source is taken from counter 1 of the 6052, derived from the AI sample clock. The program works well until I switch to another application and return or if I scroll the window or minimize/maximize the VI window, where the loop finishes late and I lose the timing I need. I already set the VI preferred execution system to "Data acquisition", so I understand that user interface tasks should not interfere with it. Am I doing something wrong? Should I select another execution system (Other 1 or Other 2)?

This VI is a part of a bigger program where the
acquired data will be processed online, but processing is not time-critical.

Would it be better if I keep the data acquisition timed loop VI window closed? Should I give it a higher pritority on the execution properties?.

Is there a way to check the effective execution system a VI or subVI is using?

Thank you.

[Stuart_G]

There are probably several things you could look at.

1. You can set the priority on the timed loop. I'm not sure what the maximum is but you might try that.
2. It is good you set the preferred execution system to DAQ, but you should probably also try increasing the execution priority.
3. Do you have 2 separate loops 1 for UI and 1 for DAQ? If you don't then your UI tasks could still interfere with the DAQ/Timed Loop tasks.
4. The way to check the effective execution system of a VI is in the VI properties where you set those settings. Most of you VIs and SubVIs are probably same as caller so they are using whatever your top level VI is using. In this DAQ VI, it is going to use whatever you are setting it too.

Stuart G

[Ben]

The new performance toolkit that comes with LV7.1 (do not remeber name) will track where every thread executes.

Also note that if a VI has property nodes, then it is forced to execute in the UI thread regardless of how the VI is configured. This also applies to dll calls that are not configured as thread safe.

Ben

[Stuart_G]

If you are referring tot he execution trace toolkit (which is the only thing I can think of) then it does not come with LV 7.1...it is a separate toolkit.

Also, on the property nodes I may be wrong about this, but it is only if the property node is associated with a front panel control will the execution be forced. If you are using say a DAQ or VISA property node then there is no effect.

Stuart G

[Ben]

Thank you for correcting me!

You are apparently listening to what I meant and not what I said.

Thank you!

"
Also, on the property nodes I may be wrong about this, but it is only if the property node is associated with a front panel control will the execution be forced. If you are using say a DAQ or VISA property node then there is no effect."


I am inclined to believe this as well.

Ben

[Daniel_Chile]

Hi Stuart. Thanks for your reply. I've got some comments:
1. If you are talking about the "priority" property of the timed loops, I understand that unfortunately this has effect only with respect to parallel timed loops. The value can be between 1 and 2147480000, and only indicates the relative priority order between parallel timed loop structures.
2. Now I've also increased the execution priority, but I have the same problem.
3. I am performing all in one loop. I have a "stop" button and some boolean and numeric indicators (even a chart), which actualize on every loop. Does this force the whole VI or the timed loop to run on the UI thread? Maybe it forces "dialog" between the DAQ and the UI thread. I would appreciate if you could clarify this for me.
I am still a little confused with this matters. Can every "branch" of a diagram execute on different threads or execution systems? In which way could I separate DAQ and UI on different loops? Using local variables? Queues? Other synchronization tools?
If the problem are the controls and indicators included in the loop, would it correct the problem if the front panel is closed, I mean, executing as a subVI of a bigger program?
4. In the "execution" VI properties one can set the "preferred execution system" for this VI. Anyway this does not guarantee that the whole VI will effectively execute on this system, even if all subVIs are set to run on "same as caller". I was wandering if there was another way to trace the threads that correspond to each execution system and the code portions that are running on each one.

About the "same as caller" preference, I've got another doubt. On my timed loop DAQ VI I am using a "buffer" subVI (similar to queue functions) created by me which stores data on a shift register. This subVI is not reentrant, so I avoid undesirable read/write problems. This subVI's preferred execution system is set to "same as caller", so I suppose that it will attemp to run on the DAQ execution system. My doubt comes because I've got a separate VI, set to run on the "standard" execution system, that calls this buffer subVI to read the data. How does LabView manages this? Does the buffer subVI permanently switch between execution systems? What could be the advantages of the queue functions?
For the records, the original problem that motivated this discussion remains the same even if I do not use this buffer VI.
Thank you

[Stuart_G]

I will try to answer some of these questions. The best way to separate the DAQ and UI into different loops would be probably to use a queue. That is normally what I use. You can't set the branch of a diagram to execute on different threads. What you might try doing is in the UI loop set a timer which yields time to the DAQ loop. UI's seldom need to run as fast as the DAQ loop...humans just don't need to see updates any quicker usually than 500ms. Another thing you can try is having the UI in a separate loop and implement a queue. Then create a SubVI for your data acquisition portion and use the queue in that VI also. This way you can set the priority on the DAQ SubVI. Also, for UI use the event structure which is more efficient than polling
.

I think you kind of answered your own qustion on if the front panel is closed will it help. In your original post this started out because you were moving windows adjusting sliders, etc. If the user can't do that then yes it probably will help.

Keep in mind if you are using the timed loop on Windows, that even though it can set priority levels there is still a lot going on. If you want real determinism you might try using LabVIEW RT.

I'm not sure what you mean in #4,but there is no other way I know of to trace threads other than using the execution trace toolkit (and I think it only works for LabVIEW RT but don't quote me on that).

[bshah]

we discover an unaddressed issue with the timed loop which is going to get fixed in the soon to come 7.1.1 patch. Please keep a lookout on ni.com and download it. This patch should fix most of your problems. You should still be splitting your UI and time loop code in different VIs (as mentioned by Stuart) but you shouldn't need to change the execution system in VI properties.
My suggestion:
1> Download the 7.1.1 patch
2> Break out your code into UI and time-critical components
3> Use queues to communicate between these components
4> Set the execution system to normal for everyone. (Remember a "time-critical" execution system VI will preempt any timed loop or the timed loop preempts everything BUT time-critical VIs).
This should solve your problem.