Mapping/Buffering Motion Axis on CompactLogix

I have always used mapping to buffer IO to avoid random program hiccups caused by changing inputs in the middle of a program scan.

Now I am doing an integrated motion project that has 2 axes in a motion group. I do not map/buffer the axes, but use them directly in commands such as MAM. I have not found anything saying whether it is necessary to map since the Axes are not the actual IO tag of the Kinetix 5500 drive.

Twice I have seen the machine on startup go to a 0 position when it was instructed to go to a position such as 200mm. I am not sure whether to blame this on lack of mapping of the motion axes or something else.

Do the Axes synchronize with the program scan or is it necessary to buffer them?

Hi Archie,

If you send me a copy of your program I may be able to help.
(Only Studio 5000, v21, v28, v29 or v30)

Bye

Jose

I'm not saying that this is the problem now but most motion problems I have had have been because either a motion tag was used more than once or was left in a weird state before repeating a sequence. Out of sheer paranoia these days I nuke each of my motion tags with a clear instruction before using them again.

Also make sure you are using the correct status bits PC, IP, DN. The usage is inconsistent across the instructions.

I verified all the motion command tags were only used once.

I ran this multiple cycles and about every 10th cycle it just takes off to where ever it wants to go. I even noticed multiple times it would move in the wrong direction for a few mm, then turn around and go to its target. I put some debug code to make sure it wasn't giving a Home command and make sure the position was set prior to triggering the move command. Nothing turned up.

For something random to try, I put in a 100ms delay from the time the MSO was issued and the Enabled status returned until the MAM was issued. So far it has not done any of these strange moves. Very possibly a coincidence, but so far I have been unable to repeat the problems.

Archie said:

I it would move in the wrong direction for a few mm, then turn around and go to its target.

Click to expand...

Not sure about the rest, but the above may be due to improper axis tuning

Regards

chavak said:

Not sure about the rest, but the above may be due to improper axis tuning

Click to expand...

I did suspect that because you could hear the motor hunting. I backed off the gains and the hunting stopped, but the random motions continued.

I ran this machine at least 25 cycles since putting in the 100ms second delay and not once did it do the backing up or going to the wrong position. I did checked the program cycle time and it is 0.8ms which is less than half of the motion group update period of 2ms. My suspicion is now leaning toward the program changing commands faster than they are sent to the servo.

3. Group Axis time is 1msec for each axis + 2 msec
a. Example 4 axis
i. 4 axis x 1msec +2 msec = 6msec for the base update period.

I am thinking your course update time is not set right.

If your autotune is not working out for you where you get hunting, try to manually tune the axis.

A couple of comments, based solely on my experience, take it or leave it.

1. The recommended MG CUP Jim mentions is a fine starting point. I've gone faster than this calculated number without issues many times, but do tend to work on systems with higher-end CPUs (L7s and L8s) which I believe makes a difference.
2. Auto-tuners are generally pretty conservative. The results work for many applications just fine. Some have an "aggressiveness" or compliance factor which can help. If you need high-performance, you'll often find you can do better with manual tuning. Note that with ControlLogix you do NOT have access to all parameters used by the control algorithm. If you auto-tune, make note of the parameters and then do some manual tuning, then manually restore the auto-tune parameters, you do not usually get the original performance. Auto-tuning again corrects this. I had one customer bring me in to re-tune a 1yo system that was giving them trouble. I increased the auto-tune proportional gain 1200x (that's not a typo) on an axis with a very robust mechanical design, fixed all their problems. They had a number of identical machines with similar low-tuning gains and we fixed them all.
3. Perhaps because of #2, axes can be corrupted not only in the project but in the controller/CPU resulting in strange performance issues. One thing you should NEVER do is copy an axis in a project, always create them new from scratch. If you suspect a corrupt axis, delete it from the project (and all the associated code) and download to the PLC to clear it from the CPU as well. This may sound silly, but it's required. I actually made a blank hardware-only config to download to clear all axes info from the CPU the first time I fought this. Once you've done this re-create the axis (or axes) from scratch, import your code and download the project.
4. Make sure your system is mechanically capable of performing the move you are commanding. I've seen this many times before, either the engineer doesn't completely understand the motion instructions or is over-optimistic about system capabilities. This is especially true with large inertia loads. Often times you'll end up cranking open the position and/or velocity following error windows to avoid those faults, but that can also effect real-world performance, especially with multi-step motion operations. Note that auto-tuning also auto-sets the following error values. I've had to program SSVs to set those values due to overly-eager maintenance folks with over-confidence in auto-tune.

Cheers,
-Brad

A trend showing the command, target, actual positions and control output would avoid a lot of guessing.