10-26-2012 12:40 PM - edited 10-26-2012 01:07 PM
I'm having an issue I'm fairly certain is related to the way parallel while loops execute, though I is possible it is something more basic that I'm somehow missing. I'm a physicist, not a Labview programmer by training, so while I consider myself pretty experienced there are a few holes in my overall understanding in places where I never went before. This is probably one of them. I still sometimes get hung up on issues of Labview qua parallel programming.
BACKGROUND: I have multiple parallel while loops that collect serial data from separate VISA resources representing different sensors. Up until a week or so I had only a *single* data collection loop (state machine architecture) as all our sensors were multiplexed on a single serial line (new lines arrive at 10 Hz). Everything executes fine with that. The current issues arose when I wanted to add some serial lines for different types of sensors that collect data at a slightly different rate - solution seemed obvious, use multiple parallel while loops so each line of data from each resource can be collected at its own rate. The asynchronous data are put together in the "main" while loop using local variable so that the most recent data from each resource is put together in a single array, and in sync with the main loop. While the main loop has a lot of analysis in it, this is the basic structure. As you can see I have use some vis here that handle the serial data.
When I added a few parallel while loops (as above) to collect the serial data from the other sensors (first introduction of more than one parallel loop) I got some "synchronization" issues in that instead of reporting the sensor data from each sensor (and each while loop) "now" data from different points in time were out of sync: for example sensors which should read a spike in activity at a certain moment read late (time shifted). Different while loops sometimes have data that is shifted different amounts. Probably could have fixed using re-entrant exicution. So even though there are parallel while loops it appears that the program is not reading the data from the resources as fast as it is produced. I should note that I clear the resource buffer as the last step in the set up block, though my understanding is that this should not necessarily matter since the independent loops should catch up with the data collection (very low rate, ~ 12 Hz) and the data on "DATA STRING 2" and "DATA STRING 3" should be the most recent (current) data.
THE CRUX OF THE MATTER: So the above program has the issue I described, but if I replace the above code with a version that simply has the contents of the vis removed for vis and place in the main body of the code, like this it fixes (sort of - see below) the problem. Probably could have fixed using re-entrant execution.
(Edit: there is a typo here the "com2" in the lower while loop should be "com3". They are all different resources).
When I take the latter code that works, compile it, and put it on a laptop there are possibly related problems that arise. It seem that the execution get locked on one or the other of the while loops where data arrives from one resource but not one of the others, or sporadically from the others. So using a different/slower computer and things don't work. The WAY it does not work does not line up with my understanding of how a slower computer might muck things up, so that is not good. Obviously I don't have a deep enough understanding of what is actually going on when Labview execute these parallel loops.
Might it be enought to add some "waits"?
Does anyone have some insight into these issues? Can anyone point me to a post or something that can help be understand what is going on?
10-26-2012 02:00 PM
Your loops are what are known as free running loops. They are not really giving the scheduler a chance to call other code. Once inside a loop it will starve the CPU out which prevents other tasks from running. You should include a Wait 0 in all of your loops. This allows the scheduler to run other tasks.
10-26-2012 03:24 PM - edited 10-26-2012 03:26 PM
I think I understand what you said and what you are seeing.
Several loops expecting data messages every 100mSec VISA Timeouts are the default 2000mSec. VISA is not the likely culprit here but it may be your error handleing. Simple error handler is not reentrant and each loop is using a copy of the same namespace. SEH is also a pig that goes and does a lot of stuff just to ignore errors (that seems to be what you are doing with it. mode 0 right?) It was never intended to be used inside a loop but at the end of an example program.
Better: use clear errors (Its block diagram is really just the error in error out terminals with VI Properties set to disable automatice error handling and error dialogs)
Best: Disable automatic error handling and error dialogs on your vi