Getting data from Multiple cDAQ racks at the same time.

[nonecure]

Thanks, Your example looks much better than the things I have tried. 

My worry is that this machine runs 24 hours a day and test a part every 4 seconds, and over time the potential is there for one rack to have more samples than the other.  The machine has potential to run for months before being shut down.  If one rack gets a few extra samples per hour, then over time I will be grabbing older data and the buffer can overfill.

[TheGeeze]

Your concern seems valid.  However, it sounds like you have sufficient time to flush the buffer inbetween part testing if necessary.  You can flush the buffer by doing a DAQmx read with the number of samples set to read all available.  Check the help to find out the exact syntax.  Let me know if you want any guidance implementing this functionality.

[nonecure]

The machine tests parts on 3 different stations, therefore this is no real good time to try and clear out the buffer. 

Is there a clever way to pull all available samples from cDAQ2 every time cDAQ1 has its 25 samples?

[nonecure]

The biggest part of my delay was not seeing the forest through the woods.  The data in cDAQ2 local was pulled well before the DAQmx read finished.  All I had to do was put a flat sequence around the locals going into the array so that the data is not populated until the read is complete.

I start cDAQ2 first so it has its data before cDAQ1.  This is not a perfect method, but it works.  I am still open to a better method.

[Mark_Yedinak]

Both your update and Ryan's example do not require the sequence frame around the start tasks. In both cases you can use pure dataflow to accomplish what you want. While there are cases where sequence frames are necessary, such as yours around the local variables, I recommend that you avoid using them needlessly. They are pointless when the dataflow is already there and unfortunately are bad examples for new programmers.

[nonecure]

Do you mean data flow like my first picture, having the error wire go to one then the other?

[Mark_Yedinak]

Precisely. The code in your first picture (at least the area with the start tasks) is identical to your last one. They will both execute in the same order with the lower start task running after the first one completes. The presence of the sequence structure in the last picture is totally unnecessary since the error wire, as wired in the first picture, will accomplish the same thing for you.

[nonecure]

Thanks, that is the kind of feedback I like to get.

[TheGeeze]

The reason I included the sequence structure is to do our best to ensure the start tasks happened as close to the same time as possible.  While data flow enforces the sequence of things, basic LabVIEW diagrams do not enforce when two parallel actions occur.  If, for example, there was a lot of configuring to be done on one task but not another, then the sequence structure would help bring the timing of those start calls closer together.

From what I can see in your code, Mark is absolutly right.  There is nothing happening before those calls that will cause one to happen significantly before the other.

Also, I still do not see the reason for the two loops, it seems like everything can be accomplished in the same loop.  You could simply put the read inside of the sequence structure you have inside your larger loop.  It's generally best to avoid the use of local variables whenever possible!