Rockwell Kinetix 5700 Losing Absolute Position at Power Off

CNLG

Member
Join Date
Aug 2021
Location
Stockholm
Posts
9
Hello, First thank for all the help i've gotten through this forum over the years reading others threads.


I'm having an issue with Kinetix 5700 Servo Drives losing their Absolute Actual Position at Power Off (Entire Machine Breaker) using Cyclic Mode.

It seems to be that while the Servos have "HOLD" at Standstill and loses power it moves the axis just slightly at shutdown. This causes something strange as when it gets powered on again Axis Positions are slightly off.

I have tried powering it off with and without load.

With load it will coast away (bigger value) as the load is pushing onto the axis.
Without load it will slightly move in (smaller value) as the power is turned off.

In Both scenarios the position is now not the same the before power off position.
When running the current Recipe I now get everything with an offset in reality but virtually the same.

With Load I get a bigger offset.
Without Load I get a smaller offset.

Has anyone had or heard of a similar issue? Thanks in Advance,
and please don't hesitate to ask for detailed specifics if that could help.
 
Brake release and engage parameters under axis properties. In our cases changed both parameters from 0 to 0.3.
 
Brake release and engage parameters under axis properties. In our cases changed both parameters from 0 to 0.3.

Heya, I currently do not have any External Brake on these axis, and I cannot see any Brake Parameters, which I'd assume is because of this. The Axis is being held in place with Velocity/Position Lock. The Load itself is very light.

The Servos are ERS3 btw.
 
Brake release and engage parameters under axis properties. In our cases changed both parameters from 0 to 0.3.

Just to add, I found these and I guess these are the ones you are poining at. But since I still do not have any External Brake this wouldn't do any difference for me right?

MechBrakeParameter.png
 
Are the motors them selves braked motors, in the MPL part number there is either 24 or 74 saying it is a brake motor, if it is 22 or 72 then it is not a brake motor. 2x is the old style connectors and 7x is the new Speedtec connectors.

What are the part numbers of you motors?
 
Last edited:
are the motors them selves braked motors, in the mpl part number there is either 24 or 74 saying it is a brake motor, if it is 22 or 72 then it is not a brake motor. 2x is the old style connectors and 7x is the new speedtec connectors.

What are the part numbers of you motors?

vpl-b1002m-p
 
A feature, not a bug

That sounds like an ordinary and expected result of powering off the servo motors, especially on a system with no brakes at the motor shaft or in the power transmission mechanism.

The servos are not "losing absolute position"; they are correctly detecting the change in absolute position even when powered down.

If you need a mechanism to minimize its motion while the servos are switched off, you need clamps or brakes. Or, you need a machine alignment or homing motion sequence to re-align the system before starting up again.
 
Also, the catalog number from the axis properties is not the entire catalog number of the motor. There is more after the "P", which tells whether there is a brake or not. Something like P*12 or P*14 (2 means no brake, 4 means brake).
 
Let me say up front that I don't have any hands-on experience with that model of Kinetix servo.
To me, absolute actual position requires an absolute encoder. If the axis moves when power is removed, an absolute encoder will power back up with the actual position, taking into account the distance moved while power was off. From the description it sounds like the axis powers back up with a discrepancy between the physical position and the position indicated by the encoder. Are you trying to operate with an incremental encoder?
 
Let me say up front that I don't have any hands-on experience with that model of Kinetix servo.
To me, absolute actual position requires an absolute encoder. If the axis moves when power is removed, an absolute encoder will power back up with the actual position, taking into account the distance moved while power was off. From the description it sounds like the axis powers back up with a discrepancy between the physical position and the position indicated by the encoder. Are you trying to operate with an incremental encoder?

I maybe wrong here, but what I think is going on is that the OP is using incremental moves rather than absolute moves. So when their system is commanded to position 123 and power is removed during movement, the system doesn't end up at position 123. In stead, maybe it ends up at 124. So when motion resumes, the systems is always off by 1. OP, correct me if I'm wrong.
 
I'm not sure that this matters but are the axes configured as position mode axes? Also, what firmware are you running in the plc? I don't know of any specific firmware related issues with position but someone might.

I was told by our local Rockwell distributor that a motor with absolute feedback will maintain absolute position when powered off as long as the motor is not rotated more than half of the absolute position revolutions when it is powered down. There are also issues when a plc program saved BEFORE the latest axis home is downloaded but that doesn't seem to be the case here.

Keith
 
That sounds like an ordinary and expected result of powering off the servo motors, especially on a system with no brakes at the motor shaft or in the power transmission mechanism.

The servos are not "losing absolute position"; they are correctly detecting the change in absolute position even when powered down.

If you need a mechanism to minimize its motion while the servos are switched off, you need clamps or brakes. Or, you need a machine alignment or homing motion sequence to re-align the system before starting up again.

Yes, it keeps up the position changes (almost) but it seems it doesnt follow it perfectly.
The issue is that the position after power down is not physically correct. I'm getting an offset when starting up and running again, we are using Absolute to not have to home it every time, but in the past I have never used absolute encoders this way.
If I'm losing a (10) or 0.01 without scaling of position units we suffer consequences in the recipe when running. This is why this is an issue. Since we havnt seen this issue previously it feels these motors should be able to handle it as well. But it might just be that Older motors without the Single Cable Power/Encoder just handled it better and the Single Cable for these motors isnt as efficient in following exact position during a shutdown for some reason. (photo of scaling below)

Also, the catalog number from the axis properties is not the entire catalog number of the motor. There is more after the "P", which tells whether there is a brake or not. Something like P*12 or P*14 (2 means no brake, 4 means brake).

Yeah you're right Sorry. "VPL-B1002M-PK12AA"

VP = Permanent magnet rotary servo motors optimized to the ratings of Kinetix 5500 and Kinetix 5700 servo drives.
L = Low Inertia
100 = 100 mm
2 = Magnet Stack Length
M= 6000 rpm
P = 18-bit absolute multi-turn (4096 revolutions) digital encoder (Hiperface DSL protocol)
K = Smooth shaft
1 = Single SpeedTec DIN connector, right angle, 325° rotatable
2 = No Brake
A = IEC metric, free mounting holes (type FF)
A = Standard

https://literature.rockwellautomation.com/idc/groups/literature/documents/in/vpl-in001_-en-p.pdf - Page 2

Let me say up front that I don't have any hands-on experience with that model of Kinetix servo.
To me, absolute actual position requires an absolute encoder. If the axis moves when power is removed, an absolute encoder will power back up with the actual position, taking into account the distance moved while power was off. From the description it sounds like the axis powers back up with a discrepancy between the physical position and the position indicated by the encoder. Are you trying to operate with an incremental encoder?

The encoder is built-in inside the Motor itself as an absolute encoder.
The encoder is working as "intended" that way and the position is remembed during power off. But Im still getting a random offset of the old physical position.

I maybe wrong here, but what I think is going on is that the OP is using incremental moves rather than absolute moves. So when their system is commanded to position 123 and power is removed during movement, the system doesn't end up at position 123. In stead, maybe it ends up at 124. So when motion resumes, the systems is always off by 1. OP, correct me if I'm wrong.

In the recipe im using a CAM control. with 6-10 positions. I believe this function will automatically increment between the cam positions?
Also. During these power off tests machine was completly still and doing NO movements

I'm not sure that this matters but are the axes configured as position mode axes? Also, what firmware are you running in the plc? I don't know of any specific firmware related issues with position but someone might.

I was told by our local Rockwell distributor that a motor with absolute feedback will maintain absolute position when powered off as long as the motor is not rotated more than half of the absolute position revolutions when it is powered down. There are also issues when a plc program saved BEFORE the latest axis home is downloaded but that doesn't seem to be the case here.

Keith

Axis are configued as position mode.

Firmwares are:

Studio 5000: 33.13
2198-DO12-ERS3: 13.005


"There are also issues when a plc program saved BEFORE the latest axis home is downloaded but that doesn't seem to be the case here." - This will help another issue I've seen probably thank you.


Edit 1: We are using Absolute Encoders to not have to home the motors every time. and We have never seen this issue with older kinetix 6000. We are currently in the phase of upgrading to 5700 ERS3/4 and Tuning might not be perfect either if this can cause issues. with gains and such.

Edit 2: Motor Information

Edit 3: More Info

Edit 4: Photo.

Scaling.png
 
Last edited:
Originally posted by CNLG:

In the recipe im using a CAM control.

This may be the source of the issue. It sounds like your actual axis position is reporting correctly but the axis position is not "synced" to the cam slave position. I'm not sure there is anything specifically in the motion system that enforces a 1:1 absolute relationship between a master position and a slave position in a cam relationship. I believe what the cam function is doing is applying slave position command deltas based on the master position delta and the cam relationship. So if the slave axis is moved by something other than the cam then the cam action will just pick up from that point. One neat side effect of this is you can apply an incremental move to a cammed slave at any time to change its phase. But one downside may be what you are seeing.

There is an instruction called Motion Calculate Slave Values (MCSV). You provide it the cam profile and master value as inputs and it will output the slave position, slave velocity and slave accel rate associated with the cam at that master position. You may want to run the MCSV instruction with data for your slave axis as a step in the recovery process from an interruption and then perform an absolute MAM on the axis with the slave position output of the MCSV as the position command for the MAM. Do this prior to enabling the cam relationship. This should "resync" your cam position to your axis position.

Keith
 
This may be the source of the issue. It sounds like your actual axis position is reporting correctly but the axis position is not "synced" to the cam slave position. I'm not sure there is anything specifically in the motion system that enforces a 1:1 absolute relationship between a master position and a slave position in a cam relationship. I believe what the cam function is doing is applying slave position command deltas based on the master position delta and the cam relationship. So if the slave axis is moved by something other than the cam then the cam action will just pick up from that point. One neat side effect of this is you can apply an incremental move to a cammed slave at any time to change its phase. But one downside may be what you are seeing.

There is an instruction called Motion Calculate Slave Values (MCSV). You provide it the cam profile and master value as inputs and it will output the slave position, slave velocity and slave accel rate associated with the cam at that master position. You may want to run the MCSV instruction with data for your slave axis as a step in the recovery process from an interruption and then perform an absolute MAM on the axis with the slave position output of the MCSV as the position command for the MAM. Do this prior to enabling the cam relationship. This should "resync" your cam position to your axis position.

Keith

I'll see what I can look up using this.
 
Update:
I don't actually know what caused the issue to give a position offset. Since yesterday it just started losing <0.001 PositionUnits instead of >0.01 PositionUnits which is within the limit of recipe to handle it correctly. I had been working on project aside of that while a tech was working on it. I suppose he found something... Can't say it 100% was a mechanical issue but it feels like it.
 

Similar Topics

Why the Position Loop Bandwidth, in Rockwell axis of Kinetix 5700 Servo Drive, is in Hertz ? Same for the Position Integrator Bandwidth . What is...
Replies
2
Views
2,664
Good Morning , I'm having a problem with a Kinetix Servo MAPC instruction. I keep getting a #85 Fault. Could you give me some...
Replies
1
Views
1,656
Good Morning , I'm having a problem with a Kinetix Servo MAPC instruction. I keep getting a #85 Fault. Could you give me some...
Replies
0
Views
1,120
Hello Everyone hardware: 1769-L36ERMS Compact GuardLogic 5370 Safety Controller, revision 30.014 drive: 2097-V32PRO-LM Kinetix 350, 2A, 240V...
Replies
2
Views
1,845
Good Afternoon , I am familiar with the RS Logix 5000 environment , but I am really struggling with motion . We have a number of Kinetix...
Replies
4
Views
2,373
Back
Top Bottom