Synchronizing multiple consumer producer loops

[geneM]

I have a VI  with 3 producer/consumer loops running in parallel.  One of the loops reads a 3 axis accelerometer on a submerged device, the 2nd loop reads a 3 axis accelerometer on the buoy supporting the submerged device and the 3rd loop reads a load cell on the cable between the buoy and the submerged device.  All three devices are networked through a variety of network switches, DSL modems, radio modems and so on, so the data shows up at the main computer pretty asynchronously.  RIght now each device is sampling at roughly 10 Hz.  Each loop uses the standard TCP functions to read each device at whatever rate the data gets to the computer.  The VI runs pretty well but after 30 minutes or so, the data starts to get out of synch i.e.., one loop will acquire and plot data pretty smoothly but the other two loops seem to read and plot a bunch of data really quickly and then pause before plotting a bunch of data really quickly again.

I'm guessing the loops are getting out of synch with one loop getting most of the CPU.  Is there a clean and simple way to make sure each of the loops gets a roughly equal slice of time?  Would it be better to have one producer loop reading all the devices as fast as it can and then enqueing the data to 3 separate queues?

Thanks - Gene

[JÞB]

I would diffinately look at the multiple producer queue example as a good place to start.  It just seems a lot simpler to pass all three data sets into the same queue for processing (And a bit more scalable too)  Synchronicity of the data is likely controlled by a timestamp in the measurements themselves leaving you with the option of just processing data on a first come first served basis.  Even If some of your measurements arrive non-sequentially, the timestamps from the measurements will allow you to sort the results in your analisys.  Of course, If the equipments DONT supply the time of each measurement- you need another approach.

[johnsold]

Gene,

Sounds like fun.  Probably what is happening is that a hurricane has hit the system.

I would use three producer loops, one consumer loop, and three queues - one from each producer.  Anytime you have loops running in parallel, each should have some kind of wait to avoid hogging the CPU.  The TCP Read has a timeout capability, so it probably can serve as the wait function.

Lynn

[tbob]

I agree with Lynn about the wait issue.  Do you have delays in each of your loops?  You should have equal delays in each loop.

[geneM]

I can't believe how quick and helpful this forum is.  I don't have any waits in any of the loops.  Just to make sure I understand, you're talking about the plain old Wait (ms) function from the timing functions menu?  I never understood this was a non-blocking wait, i.e., whatever function is "waiting" basically gives up the CPU, is that correct?  I will try this immediately.

Many thanks - Gene

[tbob]

Yes thats it.  Wait(ms).  Whenever you have a loop, put in a wait, even if it is 0ms.  This gives the CPU time to do other things, like handle the DAQ.  There are exceptions to the wait, and they involve having a wait in another form.  If you have an event structure in a loop, the timeout case can be wired with a number.  this is the same as a wait.  No need to add another Wait(ms) here.  There are other examples that I can't think of right offhand.

[arizzi12]

Jeff, can you pls provide a link to the "multiple producer queue example" you referenced?

I haven't been able to find it.

thx,

Anthony

[JÞB]

...LabVIEW xx\examples\general\queue.llb\ Queue Multiplexer.vi