how to stop Counter output when a condition mets from Digital or analog input in LV

[DMic]

I am using Daq Assistant to generate pulses on a counter to drive a stepper motor. Counter pulses are correct when using without while loop and setting the "samples" on the daq Assistant in advance.

        In contrast, when i want to stop the counter when a certain condition is met from checking analog/digital input. In this case the period is not consistent and not exact. for this i put the daq assistant inside a Timed Loop and modified the samples  to read to 1.HI/Lo time is 250us, Loop dt =500 , clock 1MHz selected on timed loop.

please see whether this approach is fine or suggest alternate one so that we can stop counter when a certain digital input becomes HI.

Thanks

[Kevin_Price]

Step 1 - stop relying on the DAQ Assistant.  Look at one of the shipping examples that configures counter pulse generation using the regular DAQmx functions.  (You can probably ignore / delete the parts related to triggering for now.)   You'll see that it can be pretty straightforward to stop a pulse train whenever you like when you use regular DAQmx functions.

Step 2 - I don't know what hardware or OS you're using, but Timed Loops aren't going to give you perfect timing on most platforms.  Even on the platforms where they *might*, it'll still depend on you coding properly such that you don't prevent the Timed Loop from being consistent.   The DAQ Assistant is *notorious* for being a very inefficient way to handle data acq in a loop.

The counter pulse periods should be consistent and exact, the loop iteration timing might very well be neither consistent nor exact.

-Kevin P

[DMic]

1. So in configured examples in labview should we still use loop or not . if yes on which block. Like , start. Create task etc

2. I m using Pxi rt 8187. With pxi 6289 card

[Kevin_Price]

1. You should be able to try the example for continuous counter output as-is.  The loop merely queries the task status so that the loop can terminate in case of a task error.  The counter hardware handles all the pulse timing once you define a continuous sampling task and start it, so you may not need the loop to be a high precision Timed Loop either.

   *Some* kind of loop is necessary b/c you intend to keep checking for a "condition" so you know to stop the pulse train.   It isn't strictly necessary to query the counter task for errors in that loop, but it's a good general practice.

-Kevin P

[DMic]

Yes i can see the example.that it's very helpful. But can we ensure that the counter output will stop at the same time when condition meets? With out missing any pulses. Eg at pulse number 100 stop condition meets .its there any possibility that counter output will stop deterministic ally at Pulse number 100.

In the example there is 100ms wait until next multiple. 100ms is larger than pulse hi/lo time 250us.does this will pose any issue.

Regards

[Kevin_Price]

Generally, for most kinds of "conditions" folks typically evaluate using other data acq signals and some algorithm, no you probably cannot expect to stop the counter output nearly instantaneously.  If you're evaluating real-world signals, there will almost always be some latency between the condition, your software's awareness of it, and your ability to call through the driver to stop your pulse train.  I wouldn't want to rely on doing better than single digits of msec, during which time a handful of extra pulses can happen.

The specific 100 msec in the example program will definitely contribute to the latency.  The smaller you make it, the lower the latency but the higher the CPU load as you spend a greater %age of your time executing code.   You generally don't want a loop without *some* kind of idle wait time or you'll burn too much CPU iterating.  But that idle time *will* add to your latency.  You can probably change the 100 msec to 2 msec without much CPU harm, as long as you aren't doing much real CPU work inside the same loop.

If you need an instantaneous response to the "condition", you'd need to handle it in hardware.  Even then, you'll need to know that the stepper motor and its inertial load can handle dead start and dead stop at 2 kHz.   Is it a microstepping drive?

-Kevin P

[DMic]

Yes thanks.

My last discussion is on

1. logging and displaying the output pulses on host PC,  that i am sending to motor drive. 

2. Does the pxi supports serial data input. 

Regards

[Kevin_Price · Accepted solution]

1. To be meaningful, these should be measured in hardware with another data acq task.  Otherwise you're just displaying what you *hope* to be doing.

   It'll probably be simplest to physically wire to an analog input channel and sample fast enough to get the needed timing resolution for the pulse edges.  You've got 250 usec between edges and a decent starting point is to sample at 10x == 25 usec per sample == 40 kHz.

2. I'm pretty sure some PXI controllers have a serial port built in.  Or you can get a dedicated PXI card (yes, they're available), or a USB to serial converter.

-Kevin P

[DMic]

As you mentioned input the same pulses on another analog channel. Now I would like to do 2 things

1. can I replicate the rotation of stepper on the dial gauge as the motor rotates. For example first acquiring the pulses and then converting the pulses counted to position (x pulses /deg). can you recommend some tech to pulse count or any other method

2. saving the data in degrees.

thanks

[Kevin_Price]

1. I don't generally have a lot of insight about dial gauge indicators.  Once or twice I've customized one to show continuous rotation, my recollection is that making it work that way depended on something not obvious to me at the outset but simple and sensible once I found the help.   Sorry, that's about as much as I can say for sure.

2. If you know steps per rev, I'm not sure where the difficulty would be in converting to degrees.   If you don't know steps per rev, you'll need to figure it out.

-Kevin P