Single Turn Encoder

Good Morning Gents.

L35E, RSL5000 V20.18

I have a quick question for you regarding a single turn encoder I am using for a new project. I am using this encoder to A track line position, B to tell me RPM and C to increment a BSL instruction.

The first two things no troubles. The one thing I am noticing is that if I have my encoder resolution set to more than 10 counts per rev. I start missing the 0 position.

EX: I am using an EQU instruction to turn on a one shot. The EQU instruction looks at encoder position and if Equal to 0, trigger the ONS. However, if my resolution is set to more than 10 and I do 20 revolutions, I might only count 11 one shot enables. At 10 Pulses it is very accurate.

My question is this?

What is the ideal way to catch the 0 position reliably at a resolution higher than 10 counts per rev. ???

I would like to run at 100 counts/rev.
My max RPM would be about 140 RPM. But this is not reliable even at 80 RPM.
My RPI for encoder is 2.0ms.
My max scan time at this point is 5.08 with an average about 1. If this is relevant.

Thanks for any advice in advance!

1) Don't use EQU. Use GEQ or Window type instructions.
or
2) Use the programmable direct outputs on the encoder module (if you have any).
or
3) Use an event driven interrupt routine to handle reading the encoder.

140 RPM = 2.33 RPSec. At 100 Counts/rev, that is 233 counts per second, or 233 Hz, or 0.00429 sec/pulse. .00508 sec/scan will not be guaranteed to catch that at all. You are even pushing things with the 2ms RPI.

rdrast said:

1) Don't use EQU. Use GEQ or Window type instructions.
or
2) Use the programmable direct outputs on the encoder module (if you have any).
or
3) Use an event driven interrupt routine to handle reading the encoder.

140 RPM = 2.33 RPSec. At 100 Counts/rev, that is 233 counts per second, or 233 Hz, or 0.00429 sec/pulse. .00508 sec/scan will not be guaranteed to catch that at all. You are even pushing things with the 2ms RPI.

Click to expand...

To your first response: "Use GEQ or window type" Are you saying that a LIM instruction would be better? High could be say 101 and low could be 99 with the test being the encoder position?

Second response: There are no options with this encoder, very basic.

Third response: "Use an event driven interrupt routine to handle reading the encoder" What would I use to trigger the event task? This encoder will be running all the time and is the very backbone of the line functionality so this will need to be continuously running said task.


All this being said, Do you think I can reliably mange this with using 10 counts per rev without missing my 0.

Thanks for the advice!

Are you using a high-speed counter (a 1769-HSC, for example, can reliably entertain up to 1 million pulses per second, and like rdrast alluded, can conditionally energize its own outputs independent of whatever your program is doing) or an ordinary digital input module with your encoder? If it's the latter, you are bound by scan time, backplane RPI, or the module's ability to detect pulses, whichever is worst.

Your best illustration is this:

My RPI for encoder is 2.0ms.

Click to expand...

The encoder I am using is 842E-SIP1BA-A.(apologies for not including that in my OP.

I had a Rockwell motion guy in today for a visit. I showed this to him and he is thinking that I might try a managed switch. He is sending me a spare one to experiment with.
I have used the HSC card before with regular encoders and never had this issue.
I have been playing with this more today and I realize that I can turn it at 140 RPM and with 0-40 Pulse resolution it is reliable, more than that and I start to miss the ability to use one incremented position as a condition in my logic.
For what I am doing with it this is more than sufficient but I am going to entertain Rockwell's suggestion just for higher learning and personal experience.

Thanks

Good Morning Gents.

Click to expand...

No ladies on here? Maybe not.

Are you saying that a LIM instruction would be better? High could be say 101 and low could be 99 with the test being the encoder position?

Click to expand...

I think that is what he's saying and I know that solution has worked for me in some situations.

Agreed - the only time I ever use EQU is when I'm looking for a value that I set internally in the PLC or something. If I'm ever looking for a value coming in from an external device to be a certain value, always LEQ, GEQ or LIM. And give yourself a decent window too - not just 99-101 but perhaps 91-109.