DAQmx divisor

[Lara]

Hi all,

I want to count pulses that come an encoder end send a pulse on another line for every 100 pulse I receive

It sounds quite simple, I know... with the examples VI, I've managed to count the pulse from my encoder and to send pulses that I visualise on an oscilloscope but I just can't get in DAQmx synchronising philosofy...

I've been spending my whole day trying to "link" the generation of a pulse to the number of pulse received... without success !

Please help ! 

[Hal_L]

Hi Lara,

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.

Regards,

Hal L.

[Lara]

Thanks alot for you reply, Hal I will try that VI with the changes you mentioned and let you know.

In my application I am not sure what would be the most appropriate solution between this solution you pointed and the one in that thread ,could you please check it and advise me ?

Thanks alot in advance.

[Lara]

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...

[Otis]

Hi Lara,

1. The solution that Hal gave you definitely would be what I would have recommended.  However, in your case you care about the direction of the counts.  That will be rather difficult to implement because the method he recommended does not care about the actual direction.
   Pro: Simple to implement.  Hardware Timed.
   Con: Unidirectional.
   
   
2. In your case it looks like the direction is very important and that the device could potentially roll backwards, so the only way that you can really solve the problem at this point is to actually poll the value of your encoder, and if it reaches a value of 100*n, then it will create a pulse on a digital or counter line.  This will only work though if your motion is somewhat slow (order of 1 tick every few milliseconds); however, it will not be fully deterministic and could potentially miss counts.
   Pro: Simple to implement. Bidirectional.
   Con: Software Timing.
   
   
3. Unfortunately the easiest solutions may not work perfectly for your application.  There is one other option, but it would be difficult to program and would cost a lot more than you may want to spend.  What you could do is look at getting a PCI-7833R board.  With this you could use the onboard FPGA (Requires LabVIEW FPGA) to do the custom logic all with hardware timed precision and accuracy.  This would really be the best solution, but it may be like trying to kill a mosquito with a canon.
   Pro: Fully customizable. Hardware Timed.
   Con: Cost.  Difficult to implement.
   

I hope you are able to determine what the best solution is for your particular use case.

Regards,

[Lara]

Otis,

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

Best regards

[Kevin_Price]

Lara,

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.

-Kevin P.