Showing results for 
Search instead for 
Did you mean: 

USB-6215 Generate finite pulse train with Stop- Trigger



I think I'm missing something...

I want to use a USB-6215 to generate a finite pulse train to control a stepper motor driver. Since I have to  send the pulse train for clockwise rotation on one output (ctr0 out) and the pulse train for counterclockwise rotation on a separate output (ctr1 out), I know that I can handle both counter channels in one task. Now at the same time I want feedback from a switch, signaling the motor has reached a certain point, so I can interrupt my pulse train to stop the motor.

How can I do both in parallel? I read it is possible to handle several channels of the same type in one task. And it is not possible to have more than one task. Is that right?


I appreciate your comments on this.

Greets, Dave
0 Kudos
Message 1 of 2

There are several subtle reasons that your M-series device is not well suited to do what you're looking for.   A 4-counter X-series would be a much better option.   Here are comments to help explain why.


1.  There isn't support to stop a pulse train with a hardware stop trigger.  (True for both M and X series).  But X-series can support a pretty decent workaround.  You'd configure your 2 pulse train task to have a "pause trigger" which would be the outputs of the 3rd and 4th counters.  Then the 3rd and 4th counters would be single, long pulses triggered by the corresponding switches in question.  When motion trips a switch, counter 3 or 4 would be triggered, issue a long pulse, and the pulse train would be paused.  This gives software time to *notice*, clear the tasks, and get ready for the next move.

    Finite pulse trains on M-series devices consume *both* counters, leaving no similar option.  (On X-series, they consume only 1 of 4).  You can only use some kind of software polling method to monitor the switch state and then command the pulses to stop.  You'll have a slower and much more variable stop reaction.


2. "Lazy uncommit".   On an M-series, the 2 counters would take turns being the main pulse generator while the other acts as a helper.  It essentially plays the role of a hardware-timed pause trigger that *un-pauses* for the correct duration to allow the desired # of output pulses.

    Once a counter gets used as the main pulse output, there will be a route from the internal output to your PFI terminal.  When you then want to go the other direction, the route will probably still exist, and the pulse used for pause triggering will be seen by your driver as a pulse in the wrong direction.

    With an X-series device, finite pulse trains only use 1 counter, so the issue of "lazy uncommit" never comes into play.


3. Possible workarounds based on digital change detection aren't supported by your bus-powered M-series USB device.  I don't think there are similar restrictions on any X-series devices.  (Not 100% sure, but it's also the case that you won't need change detection as a workaround).


I read it is possible to handle several channels of the same type in one task. And it is not possible to have more than one task. Is that right?

Not exactly.  AI, AO, DI, and DO tasks usually *can* be multi-channel.  Counter tasks usually can't.  Not many devices support multiple counter channels in one task.  AFAIK, those that do only support it for counter outputs and I *think* I recall discussions here indicating that they don't actually start *exactly* in sync.  Plus, even if your device supported it, it wouldn't help you because it would make both counters pulse at the same time, basically telling your motor to vibrate in place.


With counters, you can (and often *must*) have more than one task.  Not more than one per counter though.  And sometimes less, such as the case for M-series counters using up both counters to generate 1 finite pulse train.



-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?
Message 2 of 2