Getting data from Multiple cDAQ racks at the same time.

[nonecure]

I need to combine an 8 port cDAQ rack and a 4 port cDAQ rack and was hoping someone can help.  I do not need the signals to be synced up exactly, but I can’t handle the 50ms delay that I have now.  The signals on the 2^nd rack is more for customer reference and the 1^st rack is doing all the real analyzing.

I need to collect samples at 500hz or every 2ms and I collect 25 samples giving me a chunk of data every 50ms.  The DAQmx tasks seem to pull at the same time, therefore the cDAQ2 In chunk is always 1 scan behind causing a 50ms delay.

Is there a better way to pull this data without having such a large delay?  I did not see anything in the examples that apply to my particular application and hardware.

Thanks,

Doug

[RavensFan]

Using local variables is the wrong way to do it because now you have a race condition between when the data was written to the indicator and when the other loop reads from the local variable of the indicator.  The data could wind up being stale, duplicated, or completely missed.

Have you tried setting up 1 task that contains the channels from both cDAQ's?

[nonecure]

I agree with you about the local variable and the data is always stale by 1 read or 25 samples.

I tried setting up 1 task in the beginning and MAX won't let me with this hardware.

[RavensFan]

Then try putting both DAQmx reads in the same loop.  Split the error wire so it hits both at the same time.  The DAQmx VI is reentrant, so they can both run at the same time.  This should allow both of them to start at essentially the same time.

[nonecure]

If one rack is slightly faster than the other even know they are set a the same rate, won't the buffer eventually overfill? 

I would think that the slower rack will pace the loop causing the faster rack to build up the buffer.  Is my understanding of this correct?

[RavensFan]

How would they be faster?  You set both to be 500 Hz.

You also are doing N channels N samples with 25 wired into both.  So both will return after 25 samples.  The buffer shouldn't fill up any beyond that.  Now if you were using Continuous samples and both were returning only 25 samples at a time, then it is a chance you could fill the buffer slowly if the clock timebases were off enough that one would occasionally slip in some extra samples relative to the other one.

[nonecure]

I am doing Continuous samples, so I would be worried that one rack can supply extra samples over time.

[RavensFan]

Then try setting finite samples.

Other alternative is to do a read of all available samples one both before reading the 25 samples on both.  That should clear out any extra samples in the buffer and wait for the new samples to come in.

[nonecure]

I'm not sure how to implement any of your ideas since my experience is light on pulling analog signals.  All my past project seem to be simple analog read and writes. 

To pull finite samples don't I need to do something different to request N samples versus just wait for my 25 samples?

[TheGeeze]

Each task will begin sampling data as soon as you start each task, so in order for each task to be synced, you want each start task to occur at as close to the same time as possible.  One way to try to do this is to put the start tasks together in a sequence structure.  This will ensure all your cofiguration steps for both tasks are complete before you start sampling.  How long are you runnig your application for?  If its not that long, I wouldn't worry about one of your chassis running faster than each other.  If you think that is becoming a problem, there are ways to diagnose that, but that would take a significant amount of effort.

I have included a snippet of how you can try starting your tasks together