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.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx Trigger

Solved!
Go to solution

Hi,

 

We have a PCI6731/Two-dimensional galvo (GSV002) and a High speed acquisition card. We want to synchronize the galvo with the high speed data acquisition card. 

At present, our idea is to keep the high-speed acquisition card and galvo in a waiting for trigger state, and then use the laser pulse (5kHz) to trigger the Stanford Research DG645 Signal Generator. Changing the triggering voltage of DG645 to realize the simultaneous triggering of the high speed acquisition card and galvo.

However, the problem is that when programming the galvo with PCI6731 DAQmx, the start trigger.vi cannot wait for the external trigger (DG645) all the time. As a result, the galvo running program is not triggered after we change the trigger level.

How can we solve this problem? Or Is there any other synchronized method to realize this objective? Thanks !!!

 

Best regards.

 

 

0 Kudos
Message 1 of 9
(1,962 Views)

You've give a pretty good amount of detail, but still not enough.

 

1. What's your high speed data acq device?  Is it an NI device inside the same PC?  If so, do you have a RTSI cable to connect it to the 6731?

 

2. NI and DAQmx make a clear distinction between the terms "trigger" and "sample clock".   Many forum users don't, probably because neither do many other data acq devices and instruments.

    So it's really important to be careful and clear with the terms used for these signals so we can be sure we're talking about the same thing.  Under DAQmx, a trigger is a once-per-capture signal marking a single point time, most often the start of acquisition.  A sample clock happens repeatedly within a capture to cause samples to be acquired and accumulated.

 

3. How do the 5 kHz laser pulse and the Stanford Research signal generator work together?  Does the S.R. instrument have a known waveform stored such that each laser pulse advances to the next sample of that waveform?   If so, this behavior would correspond to what DAQmx calls an external sample clock.   Your 6731 could do the same thing (though probably with less precision and resolution) if it were configured to use the 5 kHz laser pulse as an external sample clock.  (Just trying to help make terms and capabilities clear, I *do* understand that this isn't the role you want the 6731 to play.)

 

4. It further sounds to me like you want to *re-trigger* your 6731 galvo control at a 5 kHz rate.   That isn't going to be possible, not directly.   The 6731 is an older device that doesn't support retriggerable AO tasks.  You have to stop and restart a task to arm it for the next trigger and you won't be able to do that at 5 kHz.

    There are *indirect* ways to accomplish retriggering using a counter task that *can* be configured to be retriggerable in hardware.

    Please describe a bit more about your galvo control timing needs compared to the 5 kHz laser pulse, and what role is played by the Stanford Research output.   It sounds like you might want the SR to define different trigger levels to be used by the 6731 galvo control task.   That's not going to be possible, not even with the counter workaround.       

    Trigger levels imply analog triggering which I don't think the 6731 supports.  Even if you had an AO device that supported retriggering, the triggering level couldn't be changed without stopping, reconfiguring, and restarting the task.  And you won't be able to do that at 5 kHz.   At best you'd probably be in the 100's of Hz.

    The retriggering workaround with counters couldn't work either b/c counters only support digital triggering.

 

There's a good chance I've made some wrong guesses about what you're aiming for.  For your sake I hope so b/c I don't think you're going to be able to do what I *think* you want.

 

 

-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 9
(1,934 Views)

Hi,

 

Thank for your prompt reply! I will add more details based on your question.

 

1. The model of high speed data acq is spectrum M4i-2223x8.  All of these devices are in the same PC. The 6731 is connected with SCB-68 which connected to my galvo.

 

2. The DG645 has a channel named external trigger, it is connected with laser generation. And the scb68 and M4i-2223x8 are connected with channel A of DG645.

 

3. The DG645 is receiving the 5KHz trigger signal from the laser generation, and  outputs the pulse wave with the desired low voltage level in channel A. that is to say, it is not trigger my M4i-2223x8 and galvo. When M4i-2223x8 and galvo are in waiting for triggering state, I will increase the output level of DG645 by Labview to ensure that M4i-2223x8 and galvo can be triggered. The working mode of DG645 is not to receive a trigger and send a pulse signal, but to continuously output pulses after receiving the trigger. Even if DG645 or external sample clock in 6731 can output a pulse signal with one trigger, the galvo program needs to be in a state of waiting for the trigger until next trigger come.

0 Kudos
Message 3 of 9
(1,879 Views)
Solution
Accepted by qlin003

Sorry, still not any clearer to me.

 

My knowledge is limited to NI's 6731.  Digital pulses routed into the device can be used in different ways:

 

1. as a one-time direct start trigger for an AO task.  Repeated acquisitions would require you to stop and restart the task in software, during which time you might miss a triggering signal.

 

2. as a sample clock.  Each digital pulse would cause the task to generate the next sample in its buffer.

 

3. as a repeating start trigger for a retriggerable counter output task.  The counter output pulses can then be used as the AO sample clock.  This is the *indirect* method to accomplish retriggering in hardware with your device.

 

I'm not knowledgeable about your other equipment to comment on capabilities and don't really follow the details about how you intend them all to interact.

 

 

-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 9
(1,865 Views)

Hi Kevin,

 

Thank you for your help!

 

I think the first point you mentioned is the way my current program to synchronize. Actually, my current program miss a lot of triggering signals, which is why I wanted 6731 to wait for my trigger signal. I also tried repeatedly starting and stopping tasks (while/for loop) to detect triggers, but I think not each of triggering signal are responded.

 

The third point you mentioned give me some ideas. But I do not understand clearly. Here are some of my understandings. 

 

I need to create a retriggerable counter task with external trigger as its starting trigger input. The output of the retriggerable counter as the input of the sampling clock for my signal generation. If possible, please give me more details about this and point out my mistakes

 

Qibo

 

0 Kudos
Message 5 of 9
(1,854 Views)
Solution
Accepted by qlin003

Sounds like you understand.  Attached are the files from a very old (but still valid) example that shows how to do it in LabVIEW.   They were from LabVIEW 7 so I brought them forward to LV 2016.  Here's the original article.

 

 

-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).
Download All
0 Kudos
Message 6 of 9
(1,831 Views)

 

Thanks for your help!

 

Qibo

0 Kudos
Message 7 of 9
(1,829 Views)

Hi,Kevin

 

We want to  use the PCI6731 to output two analog voltage signals to control the X-axis and Y-axis of the 2D-Galvo respectively. 

 

The objective is: the physical channels of the two analog outputs need to perform two different tasks, one is the finite samples output (task 1), and the other is the continuous samples output (task 2). The task 2 is execute first and then the digital trigger PFI0 triggers the task 1 to work. The picture of program and .vi file are uploaded.

 

When I run this program, an error-89137 occurs. I guess the error caused by incorrect use the two sampling clocks, but I do not know how to solve it. Would you like to give some help for me?  Thanks so much!

 

Best regards,

Qibo

0 Kudos
Message 8 of 9
(1,562 Views)

I've never run a galvo but have been involved in numerous threads about them around here.

 

Typically, one must create 1 single task containing data for both the X and Y AO channels.  (Any NI DAQ device I'm aware of has only 1 available timing engine for AO so you can't run 2 distinct hardware-clocked AO tasks at the same time.)

 

Your situation seems just a little different though.  One channel slowly steps its voltage down by -0.1V per "activation".  But the other channel seemingly wants to be triggered at an unknown time by some external signal at PFI0.   Then it will do one complete finite acquisition output of a triangle wave.

 

Try making the slow channel with the -0.1V decrement be software-timed by removing the call to DAQmx Timing.  You should then also: start the task before your loop and remove the query for "Is Task Done" inside the loop.  You can just use dataflow to make sure you don't start the other task until after you've written a new offset value.

    I know at least some NI DAQ boards support 1 or more software-timed AO tasks simultaneous with no more than 1 hardware-timed AO task.  Not sure about the 6733 but give it a try.

 

 

-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 9 of 9
(1,555 Views)