Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Is there a way to reverse the active/inactive portions of the duty cycle?

I'm trying to sync the start times for an AI operation and a buffered encoder read. These two operations happen at different sampling rates and different sampling intervals, so I can't just port the AI scanclock over to the gates of the encoder counters.

My approach is to use three counters: one to generate a triggered pulse that has a width equal to the total sampling time (the trigger for this pulse comes from the AI start). The OUT from this counter then feeds the GATE for a counter that generates a pulse train while the GATE is high. Therefore, it generates a finite pulse train for the desired acquistion time. The out from this second counter goes to the GATEs of the encoder counters to
generate the DMA transfers.

The problem is that the pulse train always puts the active portion of the duty cycle at the end of the period, so the DMA transfer happens at a delay of T/2 relative to the start of the AI acquisition.

Is there a way to put the active portion of the duty cycle at the start of the period? i.e., when the gate goes high, I want the pulse train to start high then go low at the end of the duty cycle.

Thanks,

rgames
0 Kudos
Message 1 of 2
(3,173 Views)
The simplest seeming answer would often be to use 'Set Attribute.vi' to change the counter's output polarity. Then the counter will be at a high state during the delay and low during the pulse. However, that would also put it in the high state while armed and waiting for the trigger, and again after the pulse completes. It doesn't seem like that would work for you.

A near-miss idea would be to leave the polarity alone and simply specify the shortest possible delay. Use the internal max timebase as a source and set "Pulse Spec 1" == 2. On a 660x device, that'll only delay you by 25 nsec.

In fact, you may be able to change that near-miss into a perfect hit. The short delay may or may not change the timing of the DMA transfers relative to the trigger, depending on exactly how the "generate pulse train while gate is high" function is implemented. Here are some ways I can imagine:

A. The "pulse while gate is high" counter is always cycling internally. An output signal is always being generated on the TIO chip and is always being AND'ed with the state of the Gate signal coming in. The result of the AND is sent to the actual IO pin.

B. Similar to (A), but the AND'ing is done only when there's a state transition and the result is latched until the next state transition.

C. Internally, the pulse train counter always *wants* to run, but its Source is always being AND'ed with the Gate signal. Then, as far as the pulse train counter is concerned, time is frozen when the Gate is in the inactive state. This is how I *think* I remember it working.

In cases (A) and (B), the timing of the DMA transfers wouldn't be affected except for the rare case where the trigger event occurred within 25 nsec of a "scheduled" transfer. In case (C), you can compensate by changing the duty cycle of the "pulse while Gate is high" counter. Simply subtract 2 from "Pulse Spec 1" and add 2 to "Pulse Spec 2". Then (assuming its polarity is low state delay, high state pulse) make sure the encoder counter Gate is set to do DMA transfers on the low-->high transition.

Final note: if timing synchronization between analog and encoder is really important, there may be a better way. As I recall, the AI start signal does not have deterministic timing relative to the actual A/D conversions. You might instead have two counters of the 660x set to "pulse while Gate is high" and set up the other one to be the AI scan clock. Then you'd be more fully in control of their time==0 marks.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 2
(3,173 Views)