Pulse train: finite with two counters or continuous with read...

[tbd]

Hi,

      I'm trying to simulate an encoder output by using two counters to output two identical square-waves with a 90 deg. phase shift between the two.  Pulses will be generated for less than a second and it's necessary to know exactly how many pulses have been output.  My preference would be to use a "Finite" sample mode, but I get an error that suggests my board (PXI-6251) can't do this because it only has two counters.  "Continuous" sampling seems to work, however, now I don't know exactly how many pulses have been output between DAQmx/Start and DAQmx/Stop.

If using continuous-sampling, after issuing DAQmx/Stop, is it possible to read the Count of one of the counters?  I tried usng DAQmx/Read, but get an error "-200460" (no channels in task can be read.)

Using the PXI-6251, is it possible to output a finite pulse train - two waveforems - with known/predefined pulse-count, or output the pulse train for some period of time, then poll the count of pulses output?

Thanks/Cheers.

[GarPar]

Hi tbd-

     First off, I thought I would cross-reference a community example that generates pulse trains that are 90 degrees out of phase, similar to an encoder.  It can be found here.

     Second, you should be able to use a property node to determine the number of pulses output.  Place a DAQmx Write property node on the block diagram.  Click on the property and select Status»Total Samples Per Channel Generated.  This is going to output the number of samples output, so you may need to multiple this by some factor to change it to the number of pulses output.  You can place this in the while loop to output the total number of samples/pulses output for that generation.

     I hope this helps.  Best of luck with your application!

[tbd]

Hi Gary,

      Thanks for the reply, but the suggestion didn't work, unfortunately.

After performing the DAQmx Stop, Total samples per channel is always 0 - even though pulses have been generated.

FYI, I've been using code much like the example, though, there's no while loop.  I'm just calling stop with a timeout.  This works great to output a pulse train, though I need to find out exactly how many pulses have been output (inferring that from time elapsed isn't precise enough.)

> you should be able to use a property node to determine the number of pulses output.

If this turns out not to be so, do you think there might be a [readable] PXI register from which the precise number of output-pulses can be deduced?

Any help is appreciated!

Thanks/Cheers.

[GarPar]

Hi tbd-

     I don't think I understand your program.  If you were to use the sample program with a while loop and the property node, you could just have the property node connect to an indicator outside the loop through a tunnel.  Then, when the program is stopped, the indicator would display the last value from the property node, i.e. the total number of samples generated. 

     Maybe you could post your code so we can see how you are stopping thr program.  This may be why the property node is not working correctly.

     Either way, try it out with the sample program.  Put the property node in the while loop and connect it to an indicator outside the while loop and it should work fine.

     Best of luck!

[tbd]

Hi Gary,

      I've attached the VI I was using  I've since tried your idea - to read the TotalPulsesGenerated property while the task is running - but it throws an error that says the property is invalid because it's "not a buffered output task".

Any more ideas on how to either, output a pulse-train of precise # of pulses. or output a pulse-train for some period of time (say, one second) then read a precise count of how many pulses were output.

Any help is appreciated!

Thanks/Cheers

[GarPar]

tbd-

     Another idea would be to create two digital output channels, configure them to be finite so that you know the exact number of pulses being output, and you can correlate those digital output lines to a clock.  Create a counter output channel at a certain pulse rate and use that pulse rate as an input to the digital task's timing VI.  Create an array with alternating 0s and 1s and wire that into the DAQmx Write.  Do this same thing for a second digital task, but configure the second counter output to be out of phase from the first counter.  This way, you have two finite digital pulse trains with a pre-selected number of pulses.

     This should work.  Have a great day!

[tbd]

Hi Gary,

      Unfortunately this won't work.  When "Finite" pulse train is used, DAQmx automatically allocates an unused counter to do the counting.  We have no unused counters and receive an error when specifying Finite Sampling - please see OP.

Thanks/Cheers 

---

@GarPar wrote:

tbd-

     Another idea would be to create two digital output channels, configure them to be finite so that you know the exact number of pulses being output, and you can correlate those digital output lines to a clock.  Create a counter output channel at a certain pulse rate and use that pulse rate as an input to the digital task's timing VI.  Create an array with alternating 0s and 1s and wire that into the DAQmx Write.  Do this same thing for a second digital task, but configure the second counter output to be out of phase from the first counter.  This way, you have two finite digital pulse trains with a pre-selected number of pulses.

     This should work.  Have a great day!

---

[GarPar]

Hi tbd-

     What I meant to say was that you can use one finite counter output and correlate it to two different digital output tasks.  Build two digital waveforms that are 90 degrees out of phase (i.e. one is 00110011 and the other is 0110011).  Use the finite counter output task as the clock for both digital output tasks.  You can determine the number of pulses output based on the number of samples that come from the counter output.  Your counter output is going to be twice as fast as the 'encoder' output.

     Hopefully I have explained this okay. 

[tbd]

Hi Gary,

      Thanks for clarifying - that's a very clever idea!

While we built some flexibility into our test equipment, though, it doesn't allow us to route DIO to the signals involved.  We ended up spending another half-day and routed the signals from an FPGA (starting with an FPGA/Encoder-simulator example from NI.)

Thanks much for your help (the Counter/DIO idea is worth remembering.)

Cheers!