Multi-module cDAQ synchronised acquisition - I just can't work it out!

[Thoric]

DAQmx isn't my forte, so I'm struggling trying to get some DAQmx tasks working as I need them to.

I have a cDAQ device with 7 modules, nearly all different (a mix of digital and analogue input and output cards plus two bridge input moduels). I want to acquire from all input channels at 100Hz, and post to all output channels at the same rate. I need to read/write single samples, and react to these values in the software, so buffered acquisition is not an option, it must be point by point.

I can create my DAQmx channels, and I can acquire inputs and post to outputs, but the bridge modules absolutely require a clock setting, and when I try to introduce the clock function to achieve 100Hz I get very poor results. Often I can't loop my tasks at more than 10Hz!?

I've read a number of knowledgebase articles and getting nowhere fast. I can't work out if I should be using Continuous mode and simply calling the Read/Write functions in a while loop, or Finite mode and calling all three Start > Read/Write > Stop functions in the while loop. The first always ends up in an error of some form (buffer overrun or the like), and the latter ends up with terrible loop rate performance.

I even tried the included NI Example for Bridge Modules (Cont Acq Force Bridge Samples (with Calibration).vi), and when I asked for 100 Hz, the code fell over and produced the same errors that I'm getting 

The following is test code I wrote to investigate. It acquires from the first two bridge modules with one task, and also from an analogue input module with another task. It uses a virtualised cDAQ chassis so you can create one for yourself to test this code. I need them both to run at 100Hz (not necessary synchronised if that's not possible). If you cycle through the Disable Structure cases you can see all the permutations I have tried, and I've commented on the problems I encounter. Can anyone shed any light to what I'm not getting right please?

[Thoric]

I'm also seeing the NI Example "Cont Acq Force Bridge Samples (with Calibration).vi" fail using the default settings.

I'm using a virtualized cDAQ chassis with a virtual 9237 module in slot 1, setting the Physical Channel to "cDAQ1Mod1/ai0" on the front panel and running the example:

LabVIEW 2011 SP1

NI-DAQmx version 9.3.5

[Thoric]

I upgraded my DAQmx to the latest version (9.6.0), and still get the same error. Is this a problem with simulated hardware? I don't have access to the real hardware to eliminate this possibility.

[Kevin_Price]

A few brief comments in no particular order:

- I've seen that error with simulated devices before, but it hasn't been inevitable.  I could make it go away with a slower sample rate or by reading more samples more frequently or something.  It seems DAQmx tries to make an educated guess about whether to throw that error based on its knowledge of your task config (and perhaps also the hw in question?).

- As you see on the front panel of the example program, the cDAQ bridge module has a MINimum sample rate of > 1kHz.  I don't typically do much with cDAQ but I happened to run into this myself with the similar 9236 quarter-bridge module very recently.

- Not sure if you can run separate AI tasks with independent sample clocks.  It may depend on which cDAQ chassis you have or which modules support it.  I've only really dabbled with cDAQ and don't know all the ins and outs.

- Your calls to set the buffer size are ignored because with finite sampling tasks, the size is set once and for all with the call to DAQmx Timing.vi.   If you had configured a continuous task DAQmx would have overridden your buffer size of 2 with a default based on sample rate, but then your subsequent call to set the buffer size explicitly would have been honored (even if you set it back to 2).

- You should absolutely and definitely be running in continuous mode and simply performing Reads in the while loop.  Stopping, starting, and reconfiguring tasks is pretty slow and should be kept out of loops whenever possible.

- Even with a buffered task, you can choose to query for just 1 (or more) of the most recently acquired samples.  Have a look over here.

- I'd be a little concerned about possible bus latency when trying to do 100 Hz updates across the USB connection -- or do you have a chassis with LAN (if they even exist)?   Bulk transfers over USB seem to do pretty well, but I've seen/heard of latency problems with frequent single-point transfers.

-Kevin P

[GregFreeman]

---

@Thoric wrote:

I'm also seeing the NI Example "Cont Acq Force Bridge Samples (with Calibration).vi" fail using the default settings.

I'm using a virtualized cDAQ chassis with a virtual 9237 module in slot 1, setting the Physical Channel to "cDAQ1Mod1/ai0" on the front panel and running the example:

LabVIEW 2011 SP1

NI-DAQmx version 9.3.5

---

Interesting, I am running the VI with a simulated cDAQ9171 and a 9237 simulated in the first slot with the default settings and it is running fine.

[GregFreeman]

---

@for(imstuck) wrote:

---

@Thoric wrote:

I'm also seeing the NI Example "Cont Acq Force Bridge Samples (with Calibration).vi" fail using the default settings.

I'm using a virtualized cDAQ chassis with a virtual 9237 module in slot 1, setting the Physical Channel to "cDAQ1Mod1/ai0" on the front panel and running the example:

LabVIEW 2011 SP1

NI-DAQmx version 9.3.5

---

Interesting, I am running the VI with a simulated cDAQ9171 and a 9237 simulated in the first slot with the default settings and it is running fine.

---

More interesting, I replaced the while loop in the example with a timed loop just to grab the previous iterations timing and then I got the error. I'm *guessing* it's a simulation issue, but as a disclaimer I will say I'm not sure so you can't blame me when it still happens with the actual hardware!

[Thoric]

Quick update. Thanks everyone for the comments. The problem is with simulated h/w, it went away with real h/w. I lost a lot of sleep over this, but it's gone now that I'm on the real cDAQ. Shame the simulation code has an issue here though...

[GregFreeman]

---

@Thoric wrote:
Quick update. Thanks everyone for the comments. The problem is with simulated h/w, it went away with real h/w. I lost a lot of sleep over this, but it's gone now that I'm on the real cDAQ. Shame the simulation code has an issue here though...

---

To be honest, I had no idea simulated DAQ would even throw errors. One of those "great-in-theory but....." ideas. Sounds like this "feature" is not very accurate.