Consultation about multi-chassis and multi-module synchronization with cRIO 9048 in DAQmx mode

[tony.wu]

I am developing a set of vibration acquisition system，which consists of two cRIO 9048. cRIO A with 4 NI9234, 1 NI9401, 1 ni9205, 1 ni9208, 1 ni9469；cRIO B with 7 NI9234 and 1 ni9469.The development environment and drivers are both version 2020

Multi-channel and multi-sampling rate custom configuration is one of the key development requirements,which is difficult to develop base FPGA mode. so I chose DAQmx mode.However, I have encountered some synchronization problems that are difficult to solve.

1、I tried to configure NI9469 in MAX, but it only prompted that no connection was found. I can make sure that the driver and wiring are correct. I have seen in NI-DAQmx 20 manual- C series multi-device task (https://www.ni.com/documentation/en/nidaqmx/latest/devconsid/cdaqmultidevice/) “The number of CompactRIO controllers participating in a multi-chassis device task cannot exceed one.”? Is this the answer?

2、I have tried two synchronization methods in the community,

based on signal：http://www.ni.com/tutorial/5376/en/#toc4 ；

based on time：https://www.ni.com/tutorial/55200/en/#toc6,

but signal-based synchronization will always report an error, time-based synchronization can work, but  must wait a few seconds after the task is executed, otherwise an error will occur，why？

3、The following is a set of acquisition results in a non-synchronized state. The difference between different modules far exceeds the filter delay. What is the problem?

[Terry_ALE]

Multiple rates may be the issue.

Could you acquire everything at the same rate and then reduce on the controller? 

[James_McN]

Hi,

I don't have a full answer for you but a bit of information about the start time.

The start time is added by the driver rather than at the hardware level. The differences between different tasks will be due to software timing variations when when DAQmx puts a start time on it. Between chassis will also contain any difference in system clocks.

As Terry says multiple rates will also have a factor in this.

For time-based the reason for the delay is that you need the timestamps on each controller to sync and enough time for the task to start and the start time to still be in the future on both chassis.

I've not tried the 9469 before so I can't talk to that - I would have expected it to be supported but I'm not sure.

With something like this I would generally start by trying to get the 9234's to synchronise across the chassis. Once you have that you make the other modules a slave to the 9234's since their timing is more complicated. Ideally, as Terry says, acquire everything at the same rate for simplicity.

[tony.wu]

Thank you for your prompt and detailed reply.

1、I have placed the daqmx startup task in the same sequence frame. Is there a difference of tens to hundreds of milliseconds in the parallel execution of daqmx software?

2、Maintaining a consistent sampling rate will indeed greatly simplify the development difficulty, and different sampling rates can also be obtained through downsampling. But this will cause another problem: Setting up an anti-aliasing filter that varies with the sampling rate is needed, self-developed anti-aliasing filter will be considered unreliable.

In addition, these two synchronization method include application scenarios of multiple devices and multiple sampling rates, which should work，right？

[James_McN]

Hi Tony,

---

@tony.wu wrote:

Thank you for your prompt and detailed reply.

1、I have placed the daqmx startup task in the same sequence frame. Is there a difference of tens to hundreds of milliseconds in the parallel execution of daqmx software?

---

I believe (but am not certain) that the first start timestamp is applied when it is read from the card to the PC which may account for more variation. In short though, this will never offer any good degree of synchronisation.

---

@tony.wu wrote:

2、Maintaining a consistent sampling rate will indeed greatly simplify the development difficulty, and different sampling rates can also be obtained through downsampling. But this will cause another problem: Setting up an anti-aliasing filter that varies with the sampling rate is needed, self-developed anti-aliasing filter will be considered unreliable.

In addition, these two synchronization method include application scenarios of multiple devices and multiple sampling rates, which should work，right？

---

I think there is existing functions for downsampling with an anti-aliasing filter which would be reliable. But yes I believe this is possible with these synchronisation methods to have multiple tasks synchronised. Starting with one though will make life easier.

So if the time delay isn't an option then you should be looking at the signal approaches. The 9469 seems to be supported on compactRIO as it is shown in https://www.ni.com/en-gb/support/documentation/compatibility/09/software-support-for-compactrio--com... so troubleshooting that is probably the first step.