Acquire data from different devices (CAN, cDAQ, TCP/IP)

[User002]

Hey guys,

I have a very basic problem. 

I want to acquire multiple analog and digital inputs. The analog input should run at a rate of 100 Hz and 10 samples be read, resulting in a loop duration of 100ms. Therefore I have timed the digital inputs at a rate of 10 Hz with the AI Sample Clock as a source and read only one sample to have the same loop duration.

Now when I use simulated channels it works perfectly fine, but when I use the real world device (the NI cDAQ-9178 with the modules NI 9205 for the analog voltage inputs, the 9203 for analog current inputs, the 9217 for RTD inputs and 9422 for digital inputs) it only displays the analog values, not the digital values.

What haven't I taken in consideration?

Thanks in advance!

[User002]

Hi guys,

I have an application which needs to acquire data from different devices, such as a normal cDAQ for the sensor inputs, a CAN device for a external cooling pump and from a TCP/IP protocol of a high voltage power supply unit.

What is the best practice for this problem, if I want to acquire the data all at the same time and then send it via a queue and notifier to parallel loops to display it and log it so that all data is synchronized?
Should I just put all the acquiring functions in one loop or is there a better way to do this?

Thank you in advance!

[GerdW]

Hi phi,

---

@User002 wrote:

What is the best practice for this problem, if I want to acquire the data all at the same time and then send it via a queue and notifier to parallel loops to display it and log it so that all data is synchronized?

---

I recommend to handle each device/DAQmx task in its own loop (or even VI).

So you will have several loops, for AI, AO, DI, DO, CAN i/o, TCP i/o, and so on!

I also recommend to think about a proper program design before starting to implement all those loops…

[User002]

Thank you for your answer!

With this approach, how can i put together the data of all loops synchronized, because I want to put them into a queue and as far as I know one can‘t predict in which order the elements of different loops are put into the queue?!

[ZYOng]

Instead of trying to synchronize all loops (which are prone to the jitter from software timing), you should try to get all data points synchronized.

For your coding in the first post, you should use an error cluster or stack sequence structure to ensure that the slave task starts before the master task. Otherwise, the sample clock from the master task might reach the slave device before it is ready. Besides, you cannot set a different sample rate when using sample clock synchronization. The digital slave task must also use 100 Hz of the sampling rate. You can average the data returned from DAQmx Read VI.

To synchronize CAN with DAQ, see the shipping example <LabVIEW>\examples\nixnet\examples.llb\Synchronize C Series CAN with DAQmx Analog Input.vi

Unfortunately, TCP/IP is lacking hardware-timed sampling mechanism. It will always have a non-predictable latency. What are you trying to read using TCP/IP? Perhaps the third-party software or device can use sample clock and send data at precise intervals.

[User002]

With TCP/IP I'm trying to read the actual voltage and current from a high voltage power supply (EA PSI91500 3U, https://elektroautomatik.com/shop/de/produkte/programmierbare-dc-laborstromversorgungen/dc-laborstro...).

Would it be sufficient if i just put the read VI of this specific device into the same loop as the other read VIs?

[GerdW]

Hi phi,

---

@User002 wrote:

With TCP/IP I'm trying to read the actual voltage and current from a high voltage power supply (EA PSI91500 …

Would it be sufficient if i just put the read VI of this specific device into the same loop as the other read VIs?

---

Well, each additional function in your main loop will slow it down and may so enforce problems/errors for other device access running in parallel…

I keep my suggestion: handle each device/port in its own loop, independently from each other!

[ZYOng]

It does not seem like the EA-PSI91500 has an internal sample clock mechanism. You can only do polling with it.

The lowest latency can be achieved by using the sample clock to time the timed loop that does the polling with EA-PSI. However, this requires DAQ Devices with Hardware-Timed Single Point Sampling Mode Support and cDAQ does not support this.

In your case, if your acquisition rate is low (below 1000 Hz), you can place all three into a single while loop and read ONE sample per iteration. This should give you minimal latency between the three devices, probably at around 100ms.

However, if you need a higher streaming rate for logging, the best you can do is to use three separate loops for DAQ, CAN and EA-PSI, then synchronize the DAQ and CAN. The latency and timing accuracy of EA-PSI would have to be sacrificed. 

[ZYOng]

Seems like EA-PSI supports CAN communication as well. If you can integrate it into your CAN loop, it should simplify your coding. Its timing can benefit from the synchronization with DAQ as well.

If CAN is not possible, you should use RS-232 or USB instead of TCP/IP. Ethernet has the worst latency performance. RS-232 has the lowest latency but it would require you to use the onboard RS-232 port. If you are using a USB-232 adapter, you should just use the USB to communicate with EA-PSI directly.

Reference: Instrument Bus Performance – Making Sense of Competing Bus Technologies for Instrument Control

[User002]

With the approach of the three different loops, what would be the best practice to collect them all synchronized in a cluster for example so that I can send them with a queue to the logging VI ?