Hi

I am using a

CPU 1510SP-1 PN v2.9
G120C PN firmware version 4.7.13
Sick encoder AFM60A Multiturn encoder Advanced 30 Bit V1.0

I have linked it all up to the Positioning Axis for a rotatory control everything seems to be working ok. It will stop and start at the position requested. However randomly it will suddenly go to full drive and rotate at full speed until the positioning monitoring throws an error. 

I have set a dynamic velocity limit of 27 °/s but when it fault is is running at 47°/s

Has anyone got an idea whats going on and where to look to fix this?

Hi there,

if this was happening all the time, my guess would be some wrong invertion of the encoder, so that the axis tries to do position control, but intertpretes the actual movement in the wrong direction.

But as you say this only happens randomly, this can't be it.

Best you configure a trace recording to be made. Ensure to set the sampling of the recording to OB MC-Servo (so that you capture every value in the same cycle as the TO processes it). My guess would be to record the following parameters of the TO: Velocity, ActualVelocity, VelocitySetpoint, Position, ActualPosition, ErrorDetail.Number, StatusWord, StatusPositioning.FollowingError.
With this you can see if there is any error at the TO (ErrorDetail.Number), and which commands have been given to the TO (StatusWord; perhaps there is an accidental command?). Also you can see if setpoint values and actual values fit together (if not there might be some parametrization issue). Also VelocitySetpoint shows the setpoint after position control, while Velocity is the setpoint before position control (i.e. the one that is given to TO via command); so you see the position controller's impact in this situation.

Maybe the hardest part then is to find a trigger condition, which ensures to record this specific situation, and not just everything. It's up to you to think of something suitable (either existing or to be added to the program).

EDIT:
I actually have a guess!
Your encoder is a 30 Bit absolute encoder. Check how this encoder increments its position value, specifically at which point it overflows.

For the TO you can configure where it expects the encoder value to have its overflow. Since some versions, the default parametrization in the TO is to expect the overflow in the encoder raw value (Gx_Xist1 in the telegram) at 2^32-1 bits, i.e. it expects the encoder to use all 32 bits of the Gx_Xist1 slot in the telegram, as specified by the PROFIdrive norm. But some encoders don't do this. Instead they overflow earlier. If your encoder now overflows not after 32 bits but after 30 bits (its resolution), but the TO expects overflow after 32 bits, the TO will interprete this overflow not as a regular overflow but as position jump. In consequence the position control will lead to such movements.

See also here in the documentation, section "Evaluation of incremental actual value Gx_XIST1 with absolute encoders": https://support.industry.siemens.com/cs/ww/en/view/109817884/158541876619

To check this, either check your encoder's manual or contact the manufacturer. You could also do a trace recording of the Gx_Xist1 value in the telegram and check where the value overflows to/from zero.
Then check how this BehaviorGx_XIST1 property is set in the TO and adapt it if needed.

Regards,
daviso

Thank you for the reply. I will run the traces and see where that leads me. 

I do have the "Bits for fine resolution in the incremental actual value (Gx_XIST1)" set to 2 so if the encoder is only 30 bits that makes sense. I will try that first and if that's not the issue, try your first suggestion.

Thank you so much for the time you put into the reply!