Prev_Cycle Time

[RMA]

That's just a question of the process requirement. If you're using it for PID control of a temperature loop for example, then 200ms is fast enough to provide good control and slow enough not to hurt the cycle time.

On the other hand if you wanted to do motion control or something like that, you might need an interrupt period of 10ms or less, which almost certainly would have an impact on cycle time (depending on how big the program in OB35 is).

 

[userxyz]

...

And, what if you have 2 PID's, both in OB35 ?? Or is better to set the cycle time on 100ms and let run 1 pid, but every 100ms changing the data to process

?? What would you do if having 2 or more PID's in OB35 ?

That's just a question of the process requirement. If you're using it for PID control of a temperature loop for example, then 200ms is fast enough to provide good control and slow enough not to hurt the cycle time.

On the other hand if you wanted to do motion control or something like that, you might need an interrupt period of 10ms or less, which almost certainly would have an impact on cycle time (depending on how big the program in OB35 is).

 

[userxyz]

..

I am still confused a bit, Why does FB41 have to run in OB35 or something like that ? Isn't the normal cycle good enough ? Ok it changes, this can affect the PID regulator, I understand, but, it's for temperature control, so it wont be that bad to run in the normal cycle I guess ?

And, what if you have 2 PID's, both in OB35 ?? Or is better to set the cycle time on 100ms and let run 1 pid, but every 100ms changing the data to process

?? What would you do if having 2 or more PID's in OB35 ?

 

[Jeebs]

If I read it correctly:

For your application it should be 100ms.
It can be found in your code.

It adds the OB1-cycle time (LS-tijd) until it reaches a value equal or larger than your 100ms setpoint (PID_time). If the added time (LS-tijd) is lower than the PID_Time then it jumps to NOP, skipping the whole PID.

Once it reaches added time (LS-tijd) equal or larger than the PID_Time it subtracts the setpoint (PID_time) from the added time (LS-tijd). This is done to keep the PID getting run as close to 100ms as possible.

OB1-time is used so you could change the rate at which the PID is run during runtime. Changing HW requires donwload and PLC in stop.
Once your timings are set and you know they will not change, then OB35 is better yes, but if you are not sure your timings are correct then the OB1-time might be used.

Hope this helps
Jeebs

 

[kamenges]

Originally posted by Combo:

Ok it changes, this can affect the PID regulator, I understand, but, it's for temperature control, so it wont be that bad to run in the normal cycle I guess ?

And that is why you would use the Prev_Cycle value. It will significantly minimize the effects of scan variation when FB41 is called outside of OB35. If you call FB41 from inside OB35 then the Prev_Cycle value doesn't get you much.

Then again, as you said, if the plant time constant is long enough you probably don't need to worry about the effects of the scan variation anyway.

Keith

 

[Peter Nachtwey]

Just curious

That's just a question of the process requirement. If you're using it for PID control of a temperature loop for example, then 200ms is fast enough to provide good control and slow enough not to hurt the cycle time.

Why doesn't executing the PID every 200ms not hurt the cycle time? It may not hurt the average cycle time much but it certainly will add to the peak cycle time.

Executing the PID every forth interrupt works well since the peak time is only increased by one PID execution time. However, the prev_scan time better be set to the time between interrupts times 4.

I thought onetrickypony had a good answer. That is why I have left this alone till now.

I think it is a shame that so much time is spent on this problem. There should be a hardware free running clock in the PLC so when the PID is executed it can compare the current clock with the previous clock and adjust the effectiveness of the gains for that scan accordingly.

Something to think about. So how often does OB35 interrupt? I know it is supposed to be every 100 milliseconds but has anybody done a test to figure out what the minimum and maximum times are between interrupts? What is the standard deviation? Do the variations in interrupts accumulate or will OB35 interrupt in 101 milliseconds one time an then compensate by interrupting in 99 milliseconds the second time? What is the interrupt latency? It would be interresting to compare the different PLCs.

In all the years monitoring the forum these points have never been discussed.

 

[userxyz]

...

I think no one dares to answer these questions of you, too delicate

 

[FrancisL]

As I said before, it is best to put a little scheduler (rotating a bit round a word is good way) in OB35 and running each PID on a different scan – that is once (or more if the PID need to run faster) each time it is scheduled so that the load is distributed evenly.



Determining how often each PID need to execute is entirely down to the process, there is no point in running a loop that responds slowly very fast - Nyquist and all that.



Incidentally this is where DCS’s are generally better, as the handle the scan timing themselves – but mind you, so did Texas PLC’s many years ago.

Francis
www.urswriter.com and www.controldraw.co.uk

 

[userxyz]

Dcs ?

dcs ?

As I said before, it is best to put a little scheduler (rotating a bit round a word is good way) in OB35 and running each PID on a different scan – that is once (or more if the PID need to run faster) each time it is scheduled so that the load is distributed evenly.



Determining how often each PID need to execute is entirely down to the process, there is no point in running a loop that responds slowly very fast - Nyquist and all that.



Incidentally this is where DCS’s are generally better, as the handle the scan timing themselves – but mind you, so did Texas PLC’s many years ago.

Francis
www.urswriter.com and www.controldraw.co.uk

 

[FrancisL]

DCS - Distributed Control System

 

[Peter Nachtwey]

I think no one dares to answer these questions of you, too delicate

If you are refering to the variations of cycle time, I don't care what they are. I would just like to know but I don't have the time to set up each PLC and generate a 'real' program to do the test.

I find it odd that no one really seems to care. A few millisecond wouldn't matter when doing a temperature control system. It would if the PID was doing position control. It also makes a difference to all of those that use difference betweeen encoder readings to compute velocities.

Incidentally this is where DCS’s are generally better, as the handle the scan timing themselves – but mind you, so did Texas PLC’s many years ago.

Are you saying that DCSs have less jitter in the scan times or that DCS do a better job of automatically computing the time difference between each execution as I suggested?

 

[FrancisL]

Quote:
Are you saying that DCSs have less jitter in the scan times or that DCS do a better job of automatically computing the time difference between each execution as I suggested?
</FONT>In general with DCS implementations of PID control you do not have to do anything other than set the scan rate. You do not have to 'call' the PID function at all, as the DCS controller handles all that.
I am not sure if any of these use the previous scan period, I think they assume that the PID is executed at equally spaced intervals. IE there is no 'jitter'. Of course all systems will have some jitter but if it is small relative to the scan rate it is not a problem.
DCS controllers are not designed for high speed position control.