From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Triggered output in a ''for'' loop

I want to syncronize my NI 6363 DAQ with another DAQ I have on my computer. I have a function generator to create a trigger but as I understand this trigger should not be shared to both DAQs but one DAQ should trigger the other to achieve optimal sync. I have created a code (top part of the picture) where I use my NI 6363 to generate an output everytime it is triggered. The output is used then as a trigger event for the second DAQ. I want to generate the output in a ''for'' loop so I have placed the start and stop VIs inside the "for" loop as it can been seen in the attached picture. One problem is that the output is created N times even if the trigger to the NI 6363 arrives only once. Another problem is speed, I think the communication takes too long and I want to speed things up. Using this code with a 256 "for loop" it takes about 500ms. If I remove the output generation it takes only 50ms. Is there a faster way? and if yes, what should I change to generate the output only when a trigger occurs?

I should probably mention that the second DAQ has an automated trigger out function which generates a trigger pulse when a trigger is received. So in theory I should be able to use this trigger out to trigger NI 6363. The issue is that the pulse width is below 20ns and ampltitude 3.5V, which should be too narrow for NI 6363. A colleague however suggested strecting this pulse to a few hundreds ns which should be sufficient for NI 6363. I was hoping to hear some thoughts on this solution too. 

labview code.png

0 Kudos
Message 1 of 6
(1,159 Views)

I have to keep this brief for now.

 

1. You could just trigger both devices from your function generator.

 

2. However, triggering *alone* will only sync the 2 devices at one instant in time.  After that, tolerances in their onboard clock will cause their notions of time to gradually drift apart, so they won't remain locked in sync over the long haul.

 

3. I frequently advocate the use of a shared sample clock signal as a better method for sync, especially with 2 or more devices.  This keeps them locked in sync.   (And quite often, no trigger will be needed at all.)

 

It isn't clear what your big picture is here, but from the code I can see in your pic, you aren't just one small step away from having it all wrapped up.  I foresee quite a bit of troubleshooting and debugging ahead due to a variety of sub-optimal constructs in the code (unwired errors, stacked sequences, little attention paid to wire "tidiness", etc.)

   Tell us more about the general aim of your program, what other DAQ hardware you intend to use, why sync is important, etc.  Give us a chance to understand what you're trying to accomplish, and we'll probably be able to give better specific advice.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 6
(1,116 Views)

The application is biomedical imaging. We use the NI DAQ to guide the scanning process over two axes (two output channels). Data are recorded using a fast DAQ from Gage (Cobra Max). Sampling frequency is at the order of 200MHz so it cannot be performed by our NI DAQ. So in order to reconstruct correctly the scanned sample we must sync the scanning process with the data acquisition.

Lastly I believe we need the the trigger because scanning and acquisition follow the frequency of our laser system. Our laser delivers a pulse which triggers an event we want to record. The purpose of triggering is to sync laser pulses with scanning and acquisition.

I appreciate your help and patience.


 

0 Kudos
Message 3 of 6
(1,107 Views)

It looks to me like you'll need to use Reference Clock based sync, something I personally have only ever rarely dabbled with.  That combined with each device reacting to the same trigger signal should result in the sync you need.

 

I found this rather detailed discussion of sync methods which I'm going to spend more time reading over myself!

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 6
(1,073 Views)

Thanks for the suggestion. I will study it carefully.

0 Kudos
Message 5 of 6
(1,070 Views)

I have been trying to implement the trigger plus clock solution. As far as I understand, I should insert a property node to specify the reference clock source and of course the trigger  source. The code I plan to use is showing in the picture below, any feedback would be appreciated.

One problem however that I came across when trying to connect evrything is impedance mathing. In the second picture you can see the 10MHz clock reference I will use for sync. The problem is that the waveform is distorted when connecting my NI6363 (through SCB-68A) as you can see in the third picture. The connection to the SCB-68A is terminated with a 50Ω impedance but I fear I did not connect it accurately, hence the distortion. I should also mention that the other DAQ which will be also connected to the reference clock has a 50Ω termination built in. So I should aim for 50Ω termination at the NI6363 end also.

 

clock.pngIMG_20210419_162323.jpgIMG_20210419_162256.jpg

0 Kudos
Message 6 of 6
(1,055 Views)