Multiple CLGX Processors

Hi, im using RS Logix 5000 to program a machine with 16 servo axes, and 170 I/O. Our scan times are usually around 15ms, with a max of 30.

Our goal is to spit out a product every 3 seconds. We are having problems reaching that goal (Currently around 5 seconds), and we are thinking that maybe the scan times are nickle and diming us to death.

I have read that you can use multiple processors with control logix, and im wondering how that works. Does each processor run a certain portion of code, or do the processors just share the burder?

thanks,

Steve

Hi Steve-
Each processor would run its own section or part of the total code required. It is reasonably likely that the motion axis control is what is causing the long scan times. If you are not running all 16 axes tightly coordinated you can split the axes across the processors and probably decrease the total scan time. There are ways to handle coordinated motion across multiple processors. I've never done that, though, and I don't think you get the benefit if you do that.
Is it the motion profiles that aren't completing as fast as you need or is it some high speed discrete action that is slowing you up?

Keith

Keith,

Our axes can easily be grouped in four axes. some of our axes moves we would like to take as little as 30ms to do, but the closest we could whittle it down to was 100ms. of course the timers we are using to measure the moves could be off by as much as a scan or two.

Another problem that could be affecting us is 3 of the axes arnt very well tuned, the 3 axes are on a ball screw, and we have very limited travel, so the auto tuning is unable to complete. we have manually tweaked its values to give us better performance, but I still dont think its 100% (any advice on manually tuning axes?)

so to answers your last question yes, it could be the motion profiles that are slowing us up, but I dont think it is to the extreme of 2 seconds off our desired target. My thinking right now is that with two processors reducing scan time, I might be able to gain 5 ms here and there which would eventually add up

thanks,

Steve

PERSONALY I DON'T LIKE TO CONTROL AXIS WITH CLX AXIS CONTROL CARD
IT'S THE OLD WAY TO DO IT

GET INTELLIGENT SERVO DRIVE LIKE THE DKC03 FROM INDRAMAT
AND SERCOS INTERFACE OR DEVICENET THEN YOU DON'T HAVE TO WORRY ABOUT SCAN TIME BECAUSE THE DRIVE HANDLE ALL THE MOTION ITSELF

ALL YOU HAVE TO DO IS GIVE THE DRIVE A SETPOINT AND WAIT FOR THE MOVEMENT TO BE COMPLETE

Assume Nothing. ( Where did I recently here that?)

SLY said:

PERSONALY I DON'T LIKE TO CONTROL AXIS WITH CLX AXIS CONTROL CARD
IT'S THE OLD WAY TO DO IT

GET INTELLIGENT SERVO DRIVE LIKE THE DKC03 FROM INDRAMAT
AND SERCOS INTERFACE OR DEVICENET THEN YOU DON'T HAVE TO WORRY ABOUT SCAN TIME BECAUSE THE DRIVE HANDLE ALL THE MOTION ITSELF

ALL YOU HAVE TO DO IS GIVE THE DRIVE A SETPOINT AND WAIT FOR THE MOVEMENT TO BE COMPLETE

Click to expand...

What do you think the PLC is doing when it commands an axis to move from one point to another?

Your intelligent drive controller may do a fine job at controlling one axis but how does it coordinate 16? Obviously there must be some master smarts some where beside the drive controller. In Rockwell's case it is in the Control Logix.

DeviceNet is fine for small applications but to get all the data the master controller near as fast or as synchronously as over the Control Logix back plane. The Control Logix is sort of like a sercos in the way information is synchoronously transmitted from the master controller to the axis controllers. The only issue I see between sercos and cards in the the control logix back plane is the 'field bus' issue. Not a performance issue.

The control logix has a MAM ( motoin axis move ) command that starts the motion and has a move complete ( I forget what it is really called ) when it is done. That is simple.

Steve, I don't like to play 20 questions but:

1. Have you calculated how long each motion should take? Provide Info.
2. Have you done a timing diagram? ( post .jpg or .bmp)
If you don't have one, go to the hall of shame.
3. Are you getting errors? Which?
4. How can you be off by 2 seconds and not see something obvious?
5. What is the RPI for the motion controllers? Isn't that just as important as the scan time?
6. What are the parameter you have for each of the MAM blocks? If the accelerations are too low then you may never get to the velocity you set and all the time is spent accelerating and decelerating.
7. Rockwell has table that show what percent of the CPU time each axis will take at different RPIs. So how much time does your CPU have left for ladder execution?

Get the execution time for each step of the cycle. Use the real time clock to save the time away at the beginning of each move and at the end of each move. From this you can build your timing diagram and compare it with your desired timing diagram. Then you can TELL us where the problem is.

Don't you think this information matters? I don't think that the CPU being overloaded would slow done the cycle time by another 2 seconds. The motion profiles should always take the same time.

Keith is right about the 16 axes being controlled from just one cpu.
16 axes will use up most of your cpu time. I just think you should find the real problem before spending money.

1. Have you calculated how long each motion should take? Provide Info.

Click to expand...

Yes. Right now we are doing triangular moves for most of the moves. We calculate the accelerations and deceleration needed so its acceleration 50% of the time and decelerating the other 50. we calculate this right before the MAM, and then tweak the numbers to account for S curving.

2. Have you done a timing diagram? ( post .jpg or .bmp)

Click to expand...

No, the thought gives me a bit of a head ache, but I guess its something I might have to do if I want to find where the hold up is. I have been using a spread sheet the engineers made up, but it is more or less a guide.

3. Are you getting errors? Which?

Click to expand...

no

4. How can you be off by 2 seconds and not see something obvious?

Click to expand...

A few of our moves are off by up to a few hundred miliseconds, but the sum of them is no where near 2 seconds. We have been trying to keep the servo acceleratoins under 2 G's which theoretically should be enough, but tomorrow I think im going to try to push them a bit harder.

5. What is the RPI for the motion controllers? Isn't that just as important as the scan time?

Click to expand...

You have to forgive my ignorance, im new to servo's. RPI is the update time? We are using SERCOS with AB Ultra 3000 drives, right now I have the course update period set to 16ms (1ms for each axis)

Get the execution time for each step of the cycle. Use the real time clock to save the time away at the beginning of each move and at the end of each move. From this you can build your timing diagram and compare it with your desired timing diagram. Then you can TELL us where the problem is.

Click to expand...

I didnt realize that you can use the real time clock, Tomorrow what I will do is figure out how to use it and then capture the time at each event in the process

Don't you think this information matters? I don't think that the CPU being overloaded would slow done the cycle time by another 2 seconds. The motion profiles should always take the same time.

Click to expand...

I agree, today I hacked and slashed at my scan time, managed to cut it in half, and I did not notice any significant improvement.

Thanks a lot for the help. This is the first time ive programmed a machine from scratch.

regards,

steve

WHAT ABOUT QUESTION 6?

I can calculate the times in my sleep so the MAM parameters would be helpful

Use a timer to time the whole cycle. Save away the accumulated time at each step.

2 Gs is a pretty fast acceleration.

Because you are getting no errors I the actual trajectory must be following the target trajectory without saturating the output. Therefore I think the target trajectories are taking longer than what you expect or the system is having a hard time getting into position and completing a move.

The coarse update rate of 16 milliseconds means that the PLC may have to wait upto 16 milliseconds to see a in poition condition. On the average it will be 8 milliseconds.

Make a chart showing the target and actual positions. Also save in the chart some timer information like a bit that goes on and off every 100 milliseconds so we have a time scale. Save the results and post it.

I wonder if the S curves are lengthening the acceleration or deceleration times. That wouldn't be good.

Are the axis moves co-ordinated? i.e. is there (or can there be) gearing or camming used? Reason for asking is that maximum velocities and accelerations of the slave axis are ignored with these functions.

Perhaps you could try programming a TCAM for the 30msec move. That should determine if the axis is capable.

The coarse update rate of 16msec. is as recommended at 1msec. per axis for an L55 processor. As I understand it, this is how often the controller compares command and actual positions and updates its output. 16 msec. is probably too coarse for a 30msec. move. I'm curious what times you're seeing for the motion group scan (typical & max.). I have a system with 6 axes plus 2 virtual axes on a L55 where I have set the coarse update to 10 msec. - typical scan is 5 to 7 msec. but occcasionally exceeds 10 (group overlap fault). If anybody reading this has some insight on that, I would be grateful.

Worst case

Gerry said:

I have a system with 6 axes plus 2 virtual axes on a L55 where I have set the coarse update to 10 msec. - typical scan is 5 to 7 msec. but occcasionally exceeds 10 (group overlap fault). If anybody reading this has some insight on that, I would be grateful.

Click to expand...

Each motion instruction takes a certain amount of CPU time to execute. This time is above the normal coarse trajectory processing time. Rockwell has table of the execution times for each type of motion instruction. Some of these instructions can take time to execute. I have seen a table of motion instruction execution times, but I can't find it in the manual. It is possible exceed the coarse update time when issuing commands to all axes at once. You may need to make your coarse updates a little longer to avoid this fault.

M02AE Manual

I agree that 16 milliseconds is too long for a coarse update as this allows only 3 points to define the motion profile. A 30 millisecond move is also impossible because two coarse updates require 32 milliseconds. I don't think s-curves or using TCAM is going to change that. More coarse points are required. I estimate that one should have about 7 coarse points minimum to do a point to point move do avoid discontinuities in acceleration. This would means that Steve needs a coarse update of about 4 milliseconds at most.

tweak the processors

You need to set up your processors for periodic instead of continuous
scan and also you need to check your processor's time slice setpoint.
30 mS should be achievable.