Encoder Based Part Tracking - Bi-idirectional Travel

Veteranpete · Nov 6, 2015

I am working on a project in which I will be tracking multiple parts on a conveyor with specific positions where the parts are marked. The conveyor has an encoder and I am using the encoder count difference from my last scan to increment the part positions.

My issue is that my logic works in a completely forward direction. In my application, there exists the potential for reverse travel(briefly). My problem is that I assume if my current encoder count is less than my last encoder count, the encoder has rolled over and I have missed a whole rotation plus the current encoder count. This is resulting in large jumps in part positions. I have tried to manage it by truncating the scan difference such that if the scan difference is greater than a limit, I set it to a maximum value.

The only solutions I can think of are band-aids and I am looking for a better alternative that allows movement in both directions and can identify the difference between a rollover and a roll back motion.

I am using a Micrologix 1100 - but this issue exists in RSLogix 5k as well.

Anyone have any suggestions?

Thanks for the help.

I have uploaded an example of my code.

F8:26 is the encoder count difference from my last scan
F8:25 is the encoder count read on the last scan
F8:20 is the encoder count difference limit

KalleOlsen · Nov 6, 2015

Veteranpete said:
I am working on a project in which I will be tracking multiple parts on a conveyor with specific positions where the parts are marked. The conveyor has an encoder and I am using the encoder count difference from my last scan to increment the part positions.

My issue is that my logic works in a completely forward direction. In my application, there exists the potential for reverse travel(briefly). My problem is that I assume if my current encoder count is less than my last encoder count, the encoder has rolled over and I have missed a whole rotation plus the current encoder count. This is resulting in large jumps in part positions. I have tried to manage it by truncating the scan difference such that if the scan difference is greater than a limit, I set it to a maximum value.

The only solutions I can think of are band-aids and I am looking for a better alternative that allows movement in both directions and can identify the difference between a rollover and a roll back motion.

I am using a Micrologix 1100 - but this issue exists in RSLogix 5k as well.

Anyone have any suggestions?

Thanks for the help.

I have uploaded an example of my code.

F8:26 is the encoder count difference from my last scan
F8:25 is the encoder count read on the last scan
F8:20 is the encoder count difference limit

Hi Veteranpete, and welcome to the forum.

I don't know AB much, so I cannot help you specifically.

But here's how i treat encoders to be wraparound immune.
Example: 24+sign -encoder (=25 bit).

I load the encoder value, shift it 7 bits up and save it in a double int. Now the signbit is the msb in the DINT.

Now you can play with it with double-int math, not worrying about the wraparound.
Mind that the bit value now is 2**7, so your calculations must be adjusted.
(or the result could be shifted 7 bits down).

Edit:
A 12 bits encoder would be shifted 4 bits up, so the encoder msb now is the msb in an INT.
Then I use INT maths.

I hope you get the point.

Regards
Kalle

Doug-P · Nov 6, 2015

Just guessing but, it sounds like a conveyor stops and a chain (or something) rocks back a little. Could you include the motor run signal as part of the encoder logic? ie. ignore counts when motor is off.

One alternative might be to relocate the encoder, maybe connect it right to the drive.

jrwb4gbm · Nov 6, 2015

You might want to consider using a quadrature encoder. You can then sense direction also.

OkiePC · Nov 6, 2015

In your rollover math, you should be able to detect the magnitude of the change and determine whether it was a rollover or backward travel. Whether this is possible may depend on the number of counts per second you are getting from the device.

For example, if the count ranges from 0-1023 increasing in the forward direction, and your difference comes out to -950, that is probably unrealistic for backward travel and is likely a rollover. But if the difference is -50, it is probably backward travel. You would have to do the math to know based on scan rates and actual speed what constitutes the outside range of possible differences for normal travel versus rollover, and then limit check your result to determine that it was a rollover if it is outside this range.

Veteranpete · Nov 6, 2015

I am using a shaft-mounted encoder and what happens is when the drive(not controlled by me) stops, the stopping torque causes the shaft to go back slightly. I can see this when I trend the encoder accumulator. What makes it more difficult is that it's a 10k encoder so as it is moving backwards, each step is amplified.

I am planning on putting logic that essentially says "if absolute difference < limit, then it is a rollback." This is doable, but not as clean as I would like. I was just curious how others handle this kind of scenario and to see if I am accumulating my counts incorrectly.

I am using a quadrature encoder, which is causing my issues - I've thought about only looking at positive direction and changing the counter mode in the PLC...but that's not a good option either.

danny.michael · Nov 6, 2015

In the ControlLogix world you can use the Pulse Multiplier PMUL instruction if you are allowed to use function block programming. The output of the instruction is the number of counts, positive or negative, since the last scan. It takes a little setting up, but it works as advertised.

KalleOlsen · Nov 8, 2015

I see you didn't catch my point in post 2. I'll try with an example, and change the expression from 'wraparound' to 'rollover'.

Ex. a 0-1023 counter (2^10)
Load the value and shift it 6 upwards.
Subtract the old value and shift the result 6 downwards.
And you - lucky man - will never see the rollover.

An example with S7 mnemonics:
The encoder rolls back and over from 1..(via 0)..to 1023
SLW: means shift a 16 bit word to the left (upwards).
SRW: ditto to the right.
-I: is a 16 bit subtraction.
// means comments on the rest of the line
Here we go:

L COUNTER // 03FFh = 1023
SLW 6 // FFFFh = -32768 or 65535 if seen w/o sign
L OLD_CNT // 0001h = 1 (old value from last scan - before rollover)
SLW 6 // 0040h = 64
- I // FF9Bh 16-bit INT subtraction result of OLD_CNT - COUNTER
SRW 6 // FFFEh = -2 VOILA! The rollover is 'gone'

I can do this in ladder in the Simatic, and I'm sure it can be done in an AB also.

Kalle

Encoder Based Part Tracking - Bi-idirectional Travel

Veteranpete

Member

KalleOlsen

Member

Doug-P

Member

jrwb4gbm

Lifetime Supporting Member

OkiePC

Lifetime Supporting Member

Veteranpete

Member

danny.michael

Lifetime Supporting Member

KalleOlsen

Member

Similar Topics