NI Pulse Genation using clock with PFI line

[ssezgin]

I am using pulse train generation vi with my NI-6363 Multi-function USB board in my test stand sequence. I need to iterate through all the available 16 PFI channels one at a time. Simultaneous pulse is not desired!  I have 4 counter available. What I see is counter does not reset so in each iteration when I start pulse it still generates pulses on the previous channels I already used. Once all the sequence is done, on the next fresh sequence run I end up having all the PFI lines active once I create the counter task using the default VI below.

Any idea on how to reset the counter and flush all the PFI channels it adds to task internally.

Close and Clear tasks apparently does not do it. Otherwise I would need to power cycle the NI board in between each iteration or use a MUX which is not intended.

The example VI comes with the LabVIEW in the link below is in the attachment.

C:\Program Files\National Instruments\LabVIEW 2016\examples\DAQmx\Counter Output\Counter - Continuous Output.vi

[ssezgin]

The workaround I implemented was using a dummy frequency read task using clocks after the pulse generation to reset the counter. I am now able to generate and iterate through all the PFI channels one at a time over and over again but there gotta be a better way?

[cbutcher]

So you're re-running the example file (exactly as attached) whilst changing "Output Terminal" and seeing that previously selected Output Terminals are still in use, in addition to the currently selected one?

Just to check simple things:

• You are not clicking abort to stop the VI
• Each "test" is a separate click on the Run arrow (or Ctrl-R press)
• The generation does correctly stop when you stop the VI? (and then just resumes despite the change in Output Terminal when you select a different value for the next run)

[ssezgin]

Yes exactly.

I am not aborting the VI.

Each test is a separate click of the run arrow.

Generation stops correctly when you stop the VI. Yes it resumes in the next run.

[Kevin_Price · Accepted solution]

This is a known issue feature characteristic of signal routing on many DAQ devices.  You'll find more info by searching for "lazy uncommit".   Generally, you need to do some kind of workaround.  You seem to have found one that works, but be sure to test it out well to make sure it's reliable.

-Kevin P