Gated pulse train from a 9401 gets stuck in a high state

[agoncalves]

I posted recently in the LabVIEW board and I am now running into an issue that I think would be more appropriate to discuss in this board. I am using the attached VI to generate a gated pulse train using an NI 9401 in a NI cDAQ-9171 chassis. I'm running into an error where at certain pulse settings, the gate will trip and be stuck in the high state for the entire duration of the pulse. Attached are photos of the output from the 9401 on a Tektronix 475A oscilloscope.

200us_Gate_a.jpg shows a 4.5 MHz, 50ns signal with a 10MHz, 200us gate. 200us_Gate_b.jpg shows the gate stuck in the high state for the remaining 99.8ms after the 200us gate. While the VI runs, the output on the oscilloscope switches back and forth between 200us_Gate_a.jpg and 200us_Gate_b.jpg with a regular frequency, it's not tripped randomly. I checked the output of the gate pulse on its own and didn't find anything wrong with it, so it looks like something is happening internaly after the signal is routed to the high frequency signal.


My goal is to run this VI with a variety of different gate widths. I've found that if I set the gate to 300us, 600us, or 900us, then the pulse looks fine. Any other value causes the gate to periodically trip and get stuck in the high state. I'd like to bring the gate as low as 100us. Has anyone seen this happen with their counters?

[kevins33]

Hi,

Has this configuration ever worked? Are you able to generate the pulses individually, or do they still get stuck in the high state for the entire duration of the pulse? Are there any pulse settings that do not produce this response?

Thanks,

[agoncalves]

Hi Kevin,

No, the configuration I described has never worked at those settings.

I am able to generate the pulses individually without getting stuck in the high state.  I have a case structure in the VI so I can run the program with the pulse trigger property node disabled and I can see both pulses running the way I would expect them to at Ctr0 OUT and Ctr1 OUT.  With the pulse trigger node enabled, I am still able to see the gate pulse running properly if I probe the output of Ctr0, but looking at the now-gated output of Ctr1 is where I see the gate tripping.

There are pulse settings that do not produce this response.  These are the ones that I've found so far:

Pulse Train: 4.5MHz, 0.225 duty cycle

Gate: 10MHz, duty cycle that is 0.0009, 0.003, 0.006, 0.009, 0.012, 0.015, 0.018, or 0.021

Pulse Train: 4.5MHz, 0.3375 duty cycle

Gate: 10MHz, duty cycle that is 0.0009, 0.009, 0.018, 0.027, 0.036, 0.045, or 0.054

Pulse Train: 4.5MHz, 0.45 duty cycle

Gate: 10MHz, duty cycle that is 0.0009, 0.009, 0.018, 0.036, or 0.054

[kevins33]

Is there a desired order that you want the tasks to start? Can you successfully bring the gate as low as 100 us without the pulse trigger property node enabled? Is it only when this case structure is enabled that the gate gets stuck in the high state?

On a sidenote there are some small coding corrections. The DAQmx Create Task error wire is not connected in the Pulse Train section. It is good practice to insert a DAQmx Stop Task.vi before each DAQmx Clear Task.vi. Also, you should probably merge the error wires after the DAQmx Clear Task.vi and send that single error wire into the single simple error handler. 

[agoncalves]

Ideally, I'd want the gate task to start first because eventually I'd like to add a control that turns the pulse train on and off while the gate pulse is running.

Yes, I can bring the gate as low as 100 us without the pulse trigger property node enabled, it's only when the case structure is enabled that the gate gets stuck.

Thanks for the corrections, much appreciated!

[agoncalves]

I'm not sure if this will help illustrate the issue, but I uploaded a couple of videos to show what I'm seeing on an oscilloscope.

This is the pulse train with a 100 us gate, tripping and repeatedly getting stuck in a high state for the entire length of the pulse: 100 us gate at 50 ms time/div and 0.1 ms time/div 

This is the same pulse train with a 300 us gate, where the gate's width stays consistant: 300 us gate at 50 ms time/div and 0.1 ms time/div

[kevins33]

In the attached VI, there is is one way to ensure which task begins first, the way to do this with by merging the error wires. You can also use sequence structures, but I prefer the merging error wires method. 

Another thing you can try is moving the DAQmx Timing.vi in front of the case structure, and let me know if the gate continues to lock up. 

[agoncalves]

Thanks for the VI and the tips on arranging the Start Task VIs.  Unfortunately, the gate is still locking up.  Changing the position of the DAQmx Timing.vi in the sequence doesn't seem to affect the output.

[agoncalves]

I found a workaround that reliably produces the signal I'm looking for.

Instead of trying to program a continuous pulse train that starts on the rising edge of a gate pulse and pauses on the falling edge, I put together a VI where a finite pulse train is re-triggered by the rising digitial edge of a continuous pulse train.  The VI calculates how many pulses would fit inside the desired "gate" (the pulse width of the continuous pulse train) and sets the result as the number of samples so the finite pulse train ends right before the falling edge of the continuous pulse train.  

I'm using two 9401s to do this, I couldn't get it to work with only two nibbles:  The first 9401 is configured so one nibble outputs the continuous pulse train/start trigger signal.  This start trigger signal is wired to one nibble on the second 9401.  The other nibble on the second 9401 is set to output the finite pulse train.

This at least gives me the option of adjusting when I want the high frequency pulse train to stop.  I don't see the signal getting stuck.

I'm still not sure why I'm running into trouble at certain duty cycle settings when I try to do this using the Pause Trigger property node and only one device.  Am I just running up against the gating limitations of the 9401?

[John_P1]

---

@agoncalves wrote:

I'm using two 9401s to do this, I couldn't get it to work with only two nibbles:  The first 9401 is configured so one nibble outputs the continuous pulse train/start trigger signal.  This start trigger signal is wired to one nibble on the second 9401.  The other nibble on the second 9401 is set to output the finite pulse train.

---

You can route signals between the counters internally to avoid having to use the extra 9401 and additional wiring.

If you want to use a counter without outputting the signal to one of the terminals on your 9401, you should reference the counter like this:

<chassis name>/_ctrX

The internal name for the counter output would be:

/<chassis name>/CtrXInternalOutput

Where "X" is the counter you are using {0:3}.  Using this you can run the continuous counter output task and route it to the other counter's start trigger without having to make these external connections.

Default name filtering options prevent you from seeing thsee options in the drop-down list (see here).

Best Regards,