SpaceLogic for Niagara Forum
This forum is a place for technical users to share information and collaborate on the integration of SpaceLogic BMS controllers into Niagara BMS.
Posted: 2020-11-30 09:46 PM . Last Modified: 2020-11-30 10:04 PM
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-11-30 09:46 PM . Last Modified: 2020-11-30 10:04 PM
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..
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-01 09:08 AM
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.
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-01 09:25 AM
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.
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-01 09:48 AM
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.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-01 09:52 AM . Last Modified: 2020-12-01 09:56 AM
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-01 09:52 AM . Last Modified: 2020-12-01 09:56 AM
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.
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-01 06:29 PM
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
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-02 08:53 AM
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!
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-04 12:37 PM
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.
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-08 11:50 AM
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
Schneider MPX Loop:
Jim's "Large Loop"
Link copied. Please paste this link to share this article on your social media post.
Create your free account or log in to subscribe to the forum - and gain access to more than 10,000+ support articles along with insights from experts and peers.