LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multi-Device Synchronized Analog Input to TDMS with Start/Ref. Trigger

Hello,

 

I'm developing a data-logging VI using multiple devices (4x PCI-6115 bridged by RTSI cable) where data is streamed to a TDMS file, and I had a question regarding synchronization and triggering. I've read through a bunch of whitepapers and examples, and was confused on the differences between various approaches to synchronization.

 

VI Objectives: In the VI, the user selects various channels of interest across various devices from which to log data. In "automatic mode" the VI should wait to receive a "prepare" signal from an external source. After the "prepare signal" is received, the VI should wait for a trigger signal at which point it logs data to a TDMS file until a reference trigger tells it to stop. In "manual" mode the user can "prepare" the machine with a boolean, then toggle another boolean to acquire data, then stop data logging with the same boolean.

 

  1. Since all 4 devices are the same, I figured I could create a multi-device task where all the channels in the task share the same sample clock ([link removed]). Is there a benefit to the multi-channel/multi-device single task implementation versus a master+slave implementation where individual tasks handle a single device (https://www.ni.com/en/support/documentation/supplemental/06/timing-and-synchronization-features-of-n... Figure 10)? 
  2. The VI is armed from another computer via PFI3. Is there a simple way to monitor this input for a signal? My current implementation creates a "CI Count Edges" task and waits to count 1 sample on ctr1, where PFI3 is supposed to be linked to CTR1 Source according to the pinout. 
  3. Secondary to that, I have the single multi-device/multi-channel task wired to a single start(rising) and reference(falling) trigger sourced from Dev1/PFI1 . Will this be sufficient to synchronously trigger all 4 devices? (I have not been able to test any of the remote triggering configuration for the VI yet).
  4. Lastly, this VI works in an alternate mode where the user can manually acquire data (state machine with a manual mode). On the computer that the VI was developed, there are 4 simulated PCI 6115 devices linked by a simulated RTSI cable. The manual mode works perfectly on the development computer and is capable of logging data [single task with multi-device/multi-channel impplementation] to a TDMS file (DAQmx Configure Logging(VI)). However, on the computer with the physical PCI-6115 cards, the manual mode is only able to acquire samples (AvailableSamplesPerChannel >> 0), but the TDMS file is empty besides header information. If I however, only select channels from one device, all the data is written properly. Any hints on this?

I can post screenshots/VI tomorrow and will follow-up to assist with any questions regarding my issue. Any help is appreciated!

0 Kudos
Message 1 of 7
(3,458 Views)

brehidran,

 

I think I have an idea of the scenario you are describing, but some code would probably allow me to get a better picture. A screenshot will suffice as well. I suspect you should be able to set up a pulse train using one of the devices onboard counters. You could choose when the pulse train signal begins generation, which would let you control when the devices begin acquisition.

 

Ryan

Ryan P.
CLA
0 Kudos
Message 2 of 7
(3,399 Views)

Hello,


Ryan, thanks for your response.

As I mentioned the multi-devices in single task approach works well on the simulated devices machine, but on the machine with physical cards it doesn't read from buffer when multiple devices are selected, only single device tasks.

 

daqMachine_1Device.pngSingle-device task (can be multi channel)

daqMachine_1Device.pngMulti-device task

  

 

 

The sequence goes from "prepare" to "acquire" for creating the virtual channels then acquiring data.

setup.png Virtual Channel and Task Creation

 

manualAcquire.png

Data Acquisition Loop

 

Note: In the code none of the automatic mode setups have been tested to work yet, I was trying to sort out the manual acquire mode first.

 

If the multi-devices on a single task approach works, I would like to use it for its simplicity. If I however, the recommended approach is to use a pulse train to synchronize the multiple devices, then that will suffice.

 

 

0 Kudos
Message 3 of 7
(3,389 Views)

brehidran,

 

Could you send the 'Date and Time to Path.vi' that you have in the 'prepare' state?

 

Thanks,

Ryan

Ryan P.
CLA
0 Kudos
Message 4 of 7
(3,359 Views)

Sorry, I've attached the file.

Thank you for your assistance.

0 Kudos
Message 5 of 7
(3,353 Views)

RyanP,

 

In further troubleshooting my system, I found that a loose RTSI cable connection was the culprit for the difference in operation between the simulated and physical devices computers. The manual acquire mode for the multi-device single task implementation works!

 

My question still remains, in that I'm curious how synchronizing multiple tasks via a master pulse train / clock would fair compared to the multi-device single task implementation.

 

Regards,

Brehidran

0 Kudos
Message 6 of 7
(3,351 Views)

Ryan-P,

 

So, I got to working on the auto-acquire state for the VI. I got the VI to accept a "prepare" trigger by using a "CI Cnt Edges" on CTR1 (in the current test config it watches PFI0 since I can't hook my function generator up to PFI3). Anyways when I turn on the function generator it counts an edge, sets the system to "prepare" mode and immediately bolts over to "autoStart" and begins logging data since the Start Trigger also watched PFI0 where the function generator is. Everything so far is great! (This is the attached version: HF_DAQ(noStop)).

 

My goal, however, would be to stop the data acquisition on the falling edge of the PFI0 trigger. I thought about using a ReferenceTrigger set to PFI0 falling edge + ReadPropertyNode with RelativeTo set to CurrentPos, but using the DAQmx TDMS Logging VI prohibits the use of a ReadPropertyNode. The problems I face are very similar to (http://forums.ni.com/t5/LabVIEW/DAQmx-TDMS-streaming/td-p/1334248), but I will be sampling ~10channels at 1 MS/s and wish to have the data streamed to disk and also be stopped from an external trigger. The data acquired during the VI's run is supposed to be synchronized to an external trigger. Would a triggerable pulse train implementation hooked to the AI-task's sample clock be advisable in this situation?

 

Thanks for your help!

 

 

 

0 Kudos
Message 7 of 7
(3,336 Views)