I'm looking to see if anyone can explain an odd LabVIEW display behavior that I'm seeing when testing some timeout functions in a third-party DLL. I have a work-around in place but I'd still like to know why, without the work-around, the information displayed by the front-panel indicators is not synchronized with what's happening in the execution of the VI even though I've tried all sorts of things to enforce synchronization. Note that to run this VI in a useful manner, you will need to be able to communicate with a Galil motion controller over an Ethernet connection and that will, for the most part, limit this discussion to what the experts among you know to be happening under the hood of LabVIEW in situations like this.
This is what the VI looks like when my work-around (Bogus wait added) is active. It is a small state machine that uses the elements of the "Test Sequence" array to tell it what to do at each step of its execution. Here it reads an initial timeout value, sets a new timeout value, reads it back, tests the timeout by requesting a READ of the controller (without having first asked it to say anything), followed by restoring the initial timeout and then stopping. The two indicators in the red rectangle are there to show the current execution state and it is this pair of indicators which do not remain synchronized with the actual program state.
![Display Problem A.png]( "Display Problem A.png")
When execution completes this is what's seen.
![Display Problem B.png]( "Display Problem B.png")
If the bogus wait time is too short, then the indicators are not synchronized with the program state or in this case, with each other. Note that the only time the VI display is static enough for me to grab a screen shot like this is during the "Test Timeout" period. When the timeout eventually occurs, things become synchronized and the same results are displayed.
![Display Problem C.png]( "Display Problem C.png")
Here is the code. I'm also attaching a zipped folder with the code just because I don't know if snippets are smart enough to include any DLLs referenced by the call-library nodes.
![Timeout-Test Snippet.png]( "Timeout-Test Snippet.png")
Here on the left-side of the FOR loop the "State" and "Index" indicator terminals can be seen. The "Bogus Wait" needed to make the indicators work synchronously appears below in the same area. Before coming up with this "fix" the things that I tried, which did not work, were:
- adding the flat sequence structure seen here with the indicators in its first panel
- Using property "value" input nodes linked to the two indicators with their error outputs daisy-chained to the error input on the "G Read" (timeout test) function.
- setting the indicators for "synchronous display" (apparently this setting actually only works with multi-threaded code, which I don't believe this to be)
- setting the "defer front panel updates" property to false
One thing else that did work was connecting a "probe" to any data path on the input side of the conditional frame. I figured it also cause a few milliseconds of delay like the wait.
My best guess at what's going on is that display updates are "launch and forget" actions that happen on parallel execution paths within the single execution thread and they depend on getting a few time slices from the main process to complete. But when the main process calls an outside library, that outside library does not know to share time with any other processes that might be running within the same thread. Does any of this make sense?
WF PS Configure Voltage Output.vi': SubVI is not executable
