Hi All,
I want to control a gantry axis with two AC rotate motors, one on either side of the gantry beam. The specialities and the performance I want is described as follow:

Specialities:
1. Span of beam: 1m
2. AC Servo Moter: two Sanyo AC Motor,1kw, Max speed:4500/rpm, 2000 pluse/r INC encoder.
3. Motion controller: Galil DMC-1842
4. Load weight:30kg
5. Pitch:20mm

Performance:
1. Speed: 1.28m/s
2. Accelerate Speed:2.6G
3. Position precision:0.01mm

I have tried several method suggested in this forum.

1. Position control mode
Since the position control with DMC-1842 is open loop, I send the same command pluse to the two driver. The result is acceptable except the noise and the jerk with short distance position. When the motor moving with high speed, the noise is too loud. I have tried to tune the filters in the driver but the effect is not satisfied. Another problem is the jerk. For example, the moving distance is 20mm and the speed and the Acc is same as above, the moving time is about 66ms in theory. I can achieve this in about 75ms, but the jerk is hard. I tried to use S curve to eliminate the jerk but the moving time is not satified. Can anyone give me some advices to solve these two problems?

2. Velocity control mode:
In this mode I tried Master/Slave mode which is suggested by Galil. The performance is nearly with mode 1. But when I servo off the motor, the two motor will shift a litter. I think the two axis may fight each other. I want try to send the same command trajectory to both side but since the velocity mode is close loop, I don't know how to tune it and how to connect the loop. Can anyone give me some advices? Thanks.

 

I don't know what the relative strengths and weaknesses of the Galil controller are - it sounds as though you have found a few weaknesses in it's design in this application.

We have accomplished gantry applications with both single motors at either end of the gantry (2 motors and 2 drives total) and 2 motors at either end of the gantry (4 motors and 4 drives) using a Delta Tau controller.

These gantries ranged from a 15 tons to over 80 tons and speeds varied from 4m/sec down to .5m/sec for the largest and heaviest machines. These systems are capable of 1G acceleration generating less than 0.005" following error.

Drives are operated in torque mode and the command from the trajectory generator (motion program) is fed to multiple PID loops simultaniously through a simple feature available to all Delta Tau controllers involving the coordinate system definition.

The master slave arrangement is a poor way to control this kind of mechanical servo arrangement. The slave will follow the master's encoder which will be once removed from the master's commanded trajectory. Invariably as you push the system the master will develop following error which will then manifest itself as an imperfect command for the slave to follow resulting in the "crack the whip" response you are experiencing as jerk.

I am not sure how married to the Galil controller you are, but I have found that while using the most capable controller might sometimes be overkill in some applications, that in cases like this, you can't afford to spin your wheels forever trying to beat something into submission that was never really designed for that kind of application to begin with.

As a wise old sage once told me, "You can't make Chicken salad out of Chicken manure". . .

Cheers,

Ken Brown
Applied Motion Systems, Inc.

 

After giving this a little more thought, I realized that while it is easy to poke holes in another's design, it would be more constructive to give a little more detail on an appropriate design for this kind of application. I should have done this the first time around.

The following is based on your presentation of the design (with holes filled in with assumptions when information is not clear).

Taking a step back it looks as though you are generating your command in the Galil and sending it to the Sanyo amplifiers as step/direction information. This means that the actual position loop is being closed in the amplifier. I will discuss this later.

Also, you mention 20mm pitch (interpreted to mean 20 mm travel per revolution of the motor) and a 2000 count / revolution encoder feedback.

Position precision is ??? Is this the desired performance or a statement of the existing design?

If this is a 2000 line count = 8000 quadrature count encoder which I think is pretty standard for Sanyo Denki motors, you have 8000 counts / 20mm = 400 counts / mm = .0025 mm per encoder count. Your desired accuracy is .01mm leaving you with a maximum following error allowance of 4 encoder counts... (a very small number of counts).

If I have misinterpreted your encoder resolution... all the worse as then you would only have 1 encoder count of allowable following error before you exceeded your desired precision.

As far as closing the loop in the Sanyo Denki drive is concerned - for this to work properly, you would need to run the pulse / direction command directly to each drive in parallel and run identical gains in each amplifier. Without knowing the stiffness of the drivetrain / gantry arrangement, it is difficult to address the homing / offset details, we typically design the system with enough stiffness to run the system with one motor at a time as required to do homing and then close the position loops on both motors and apply position offset to correct non-orthoganality that may be present due to drivetrain misalignment after each motor is homed individually.

Also unknown is at what rate the Sanyo Denki amplifiers are closing the position loop and what do they do with the step/direction command as far as any slewing or inter-loop closure interpolating. You can introduce a whole host of problems here if the loop is too slow and another set if the loop is too fast.

As I think about this, another unknown is whether the Galil is commanding step and direction without any feedback (i.e. the step and direction commands are derived directly from the trajectory) or is the Galil using the feedback and a servo loop to drive step and direction from following error?

When you have a system that must accelerate aggressively while having path accuracy, you most certainly need acceleration and velocity feedforward terms in the PID loop. Given the coarse resolution of your system (relatively low encoder counts per linear distance traveled) these feedforward terms require differentiation of the commanded position and when you differentiate the command for velocity feedforward or double differentiate the command for acceleration feedforward, you will invariably get noise when you run with low resolution systems.

Without the feedforward terms, you cannot expect to achieve path accuracy when pushing the system as hard as you would want to push it.

As you can see, there are lots of variables and questions about this kind of design and proper specification of control architecture and components.

We are getting ready to ship a system with 32,000 lbs of thrust generated by 4 linear motors that will employ 0.5 um feedback for a large machine tool X-axis. This system is serial #10 for us as far as gantry control systems go... we have learned a lot along the way and while I am certain that your motion control vendor and manufacturers are confident that they can do these kinds of applications with the hardware you are using, I think you will have a rough road ahead trying to accomplish the accelerations you have described with any kind of accuracy and smoothness.

If given the motion spec’s you have listed, I would ditch the pulse/direction interface and run with amplifiers designed to take a torque command and select a motion controller with feedforward terms that are interpolated internally to increase command and feedback resolution (so that any differential operations are done on high resolution/smooth data). You will find that you will be able to achieve much better path accuracy, quieter operation and perfectly robust positioning right up to the current limit of the amplifiers.

Ken Brown
Applied Motion Systems, Inc.

 

Hello Mr. Brown,
Thanks for your help. First I'll answer some questions you aren't know clearly.

1. The counts is 8000 counts/r.
2. The Position control mode I mentioned is an open-loop mode. It means that the Galil only send the step and direction command without any feedback. Just like the way to control a step motor.

But I stll have some questions.
1. You suggest to use torque mode. I want to know why? Is there any weakness when using velocity mode with gantry?
2. Supposing I send the same torque command to the both drivers and each controller has its own close-loop. if one of the motor's specialitis has a litter different with the other, there must have position error between two motors. As the torque command is same, the following error will not be eliminated. Is this right? I'm waiting for your reply.

Thank.
weblight
2005/8/6

 

Ok - first off - this is a very poor way to control a gantry if you are worried about wracking. If you send a step command and the motor does not accomplish the step then your controller does not know there is a problem.

Assume that one motor has bound up for whatever reason. The controller will continue to happily command motion on the other motor, leading to severe wracking, possibly including mechanical damage of your system (I have seen this happen).

As to torque mode - there are a couple of weaknesses to velocity mode, and the main one here is that you have to tune your loops in two places - the velocity loop in the drive and the position loop in the controller. Both loops are load dependent, so if your load changes you may have to be able to do real time gain scheduling (for example if your gantry picks up a significant load - you now may require two sets of parameters - one with the load and one without. And if your gantry runs with the load on one end of travel you may need to have one set of gains with and without load at one side of the gantry and another set of gains for the other end. If your drives are in torque mode then you tune only the current loop at the drive - which is load independent, and generally provided by the drive/motor manufacturer. The rest of the tuning is at the controller end, and you can easily run code to do real time gain scheduling.

This assumes that
a) your controller can close the loop quickly enough - I recommend 2 kHz as a minimum for torque control b) your drive is reading the torque command AT LEAST as fast as the controller is updating the loops - preferably two to ten times as fast.

Typically each motor will have its' own drive and feedback, and the controller will be monitoring position for each motor. If one motor falls behind the other then the controller will increase torque to that motor until it catches up. If the position differential between the motors becomes too great then the controller will halt the motors then issue a fault and will let you know what is happening so that you can determine what needs to be done.

Davis Gentry
Delta Tau Data Systems