Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Counter Pause on Digital Level; resume on user input

Hi, rotating a sample wheel with stepper driven by continuous counter output.  Each position of sx wheel has a key for a photo-interrupter.  When interrupted, counter pauses.  

I desire to 'override' the pause trigger with a user input control 'resume' but immediately revert to triggered stop at next sx position.

 

Attached is a small snippet that shows the pause setup I have.  The 'Data Changed' vi is for the user to change frequency or rotation on-the-fly if needed.

 

Suggestions on how to accomplish would be appreciated.

Thanks,
Chris

0 Kudos
Message 1 of 7
(3,130 Views)

Let me describe what I'd *want* to do & you can tell more about your DAQ device and # steppers if needed.

 

I'd want to use one counter to generate the pulse train and another counter configured for retriggerable single pulses with maximum high time (about half a day using 100 kHz timebase and 32 bit counter).  The pulse train counter would be configured to pause when the other counter's output is high.

 

This is a starting point to make sure that the pause behavior occurs instantly based on hardware timing from the photo-interrupter transition.

 

Then on a user button click, stop and restart the retriggerable pulse task.  That'll reset the output state to low and get it ready for the next transition.

 

 

-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? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 7
(3,118 Views)

Thanks Kevin,

Yes, I was aware of that method.  However, I have three stepper motors to control (similarly) and only four on the USB-6341. I hoping to find a software solution, or some minimal external hardware.

If not doable then will just require the user to 'jog' the stepper to each location.

Appreciate your feedback.

Chris

0 Kudos
Message 3 of 7
(3,115 Views)

The first fundamental trade-off is between a reliable hardware-timing based approach and a less reliable software-timing approach.  Software timing is just fine for quite a lot of things, but motion control isn't often one of them.

 

In your case, software timing will open up the possibility that the motors will continue stepping some undeterministic # steps after the photo-interrupter transition happens.  You'll find that the # will be capped to some small limit about 99+% of the time, but the other 1% is where things get "interesting."   There is no true upper bound.  However unlikely it may be, it's at least conceivable that the motor could keep stepping all the way to the *next* index point.  That'll throw off simple error checks like verifying that the photo-interrupter is still in its special state after stepping is known to have stopped.

 

In short, using software timing will be a compromise.  Just be careful to consider the various possible bad behaviors, your ability to detect them, and what their impact could be.  A 2nd X-series board would support a more reliable hw-timed approach.

 

 

-Kevin P

 

 

P.S.  There are probably some simple logic chips with "1 shot" behavior and a reset line.  These would serve the same function as the retriggerable single pulse counter tasks.  You just need it to be resettable from a static DO line your software can control.   

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? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 7
(3,111 Views)

Again thanks for the input Kevin,

If this were the ideal world I would put absolute encoders on all 3 axis and be done with it.

Unfortunately, this is a University...FAARRRR from the real world.

I continue to try.

Chris

0 Kudos
Message 5 of 7
(3,107 Views)

Whole other thought here: once you've landed in any one "home" index position, wouldn't you always be able to know how many steps it takes to get to the next one?  Then you can just run a finite pulsetrain with that # steps.  On X-series boards, finite pulsetrains no longer consume 2 counters each, so you can have 3 of them on one board.

 

If wanted, after the finite pulsetrain ends, you can check and very that the photo-interrupter is in the expected state.  Or you could keep polling it to confirm the eventual transition to the expected state.

 

 

-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? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 7
(3,104 Views)

Good idea Kevin,

Unsure about the machining tolerance of the sax 'wheels' however...but might be 'close enough'

Definitely something to consider and test.

THANKS.

Chris

0 Kudos
Message 7 of 7
(3,098 Views)