Beginner CLX PID question about update times

I am tuning a small drive that turns a flywheel and moves it to different setpoints.

As far as I know, the PID instruction should be in a periodic task on an unconditional rung, and the loop update time should be equal to the periodic task update time? Is this correct?

Assuming that's correct, the update time of both the periodic task and the loop update time should be 1/5 of the natural frequency of the system? Is this correct?

Assuming the above is all correct, how do I find the natural frequency of a rotating flywheel? I am using an AB VFD to drive the flywheel.

Is the natural frequency the RPI of the analog output card that goes to the AB Drive unit? Or the RPI of the HSC module? I'm a little confused here.

bump

Is the natural frequency the RPI of the analog output card that goes to the AB Drive unit? Or the RPI of the HSC module? I'm a little confused here.

Click to expand...

the natural frequency of the “system” (the mechanical/physical stuff) has nothing to do with the RPI of the controller's modules, etc. ...



as an example, you can see the “natural frequency” of the Hotrod system’s temperature loop in the figure attached to the following post ...



http://www.plctalk.net/qanda/showthread.php?p=27963&postcount=13



basic idea: IF (big IF) you crank the Proportional action WAY UP ... and turn the Integral action OFF ... and turn the Derivative action OFF ... and enter a reasonably high Setpoint (target) ... then get the system rolling, it will establish a natural period of oscillation - much like the pendulum on a grandfather clock ...

side trip: old-timers often call this oscillation effect “hunting” ... if you’ve ever ridden on a school bus with a speed-limiting governor on it you’ll be familiar with the idea ... the driver pushes the pedal to the metal - and holds it there ... the engine speeds way up ... the governor throttles back on the gas ... the engine slows down ... the governor relaxes ... the engine speeds way up ... the governor throttles back on the gas ... the engine slows down ... the governor relaxes ... the engine speeds way up ... and so ad infinitum ...

Click to expand...

CAUTION NOTE: in many cases, it is NOT SAFE to do what I just described ... some mechanical industrial systems will tear themselves apart if you get them to oscillate this way ... we’re just talking theory here ...



but anyway ... once you know the system’s natural period of oscillation, the customary “rule of thumb” is that you should execute the PID control at least ten times within that period ... more often is better ...



in reality, many programmers just trigger the PID into execution about once each half second and get on with their lives ... if your system is especially fast (high rate of oscillation) then you might have to increase the rate of triggering the PID in order to get good control ...



next thought - since you mentioned the terms ... you’ll want the RPI settings for your input and output modules to be set fast enough to accommodate the PID’s rate of execution ... most programmers would have the RPI updating at least several times during each period between PID executions ...



finally ... personally I’m a little bit fuzzy on how you’ve described your system ... moving a flywheel to different “setpoints” with a VFD just doesn’t sound like a “good fit” application for PID control ... but maybe (probably?) I just don’t understand what you’ve written ...



anyway ...



it would probably be a good idea to repost with more detail about what you’re trying to control ... the more we know, the more we can help ...

I thought I had responded to this? Oh well

PLCDontUQuitOnMe said:

I am tuning a small drive that turns a flywheel and moves it to different setpoints.

As far as I know, the PID instruction should be in a periodic task on an unconditional rung, and the loop update time should be equal to the periodic task update time? Is this correct?

Click to expand...

Yes, doesn't the drive have a PID with auto tuning? That would be easy.

Assuming that's correct, the update time of both the periodic task and the loop update time should be 1/5 of the natural frequency of the system? Is this correct?

Click to expand...

Unless you have a compliant load you should only have a time constant for the inertia. It takes 5 time constants to get to the velocity set point if the set point is changed instantly. The same time should be 10 times shorter than the time constant.

Assuming the above is all correct, how do I find the natural frequency of a rotating flywheel? I am using an AB VFD to drive the flywheel.

Click to expand...

You don't. You find the time constant. Finding the time constant is similar in motion and heating applications so Ron can help you out there.

Is the natural frequency the RPI of the analog output card that goes to the AB Drive unit? Or the RPI of the HSC module? I'm a little confused here.

Click to expand...

RPI has nothing to do with the time constants or natural frequency. The requested packet interval is an Ethernet feature. You shouldn't be trying to close the loop over Ethernet.

Do you actually have a speed feedback signal from the flywheel ?

If not, you'll be using the actual speed value from the drive, which is just the frequency of the motor current sent to the motor, not a measure of how the flywheel is turning.

If you don't have positive feedback, there is absolutely no need for a PID controller, just send your setpoints to the drive and let it increase/decrease frequency to match the setpoint. You can set drive acceleration/deceleration time and shape (Linear/S Curve) to suit the load (I would suggest S Curve if available for a flywheel application).

Sorry for the late reply. Yes, the flywheel has an encoder on the drive, which is read from a HSC module.

I have found the natural frequency of the system using the above-mentioned procedure and found it to be about 1 second, or a 1Hz oscillation.

So I've set the loop time and the periodic task time to 50 ms.

Now I'm having a different problem. Using just proportional gain, I can get the flywheel to rotate to setpoints quickly, and with a fairly small error. My Kp is around 120.

Unfortunately, when I add in any significant Ki to the Kp, the system begins overshooting terribly, and also overshooting on the way back, ie: it begins oscillating wildly.

This is starting with a Ki of 1. If I bring that Ki up to 10 the oscillations are ridiculous.

Dropping the Ki below 1, yields very poor results, as it takes around 5 seconds or so for it to build up enough integral to actually begin moving the flywheel towards the setpoint, and once it moves, it recalculates the integral I think because it stops, then builds up some more, and moves closer to the setpoint, then stops again. With this process it will take 30 seconds just to get to the setpoint, when I could have gotten there much faster with just Kp.

It's like, if you use enough Ki to actually attempt to correct the steady state error with any kind of speed, it will overshoot and do more harm than good...use very little and it will correct the steady state error, but it will take forever. There doesn't seem to be any middle ground. Maybe there is an error with my scaling???

Also, adding Kd doesn't seem to help at all, just creates a greater overshoot.

Although I think the problem is something more than just tuning, what ratio should I be looking at for Kp:Ki:Kd? 100:5:3 or something like that?

One more question: Do you need to toggle the PID initialization bit every time you change a setpoint. I read somewhere about this helping with the integral function of the PID instruction.

Shameless bump