Prev_Cycle Time
- Thread starter userxyz
- Start date
onetrickpony
Member
PID loops especially the I & D terms are time dependant. if you use OB1 the cycle time is variable, hence the prev_cycle time is required to calculate PID loops correctly.
godfrey
Member
But isn't OB35 called on a regular timed basis regardless of the variation in scan time?
RMA
Member
The only thing I can think of is that OB35 interrupts the main cycle every 100 ms (or whatever time is specified for OB35). Particularly for a relatively slow process, this may be too often and unnecessarily lengthen the cycle time. Using Prev_Cycle to recalculate the values for the loop instead, could lead to faster times on average.
In this case it would probably make sence to "roll your own" PID (as required) controller, optimised for the process concerned.
In this case it would probably make sence to "roll your own" PID (as required) controller, optimised for the process concerned.
kamenges
Member
This doesn't directly answer your original question. However, it doesn't matter so much that the value changes as long as you knbow what the value is. I haven't worked with FB41 before. As long as FB41 allows one to change the update rate every time it is called and it uses the latest update rate as part of the I & D calculations then using Prev_Cycle as the time should be OK. I have done something similar with other processors.
As for your original question I'm not sure why someone would choose to do this as opposed to using OB35. By using scan counters and selective FB calls several different update rates could be used out of a single OB35 update rate.
Keith
FrancisL
Member
Could the answer be that they just got it wrong?
Clearly using a time interrupt is better.
I have used OB35 for PID before - but not just by running all the PID's each time. Most PID's do not need to run every 100mSec, so use a little scheduler in OB35 so (a simple example) if you have 4 PID's then each will run once every 400mSec, but only one will run each 100mSec.
Clearly using a time interrupt is better.
I have used OB35 for PID before - but not just by running all the PID's each time. Most PID's do not need to run every 100mSec, so use a little scheduler in OB35 so (a simple example) if you have 4 PID's then each will run once every 400mSec, but only one will run each 100mSec.
JRW
Member
If the ob35 cycle time is changed in the hardware.
the cycle time in FB41 will not have to change.
Make sense?
the cycle time in FB41 will not have to change.
Make sense?
FrancisL
Member
PID Algorithms generally depend on being executed with a consistent time base, as the maths they use for integration and differentiation assumes so. And if the scan rate is not consistent they can produce errors. Don't ask me the maths but there is plenty.
In addition using a timed interrupt, which is what OB35 is, ensures that whatever is called from there overrides the main scan, in fact interrupts it, so that you can be sure that the PID (in this case) is executed consistently.
PID Algorithms are also processor intensive, and calling all the PID from the main scan, (or a timer in the main scan), will produce 'lumpy' scans which of course we do not want.
Quite why there is a Prev_Cycle parameter beats me, anyone got an idea?
Here we need an answer from the designer of the PID FB.
In addition using a timed interrupt, which is what OB35 is, ensures that whatever is called from there overrides the main scan, in fact interrupts it, so that you can be sure that the PID (in this case) is executed consistently.
PID Algorithms are also processor intensive, and calling all the PID from the main scan, (or a timer in the main scan), will produce 'lumpy' scans which of course we do not want.
Quite why there is a Prev_Cycle parameter beats me, anyone got an idea?
Here we need an answer from the designer of the PID FB.
L D[AR2P#0.0]
Lifetime Supporting Member
Going back to the original question:-
How do you know that some people do - or am I misinterpreting the question ?
Combo said:
How do you know that some people do - or am I misinterpreting the question ?
Well,
I've seen this in a program, a machine that we bought..
Personally, I prefer OB35, it's easy... and works...
But how can you determine the OB35 cycle time ??? How much do you have to enter...
here is the program I've seen:
I've seen this in a program, a machine that we bought..
L D[AR2 said:
Personally, I prefer OB35, it's easy... and works...
But how can you determine the OB35 cycle time ??? How much do you have to enter...
here is the program I've seen:
RMA
Member
You can modify the OB35 interrupt period by right-clicking on the CPU in HW-Config -> object properties -> cyclic interrupts.
Don't make the time any shorter than you really need it, or you could end up unecessarily extending the cycle time.
Don't make the time any shorter than you really need it, or you could end up unecessarily extending the cycle time.
Similar Topics
Hi,
In OB1 there is no Prev Cycle time anymore.
Is there a solution to have something like this ?
Or do I have to substract the previous clock...
Hi Guys,
I searched throughout the forums but didnt find any information on this topic.
I currently have an application that relies on macros...
Hello PLC friends. I've been going through a saga of diagnosing and fixing an old PLC setup that I inherited. I am learning as I go.
Initial...
Hi everyone.
I have an issue with an Allen Bradley PLC model 1769-L30ER. This PLC had a previous program with a different IP address but when I...
My Panelview plus 700 HMI stopped working and I replaced it with a new one. Moved the sd card from the previously installed panel to this one and...