CtrnInternalOutput change pulse length.

[senper]

Hi,

I am using a PCIe 6320 in windows 10 to create a reseteable count down pulse counter, for example 8-7-6-5-4-3-2-1-(0)-8-7 ....

In order to to that, I am using the couter output event routed to the counter gate. It almost work fine, the problem is that the counter output signal is active until the next pulse, so I miss one pulse. As you may see in the next image.

As far as I know you may only modify: Counter Output Terminal, Counter Output Behavior, Counter Output Pulse Polarity, Counter Output Toggle State but there is no way to fix the length of the counter out put event.

I´ve try to isolate the problem from the main software I am developing and I have the same problem, when I modify an Example.

Any suggestions? I am out of ideas. Unfortunatelly I don´t have any spare counter, as they are been used in other parts of my software,

Regards

 

[Kevin_Price]

1. No, to the best of my knowledge, you cannot *directly* control the pulse width of the terminal count output event.  As I recall, the width will be 1 cycle of the timebase signal used by the task.  You can see that its edges are synced to the rising edges of the other signal on your scope, so I presume that signal has the timebase role in your measurement.

2. Maybe you can experiment with trying to explicitly declare the task's timebase?  I'm not sure it'll be allowed, but it's worth a try to declare one of the internal timebases (100 MHz, 20 MHz, or 100 kHz on your X-series device).

3. You showed an example based on a quadrature encoder and there's a not-well-documented quirk about Z-index reset with NI counters -- it's actually level based rather than edge based, which is probably why you lose one of your counts.   As an experiment to verify, you can wire up A&B from a real quad encoder but wire the PFI line used for Z-index line direct to a constant 5V high.  Spin the encoder and it will count 1,2,3,0,1,2,3,0,1,2,3,0...    The reset keeps happening while the *level* of Z-index is high and the designated quad state is also present.

    The scope signal doesn't *look* much like an encoder though, which would typically be a 50% duty cycle at constant speed.

4. With an X-series device like yours, you can also perform a hardware-based count reset in regular edge-counting mode.  I haven't had occasion to fiddle around with this feature, but I *think* it will be edge-based instead of level-based.  And I *think* you can reset to any chosen count value, not only to 0.

    Could this work for your system? 

5. If my theory from #2 is correct, you have a bit of an electrical race condition going on with some things that are edge-based and others that are level-based.  Are you sure that you *ALWAYS* miss one pulse, and NEVER miss zero?   If so, you might be able to reset to 7 instead of 8.  That'll make a little ambiguity at the 7 count because you won't know if the count *should* be 8 instead.  But it would make sure the resets happen at the right pace.

    All in all though, I'd be pretty leery of depending on this behavior remaining consistent enough to rely on.

-Kevin P

[senper]

Hello Kevin, 

Thank you for your time, I will try to sumarize some of my findings.

The code has been used several years with a PCI-6602 counter/timer DAQ, with these conters the counter output event had a fixed time, maybe arround 1ms, and it was fine for my application. And there were several examples of reseteable count down using counter output routed to the gate.

With this new X series card the output event is active until another pulse is received, so the reseteable count down must be programmed in other way, this will make the software incompatible with previous hardware, I am not happy with that but I have to live with it.

1) The signal that I´ve shown in the previoys image it is a periodic image as I have reproduced the problem with another computer, a wave generator and an oscilloscope. The real application send pulses in an asyncronous way, with a máximum frecuency arround  25 ms.

2) Not sure if it may work but I will look into it.

3) The reason I miss one count, in this case, is not about the Z index, it  is because the counter output event gate is routed to the gate and it is active not for one ms but until another pulse is received.

4) Now I am working this solution, if it works I will report it.

Yesterday I´ve found a solution that I don´t like at all, I may change the the reset counter value to 7 instead of 8,as I know that always I will miss oun count.

Kevin, thank you again, I appreciate your time and It is really helpful to see other points of view.

Regads

[Kevin_Price]

I'm very curious about the code that worked with the 6602.  Way back in the day when I dabbled a lot with the 6602 and M-series boards, I only ever knew of two theoretical ways to count down and reset.  (This was circa 2005 before X-series devices were introduced with their new feature to support count reset for edge counting tasks.)

One was with an encoder task.  You could kinda trick the device by configuring for a "2 pulse encoder" (which would increment for A edges, decrement for B edges), wiring A to be constant High, setting up Z-index reload for A High B High, setting up the z-reload value and initial count to be positive, configuring the task to pulse on terminal count, and then using that output pulse signal as the Z-index channel.  This was a theoretical idea that I never had need of trying personally, it just arose during some forum thread or other.

The second way was to set up pulse generation using "Ticks" as the units.  Then you could set all the timing parameters (low ticks, high ticks, initial delay ticks) to the same value and the *inherent* internal behavior of the counter was to count down from those tick values to zero, whereupon it would do an internal count reset back to the next tick value and count down again.  With the default output behavior of "toggling" on terminal count, this is simply the way pulse generation works.  But you could choose to pulse on TC and configure all the pulse timing params to have the same tick value.   At any time you can query the count value to check the count down progress between terminal counts.

One final related method could be used to count *up* and reset, but then you could transform that to a count down on the app side.  That method would configure for buffered period measurement with Ticks as units.  Each time an input active edge was seen, the count value would be latched and the count would reset to 0 to be ready to measure the next period.   I'm not sure if this method could *also* be used to generate a terminal count pulse though.

Is one of those methods how your old code worked?  Which one?  Can you post it or describe the config in more detail?

I'm also surprised to hear that you were seeing ~1 millisec output pulses.   My recollection from back in the day when I dabbled a lot with the 6602 and M-series boards was that the output pulse lasted for one cycle of the task's timebase.  My memory is that I observed a pulse width of 50 nanosec, which was 1 cycle of the 20 MHz timebase, though I don't remember which device and which mode I was experimenting with at the time.

-Kevin P

P.S.  I just followed up and found this old post of mine from 2005 that addresses some of this stuff.  Since that was much closer to the time I was actually doing the tinkering, the info is probably more reliable.  Although it's also possible that some of the once-true observations have changed over the course of dozens of DAQmx releases since then.

[Kevin_Price]

Just thought of another possible sneaky idea: a retriggerable DO task that generates a single pulse of your desired duration, triggered by your CtrNInternalOutput signal.  Note: only port 0 DO lines support hardware timing on any X-series devices I know of.

This makes use of some additional X-series features not available on older M-series or 6602 TIO hardware, namely retriggerable DIO and the ability for DIO tasks to derive their own sample clocks from the internal timebases.

-Kevin P