Retriggerable pulse generation with matlab

[gujax23]

Kevin

I shall give your suggestion a shot at soon.

However, I am a bit curious. Why does clock not matter? I have an external clock but looks like trigger - especially retrigger will make clock not matter?

Thanks

[Kevin_Price · Accepted solution]

Well, I'm still not 100% sure I've identified exactly what you need to do.

One common point of confusion in general is that DAQmx makes very specific functional distinctions between clocks and triggers, whereas those terms seem to get used more loosely and sometimes interchangeably out in the wider world.

In DAQmx a sample clock initiates the capture or generation of a sample.  For a single task run, there will generally be many sample clock pulses -- an indefinite number in the case of Continuous Sampling.

    Also under DAQmx, a trigger is a one-time event per task run.  Most typically it initiates the task to start.  The task will only start in response to the first trigger pulse it sees.  Subsequent pulses arriving while the task runs will be ignored.

I *think* you have a case that's kinda in-between.  The "task", such as it is, involves generating a single pulse in response to a trigger.  DAQmx Timing is set to be Implicit because the timing associated with the pulse is *implied* by the timing parameters that define the pulse.

    So far, we're on board with my earlier general description.  One trigger produces one task run.  But since the task will complete before the *next* trigger pulse arrives, AND you've configured the pulse task to be retriggerable, you'll get a continuous-looking behavior.  The rules are still being followed, but until you break it down into its subtler details, it may look more like a clocking situation than a triggering one.

A timing diagram and description of the desired behavior would still be helpful.  You may want something different than I've been thinking so far.

-Kevin P

[gujax23]

Kevin's solution was a bingo!

However, I am really puzzled. My vi fails. The only difference being I have a sample clock defined. I am posting again my vi which is slightly edited version of the one I replied to Santosh.

So if I run 6218, I do not have initial delay true or false condition because I force it to be false. And then I have the timing module which as I argued before is perhaps not needed because trigger is doing all the job (being a re-triggerable event)

Which is why I was forced to use implicit timing because otherwise my vi does not even run.

However, with my vi, the trigger signal and counter signal run wild relative to each other and approximately synchronize under very special values for pulse width. Beats me!

I could post a video but I hope I am clear:

counter moves w.r.t trigger in my example

In Kevin's both are rock steady fixed relative to each other

Can someone please explain what is going on? My suspicion is that by incorporating a timing module I am forcing the re-triggerable event to be w.r.t internal clock. When i try to set an external clock it throws an error.

[Kevin_Price]

I can't open your posted code.  Please use the menu "File->Save for Previous Version..." back to LV 2018 or so and I can very likely explain what the problem is.

But in very general terms, it's important to realize that several things about Counters are "just different" in comparison to AI, AO, DI, DO.  All those other I/O types are inherently about signal levels where clocks are used to define the timing for capturing or generating them.  Counters are inherently about capturing or generating digital *changes* and have an "implicit" internal ability to detect or control the timing between them.

The distinction can be a little subtle, but nonetheless pretty important.

-Kevin P

[gujax23]

I decided to instead put a picture of my vi. And also saved it as 2018 version.

Hope this picture or the new uploaded file works for you.

Thanks

[Kevin_Price · Accepted solution]

It's kinda subtle and not particularly obvious, but...

Declaring a *continuous sampling* task implies that you want to produce your own never-ending stream of pulses in reaction to just one triggering pulse.  Once that single trigger arrives, your pulses run on their own according to your initial timing parameters.  If they don't happen to match the timing for the incoming pulses (and they almost certainly *won't* match exactly), you won't *stay* in sync.

My method never calls DAQmx Timing and therefore generates only 1 pulse per input trigger.  Making it "retriggerable" is the thing that makes it keep generating pulses.  It pulses once per trigger, so as long as the triggering pulses keep coming, you'll keep generating additional output pulses.

-Kevin P