Kinetix Virtual Axis Postion

[noxcuses]

Hello !!!

I'm commissioning a system that has two Kinetix 5700 Drives/motors going to driven wheels on the same physical axis. To keep them synced, I have them both geared to a virtual master. This works as expected.

The system is a pick and place gantry, so positioning is very important. I home the three axis at the same time in which they all read the same actual position afterwards. After running awhile I've noticed the Virtual actual position and slaves don't match. On some occasions I've noticed the virtual vs slave position gets off quite a bit when the tool hits something while teaching points.

I've used this method of gearing before with good results in different applications. I'm wondering once running in Auto mode if the position will get off and crash. I've added logic to compare each scan and fault if too far apart. That seems a bit goofy though.

I've checked scaling and repeatablilty. The abs encoders on the two MPL servo motors always read very close to the actual physical position. The virtual is the only one that is not correct. Any suggestions on what to do to keep them synced or what could be causing them to read differently?

 

[Tinine]

Hello !!!

I've noticed the virtual vs slave position gets off quite a bit when the tool hits something while teaching points.

You have ruled-out some form of mechanical slippage, right?
When this happens, the control tends to get the blame

The way I picture this, slippage is not likely if the two separate motors appear to be in agreement but I have no idea how the mechanics are linked.

I've added logic to compare each scan and fault if too far apart. That seems a bit goofy though.

Au contraire, I would say that this is a good policy.
Wherever I have a drive-train, I prefer dual-loop feedback (encoder on the motor + encoder on the load), the main reason being backlash but it's nice to have two feedback devices to compare. What I do find goofy is relying on a feedback device that couldn't be further away from what is supposed to be controlled (back-end of a motor?)

I've checked scaling and repeatablilty. The abs encoders on the two MPL servo motors always read very close to the actual physical position. The virtual is the only one that is not correct. Any suggestions on what to do to keep them synced or what could be causing them to read differently?

At this point....an extreme long-shot but hey-ho; I got my knickers in a twist, one time when I was canceling following error. I somehow redefined my actual position but with the error added to it. Sure the error was no-more but my position was off.
Like I stated, long-shot but if you're programming, who knows.




Rgds,


Craig

 

[noxcuses]

Thank you for the response.

You are correct that mechanical slippage is the main reason. I noticed when decelerating sharply, I could hear the system shutter and of course the positions were off.

In the beginning of the project, I suggested to the customer to run it in dual loop mode as you stated. My mistake was not being specific of how to do that. They purchased Ethernet/IP motion encoders for the non-driven wheels. From I've read, Kinetix 5700 dual loop mode only uses encoders attached to the one of the drives 2 ports. So I use those encoders to verify the virtual position, motor encoders are all reading the same.

My thought for recovery is to fault the machine. Do a "MRP" instruction moving the non-driven encoder value in the virtual actual position. Then allowing to clear fault and run.

???

 

[Peter Nachtwey]

Rockwell and Delta do things pretty much the same. You really shouldn't need a virtual axis since each axis has its own target position/ideal virtual position. The actual position of each axis should follow its own target position very closely. If not, the axis should generate a following error. This is standard on the motion card series.
You should check if there is a target position for each axis. There should be. Next check if there is a following error bit. There shouldn't be a need to do your own check.
The target position is a virtual position, so you don't need to generate another. If a tool is obstructed, only the actual position will be affected. After the obstruction is gone the closed loop control should try to make the actual position keep up with the target position.
It should be easy to move two axes from 2,2 to 4,5 where axis one moves 2 inches and axis 2 moves 3 inches. This should be a standard feature. We were doing this back in 1986.

I don't like any fieldbus encoders. The Ethernet causes feedback delays.