04-22-2024 05:59 AM
Hi all,
I'm thinking to buy a cDAQ ( cDAQ-9171 or similar but with more slots) that I will use together with some acquisition modules. I'm now thinking about synchronization and wondering if it is possible to synchronize everything to an external timing board (e.g. a SPECTRACOM TSync PCIe) that will go into my workstation. Is there the possibility to sync the chassis time with this timing board?
Thank you
04-22-2024 08:12 AM
cDAQ does not have its own controller and receives the timestamp information from the host PC when DAQmx API is called. The only usable timing signal from SPECTRACOM TSync PCIe that it can use is the 10MHz clock, which needs to be routed through a C Series digital module.
04-22-2024 08:30 AM
Thank you very much for your reply.
Could you please elaborate some more? I know that if you write a software that uses the TSync board, you can set a trigger that basically wakes up the application, and that you can also get precise time via GPS, IRIG and so on. If what I have understood is correct, with this chassis, I cannot use BNCs or similar, but I will have to make my software interact with the NI chassis, setting somehow the 10 MHz timing board clock. Am I understanding correctly?
In alternative, I came across to this link: https://www.ni.com/en/support/documentation/supplemental/21/signal-based-synchronization-of-analog-i... and apparently there are chassis with BNC that I suppose they can be connected to the TSync board. Am I wrong?
My idea is to have different cards (NI and other ones, both analog and digital inputs) connected to my workstation and synchronize everything using the timing board somehow.
04-22-2024 08:33 AM
I've also found this: "Parallel/Correlated Digital IO Modules could also be used to receive or send trigger and timing signals across the chassis. These Digital I/O modules are preferred when there isn’t sufficient BNC or SMB ports on the NI Compact DAQ Controllers and Chassis or the signal bandwidths exceeds that of the BNC or SMB connector (1MHz)." So did you mean that I can just use a digital module, and use one of its BNC connectors? but then the question is whether the other modules will also synchronize to it. I assume yes, upon correct configuration. Please correct me if I am wrong.
04-22-2024 06:59 PM
USB cDAQ does not support time-based synchronization (GPS, IRIG etc). It only supports signal-based synchronization. cDAQ-9178 has a built-in BNC connector that supports timing signals up to 1MHz. Since TSync board outputs 10MHz, you would need a module that can accept that high-speed signal. Note that not all NI digital module supports 10MHz.
As I have mentioned earlier, cDAQ does not have its own controller. The timestamp is provided by the host PC. If you connect that cDAQ to the desktop with TSync installed, it will have the same time, plus a few milliseconds of delay from the USB communication. If you want a shorter delay, get PCIe-based DAQ device.
TSN-enabled cDAQ (9185 and 9189) supports 802.1as (gPTP). TSync seems to support PTP, but you would need to check with the vendor if they support IEEE 1588 (PTP) or 802.1as (gPTP). You can configure TSN cDAQ to use IEEE 1588 (Does the NI-9185/9189 Support PTP/IEEE 1588v2?)
04-23-2024 02:47 AM - edited 04-23-2024 02:49 AM
How about using the cDAQ to generate sync or trigger pulses and use your PC timercard to time capture (timestamp) these pulses?
04-23-2024 09:00 AM
Thank you again for the great explanation.
you would need a module that can accept that high-speed signal.
So, if I have 4 different modules mounted in this chassis, the signal arrived that arrives to one of the module can be propagated to the other ones for synchronization purposes, right? in this case I will just need to find a module that supports the 10 MHz input. Regarding the timing board, yes, there is a 10Mhz output, but there are also 4 General Purpose Input/Output. The user guide says:
"The General I/O output can be programmed as a square wave synchronized to the 1PPS.
When used to output a square wave, the General I/O has a programmable period range of
100 nsec to 1sec (10 MHz to 1Hz) in 5nsec steps and a programmable pulse width of 10 nsec
to 999,999,990 nsec in 5nsec steps (polarity is programmable).
The General I/O output signals timing are accurate relative to the Input reference’s 1PPS signal
to within ±50 nsec. The General I/O output has a programmable offset, which ranges from
–500 msec to +500 msec in 5nsec steps."
Shouldn't this be enough?
If you connect that cDAQ to the desktop with TSync installed, it will have the same time, plus a few milliseconds of delay from the USB communication.
Do you mean that I can make the cDAQ sync "via software", using the TSync as "trigger" and taking into account the USB latency issues.
I believe that the few ms of delay would be too much. If I have understood correctly, with PCIe, this kind of syncrhonization would work better as the PCIe is faster than the USB. I've found somewhere in the NI website that USB cDAQ are better in terms of latency compared to the ethernet ones, but I am not totally sure about this.
TSN-enabled cDAQ (9185 and 9189) supports 802.1as (gPTP). TSync seems to support PTP, but you would need to check with the vendor if they support IEEE 1588 (PTP) or 802.1as (gPTP). You can configure TSN cDAQ to use IEEE 1588
Unfortunately I did not find anything about gPTP or PTP in the manual.
Thank you again.
04-23-2024 09:00 AM
Good idea in general. The fact is that I need everything syncronized with the GPS time (via the timing boar), as there will be other systems and we all must agree on the time, so I believe this option cannot fit my requirements. Thank you.
04-23-2024 07:04 PM
If TSync can generate 1MHz, you can use the chassis PFI port of cDAQ-9178. Most modules can access that signal as the master timebase. I mentioned most because DSA analog input modules use different timebase frequencies. That would be a separate discussion if you are using any DSA modules.
When it comes to synchronization, there are two signals to be shared, timebase and start trigger. Read Accuracy of the Waveform Timestamp Returned by NI-DAQmx for more details. You can share the same timebase by outputting 1MHz from TSync to cDAQ, ensuring that the dt is synchronized. And by using the same trigger, the entire acquisition is fully synchronized. t0 is susceptible to communication jitter, unfortunately, but it is for cosmetic purposes only and can be corrected through offline processing.
SPECTRACOM has a TSync PCIe variant that supports PTP (Model TSync-PCIe-PTP)
If you want to synchronize using GPS, there is NI-9467. Unfortunately, it is only supported in cRIO using FPGA mode. cRIO-9056 is the cheapest 8-slot cRIO chassis that supports both FPGA and DAQmx.
04-24-2024 03:49 AM
Thank you again for your reply. That sounds good, I think that chassis or a smaller one (cDAQ-9174) should be ok then.
About the modules, I was thinking about NI-9230, NI-9403 or similar ones.
t0 is susceptible to communication jitter, unfortunately, but it is for cosmetic purposes only and can be corrected through offline processing.
I do not think this will be an issue, thanks.
SPECTRACOM has a TSync PCIe variant that supports PTP (Model TSync-PCIe-PTP)
Thanks for letting me know. With the previous configuration I don't think it will be needed, but please correct me if I am wrong.
Thank you again for your reply. That sounds good, I think that chassis or a smaller one (cDAQ-9174) should be ok then.
About the modules, I was thinking about NI-9230, NI-9403 or similar ones.
t0 is susceptible to communication jitter, unfortunately, but it is for cosmetic purposes only and can be corrected through offline processing.
I do not think this will be an issue, thanks.
If you want to synchronize using GPS, there is NI-9467. Unfortunately, it is only supported in cRIO using FPGA mode. cRIO-9056 is the cheapest 8-slot cRIO chassis that supports both FPGA and DAQmx.
Using the previous configuration should provide same results, but this could be a good alternative (although more costly). In addition, I am not even sure if I can use the previous modules on this.
Thanks again.