Multifunction DAQ

Showing results for 
Search instead for 
Did you mean: 

Ethernet cDAQ 9184/9188 Continuous Data acquisition

Hi All,

I am researching on possibility of using Ethernet cDAQ 9184 or 9188 for one of our new product that requires continuous Data acquisition from our OEM devices (switches, indicators, sensors, etc.) through various c series modules simultaneously.



I have two questions here for the experts:

  1. What will be the time delay between when a driver function is called and the actual hardware I/O is updated (bus latency)?
  2. Is it possible to update (read/write) various c series module from different chassis (atleast 4 chassis in the network) simultaneously using one data packet from the PC ?

Any help would be greatly appreciated.



0 Kudos
Message 1 of 5

This article may answer part of your question, as it addresses the latency of some our devices.


As far as updating the cDAQ chassis, there is not a way to configure all of them with one single data packet.  However, if tight synchronization of a measurement is desired, there are other ways to do that.  Some of the various options include sharing triggers or clocks, or synchronizing measurments with timing & synch modules, or GPS receivers.  For long distance synchronization with tight tolerances, our PXI platforms support fiber optic synchronization.

Andrew H.
Systems Engineer
0 Kudos
Message 2 of 5

Hi Andrew,

Thanks for your response.


We have pretty much fixed on our requirement:

  1. Ethernet as a control bus
  2. Need to control 4 chassis from 1 PC through a switch with combined response time of 10ms or less (latency)
  3. Continuous measurement/acquisition

I would prefer Ethernet chassis IP address to be auto configured rather than manually assign, but that is not a prime requirement.


Would you suggest Ethernet cDAQ’s for multiple chassis configuration with latency of 10ms or less?  



0 Kudos
Message 3 of 5

Whereas a good, clean ethernet network can theoretically achieve the latency listed on that chart, there are often other factors in practice.


One of the chief factors is operating system latency.  You could see this kind of latency perhaps on a PC, but not in any sort of robust or deterministic way.  I would recommend looking at a real-time operating system for an application like this, and perhaps use something like the cRIO platform.


If you have decided on ethernet as your bus, 10ms could be a tight latency.  I would suggest calling one of our reps to discuss your options in more depth, where they can discuss more details of your application.

Andrew H.
Systems Engineer
0 Kudos
Message 4 of 5

Thanks Andrew...



0 Kudos
Message 5 of 5