Motion Instructions synchronized movement

Hey Forum,

Im working on a project where I have to move a steel press up and down while keeping it level. My question is can I use some of the advanced motion instructions to move 4 axis in concert. I currently use my own system of checks with MAJ (Motion axis Jog)and MCD (motion change dynamics) commands because the drives don't move at quite the same speed and have various degrees of wear so I reference the encoders constantly.

Would commands like MAG(Motion axis gear) or MCLM(Motion coordinated linear movement) allow me to issue one command that would move all of them so they stay within half an inch of the other?
------------------------------------------------------------
I don't know if these commands watch position values and move accordingly or just output commands that should follow the path.

I can't find details on how the commands accomplish the movements like what values they watch and act upon aside from velocity output
-----------------------------------------------------------------

Any help would be appreciated.

System: rslogix 5000
1756-M02AE Motion axis card
encoder feedback

--Darkzadow

Create a virtual axis and CAM or Gear all the motors to it with the same cam.

You should be able to synchronize the four axis using any of the motion commands IF using TWO 1756-M02AE modules .

Once each axis is configured for one channel of the analog motion modules, then, as dskohio suggests, you could create a CAM motion profile referenced by all axis via four MAPC instructions.

Darkzadow said:

Hey Forum,

Im working on a project where I have to move a steel press up and down while keeping it level. My question is can I use some of the advanced motion instructions to move 4 axis in concert.(1) I currently use my own system of checks with MAJ (Motion axis Jog)and MCD (motion change dynamics) commands because the drives don't move at quite the same speed and have various degrees of wear so I reference the encoders constantly.

Would commands like MAG(Motion axis gear) or MCLM(Motion coordinated linear movement) allow me to issue one command that would move all of them so they stay within half an inch of the other? (2)
------------------------------------------------------------
I don't know if these commands watch position values and move accordingly or just output commands that should follow the path. (3)

I can't find details on how the commands accomplish the movements like what values they watch and act upon aside from velocity output
-----------------------------------------------------------------

Any help would be appreciated.

System: rslogix 5000
1756-M02AE Motion axis card
encoder feedback

--Darkzadow

Click to expand...

(1) Exactly what the "motion" system is designed to do - multiple axes "in concert"

(2) Think "half a millimetre", not half an inch, you can move them in near-perfect synchronism - but i have to ask why these press axes aren't mechanically linked ?

(3) Everything is closed-loop, you ask for a motion - the system delivers it. Providing the loading, inertia, and mechanicals allow it, the system will move it the way you program it.

Hey sorry I couldn't get back sooner got stuck on the plant.
Ok the gearing camming looks like it should do what I want it to.

Thank you dskohio, dmairgineau, and daba.
I should be able to puzzle out any trouble I have after trying this.

As for why they are not linked they were installed maybe 20-25 years ago and literally are 4 separate motors with 4 separate control systems.

So to summarize using cam or gearing to a virtual axis should allow for synchronized movement.

Just making sure even if one drive moves slower than the others the command should compensate and move all at the slowest drives speed.

Thank you guys again this helps immensely.

Darkzadow said:

Just making sure even if one drive moves slower than the others the command should compensate and move all at the slowest drives speed.

Click to expand...

That isn't what camming does, or any motion instructions that I know of. The motion controller should generate whatever reference is required to make the associated axis follow its target profile.

If you KNOW one axis is always going to be slow, or a problem, then use that as the master, and gear the others to it.

So camming will only produce the output to move the drives to a profile and not make sure that the drives are following it based on encoder feedback?

sometimes you do not know which one is going to have troubles keeping up with the reference

eg twin lifts on a crane 40 ft container - load spec is 60/40 out of balance but the load has shifted during transport to 80/20

Simplest way is to lock as discussed above - then monitor ALL of the following errors (Position Error) if any get to large then slow down the speed of the movement until the following error is within limits.

This is programming getting around design issues again


Camming is creating References - Physically one axis may have trouble keeping up with the reference - that is a tunning / design issue

Ok so gearing sounds like what I need cause i am using a simple 1:1 ratio with all drives to a virtual axis. I should then move using Move or Jog commands on the virtual axis and correct errors by slowing down using motion change dynamic.and as I understand from reading that using incremental jogs on the slave axis allows for fine positioning.

I apologies if I ask for this level of clarification I am literally just out of college with 0 functional knowledge of PLC and motion control.

This is why people buy better motion controllers

rdrast said:

That isn't what camming does, or any motion instructions that I know of. The motion controller should generate whatever reference is required to make the associated axis follow its target profile.

If you KNOW one axis is always going to be slow, or a problem, then use that as the master, and gear the others to it.

Click to expand...

Never gear to an actual or feed back position unless there is no other choice.
It is difficult for many motion controllers to determine the velocity and acceleration of the master so that feed forwards can be used. A virtual master is not hindered by feed back quantizing so perfect velocities and accelerations can be generated. The problem with some controllers is that the only the perfect virtual position data is used and often it is quantized back to counts for the slave controller.

Even when using tricks like models and Alpha-Beta-Gamma filters to compute the estimated position, velocity and acceleration of the master, from its quantized feedback, there are still errors. You don't want to gear to quantized feedback data.

I would use the virtual master idea and index through the cam table slow enough where no axis exceeds is maximum speed.

Using the slowest axis as the master doesn't always work. If one of slaves must move much farther so the ratio of the slave/master distance is high the top speed of the slave could be exceeded. One could a check to see which axis really should be the master. The slaves would have to have their cam table scaled so they move the right distance.

Example:
The master must move 2 inches and travels 2 inches per second.
The slave must move 6 inches and travels at 4 inches per second.
If the master makes the move in 1 second the slave will still only have traveled 4 inches. The master must be slowed down.

There are some motion controllers that can do this simpler.

Our controller has a SynchMovAbs command that where you can specify the the maximum individual speeds for all the axes and the controller makes sure no axis will move faster than its limit and still all the axes get to their command position at the same time. There is no need for cam tables or virtual masters.
A target position, velocity and acceleration are generated without feed back quantizing so that very accurate feed forwards can be used by all axes.

If the axes can't maintain a speed due to obstructions or load then we have our 'hay bailer' algorithm. The master axis can change on a scan by scan basis depending on which axes is trailing. The 'hay bailer' algorithm works well for presses. A roughly equivalent of the 'hay bailer' algorithm can be impended using cam tables if the following error for all the axes were monitored and the index into the cam table was slowed down if any of the axes got a following error. You end up with four position loops and one virtual index loop.