This is more of a hardware question than a labview one. I am planning a set-up and I am uncertain that I can pull it off with my planned hardware.
I need the AO signals to be in phase with their respective AI Voltage line measurements so they simulate resistive loads or generation on said voltage lines. In the application I plan to modulate the amplitude of the signals which can be a positive or negative number (i.e. they can be in anti-phase with their voltage simulating generation). I was hoping to deploy the application in a host computer.
I was planning to use:
a) Time Sensitive Networking versions of the compactDAQ chasis (i.e. NI-9185 and NI-9189) and daisy chain them so the modules can be synchronised. It is only these two chassis and can be put on a dedicated network that is confined to small distances (<10m per node)
b) An additional voltage module NI-9205 that would also measure one of the voltage lines (trough a signal isolator) because this module can generate an Analog "comparison event" which I would set to the positive zero crossing of one of the line voltages.
c) The aforementioned comparison event as the DAQmx trigger to the AO signals in the NI-9264 module. All channels can go out in a single task, and I would take care of writing them in phase with their correct voltage via software. They would work in continous regeneration module.
It is not critical for the AO signals to be generated at the same time as the trigger, they can be a couple of cycles behind and refreshed only every few cycles. Which means that whenever the host decides to change the amplitude of the signal it can write it to the output buffer. Then the AO channels can repeat those signals until the host can process new ones. This is acceptable for my application.
Can this level of synchronisation can be done with compactDAQ and a host computer?
My budget allows for the extra AI Voltage module that generates the trigger and the Ethernet TSN versions of the chassis, but not a controller or another RT-target device.
It is not critical for the AO signals to be generated at the same time as the trigger, they can be a couple of cycles behind and refreshed only every few cycles.
This is the most crucial statement. It tells me that you aren't looking for real-time low-latency AO updates. Therefore, yes, I think you can get this done with a compact DAQ system.
Furthermore, I don't think TSN is necessary, and maybe not even particularly helpful. I would recommend signal-based synchronization rather than time-of-day-based sync anyway. The analog comparison event may or may not be important, I can't tell for sure yet.
- it's helpful if modules can share a chassis. If not possible, you'll need to run wires for sync signals.
- many chassis need a digital module to export or import their internal timing & sync signals. Some may expose one or two PFI signals right on the chassis.
- timing signals from your AI task should drive your AO task. Exporting the sample clock is probably the most straightforward method if you can run AI and AO at the same rate. You may also need to trigger AO off the analog comparison event, especially if it's important that you "observe" AI briefly before calculating *valid* values for the initial cycle of AO.
- your AO buffer should hold an exact integer # of cycles of your sine wave.
- latency from writing to the AO buffer until the new signals are generated as output signals will depend a bit on your AO device, the size of its onboard FIFO for AO, and a DAQmx property related to "data transfer request condition".
- the AO buffer you define assumes and *depends on* an exact 50 Hz input signal. Is it really exact and unchanging? If not, a more complicated approach might be needed. I'm not sure the more complicated methods that come to mind will be 100% reliable.