CLX PID control using line speed parameter

[jim767]

Michael, I'm working with a CLX L61 Allen Bradley.

 

[MichaelG]

Nice PLC platform. I use the CLX often.

The help files in RS5000 have a cascade PID, however in your case as the master loop is distance driven, I think that you may have to write your own PID - I do not have access to a controller to test if the PID can be fooled into thinking that it is being called on a time basis. (ie set the loop update time to 0.1s and call whenever you want)

If you can fool the PID then your code would look something like

If you have to create your own PID then you would need to research the PID equation to use: Other research terms for you to google are "velocity PID", "event driven PID" and "difference PID equation"
I would write a simple PID controller using the above equations but I am sure that Peter Nachtwey has his own favourite equations
Some interesting PID links that I have found researching for you
http://bestune.50megs.com/typeABC.htm

http://www.developer.com/tech/article.php/10923_1381491_3 Java implementation - I'm interested why they use Runge Kutta for the integration on page 2.

http://www.artes.uu.se/project/7/arzen1999.pdf Event triggered PID

 

[Peter Nachtwey]

I like the Bestune version C for the inner loop which is the position loop. The problem I see is that most PLC PID have their time constants in minutes instead of milliseconds.

For the outer loop, version C may is probably the best but now one must think in terms of distance constants instead of time constants.

Fortunately the Contrologix has compute blocks or structured text.

BTW, this application has got me thinking about how we could do this application on our controller. Currently our PIDs are time based. We would also have to use 'compute blocks'. In the end this may be the best solution because in the over 20 years we have been making motion controllers, this is the first time I have come across an application where a PID needs to executed as a function of distance.

Note, Bestune makes it very clear that they think version C is the best. I agree IF the SP is changed in steps or erratically by an outer loop. If someone is interested in why one would want to use version A or B then post a new thread with Advanced Control in the title.

 

[jim767]

Michael/Peter,
I have written some code and tested it with a single PID instruction which works great and I am going to try also with the cascade PID you have provided. I would like to post the code and provide some explaination of how it works. It's a stepping type action based on material footage passing. ***Could you tell me the best method to post it like you have above.*** I will be getting back to this after another project and will be implementing it sometime in January but I want the best possible method. Thanks

 

[JRW]

Jim767,

I didnt read all the other posts so if this is mentioned- Sorry

I did a guider system similar to yours. It was a tenter entry guider. It used a banner analog sensor and an inverter to make the guider follow the material edge. (one on each side)
Anyway all I did was a PID (limited to +-10% output) and I multiplied the line speed by the PID output. There was also logic for manual IN/OUT and limits for max in and max out.
It worked great.
My two cents

 

[Peter Nachtwey]

Oooh, a combination of ideas.

Anyway all I did was a PID (limited to +-10% output) and I multiplied the line speed by the PID output.

I don't think this would work for jim767's application. Limiting a PID to +/- 10% sounds a little arbitrary and scaling the output by the velocity doesn't help because the integrator will still wind up and when the system starts moving again the output will be at saturations. ( which is why you limited the outout to +/- 10%. Not good.
However, you have an excellent idea in scaling by the speed. I would scale the error by the speed, not the output. This way the integrator will not wind up when the line is stopped. The integrator will be stopped at its current value. Mathematically it should all work out the same as my distance constant idea but the advantage is that now you can use the PLC's built in PIDs. For the outer loop PID I would always have the PID SP always set to 0 and I would set the error to ( PV-SP )*(Speed)/(TuneSpeed) where the SP is the true set point ( desired position ) and PV is the true PV ( feedback position ). In other words I would use the PID PV as an error signal and not a actual feedback value. Note, all I am doing is subtracting the SP from the SP input and the PV. This way the error resulting error remains the same if the line is running at the tune speed.

The TuneSpeed is the speed at which the outer PID is tune. This is important. I like threads like these.

 

[JRW]

Thanks Peter,

You might be right- it may not work for Jim, but..

Actually the +-10% trim is so the PID doesnt have full control, if the cloth or material is farther from the center of the sensor BUT the line speed is slow, the guider moves slower to the center and vice versa.
The trim idea is from web or converting control when a dancer or load cell is just trimming tension.

The PID is put in to manual or "turned off" when the line is stopped. This prevents wind-up in my application. Also the gain can be made adaptive according to line speed. (I never tried that though) but for winders it is.

 

[MichaelG]

Ohhh Peter what an idea!!!
Effectively making the master loop distance independant, the PID Gains speed dependant, allowing loop tunning to occur at a suitable base speed that should work for all speeds AND permitting use of existing PLC PID's - all in one hit.

Jim767 - practically you will require a good speed feedback device for the web speed (encoder or tacho). I.e. need to be able to measure slow speeds accurately (read smoothly)

On another note Jim I notice that you keep on referring to your feedback and setpoints in raw units (mA or V), I convert these raw units to engineering units as soon as possible. It makes the loop setup easier and when I look at a PLC tag value I know where I am in position, I do not have to do the conversion in my head. When I am not using engineering units (millimetre, foot, m^3) I use percent.

PS - to attach files see the FAQ
http://www.plctalk.net/qanda/faq.php?faq=vb_faq#faq_vb_read_and_post

 

[kamenges]

Unless I'm missing something scaling the error or output by speed is the way that the bigger web guide players do this (Erhardt + Leimer, Accuweb, Fife, etc). This seemed to work well in the cases I used it. Emulating this should be pretty successful.

Keith

 

[Peter Nachtwey]

I realize this problem has been solved many times.

I just reinvented the wheel.

Unless I'm missing something scaling the error or output by speed is the way that the bigger web guide players do this (Erhardt + Leimer, Accuweb, Fife, etc).

I doubt they scale the output. Scaling the error by velocity is the only way that makes sense if one wants to avoid the integrator windup problem. I realize that there have been a couple people that say they disable the integrator while stopped but what about when moving slowly, very slowly?

There is little that we do that hasn't been done before. In this case I searched the for PID and velocity scaling. I couldn't find any info on it. Sometimes people like to keep their tricks secret.

The 'distance constant' idea was obvious to me. Using the velocity for scaling was not, but it works out to be the same since the PID update rate x velocity = distance. It was also obvious that the integrator time constant much change as the speed changes. Scaling the output by velocity doesn't do that. Scaling the error by velocity effectively does.

 

[kamenges]

Originally posted by Peter nachtwey:

It was also obvious that the integrator time constant much change as the speed changes.

I don't think the web guide guys use an integrator in the outer loop of their guiding systems, at least not in the general purpose, off-the-shelf stuff. The systems are geared up so high and the design deadbands are so large that an integrator in the outer loop wouldn't get you anything. I suspect they all make specialty systems that do use outer loop integrators but most don't.

That being said, Peter is correct. The easiest way to influence the outcome in the desired manner is to scale the error. It allows everything else to stay the same.

Keith