Gantry Synchronization

[Ken Roach]

kvogel and baldone, and as always Mr. Nachtwey, have given solid advice about gantry control using gearing features of the motion control system.

Every multi-axis controller includes a gearing function of one type or another. Sophisticated ones have features that are specifically meant for the control of parallel axes. Check out, for example, the automatic skew elimination feature of the Delta Tau PMAC at 1:20 in this YouTube video [link].

With ControlLogix integrated motion, the Motion Axis Gear (MAG) instruction is the basic feature used to control parallel axes. You can gear one axis to the other, or you can gear both of them to a virtual axis.

Initial alignment of machine tools is a field of endeavor all its own; most gantries use hard stops and at least a few points located by a laser tracker to determine the home position of each servo axis.

I just got back from doing some work on a sixty-foot gantry system using Kinetix 6000 amplifiers on SERCOS with ControlLogix 1756-L61 controllers, and the MAG instruction is the basic function we rely on to keep the two sides of the gantry running together.

 

[benaiahhenry]

I had a conversation yesterday with a RA motion technician and he said that he has also used both direct gearing of the slave to the master as well as both to a virtual. He also mentioned that one way of correcting for error is to monitor the following error and if it gets to large, to issue an incremental MAM move on top of the gearing on the lagging axis to bring it in line. Has anyone here used that type of correction method before and have any feedback on how well it works?

 

[Peter Nachtwey]

Every multi-axis controller includes a gearing function of one type or another. Sophisticated ones have features that are specifically meant for the control of parallel axes. Check out, for example, the automatic skew elimination feature of the Delta Tau PMAC at 1:20 in this YouTube video [link].

The skew elimination is easy. Simply give a MAM to the average, min or max of the two positions. I see nothing special there.

I was more interested in the adaptive control with the load change. They show the graph of the motion but not the control output. I can tell what they are doing by comparing the control output with the actual movement.

The first example where the cube is moved without it vibrating is an example of input shaping. This was developed by a company called Convolve.
http://www.convolve.com/player.php?id=Introduction+to+Input+Shaping
A person from Convolve visited us in the early 1990s. There is only so many ways this can be done. What isn't said is that one needs to know the frequency and damping factor of the cube on the stick. The algorithm is slick though. When using input shaping the motion profile can be a crude trapezoidal motion profile and the resulting motion will still be smooth in operation. It is easier to see what is happening if the object that is vibrating is vibrating more slowly.

I had a conversation yesterday with a RA motion technician and he said that he has also used both direct gearing of the slave to the master as well as both to a virtual.

It really makes me cringe when I hear things like that. The reason one gears to a VM instead of the another axis is that the position, velocity, acceleration and even the jerk are perfectly generated by the VM. When gearing to another axis the encoder data must be differentiated for the velocity, acceleration and jerk. This is not easy to do unless one has a special bag of tricks. The quantizing error gets to get huge. This prevents one from using the acceleration and jerk feed forwards.

He also mentioned that one way of correcting for error is to monitor the following error and if it gets to large, to issue an incremental MAM move on top of the gearing on the lagging axis to bring it in line. Has anyone here used that type of correction method before and have any feedback on how well it works?

Using a superimpose move to keep two axes in synch works. However one should alway give a superimposed move to the axis that is ahead to move back to the axis that is behind.

 

[benaiahhenry]

It really makes me cringe when I hear things like that. The reason one gears to a VM instead of the another axis is that the position, velocity, acceleration and even the jerk are perfectly generated by the VM. When gearing to another axis the encoder data must be differentiated for the velocity, acceleration and jerk. This is not easy to do unless one has a special bag of tricks. The quantizing error gets to get huge. This prevents one from using the acceleration and jerk feed forwards.

I see, that makes sense. The less error in what your gearing to, the better

Using a superimpose move to keep two axes in synch works. However one should alway give a superimposed move to the axis that is ahead to move back to the axis that is behind.

I've never controlled this type of configuration before so I don't know all the dynamics in play here. What is the reason for retarding the axis that is ahead rather than advancing the one that is behind? Is it to not over stress an axis that is already lagging, or something like that?

 

[Peter Nachtwey]

Is it to not over stress an axis that is already lagging, or something like that?

You got it. Usually the axis that is lagging behind can't keep up for a reason.

 

[coa]

Kinetix 6000 may not have torque control/sharing function. That's why Rockwell tell you with gearing function.