Lenghth vs Speed control for Drives

Hello every one, I am new to this site and posting for the first time too. in one of our machine we are using drives to cut different lengths of material for further processing. We have compact logix version 17 installed and a long ladder logix program is there for this. But still we have some issues of proper length. I want to program a PID controller for this purpose. Can some one help me out by providing me the tips of how to program this PID.

Thanks in advance

Length is an exact measurement, PID is a control loop algorithm that dampens overshoot and undershoot of a response to process change, not a way to attain an exact measurement. The two concepts are not exactly mutually exclusive, but what you are asking about is like trying to get your car to stop in the next town by setting the cruise control. They don't have anything to do with each other.

It sounds as if someone was trying to do a cut-to-length process by timing only, which is inherently inaccurate, now you are trying to cure the inaccuracies by trying to slow down the feed rate as it approaches the target length, thinking that the error is overshoot. That may not help, because if you are not actually measuring the length you are not removing the error, just your perceived CAUSE of the error, and that is not likely the only one. But if you ARE measuring the length and there is overshoot because of inertia, then that might be helpful. If you can describe the problem better we may be able to help, but otherwise we are just guessing.

PID is the last thing that you are looking for

If you answer these questions you will get a better assistance

1) What type of motor are you controlling (Servo, VSD, Stepper) (Motor drive model if possible please)
2) how are you controlling the motor - analog or comms or pulse output
3) How are you receiving feedback on product position? idler wheel resting on the product ? - analog, encoder (type)
4) Who controls the Decel and Accel rates - PLC or drive?

also search the forum for "cut to length"

Hi Michel G,

Reply to your questionnaire
1 It is Allen Bradley VFD
2 Speed is controlled through Analog O/P Card and controlled over by PLC according to length
3 Acc and dacc are independent and no control through PLC
4 Feed back is from encoders and high sped counter card scaled to length for accurate measurement.

Again we have overshoot which is controlled by running the drive in reverse and controlling the length accurately with in the tolerance. Only thing which bothers me is time taken for positioning the material for cutting.

So my idea was controlling the speed for a measured length once lenght is achieved PID will be disabled and will be enabled after cutting cycle.

May be it looks like a stupid question but to me there must be a way out for this, which I am looking for

I use very crude method for positioning using a VFD. The desired speed is proportional to the square root of the distance to travel multiplied by a constant.

You'll have to experiment to determine a proper value for that constant.. I also use a maximum speed on the high end and a minimum creep speed near the end before the stop.

It may speed up the positioning even if you do still need to make a slight backward correction.

Thanks Carlton for your valuable tip. Yes this can be done easily.

If you have an encoder that is being used to determine length, are you overshooting then just because the drive decel is making it over travel? That should be a MUCH simpler problem to solve. Just begin your decel process BEFORE you get to the end of the length you want, then as Bernie said, "creep" at a fixed slow speed of maybe 5-10Hz until you get there, at which time you engage the DC injection brake function to do a hard stop.

I did a program some time back (so going from memory) PLC was a 1100, Powerflex drive, I was using a prox and a star wheel for feedback/ pos. counter.
Run the VFD for speed "A" till counts=X, then change speed to "B" till, count =X, change speed back to speed "A" the stop at count "N" worked very well. I would think about changing the speed and slow down to creep into stop point. The key was to ramp up and ramp down, not just acc. & decel.

bernie_carlton said:

I use very crude method for positioning using a VFD. The desired speed is proportional to the square root of the distance to travel multiplied by a constant.

You'll have to experiment to determine a proper value for that constant.. I also use a maximum speed on the high end and a minimum creep speed near the end before the stop.

Click to expand...

+1

This is one method that will assist
Speed this scan = Sqrt( 2 * Decel * [move distance remaining])

The Decel value can be determined exactly - we would need analog scaling (Drive settings and PLC output) but as Bernie said experiment and you may not need to work it out

• If the value is too large you will overshoot
• If the value is too small you will undershoot
• If you have a mathematics error (reach the limit of resolution) weird stuff will happen

If the drive Decel or Accel parameter is changed then you must "reTune" this value

You can combine the creep in method
move distance remaining = Target Position - Overshoot

There is a whole bunch of physical stuff that can also trip you up

• Accel or decel rate is too fast so the product slips
• Product weight increases so the accel and decel rates are now limited by the drive limitations

I programmed something similar about a month ago. The system was meant to measure and cut material. It consisted of a CompactLogix with HSC, Powerflex, and VFD.
The HSC was attached to an idler pulley.

I ended up doing something similar to what others are suggesting - high initial speed and then slowing down before the end of the cut.

In my case, there were issues with the idler pulley not having a good grip on the material. If I remember correctly, there was some slippage, etc. This was causing some inaccurate cut lengths.

I was displaying final encoder counts on a HMI before the cut. Once everything was resolved with the idler pulley, I was getting consistent cut lengths (physically measured).

However, I always wondered if a servo wouldn't of been easier for this application (I didn't source the components). Is there a significant cost difference?

We don't know the mass/inertia.
We don't know the indexing distance or cut length.
We don't know the required precision.
Does the material stop when being cut?

The velocity=sqrt(2*deceleration_rate*deceleration_distance) formula calculates the velocity for THIS deceleration distance not the velocity for the NEXT scan and next deceleration distance. In other words the calculation is always a scan late.

How does one combine the calculated velocity with the error between the command and actual position?

PLC analog out put devices are slow.
The position feedback is read at the beginning of the scan, the calculations are done, at the end of the scan the control output is updated. That is a 1 scan dead time.

These factors make doing PLC motion control challenging.

The right way to do this is to calculate the time to ramp down time by dividing the velocity by the deceleration rate and computing the number of scan times. Now the decel_distance=1/2*decel_rate*time_to_go^2. Velocity=decel_rate*time. The time should be calculated for the NEXT scan.

cmsingh said:

Hello every one, I am new to this site and posting for the first time too. in one of our machine we are using drives to cut different lengths of material for further processing. We have compact logix version 17 installed and a long ladder logix program is there for this. But still we have some issues of proper length. I want to program a PID controller for this purpose. Can some one help me out by providing me the tips of how to program this PID.

Thanks in advance

Click to expand...

The bigger issue here has already been pointed out. You are trying to do position control with a velocity device. Square peg in a round hole.
This is a textbook positioning application. CAN you do it with a VFD?...perhaps...can you do it the same way, all day everyday with a VFD, and get the app tuned up and running in less time than a non-VFD? probably not.

Notice I mentioned "Very crude method". This is used for very slow systems in our case. It works sufficiently well in our appropriate applications.

jdbrandt said:

The bigger issue here has already been pointed out. You are trying to do position control with a velocity device. Square peg in a round hole.
This is a textbook positioning application. CAN you do it with a VFD?...perhaps...can you do it the same way, all day everyday with a VFD, and get the app tuned up and running in less time than a non-VFD? probably not.

Click to expand...

Agree.

bernie_carlton said:

Notice I mentioned "Very crude method". This is used for very slow systems in our case. It works sufficiently well in our appropriate applications.

Click to expand...

Touche'
It does all depend on the desired accuracy of the output.
After all, 2 + 2 = 5, with an uncertainty of +/- 1.