Allen-Bradley PIDE

Hi Guys!

I'm having problems getting the AB PIDE block to actually regulate anything, it seems to be the same problem everytime I try to use one

This is what I have:












As far as I can tell it's a copy of other PIDE we have, that are infact working.

The MUL blocks are only to get a greater number to work with.

SO What am I doing wrong? Any ideas?

Regards,

Michal_dk

Try just forcing ProgProgReq high all the time (True). Then see if you can get the loop to run by switching the ProgAuto command True.

Also, in the tag itself (Parameters), make sure that NO OTHER xxReq bits are True!

If I'm not mistaken, does this instruction use the velocity form of the PID equation? I tried to use it for steam turbine governor control, and ended up going back to RLL PID.

Greetings Michal_dk ...

sorry I don't have more time to dig into this - but the link below has some PDFs attached that might be helpful ...

http://forums.mrplc.com/index.php?s=&showtopic=14562&view=findpost&p=71278

just a suggestion, in addition to the screen shots, it would be a good idea to also post a copy of your .ACD program ... that way we can dig deeper "behind the scenes" ...

just a tip: notice that your PIDE was in the Manaul mode when you did the screen shot (could that be part of your problem?) ... sometimes it's helpful to temporarily disconnect all of the "mode select" inputs - and just write the proper slections directly into the "parameters" ... once you get things moving along, put the operator, etc. controls back in one at a time ...

hope this helps ... wish I had more time ...

I don't know what's difference, but I user SPover, operAutoReq, operManualReq instead of 'prog' ones.

A couple of things to try

I don't understand why you are scaling your SPProg to 1000 when you have the SP High limit set at 200 (page 4 of 9)
I also don't understand why you have a scale block on the CV with the right values in the parameters you should see a range 0 - 100. You have the max output set to 90 yet with 10% from the PID I see 90 at the output of scale block
In short you shouldn't need either scale block, PIDE takes care of that.
I would dissconect the 3 discretes from StartRegulating tag until you get it working, You can toggle the bits one at the time through Rslogix5000
Have you included a rung in the main program to execute the PID routine?
Try putting your Setpoint into SPOper, perhaps for some reason it's using that setpoint rather than SPProg
Try deleting the block and do a copy paste form one that works.
The PIDE is great when it works but with so many parameters not well explained it can be a bit of a struggle.

Thanks Guys,

There's a lot to look into. I have attached my program as it loogs at the moment, what it does is to control the vaccuum in a large wooden box to test the forces the wind will excert on roofing material.

And no, the Auto tag was True at the time of testing. The screen shots were taken at home while offline, in my spare time (It's my wife to the right)

The scaling blocks are used only as a sad attempt to get things working, I had the brilliant idea that my values migth have been too small to actually regulate on (ranging from 0-2)

Now I'm going to have to look into that very extensive PIDE explanation Ron, has kindly posted. I seem to have been wanting that post for a long time Thanks Ron.

I hope I'll get some time with the system today, but am unfortunately scheduled for training and a customer visit.

But I'll let you know, how it works out.

Regards,

Michal_dk

I think I got it

See the difference between this screen dump and the second one in my earlier post


There is a smalle difference between Real Time and Periodic But what is the difference?

Regards,

Michal_dk

Michal_dk said:

I think I got it

There is a smalle difference between Real Time and Periodic But what is the difference?

Regards,

Michal_dk

Click to expand...

DOH! Didn't even notice that!... Yes...

Periodic timing mode is what I generally use, and I either run the PIDE off of a continuous, periodic timer, or more often, stick it in a periodic task. In Periodic mode, the PIDE essentially figures out the time between executions of the instruction to determine it's timebase.

With RealTime sampling, it is actually looking for a directly connected analog input PV, which provides a timestamp for every update of the input. That way, the PIDE executes in synchronization with every updtate of the PV Analog input. Generally, this isn't required in most applications, and has an additional problem that if the analog input timestamp differs by more then 1ms from the internal RealTime clock delta between two calls to the instruction, an error bit will be set (RTSMissed).

The best, and most common case, is to use the PIDE in a Timed, Periodic task (in Periodic mode), as using just timers you can get 'jerky' response out of the instruction due to varying delta-t's between calls.

"Oversample" mode is similar to periodic, except that you manually enter a timebase in the instruction (OversampleDT), and it will update every time that timebase expires internally.

Well I haven't figured out just how to use the Quote function yet, so:

rdrast wrote :

[The best, and most common case, is to use the PIDE in a Timed, Periodic task (in Periodic mode), as using just timers you can get 'jerky' response out of the instruction due to varying delta-t's between calls.

"Oversample" mode is similar to periodic, except that you manually enter a timebase in the instruction (OversampleDT), and it will update every time that timebase expires internally]

That also solved the next question I had: Why does my CV value "overshoot" that is it reaches 100% and briefly goes to 0% and then up again - Thank you very much

Michal_dk said:

That also solved the next question I had: Why does my CV value "overshoot" that is it reaches 100% and briefly goes to 0% and then up again - Thank you very much

Click to expand...

That is because your tuning is very aggressive. The control output saturates because it is trying to reduce the error but it limited by the amount of available power. Then the rate of change starts to increase. The derivative term then tries to slow down the rate of increase so the process value does not over shoot the set point. The derivative terms will go negative and offset the other other terms until the rate if increase in the process value slows.

Ok!


It is very aggressive I have a IGain of 25 and DGain of 5. These values are not final, but I do need to regulate my valve in a very short time.

Is there another way of doing this?

regards,

Michal_dk

Yes lower the integral provided you have the time restraints the derivitive term is only used to prevent the integral from reacting too fast causing overshoot. One little tidbit as many controllers seldom use the derivitive as a great deal of ppl find that the derivitive causes them problems but in actuality its because the integral is too aggressive as Peter mentioned.

http://www.ronbeaufort.com/sample_lessons.htm

This site has several excellent articles on PID

I don't know the unit for the proportional gain

Are the I and D gains indepent of the controller gain?

Michal_dk said:

Ok!


It is very aggressive I have a IGain of 25 and DGain of 5. These values are not final, but I do need to regulate my valve in a very short time.

Is there another way of doing this?

regards,

Michal_dk

Click to expand...

If the I gain is in 1/min does that mean the time constant is .04 min? That is fast but if the system steadies out quickly that may be just what you want but you are at the limit, literally. I wouldn't worry about the satuation. That is what happens with aggressive tuning. If you look at the www.controlguru.com site you will see that the integrator time constant is set equal to the plant time constant. If your valve has a time constant of 0.04 mins then this may be right on. Even if the plant has a time constant of 0.1 min an integrator time constant of 0.04 mins would be aggressive but not unreasonable.

Now all this assumes that 25 1/min = 1/Ti= 1/0.04

Mordred, I said very aggressive, not too aggressive.
The derivative gain causes problems when the sampling is uneven and the feed back is coarse or noisy. If you look at the advanced control threads you will see that the derivative gain will dampen an oscillitory system. Increasing the integrator gain tends to make the system more oscillitory or under damped. So does increasing the proprportional gain on its own. The trick is to move all three gains at the same time so the poles stay close to the negative real axis.