03-09-2006 02:20 AM
03-09-2006 05:35 PM
So to output a pulse based on 100 "ticks" of an encoder, I recommend using a continuous counter output example. In LabVIEW, go to Help >> Find Examples >> Hardware Input and Output >> DAQmx >> Generating Digital Pulses >> Generate Digital Pulse Train - Continuous.VI. You can change the Counter Output Task to "Ticks" instead of frequency. From there, you can set the "low ticks" to 99 and "high ticks" to 1 and you should be set. Please let me know if you have any problems or questions on this.
03-10-2006 12:41 AM
03-10-2006 04:38 AM
Just one more thing, my encoder is an AB encoder that comes from a rotative motor.
When I do a simple counter read on the counter input, the numer reterned increments or decrements depending on the rotation way, that is ok.
Now, if I use this counter input (from the AB encoder) as a "counter" control in the "CO pulse Tick.vi" is it possible (and how?) to set it on "external direction" ; so that it sends a pulse not just when 100 pulses are received, BUT only when 100 pulses with the motor rotating in the same direction are received ?
I am not sure I am being very clear...
03-13-2006 02:09 PM
03-13-2006 03:36 PM
Thanks for that, it really helps to have your analysis...
I agree that FPGA would be a little bit too much in regard to what I need to do... I also agree that solution 2 is not deterministic and I can't afford missing value...
Let me explain, as the rotor swivels the encoder sends pulses (16000 pulses every 360°) and I need my camera to take a picture every 2°.
At the beginning I was thinking that using the AB encoder would be easy and the best solution, but now it seems to appear easier not to use the AB feature. If I can get the motor keeps rotating at a constant speed I will have my problem already solved...
Thanks again for your help, I'll keep you updated
03-13-2006 04:32 PM
1. Are you in control of the "rotor" motion or at least its direction? If so, and if you can put a shrt delay between direction changes, you could probably reprogram the divide-down counter during that delay so that the output pulses would occur at the same physical 2 degree positions. It would be basically Hal's idea, but each time there was a direction change, you'd use knowledge of the present state of the divide-down counter to properly set its initial count during reprogramming.
2. You mentioned getting the motor to "keep rotating at a constant speed" -- you do realize that the methods described don't really care about a speed variations, right? They just can't handle a direction change.
(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).