Synchronizing different DAQ cards using different chassis

[FS12]

Hi,

I am trying to synchronize my data from different DAQ cards that are located on different Chassis. I believe the data I am collecting is not synchronized. I am want to make sure when I collect my data its all in the same time. my DAQ assistant 4 is running on an external clock. All other DAQ assistant blocks are running at the same rate and the same sampling. Is there a way to synch them all together?

I also attached my wiring diagram so you could see what DAQ cards I am using.

If you need more information please let me know.

[Cy_Rybicki]

I did not see anything attached to your post, but based on your description you are likely correct that your data is not synchronized. See the link below for several options on how to synchronize your inputs. The simplest option (if your hardware and configuration supports it) would be to use a multidevice task.

http://www.ni.com/tutorial/5376/en/

[FS12]

Thanks for the reply.

I did look at the link you sent me. I cannot use Multidevice task because I have different inputs (strain, analog input, analog output, and encoder).

I am also using DAQ assist boxes. I also attached my code now.

Farid

[Cy_Rybicki]

You should be able to use sample clock synchronization as described in section 3 of the link, and below is another post specifically for synchronizing encoder and analog inputs. You won't be able to accomplish this using DAQ assistant though, you will need to switch to using DAQmx.

https://forums.ni.com/t5/Example-Programs/Synchronize-Encoder-Counter-Input-and-Analog-Input-with-DA...

Do you truly need synchronization, or are you just running into timing issues with your setup? Based on your code I would anticipate problems arising from trying to read your inputs, write to your outputs based on that data, and writing to file all in the same loop. If you want to stick with using DAQ assistant then I recommend splitting your code into three separate while loops: one for all of your inputs, one for your output, and one for writing to file. You can use a QMH to pass your input data to the other two loops. Your sampling won't be perfectly synchronized but your application should run more smoothly.

[FS12]

So I took your advice and converted to DAQmx. I was able to use the same clock for both my AI and encoder. Thanks for your in that end.

I am trying to use triggers to start my acquisition all at the same time. I followed step 3 in this link: http://www.ni.com/tutorial/5376/en/#toc3

But when I do setup a trigger my data acquisition stops working. I get this error from my trigger setup: 

Error -200452 occurred at DAQmx Start Trigger (Digital Edge).vi:3930001

Possible reason(s):

Specified property is not supported by the device or is not applicable to the task.

Property: Start.TrigType

Task Name: _unnamedTask<71>

I am using NI 9172 chassis. Both my daw cards are on this chassis. My other 2 chassis are NI9191 and are connected to my computer via wifi.

I attached my code

Thanks for your help

[Cy_Rybicki]

The first thing I notice is that you are specifying the analog output start trigger signal in your source input to the DAQmx Start Tigger VI. You want to use the analog input start trigger signal since you want to trigger when your analog input task starts. It could be that the error is occurring because you do not have any analog output cards though that is just a guess. If that does not work then another option would be to place both Start Task VIs in a flat sequence structure as shown in Figure 1 of the link you provided. There will be a slight delay in when each task starts, but you can always remove the extra samples from whichever task started first by comparing the t0 attribute of the acquired waveforms. A few other pointers: Leave the "samples per channel" input to the DAQmx Timing VI unwired. When you specify a value using Continuous Samples you are allocating the buffer size for the task, which is unnecessary and will cause problems since you are attempting to read exactly 4000 samples per read in your while loop. Unless you have a need to acquire an exact number of samples per read, I would also leave the "number of samples per channel" input to the DAQmx Read VI unwired. This will give you how ever many samples are available in the buffer at the time of reading, which will change every iteration but avoid potential buffer overflow issues. I would consider moving your file writing VI to a separate while loop and use a queue to pass to pass data between loops. As your file grows, it may take longer to write your data to disk and could again cause buffer overflow issues.

[FS12]

For the start trigger source I tried multiple sources but none of them worked. I do have an analog input because I am collecting data from it. I tried to have an external trigger and that didnt work. Its just I cannot trigger it to start by any method. I keep getting this error:

Error -200452 occurred at DAQmx Start Trigger (Digital Edge).vi:3930001

I tried putting my task start VIs in the same flat sequence but that didnt fix the problem. each start VI seems to start at its own time.

All I need is to make sure all the start task VIs to start at the same time. 

I tried to incorporate your other suggestions. 

Thanks

[Kevin_Price]

Long ago, I developed the habit of sync'ing tasks *solely* by sharing a sample clock.  No triggers at all whenever feasible.   This runs contrary to most advice you'll find about sync, but I find that triggers are often not needed, and sometimes add unnecessary complication and difficulty.   Yours is such a case.

To *SOLVE*:

1. Remove all trigger-related config.  It isn't needed.

2. Choose one of your AI tasks to act as the "master".  It doesn't really matter which one, they'll all share the same sample clock, but you just need to know which one is playing the role of "master".  Let's go with the one at the bottom of the diagram where you're already trying to share the sample clock with the counter task.  Stay tuned, I'm gonna suggest a different method.

3. I'm not sure how the cDAQ system decides which task will use the "ai" timing engine, and which will use "te0", "te1", etc.  Thus I'm not confident that asking for the ".../ai/SampleClock" terminal explicitly by name is the right approach.

    In place of the subvi you have now, instead you should place a DAQmx Timing property node, and query for the SampleClock-->Terminal property.  Then it won't matter which timing engine that particular task happens to be using.

4. Make sure your "master" task is started *LAST*.  You did this correctly for the counter task, just expand the "Merge Errors" node so you can similarly sequence the other AI tasks to start before the master AI task.

5. Minor note: there's no harm but also no real benefit from the call to "reserve" the task I'm suggesting you use as master.   You could get rid of that.

To *UNDERSTAND*:

    On any NI DAQ devices I've worked with, Counter Input tasks (such as encoder measurement) can *NOT* use a regular Start Trigger.  They can only be triggered by something called an "Arm Start Trigger", which can only be configured with a DAQmx Trigger property node.  (FYI, counter output tasks *can* use a regular Start Trigger, in fact they be configured to use both kinds of trigger, a capability that I've actually seen a use for.)

   Your attempt to configure an encoder task to use a regular Start Trigger is definitely one possible source for the error you report.

I just reviewed earlier replies in the thread.  I'd encourage you to try the advice in the first reply from Cy_Rybicki (in msg #2) to configure all the AI channels into a single multidevice task.  You'll still need to manually sync the Encoder task by sharing a sample clock.  Your existing method with an explicit terminal name might work reliably then, or you can switch to the method I described for querying it.

If you can't do the multidevice task, then have a quick look at the link Cy pointed to in msg #4 -- it shows sync based *only* on a sample clock, no triggers, just as I was also suggesting.  (It also specifies the sample clock terminal name explicitly, which might not be ideal on your cDAQ system.)

   I honestly don't know why the other tutorial link *talks* about sample clock based sync but then shows code that also includes trigger config.  I think that's been steering lots of folks wrong, thinking the trigger is necessary in a lot of cases where it isn't.

-Kevin P

[FS12]

Hi Kevin,

Thanks for your help. I have few clarifications:

- Sample Clock: I got the sample clock channel from the  DAQmx Timing property node. Just as you instructed. I linked it with my encoder and that worked perfectly. (a note: my DAQ card and analog input which is located at the bottom share the same chassis). But when I share my clock with my other analog input and strain gage card, I stop getting data. These two cards are connected to NI 9191 and connected to my computer via WIFI. Is this the reason why I cannot share a clock? because its a different chassis and WIFI connected? 

-Why is my master task last? should be first to provide clocks to my other tasks? 

-multidevice task: I am not sure if I can use multidevice task because I have an encoder, ai, and strain measurements. 

So my question is: Can I not share clocks if my DAQ cards are on different chassis and some are WIFI connected? 

Is there a way around this? 

Is there a better way to store my data? what if I write each source in a different file and use time stamps to sync? 

Farid

[Kevin_Price]

Sorry, despite the subject of the thread, I completely lost track of the fact that you have more than one cDAQ chassis to synchronize.

The good news is that trigger-based sync would have been *insufficient* anyway and a shared sample clock is now *necessary*.  Fortunately, you've got a head start on this approach already.

The bad news is that you need some way to deliver the sample clock signal from the master chassis to any other chassis via physical wire.  And add the corresponding DAQmx config to make it all work.

The worse news is that neither your 9172 nor your 9191 chassis appear to offer any PFI connections for sharing timing signals (like clocks and triggers).  Unless your modules support this directly (and most analog modules probably don't), you're kinda stuck.

-Kevin P