PLS (Programmable Limit Switch)

bennettdan

I have a project I want to use a Incremental encoder with just one channel and after a certain amount of pulses I want to turn on an output.
This will be used to replace six mechanical limit switches that I want to be able to change the timing while running.
I have seen a encoder object but this machine spins at up to 6000 RPM and I was curious if the object would keep up with a 512 pulse per turn encoder?
If anyone has suggestions on how to count and enable outputs faster please chime in.
I don't care about the direction so the an decoding of A and B signals are not needed of the encoder.
Thanks Dan B.

jmg

bennettdan wrote: »

..
This will be used to replace six mechanical limit switches that I want to be able to change the timing while running.
..

I don't care about the direction so the an decoding of A and B signals are not needed of the encoder.

The Prop can count external edges. So long as you have clean and fast edges from that encoder, and do not care about direction, (ie always know which way you are traveling) then HW counting should work well.

You probably need some limit switches (one or one each end?), as encoders have no idea where they start from.
Depends on the consequences of over-run.

bennettdan

I was planning on using the index bit of the encoder to start the count. This is basically replacing 6 cam switches

jmg

bennettdan wrote: »

I was planning on using the index bit of the encoder to start the count. This is basically replacing 6 cam switches

Won't that give you one index pulse per revolution ?

bennettdan

Correct 1 pulse per turn a zero for the index then start the count of say A channel then at a certain amount of pulses trigger the output. The index could be used as a zero point.

jmg

You mean all these decisions occur inside any one revolution at 6000 rpm, (ie inside 10ms ) ?

bennettdan

Yes that is correct

jmg

wow - If it can all happen inside 10ms, I can see why you are keen to replace 6 cam switches

Single edge counting does give less angular resolution than Quad Counting, but with HW counting, the Prop can resolve the
19.531us pulse rate to the precision of a Waitcnt, and the edges are sampled to within 12.5ns

Thinking about this some more, there may be a way to use that Quad precision, you have just sitting there.


If you use both counters, one on each Quad Signal, and then your SW decides which Phase, and which edge to count on, from the Index, then wait on that value on that CTR.
That now resolves rotation to full quad precision. (going one-way, of course)

Next-angle is loaded quickly when that one is reached, and again you chose which Quad(=CTRA/B) & phase and wait again.

This assumes it is valid/safe to change Ctr phases on the fly - if the Prop decodes as 1 of 4, you should be ok.

kwinn

6000 RPM is 100 revolutions per second, or 10mSec/revolution
512 pulses per revolution would be 19.53 uSec per pulse
A cog running at 80MHz can execute 20 million instructions per second

In 19.53 uSec a cog can execute 390 instructions so it can easily count the pulses coming in, determine when the appropriate pin representing one of the six switches should be set high/low, and set the pin high or low.

Keep it fast and simple by using in line code to turn each output pin on and off at the desired point on the encoder. The only complication would be if a pin had to be turned on or off at the same time as the index pulse occurs, and even that is a very minor complication.

kwinn

Keep in mind that doing this electronically is much faster and more precise than doing it with cams and mechanical switches. Whatever is on the receiving end of the pulses may need to have them on longer than 19.53uS so the program may need an "on count" and "off count" for each of the six outputs.