How to filter starttrigger on counter output precisely

[jonster]

HW PCI6602
Measurement studio 2008 (C#)NI-DAQmx 9.02I’m trying to trig a camera using the output from a counter.
The camera should be trigged when the counter input pulse width is larger than approx (filterPulseWidth 10us).To do this a have set up the following tasktask.COChannels.CreatePulseChannelTime(counter,                "TriggerTaskChannel", COPulseTimeUnits.Seconds, COPulseIdleState.Low, 0, 80E-6, 0.007);             task.Triggers.StartTrigger.Type = StartTriggerType.DigitalEdge;            task.Triggers.StartTrigger.DigitalEdge.Edge = DigitalEdgeStartTriggerEdge.Rising;             task.Triggers.StartTrigger.Retriggerable = true;task.Triggers.StartTrigger.DigitalEdge.DigitalFilterMinimumPulseWidth = filterPulseWidth;            task.Triggers.StartTrigger.DigitalEdge.DigitalFilterEnable = true;Unfortunatly this filter has the following behaviour”If the period of the filter clock timebase is tfltrclk, this filter guarantees topass pulse widths that are 2*tfltrclk or longer and to block pulse widths thatare tfltrclk or shorter. A pulse with a width between these two ranges may ormay not pass, depending on the phase of the pulse with respect to the filterclock timebase”.It means that I have no sharp distinction on my filter as one would when applying a filter to an ordinary pulse width measuring task. Implementing this with via the software in a callback is to slow.The bottom line is that I would like to generate a pulse on my counter output when the trigger/counter input is greater than say 10us. The output pulse could be predetermind as in the sample code above or as long as the filtered input (I.e counter just pass filtered input to my output).How can this be done? BR
Jongas

[Kevin_Price]

I just deleted a few "thinking out loud" ideas that didn't seem to quite fit.  Let me ask a couple brief clarifying questions in case I'm overly constraining myself.

It sounds like you want to ignore incoming pulses whose widths are less than, say, 10 microsec.  What should happen in the following scenarios:

A.  The incoming pulse train consistently has a high time of 3 microsec and a low time of 9 microsec.  Its period is 12 microsec, but its "width" is only 3.  React to it or ignore it?

B.  The incoming pulse train has both a high and low time of 15 microsec.  Clearly you will want to react to each pulse.  Do you want to react on the leading edge or on the trailing edge?   Note: if reacting to the leading edge, you won't yet know the next incoming pulse width though you will know the most recent pulse period.  If reacting to the trailing edge, you will know both the incoming pulse width and the most recent pulse period.

C. Is the width (high time) of the output pulses you generate important or only the timing of their leading edges?

-Kevin P

[jonster]

The incomming pulse train is generated by a sensor measuring a distance. The sensor pulse freq is 50kHz (so the period will be constant) and the low part of the pulse is proportional to the measured distance. Now I want to trig my camera when the distance is less than a certain distance = the pulse high width is greater than a certain value, f.ex 10us.

Regarding the scenarios.

A. Ignore since high time is to short

B. React on the trailing edge is the way to do it and the way I intended to implement it in my previous code.

I should also mention that once I've trigged the camera my sequence diagram starts all over -> as soon as I detect a pulse width (high time) greater than 10us consequent pulses are ignored until I restart the task.

C The pulse width of the outgoing pulse is not that important as long as the camera will detect it. As mentioned in B the task is not restarted until I've trigged the camea and done some I/O irrelevant processing

BR

Jongas

[John_P1 · Accepted solution]

Hi Jongas,

Is it OK if the trigger is sent once the pulse hits 10 us, rather than on the exact falling edge?  I'll assume the exact timing isn't as important, but you would like the trigger to occur very close to the falling edge (within a couple of us).  The important thing is that we trigger as close as possible to when the PWM has hit 50% duty cycle.

Some brainstorming:

Digital Filtering on the 660x Isn't the Best for This:

Digital filtering might not be as practical here on your 6602 due to the region of uncertainty between 5 and 10 (or 10 and 20) us pulses.  The TIO boards count two consecutive edges of a filter clock to determine when to pass a signal through so the guaranteed rejected pulse width is always half of your guaranteed passed pulse width (providing an external filter clock timebase that is synchronized with your external signal could potentially reduce this uncertainty but I honestly haven't tried this before and I would imagine it is not going to be very straightforward).

X Series Alternative:

Our X Series devices use a different method of digital filtering that would work better for you.  If a hardware change is an option (and you can use PCIe) then you might consider this.  You could use the 20 MHz timebase as your filter clock timebase and could guarantee to pass 10 us (200/20M) and reject 9.95 us (201/20M).  The 6320 is currently our lowest cost X Series board.  A couple of points about this solution:

1.  To configure the PFI filter, you need to use some sort of dummy task to access the property nodes.  Here is an example of this (although it is written in LabVIEW).

2.  You can route the filtered PFI signal to be exported on another PFI line, but this will reserve Counter 3.  This is documented in the Device Routes tab of Measurement and Automation Explorer.

3.  The filtered output will be 9.95-10 us delayed from the input signal, so you could trigger the camera off of the rising edge of the filtered output directly and be fairly close to the actual falling edge.

External AND Gate Alternative:

You could configure a Counter Output to generate a re-triggerable pulse with a 10 us initial delay (to be triggered off of the rising edge of your PWM signal).  Assuming the pulse is short enough to complete before the next period of your PWM signal, the counter output would only be high at the same time as the PWM signal if the signal was longer than 10 us.  Use the external AND gate to combine these two signals and the result would be the trigger for your camera (the rising edge would correspond to 10 us after the PWM signal first goes high).

If you wanted to you could make the counter output pulse a little longer (say 8 us) and trigger the camera off of the falling edge out of the AND gate (a.k.a. rising edge out of a NAND gate) which would line up with the exact falling edge of the PWM signal.  Don't make the CO pulse too long or it will overlap with the next period of the PWM.

Another Idea:

One idea that I keep coming back to is to use the internal rollover event of a counter input task (a pulse is generated whenever a counter rolls over on its Internal Output which can be routed to a PFI line).  I don't think this will work, but the idea in theory would be to:

1.  Set Default state to known value (e.g. 2^32-200).

2.  Gate the Counter so it only counts during the time PWM is high.  Have it count the 20 MHz timebase.

3.  Reset the Counter to default state on the falling edge of the PWM signal.

4.  The counter would rollover if 200 pulses occurred of the 20 MHz timebase (10 us), and the Counter Output could be routed to a PFI line to trigger the camera.

The problem is that there is no good way to reset the counter except for an encoder measurement (Kevin has already made a nice suggestion about this).  A Pulse Width Measurement would technically reset the counter, but you cannot currently set the default value of a Pulse Width Measurement task so there is no way to make the rollover happen prematurely).

Configuring an encoder measurement and working with the multiple counters on the 6602 to produce appropriate A,B, and Z signals might be a method to look into further, but at this point I think you'd be better off with an external AND gate.

I don't want to say it's impossible with just the 6602, but I can't think of a straightforward way to go about it without external hardware (although maybe I can sleep on it and think of something later... how many counters do you have to work with?). 

With your current NI Hardware, I think your best bet is to go with an external AND gate.  If you're planning on purchasing an X Series card the digital filtering idea is actually not a bad way to go.

I hope this is helpful!

Best Regards,

[Kevin_Price]

You got some great suggestions from John, and I'd agree that the external AND gate would probably be the easiest thing to do with your existing 6602.

However, extending some of John's thoughts, I *think* I've got a way to do it with just the 6602.  It's fairly convoluted and complicated, and not especially practical.  Nevertheless it was a nice little challenge that I happened to have some time to think about.  Just be aware that it's a thought experiment I haven't tested.

Concept Overview:  You may need to use as many as 4 counters working together on this.  2 of them are pretty simple and will produce retriggerable single pulses.  One of them triggers off the trailing (falling?) edge of your external signal.  Let's just say that'll be CTR0.  The other will be used to trigger your camera, and let's just say that'll be CTR1.  (Note: if your camera can react to really *really* short pulses, you may not need CTR1)    CTR2 will generate a high speed clock but will be gated (pause-triggered) by your external signal.   The final counter CTR3 will be configured as though it's doing encoder position measurement according to details below.

CTR2, the discontinuous timebase:  Configure it to generate, say, a 10 MHz pulse train which is gated by your external signal.  You do this by using a "digital pause trigger."  So it will generate a 10 MHz clock *only* whenever your external signal is high.

CTR0, pulse on falling edge:  Configure this to be a retriggerable single pulse generator.  Trigger off the falling edge of the external signal.  Set your high time to be about 1 period of CTR2.  So if CTR2 is 10 MHz, one period is 0.1 microsec and you should set a high time of about 0.10 microsec.  Set your low time and initial delay to be as short as possible, namely 0.025 microsec.   This brief pulse will act as a Z-index reset signal for CTR3.

CTR3, pseudo-encoder used for output:  Ok, hang on because now it gets interesting.  You need to configure this for position measurement using the "Two Pulse Encoder" designation.  In this mode, the counter increments on active edges of its A input and decrements on active edges of its B input.  You need to hard-wire the output from CTR2 to the B input and I would recommend hard-wiring the A input to ground.   Now you've got a counter that will decrement at 10 MHz but only while your external signal is high.

   Next you need to configure this counter to have an initial value of 100 (or possibly 99 to avoid an off-by-one issue), and also configure the Z-index reload settings to reload that same initial value on Z-index, and to do it when A and B are both low.  You further need to configure the task to make the counter's output generate a pulse on terminal count.  So whenever the count changes to 0, a very brief pulse will be generated on the counters output terminal.  If I recall correctly, it will be 0.05 microsec long and there's no way to program it otherwise.

CTR1, pulse extender:  If the extremely short terminal count pulse from CTR3 isn't long enough to trigger your camera, CTR can be generate retriggerable single pulses of whatever duration you need.  Trigger off the CTR3 output with minimal initial delay and low times.

How It Works:  CTR3 starts with a value of 100.  It will decrement at 10 MHz whenever your incoming signal is high.  If your incoming signal has a width of, say, 8 microsec, then CTR3 will have a value of 20 at the end of the incoming pulse.  The falling edge of that signal triggers a 0.10 microsec pulse from CTR0 which is wired to CTR3's z-index input.  While the Z-index input is high, both the A & B inputs will also be high, causing CTR3 to reset its value back to the Z-index reload value of 100.  CTR2 is not generating output while your external signal is low, so CTR3 just sits there with the value 100 until the next pulse from your external signal.

   Now let's suppose you get a 12 microsec wide incoming signal.  At the 10th microsec, CTR3 will decrement through its terminal count of 0 which will cause its output to pulse high for 0.05 microsec.  This will in turn trigger a longer more useful pulse from CTR1 that will trigger your camera.  At the 12th microsec, CTR3 will have decremented to (essentially) -20, at which point the falling edge will again trigger a z-index reload of the value 100 so it can be ready all over again.

Final thought (the 5th counter):  This assumes that CTR2 can be counted on to have a digital low output value while the low external signal causes it to stop generating its pulses.  IF this turns out not to be the case, there is probably still a workaround with CTR4.  You would then make CTR4 also be a retriggerable single pulse generator, triggered by rising edges of CTR2.  And you would feed CTR3's encoder A input from CTR4's output rather than from CTR2's output.  CTR4's pulse time parameters should all be minimal.

-Kevin P

[John_P1]

That seems like it will work--good idea on the Two Pulse Encoder task type.  Even though it sounds like it should be relatively simple, this was actually one of the more intricate counter applications I've seen lately.  I think this at least gives the original poster an alternative option if he does not want to use the AND gate idea, assuming he has enough unused counters available.

On a somewhat related note, we have decided to try to implement the suggestion for HW-Triggered Counter Reset for X Series devices, so this will be a bit easier once/if this feature is available when using an X Series device.  It's looking like the reset would use the gate of the counter so we would still need to use a 2nd counter to generate a gated "timebase" based on the input PWM signal.  With the Reset available the configuration would look like this:

1.  Continuous CO task at 25 MHz

-Use Pause Trigger to stop the pulse train when the external PWM is low.

2.  Edge Count Task

-Source of Edges is the internal output of the other counter

-HW Reset on Falling Edge of PWM Signal.  Value to reset to is to 249 ticks.

-Initial Count set to 249, direction to count is Down

-Export the CO Event, which will occur after 250 ticks of the 25 MHz timebase (10 us).

Again, the above would only be possible on X Series boards once the HW Reset has been implemented in the driver (although if on an X Series card you could currently use the digital filtering idea mentioned earlier).  No timeframe yet on when the HW Reset might be included.

Best Regards,

[jonster]

Kevin, JohnI really appreciate your help on this issue. I honestly thought this was a common functionality that I just couldn’t find the appropriate task for.Unfortunately I’ve booked almost all counters for other tasks (2x6602 = 16counters) so the multi counter option is not an option in my case. 

The need for 16 counters also disqualifies the X series (only 2 PCI slots).

As you have stated it is not necessary to wait for the falling edge, if the high time has been longer than 10us it is time to fire the trig. I will try out the AND gate solution and take it from there.

Once again, I really appreciate the help. If any other options pops up, please let me know.

I’ll let you know how it goes.

/Jongas

[Kevin_Price]

Future Readers:  I need to make a little correction to my previous post.  In the middle of the first paragraph of the "How It Works" section, make the following change:  "While the Z-index input is high, both the A & B inputs will also be high be low, causing..."

Jongas:  Even if you *did* have plenty of spare counters, I think you're better off with the simpler external digital AND circuit anyway.  Perhaps in the not-too-distant future, the X-series option may be fairly practical as well, though I understand it still wouldn't help your immediate situation as you're  also constrained by slots on your motherboard.

John:  I'm really glad to hear that you're tackling the idea of supporting hw-triggered count reset in edge (event) counting mode!  Thanks in advance!  Let me just take a moment to lobby for you to give further consideration to supporting it in pulse generation mode as well.   From my vantage point, edge counting mode should be the bigger (or earlier) emphasis.  But pulse generation mode support could allow the use of a counter as a kind of hw watchdog.

   First an aside to give some background to other readers.  In pulse generation mode, the count register is preloaded with the # of low ticks, then each active edge at the source input will decrement the count register.  On reaching terminal count (zero), the output state toggles while the count register is loaded with the # of high ticks.  Etc.

   So if a hw pulse at the counter's gate input could prematurely cause the count register to be reset without changing the output state, the counter could be used to perform a watchdog or deadman's function.  The idea is that you normally expect to keep feeding pulses to the gate input at a regular rate which keeps resetting the counter's count register value before it ever gets a chance to generate a pulse.  But if something goes wrong where that reset trigger fails to come in, the counter will generate a pulse which could presumably shut down power or whatever needs to happen in case of emergency.

   Another partially related thought.  Under encoder position measurement mode, the Z-index reload is sensitive to a high state of the Z input and a specific state combo of A, B.  This needs to stay supported due to the nature of some common real-life incremental encoders.   However, there are also a number of circumstances where it would be a helpful alternative to be able to make the Z-index reload be edge-sensitive.  Perhaps "hw-triggered count reset" should be implemented as an API option that is completely separate from Z-index reload.  Then an encoder task would have the option of using the default state-sensitive Z-index reload during a specified {A, B} state OR the new edge-sensitive hw-triggered reset which would probably simply ignore the {A, B} state.

   Feel free to contact me if you need any other backseat driving... 

-Kevin P

[John_P1]

Hi Kevin,

The basic watchdog idea should work for a Edge Count task as well if you export the rollover event from the counter.  Including the HW Reset for Counter Output tasks would give the benefit of configuring the pulse width of the trigger as well as possibly be more intuitive for the end user.  There might also be some corner cases when it would be helpful to have a reset when outputting a finite or continuous pulse train but I can't think of any common use cases off the top of my head.

I'll bring these ideas up at our next meeting to see what others think.

Best Regards,

[Kevin_Price]

Likewise, I can't think of a use case offhand that would need hw reset for a finite or continuous pulse train. 

Quick question: I'm not sure I'm following you on the first sentence of your last reply.  When you mention "exporting the rollover event", do you mean exporting the signal as a TTL voltage on some chosen PFI pin, or do you mean exporting a DAQmx event for software response in an event structure or timed loop?  If the former, I'm afraid I'm not seeing it.  How can you get the watchdog-like behavior from an edge-counting task?

[edit]  Oh wait, I get it now.  You were in future tense, talking about what could be done *after* hw-reset is implemented for edge-counting mode.  Right? 

Thanks again for considering the idea!   And please pass along similar thanks to all involved for the option of buffered counter output that was put into the X-series boards.  I've been wanting *that* feature since before Y2K.  (And of course, as Murphy's Law would have it, I no longer have a specific need for it in the forseeable future.)

-Kevin P