A trigger from a trigger (PCI6351)?

[did.rider38]

Hello everyone,

I currently have a VI that generates two custom signals on two different digital lines from an external trigger. This external signal is shown in red on the diagram. It is fast, with a cycle of around 20kHz. Each time the red signal pulses, the two generated signals are emitted between two red pulses. They are not shown in order to simplify the diagram.
I now want to be able to start this trigger with knowledge of its start time. To do this, a second [5V;0V] signal is used. See the blue curve on the diagram.
But I don't see how to do this. How can I make the existing programme start only when the blue signal goes to 0V? Do I need to use another trigger, but how do I configure it?

I am attaching the lVI I use to generate the two output signals from the external source wired to PFI0 (red curve).

Best Regards

 

[santo_13]

It would definitely help if you drew the timing relationship between your input signal and output signal, skip the intermediate part unless required by the system, this allows anyone to review the requirement with an open mind.

[Kevin_Price]

If I understand you correctly, your app is one of the relatively rare ones that would benefit from defining both a regular Start Trigger and also a special trigger available only to counter tasks known as an "Arm Start Trigger".  (The Arm Start Trigger must be configured using a DAQmx Trigger property node.)

Both your tasks would continue to configure the 20 kHz red pulses as their regular start trigger.  But they would also need to configure the one-time "blue" (looks black to me though) signal as a falling edge Arm Start Trigger.  Until that signal "arms" the tasks, they won't respond to the red triggering pulses.  After that signals arms them just once, they can be retriggered indefinitely by the red pulses.

-Kevin P

[did.rider38]

that's right! 👍

[did.rider38]

Hi,

You will find attached the picture of my latest IV. It shows the part of the diagram displaying the signals and the trigger configuration. Currently, I obtain the behavior I want, but the time between the first trigger and the output signal trigger is 40 ms (see Picture 2). I think it should be possible to reduce this.

The difficulty is that I am using digital inputs and outputs instead of counter outputs, so I cannot use the Arm Trigger. Since I am using the digital input reader to trigger the black signal, I think this part is causing the delay.

This is my last solution, and I don’t have any other option.

[Kevin_Price]

---

@did.rider38 wrote:

This is my last solution, and I don’t have any other option.

---

There *could be* some other options if you're interested and able to pursue them.  Are you?  (Genuine question.  I understand that sometimes a time crunch dictates accepting "good enough" rather than pursuing something better.)

the time between the first trigger and the output signal trigger is 40 ms (see Picture 2). I think it should be possible to reduce this.

---

Seems likely to me, but I'm not entirely sure how to relate the 3 tasks in your latest screenshot to the descriptions you've given thus far.  The DO part I get, but it's unclear what role the DI and CI are meant to play.  And part of the DO is opaque with your call to a custom subvi for waveform generation.  From here it's just a black box whose behavior is unknowable.

-Kevin P

[did.rider38]

Yes, I’m definitely interested, and I’d be happy to hear any new options you might have. I’m open to exploring better possibilities if they’re available.

For answer any questions : I used DO to generate two customized waveforms — a green signal and a black signal. The green signal is a square wave, and the black signal is a sequence of 1 or 2 falling pulses of 5 µs (Dt1 and Dt2). They are triggered on each falling edge of the red signal in the image, connected to PFI0.

I used DO because I don’t know how to generate two falling pulses using a CO.

Additionally, the two generated signals need to be the same length so that they are triggered on the same edges. That’s why I used an array to create them and adjust their length.

But there may be a solution here that I’m not aware of…

I used DI to manage the sequence of triggers. The generation of the signals (green and black) does not occur as long as the start signal (blue) has not been read (using the read function). There may also be a better way to do this…

 

The CI period is another function used to determine the smallest period of the red trigger signal. The periods are displayed in a histogram, which shows the distribution of the trigger signal delays. This function is not needed for triggering. It is used to observe the distribution of the non-periodic red signal.

Did.Rider38

[Kevin_Price]

I'm going to need to ask some annoyingly detailed questions.  Can't help it, the details matter.

For the first output signal (green):

- at the instant that external (red) falling edge occurs, what state should the output be in?   High or Low?  It looks high on the sketch...

- how long a delay before the green signal should transition high-to-low?

- and then again how long a delay before it should transition back low-to-high?

- will *both* these delay times stay constant throughout one of your runs or do you need either one to change mid-stream?

- what if the total of those delays is longer than the period of the external (red) signal?   You'll end up missing a triggering opportunity, how bad is that?

For the second output signal (black):

- all the same questions as before, plus

- for a given run, do you always want to generate exactly 2 pulses per external (red) trigger?   Or else exactly 1 throughout a run?   Or do you need it to vary midstream?

- what are the additional timing values for the 2nd pulse -- i.e., how long from the 1st low-to-high until the 2nd high-to-low?  And then how much more delay until the 2nd low-to-high?

- and just to reemphasize, what if the total time needed for your 2 pulses is greater than the external (red) trigger period?

Your X-series device is capable of producing the red & black signals with counters rather than DO.  One advantage of counters is support for a hw-based Arm Start trigger to react instantly to the blue overall start signal.  Another advantage is improved timing resolution and relatively simplicity for defining time intervals.  

There *is* an approach that would let the red & black signals continue to be generated with DO, but it'd still involve an additional counter and its Arm Start trigger.   The way I see it, if you're gonna have to muck about with new counter stuff anyway, you may as well take the other approach where 2 independent counters are used to generate red & black.

Within the next day or so, I should be able to throw together a simple example showing how to make 1 counter generate 2 pulses for every falling edge of an external signal.  It'll also demonstrate use of the counter's Arm Start trigger.

-Kevin P

-Kevin P

[did.rider38]

Tanks !

For answers :

For the green signal: its idle state is at zero, and upon triggering, it goes to 5 V for a duration between 30 µs and 70 µs, then returns to its idle state. Then it waits for the next trigger.

Its configuration does not change while the program is running. If its length overlaps the trigger signal (red), it will have to trigger on the next one. However, the second generated signal (black) must also be triggered on the same edge. These two generated signals must be emitted at the same time.

For the black signal, it can take the form of one pulse or two inverted pulses $5V\to 0V\to 5V$ with the same duration of 5 µs. The number of pulses, 1 or 2, is determined before the program starts. They are generated from the same edge as the green signal, coming from the red signal.

The delay of the two pulses spans a very large time scale. Its limit is determined by the period measurement (CI period). The smallest measured period defines the measurement range. If the signal exceeds this limit, it will trigger on the next edge, together with the green signal.

For information, the green signal acts on a power supply, and the red signal acts on the measurement of 1 or 2 points.