Edge Chatter or jitter from Encoder value

Hi,
I've an application as follows:
ControlLogix L62
Machine with 7 Servos running from Kinetix 6000.
An encoder connected to the auxiliary input on one of the Kinetix drives.
This encoder returns a 0-360 deg rotation position.

I'm using the LIM instruction, with the encoder feedback as input, to activate various flags controlling cylinders.

A problem I'm experiencing is as follows: Sometimes when the machine stops, the encoder value cycles from X to X minus a value, and back again. (The difference is very small)
Ex: 330 to 329.001 to 330
If I'm firing cylinders at 330, I end up with 'chattering cylinders'. i.e. the cylinders keep pulsing on/off.

A solution I'm using to overcome this issue is as follows:
IF Encoder_RawValue > Encoder_WorkValue THEN
Encoder_WorkValue = Encoder_RawValue
ELSE
IF Encoder_WorkValue > Encoder_RawValue + Hysteresis_Value THEN
Encoder_WorkValue = Encoder_RawValue 'This covers 360 rollover (Hysteresis_Value = 1)
ENDIF

This still has the problem when the machine stops at 0 on the encoder (bounce from 0 to 359.999 to 0)
I overcome this by using a LIM on the Encoder_RawValue between 0 and 359.5. (I'm sacrificing the last 0.5 deg)

I'm not happy with this solution as it seems a bit dodgy for some reason.

The machine is not high speed (approx 60 rpm) and is one direction only.

Is there a better way to overcome this problem?

I'd appreciate any advice or help you guys can give.

Thanks,
Tim

I would either put together a state machine or latch up the position reached condition until the device has rotated some number of degrees.

Keith

Latching won't solve the problem...
BTW, this is a CAM driven machine.
The servos are just used in Pick&Place positions.

I'm creating cam positions using the LIM instruction.
Cam windows can have values such as [280 on, 300 off] for one cylinder and [175 on, 50 off] for another.
The LIM instruction is circular and takes care of issues arising when the 'on' value is greater than the 'off' value.

Also, I have 150 different positions to allow for.
Not sure how a state machine would solve this.


Thanks,
Tim

Originally posted by consol:

Latching won't solve the problem...

Click to expand...

Sure it would. It's just that in your case it would be unacceptably painful to implement.

Originally posted byconsol:

Not sure how a state machine would solve this.

Click to expand...

In much the same way that latching would. If the state machine progression is made contingent on the state preceding it you wouldn't be able to go backward out of a condition once the condition is reached. For example, assume the output is supposed to turn on at 300 and off at 310. Once you enter the state triggered by passing 300, which turns on the output, the state machine won't exit that state until you pass 310. Even if the position regresses to 290, the output stays on. Since the machine always goes one direction this shouldn't create much of an issue.

Keith

Originally posted by kamenges:


Sure it would. It's just that in your case it would be unacceptably painful to implement.

Click to expand...

Yeah, getting lazy here...

Originally posted by kamenges:

In much the same way that latching would. If the state machine progression is made contingent on the state preceding it you wouldn't be able to go backward out of a condition once the condition is reached. For example, assume the output is supposed to turn on at 300 and off at 310. Once you enter the state triggered by passing 300, which turns on the output, the state machine won't exit that state until you pass 310. Even if the position regresses to 290, the output stays on. Since the machine always goes one direction this shouldn't create much of an issue.

Click to expand...

I see what you're getting at... but, would this work if the 'on' point is greater than the 'off' point (on at 310 and off at 300)?


This is the Cam position logic I'm using.
Gives me Pulse On, Pulse Off and Position active flags.


Thanks for the input,
Tim

Anybody else got any ideas?

How about sealing in the outputs when the velocity of the machine is at (or near) zero? Then you can do away with the extra tags and math you're using now.

Simple

consol said:

Anybody else got any ideas?

Click to expand...

yes
Instead of scaling your encoder to 0 to 360 degrees scale your encoder to -32768 to 32767 and use 16 bit integers. Now you can simply subtract the old position from the new position from the new count to tell which direction you are going. If your encoder goes from 0-999 then

Everything is easier if you can make you encoder look like it returns -32768 to 32767 counts or position units.

If the encoder counts to (2^n)-1 then New can be calculated by a shift instead of a multiply and divide.

Use inbuilt function

Have you looked at the MAOC (Motion Arm Output CAM) Function?

This function is highly flexible in the control of outputs based on position
It gives you a Programmable Limit switch functionality on any Motion Axis

Functionality includes

Example Output 1 - On Position:10 Deg, Enable: Inverted Output
This Turns ON at 10 Deg Providing the output is currently off effectively giving a forward latch that does not turn off when you reverse

Simpler

Lets Take your solution and improve it to fix the 360 deg chatter

Try either of the following rungs for your WorkValue



Note: IF you reverse 180 deg then everything jumps position

Sorry for taking so long with response.
Hope to try some of these solutions this week.
I'll update this results then.

Thanks for all your ideas.
Tim

Update

OK... a really late thankyou!
MichaelG, your solution worked perfectly (Forward Encoder with Rollover).

Thanks for all the help!
Tim