Loop Block Critique

[Jim_Okapal]

LOOP Block:

I had a chance to look over the function and calling script for the loop block and also compare it to what

i had done back in 2015 (Big Loop block in one of my prior posts) and was pleasantly surprised in how

two different people with NW8K and IA series backgrounds ended up having very similar ways of getting

the scripts programmed.  An overall question that should be asked is whether we're all looking for an exact

match of the WPTech block, or an exact match of the WPTech block with some added enhancements as

also seen in the other product lines.   

I'll start with some critiques, and then move on to the similarities and differences:

1)  Program "Comments" should probably be differentiated in such a way that doesn't look like

     it's actually the main program.  I ended up copy/pasting the logic into notepad and deleted

     the comments to get a better feel for what is occurring.  I tend to make some rows with

     asterisks or hyphens to separate the notes from the programming.  It kind of flows a bit better

     and easier to read.

2)  I saw some Commented out programming lines that should probably be removed. 

2)  The Argument count is up to 15 which may paint this block into a corner if any added enhancements

     are required.   There are a few similar items that could be "Indexed" to free up a few slots. 

3)  NW8k and WPTech loop blocks haven't used the deadband feature to any extent, so the block is always

     calculating non-stop slightly above or below setpt,   NW8K loop blocks have a CalcEnable value which

     works nicely to add a feature to stop the calculations if it's very near setpt.   In Continuum, the loop 

     scripts tend to include a deadband range where the script stops calculating.   A thought should be given

     to incorporating Deadbands.

4)  NW8K blocks have update times of usually 5 seconds default.  WPTech blocks are quite a bit

     quicker, but they update in regular intervals.   Continuum scripts update every scan but can be created to

     execute a particular line at desired timeframes.   The key to a good loop block is to control the output

     without needing very much CPU.   A 5-10 second update time has usually been a good benchmark for

     decent control.   The timeframe for integration in HVAC should be thought of in Minutes, not Seconds....because

     in reality very few items in HVAC are needed to be controlled where 1 second will make or break the operation

     of the system.  For the MPX Loop Block, the value will be calculating as fast as the task time or

     perhaps faster if we're dealing with a scan.    In Continuum, a scan can be a tenth of a second or less. 

     Not sure if we need it going to this extreme.    Update of 5-10 seconds should be plenty.

Initializing the Script:

This seems to be ok.   Both of our scripts are initializing the outputs, integration, numeric variables etc.

The MPX script is more focused on DateTimes in dealing with Seconds of time, where mine is dealing

with Update Times in an adjustable 5 seconds between updates.  Once the block is enabled, the update

times will dictate the timing versus the actual current DateTime. 

Looking For Invalid Inputs:

For the MPX loop the TR, Igain, Derivative and Ramp Times are being verified for being above 0.   In mine 

i'm also verifying that the OutRef/Bias and Deadbands are in a valid range.  

 .

Script Timing Intervals:

One big difference between the scripts are whether the action needs to happen every scan/task update,

or a user selectable update time.   I'm more in the user selectable update time similar to NW8K.

Ramp-up Sequence:

This one was almost identical in both scripts and i don't see any concern here.  

Proportion Calculation:

No issue here either.   It's pretty much choosing which item you subtract from the other to determine the

Direct/Reverse action

Integral Enable:

The enable portion was identical involving making sure the output ranges are valid, the error is occuring in

the proper direction.  One difference was whether the Integration starts occurring after the Ramp value has

exceeded the OutRef.   I've seen that in some blocks such as NW8K, or ignored in other systems.   I tend 

to let the integration calculate during Ramp Up.

Here's a line from the program:

OutputValue = Maximum(0,Minimum(100,SumValue, RampMax))

The SumValue will be stuck at it's proportion value until the RampMax has exceeded the OutRef.  

If the proportion value is below the Ramp Value (lets say 20% as an example), it'll hang there until it

can start moving for integration after the Ramp has finally hit the OutRef.    This isn't a big deal, as 

there is a precedent for that in some systems, while in other systems it's allowed to integrate during that

time.

Integral Calculation:

This becomes the biggest deviation between systems.   

The MPX script is using:

integralValue = integralValue + ((actualError/Setpt * TsinceCall * Igain) * Iena)

I'm using:

Integ = (Integ + ((UpTm1/60) * ErrNew * Kp1)) * Enab

PIDOut = Maximum(Minimum(((ErrNew * Kp1) + (Integ * Ki1) + (Deriv * Kd1) + ~
Ref1) * Enab,100),0)

Notice that the MPX script takes little chunks out of each integration while mine takes

the whole chuck out from the total.   Either one is perfectly fine to use and does the

same thing for that portion.   Notice the Kp1 is being multiplied into the integration for

mine.  This is the same terminology as Gain.   In the MPX script the ActualErr/Setpt is

the main difference.

There are two common PID types....Ziegler Nichols and the Velocity Format.    From my notes

back in 2015 by experimenting with NW8K and WPTech, the blocks seemed to follow a PI format

of ......   (Kp * Err) + (((Kp * Err* dT) /60)*Ki) + Bias.   I'm ignoring the Derivative for this example.

The Kp is the Gain and also corresponds to 100/TR.    The Igain is 60/dT.   Notice the Kp is multiplied 

into the Integration as well as the proportion.   This is an extension of the Velocity Format and

I've seen systems use this and WPTech seemed to be following this as well from observation.  Again,

this was 5 years ago, so maybe it's been changed with updates if it doesn't follow that anymore.

Long story short.... the heart and soul of the block really revolves around the Integration and 

we might want to make sure in how this particular line should be written.  

Derivative Calculation:

This was written very similar as well and don't see an issue here.

Some items that might improve the block:

1)  Having a control deadband

2)  Detecting an override condition by feeding an output back into the block

      to "Back Calculate" the integral.  

3)  Maybe a RampTime Elapsed value so the person knows how long it's been

     running.   Especially if it's a 20-30 minute start time.  

Conclusion:

Overall it looks to be hitting the main points of what the block is supposed to do.  I 

do have a concern if anything would ever need to be changed to it, how it would be

updated in the field after the fact.  The Integration line is the most important line in

the whole block and really needs to be as perfect as it can be...along with the timing

parameters.  Scan, versus task time, versus an adjustable Update Time.   So, Will...

I think the block itself was pretty well done as a first stab to see where we all go

from here.  and hopefully my suggestions can possibly add some value. 

Thanks for all of R+D's efforts.. 

[marian_modern-s]

Just chirping in to say that the Loop block calculating quickly is very much a needed feature. This is mostly in response to the comment

 A 5-10 second update time has usually been a good benchmark for

     decent control.   The timeframe for integration in HVAC should be thought of in Minutes, not Seconds....because

     in reality very few items in HVAC are needed to be controlled where 1 second will make or break the operation

     of the system.  For the MPX Loop Block, the value will be calculating as fast as the task time or

     perhaps faster if we're dealing with a scan.    In Continuum, a scan can be a tenth of a second or less. 

     Not sure if we need it going to this extreme.    Update of 5-10 seconds should be plenty.

---

Particularly in pressure control and clean-room operation, seconds definitely make and break the operation. If you want to add adjustable timing that fine, but the block should most definitely have the ability to re-calculate very, very fast.

[Jim_Okapal]

The travel/stroke time of the equipment itself really determines the speed needed for Loop block

calculation and update.  If an actuator has a 180 second travel time, a tenth of second calculation

won't really make a difference.  On the flip side, if a fraction of a percent change makes a large

difference in control output, then the equipment component could be oversized.    

There's only a couple situations where i needed it split-second and it was a bio-lab, or a special isolation

room and the equipment had to be internally wired, outside of a BMS due to those concerns.

[marian_modern-s]

Loops don't just control actuators, though. They can control anything that requires a feedback/recalc mechanism. Sometimes that's a VFD (much faster response time), sometimes they can stage other processes. The loop shouldn't be neutered because we want to guess what might be connected to it. And certainly, commercial clean-rooms and manufacturing labs (eye glass manufacturing, dental equipment, lipid research etc etc all types of projects we have) do need fast response-time adjustments. My point is, there's no need to remove this functionality. In fact, it would be detrimental to do so. Adding a means to slow it down is fine, as an optional feature.

[Jim_Okapal]

I'm not asking for it to be neutered, just adjustable.   Most applications it'll be 5 to 10 seconds.

If it's needed to be faster it can be.    The VFD example has a faster response, so the loop

can be speeded up.   I'm just giving an example of how the timing of 0 to 100% whether slow

or fast determines the update time of the block

I should have added that the PIDP block in the EBO function block editor has exactly what i'm 

talking about.

[Jim_Okapal]

Marian,

Wanted to get back with you now that i have more time to write back.   A scenario

that requires ultra fast response is better suited to a floating control loop, not a 

PID loop.  This includes VAV boxes, isolation rooms, pressure control rooms, clean

rooms, etc.   A value is sent out the equipment followed by a slight pause, then a new value

followed by a slight pause, etc.  There is a deadband where all further action will stop.   This

can be done very quickly if needed.    The VFD mentioned also has a lag time of it's own

for control, so the room won't be at setpt instantly.   A PID loop is not well suited for such

an environment.   

Attached is a picture of different control loop situations and the best application

for them.    For some reason, i can't load pictures into a post...the button is gone

from the top.  

The PIDP block i mentioned has two configuration settings... StrokeTime and Control Interval

In the case of actuator from before, a StrokeTime value of 180 will encompass a 0-100% range

and only allow a maximum value of about 0.55% to be sent per second.   The Control Interval set

to 5 seconds will give a final maximum value of 2.77%.  This keeps the PID loop in line with the 

actual mechanical equipment attached.

In the case of a VFD drive, the StrokeTime could be 20 seconds or less....but we'd never want to

go from 0-100% in that time period for stable control, but it gets the point across that the faster

equipment needs to have some restrictions for adequate control.   The Control Interval is just

another means of tailoring the response in conjuction with PID. 

While we should instantly see what the pressure is in the room for status or feedback, the VFD

or dampers, or anything else still has to ramp up or get in the proper position, which still takes

time.   As mentioned, a scenario that is ultra fast requiring instantaneous control doesn't do well

with PID as a rule.  It can be used, but it's not recommended for the best control.  

In case picture doesn't show up:

Slow Response (1-2 minutes) = Proportional

Moderate Response/Stable Setpts (20-30 seconds) = Proportional + Integral

Moderate Response/Unstable Setpts (20 - 30 seconds) = PID

Fast Response (3-5 seconds) = Floating

[marian_modern-s]

Hi Jim,

the picture loads fine. Thank you for taking the time to write out that post. As usual, it is very informative well written. I agree with all points. The only disagreement, if it can even be called that at all, would have been to forcibly create a loop block that only recalculates on a slow cycle. It could be a separate block, or it can be an adjustable timing feature, I just wouldn't want to see a block that only operates at an arbitrarily chosen slow rate, unless it was in addition to a faster acting (free) loop block. The use cases for P, PI, PID and Floating loops blocks are valid and the connection to a real mechanical thing important, but like I said, there are (I'm not going to venture a guess) creative uses that do not end up directly connected to mechanical equipment, but some kind of intermediary. Anyway, I agree and thanks!

[dbrum_uhlco_com]

A couple of comments to Jim's 1st post.

1. As Jim has pointed out, the integral calculation implemented with the Loop Single block doesn't match what is currently in the WPT loop.  The formula Jim has listed under Integral Calculation would provide the equivalent functionality.

2. I'm in favor of having the Loop Single block mimic the exact functionality as the WPT block.  A future enhancement would be to provide an additional Loop block that would mimic what's available with the function block PIDP loop. This would have the deadband, control interval, ability to pause the loop at a particular output and stroke time settings.  

[Jim_Okapal]

I went ahead and did a comparative "timing" test with 3 loop blocks to complement Dan's post

It will use the actual loop while in  WPTech, the Schneider MPX loop, and the LargeLoop that i

had posted on the MPX forum.    All are running at the same time when the LoopEnable is activated.

The end result is there is indeed a problem with the integration line in the MPX script and can

confirm Dan's post.  

The test scenario was:

Space Temp = 75

Spece Setpt = 70

TR = 20 (or Kp = 5 for gain which is 100/TR)

IG = .2

Deriv = 0

Outref = 0

Action = Direct

Ramptime = 0

This will cause the loop block to go to 25 upon first activation, and then the igain will 

increase accordingly.   I then did a screencap when the actual WPTech block got up

to 50 from 25.   

WPTech Loop

WPTech Loop

Schneider MPX Loop:

Schneider MPXLoop

Jim's  "Large Loop"Jim Loop