Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Highlighted

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?

 

2I have tried two synchronization methods in the community,

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

based on timehttps://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?

 

3The 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?J8F9EZTG}AOECHDE@DOND06.png

 
 
0 Kudos
Message 1 of 5
(194 Views)
Highlighted

Multiple rates may be the issue.

 

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


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
LabVIEW Programming (make LV more popular, read this)

LabVIEW FPGA for High Throughput Applications | VI Week 2020
0 Kudos
Message 2 of 5
(184 Views)
Highlighted

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.

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 3 of 5
(157 Views)
Highlighted

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?

0 Kudos
Message 4 of 5
(141 Views)
Highlighted

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.

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 5 of 5
(116 Views)