pid update rate effect

[kamenges]

There is one thing you need to understand and should not proceed until you do understand it.

The PID instruction will automatically account for call rate AS LONG AS YOU TELL IT WHAT THE CALL RATE IS. There is a location in the PID configuration data that allows you to enter that data. As long as you are honest with the instruction about the actual call rate the instruction will manage the effects of the call rate.

So don't get hung up on trying to figure out what the scaled gain value will be. Just consider it in terms of one second and calculate from there.

Keith

 

[michaeli]

developed tuning values as shown in attachment for the open Loop testing posted on june 29. have i done this correctly? any Feedback greatly appreciated.

 

[michaeli]

Stu - thanks for your reply. could you review my post of couple minutes ago. are these the values to use even considering the setup using a loop update of 1 sec and plc scan time of 35ms?

 

[michaeli]

Stu - setting up call rate - for this the update time in the pid box then should be changed from 1 sec to 35ms which would match the approximate plc scan time of 35ms?

 

[daba]

Keith - thanks for update and making things a little clear.

have other question with loop update at 1 sec and plc scan rate at 0.035 sec. if Ki value in block is at 0.001 then the real effective Ki value would be .001/.035 = 0.028? also if Kd in block is 0.025 then real Kd value is 0.025 x 0.035 = .000875?

You must FORGET about the PLC scan rate, it is of NO consideration...

BUT !! You must "scan", or "enable" the PID instruction at the time interval you program into the PID's Update Rate.

The PID instruction does its calculations based on the change of the feedback signal since it was last scanned. If it believes it was last scanned 1 second earlier, but in fact it is scanned 35mS earlier, it will make the wrong corrections.

IT IS IMPORTANT to scan the PID instruction at the same rate you have configured it, regardless of the rest of the PLC code "scan" rate.

To achieve this, put your PID instruction into an STI for best accuracy, or trigger it (enable it once) in your cyclic program using a timer .DN bit (slightly less accurate, but mostly acceptable)..

Break the connection between the PLC code scan, and the frequency of executing your PID instructions, and you will succeed.

 

[daba]

Stu - setting up call rate - for this the update time in the pid box then should be changed from 1 sec to 35ms which would match the approximate plc scan time of 35ms?

NO !

execute the PID with a timer or put it in an STI....

that way you will "future-proof" the PID control, adding code to the PLC will not affect the PID control

 

[michaeli]

Daba - working on getting timer/STI setup. also did you have a chance to review open loop test data (june29 11:38am post) and proposed PID values (July 1 3:43pm post). Also from open loop testing the dead time is about 300 seconds - once I have timer/STI setup is a loop update of 1 second to fast?

 

[daba]

Daba - working on getting timer/STI setup. also did you have a chance to review open loop test data (june29 11:38am post) and proposed PID values (July 1 3:43pm post). Also from open loop testing the dead time is about 300 seconds - once I have timer/STI setup is a loop update of 1 second to fast?

I can't comment on the values you proposed, there are too many variables to take into account. You also need to consider initial start-up time versus continuous running response.

What I can comment on is the PID update time. No I don't think 1S is too fast... most PID loops I have configured faster than that, typically 100mS. Whatever rate you execute the instruction at should be set into the PID data Update time register. It (the PID instruction) cannot measure how long it was since last executed, you must tell it. That is why having it in normally scanned code, which is susceptible to scan-time variations, is just wrong.

Just remember it is ONLY the PID instruction itself that needs to be scanned at a consistent time-base, so if you execute it in an STI, the STI itself won't have too much of an impact on the main routine's scan time.

It is usual for the PID instruction to be scanned continuously (at the set rate), by not have any conditionals on the rung. You control the PID modes (e.g. Auto, Manual, etc.,) by setting control bits in the PID data-block.

It is easy to configure a STI file, just put the PID rung into it, and specify which file is the STI, and the execution rate, in the processor status file.

Don't forget, you will NOT need to, and it would be totally incorrect to, put a JSR to the STI file anywhere in the other code. The processor handles the execution of the STI once it is configured in the status file.

I am confidant that putting the PID instruction in an STI will enable you to tune the PID to your desired response, and that tuning will not be affected by anything you do to the rest of the code.

 

[michaeli]

Daba
had timer added so PID update is at 1 second and not effected by much faster PLC scan rate. can u review attachment. if ok will then work on developing best Kp, Ki and Kd values.
thanks

 

[michaeli]

Daba
just had timer added. would this now have pid with correct update and not effected by fast plc scan time? is image clear - can attach a file that might allow for more clear viewing.

 

[michaeli]

Ron - when u have a chance could you please review open loop test data (june29 11:38am post) and proposed PID tuning values (July1 3:43pm post).

 

[Ron Beaufort]

I'll be happy to calculate some values for you (as my work schedule will allow) but I'll need to see the ENTIRE "RSP" project file in order to make sure that your block transfer reads and writes - and your signal scaling - are all correct before doing that ...

plus the open loop test that you posted in #29 has "issues" ... the signals weren't properly "settled out" (as shown below) so any calculations that I run aren't going to be accurate ...

I've been checking in on this thread from time to time (as my work allows) but I haven't been able to contribute anything useful - since most of the screen shots that you've posted are unreadable ... having the ENTIRE RSP file would make this a lot easier ... are you allowed to post it? ...

TIP: when you do a screen grab, try saving the file as a PNG type (instead of JPG) ... those are usually a lot less "blurry" around the edges of the text - and we can usually read those ...
.

 

[daba]

michaeli - using a timer .DN bit to trigger the PID is acceptable in some cases, providing you don't want precise and fast control.

However, the actual execution of the PID will vary by up to the scan time of the code, plus the timer will need another scan of the code to reset itself.

Let us say your scan time is 54mS, then the PID will execute at between 1.054mS and 1.108mS. You can remove the self-resetting scan by issuing a RES of the timer, driven from its .DN bit (do this after the PID rung so the .DN bit will actually trigger the PID).

I still recommend putting the PID instruction, on a rung by itself, i.e. no conditional instructions on the rung, in an STI file. That way it will execute at exactly the rate you program the STI, regardless of any other considerations of scan rate etc.

 

[michaeli]

any feedback, comments or suggestions on method used for determining best pid values based would be much appreciated.

 

[michaeli]

Hello Ron - attached files above for second bump test for your review. have rsp file but to large to post on this site. can I send directly to you. thanks