Hey folks, Phil Zito here and welcome back. In this post, we're going to be covering how to program from submittals or basically just how to program from any sequence of operations documentation.
So, if you've been following up to this point, we began with releasing information from sales to operations all the way now into actually writing some programs. Now some of you may be wondering, “How in the world is Phil going to teach people how to program from submittals through a blog?” Well, programming is definitely one of the most visual besides graphics. So, we're going to have a bunch of bonus resources for you.
Below this post, you will find our Ultimate Guide to BAS Programming and our BAS Programming Mini-Course, both of which are free and can be found at Smart Building Academy. In addition to that, we're going to go through the process of taking a sequence and translating it into programming because what I've noticed is that, when it comes to programming, people fall into two camps:
- They either have zero experience with any building automation software and programming.
- They have experience with building automation programming software, but they just don't know how to make heads or tails of a sequence and turn it into a program.
So, I'm going to be focusing on the latter group here, the folks who understand building automation software, and are trying to figure out how to turn that into a sequence. But don't fret if you are someone who has absolutely no experience with BAS programming software, this is still going to be valuable to you, as well as the resources we’ve provided below.
Programming is one of the highest paying skills in building automation, besides integration and sales. If you are a programmer, you are in incredibly high demand. You can basically write your own salary expectations right now, and you also have a skill that, in my opinion, can be a lot of fun and very fulfilling.
It's kind of like adult Legos. If you think about it from an angle like adult Legos, then programming becomes just a matter of understanding statements that are being made in sequences and translating those statements to the appropriate design patterns. I'm going to repeat that because understanding that is key.
“Programming is understanding the statements that are being made in sequences or in submittal documentation and translating those into design patterns.”
Let's define what all that means. So, a design pattern is just a way of implementing. You see design patterns every single day in your life. If you are looking at a car, most cars have four wheels, two to four doors, an engine in the front, and a trunk in the back. They follow a pattern. Now, the interior, exterior, and the mechanical parts of it may change, but there's a pattern to things. When you look at engines, how they perform, or motors, how they perform, they all follow a pattern in how they're designed.
Well, programming is no different. If you think of one of our most common patterns in programming, which is called the comparative pattern, this is where we look at two numbers and we compare the two. It doesn't have to be numbers, it can be Boolean objects, etc, but we compare these two objects to one another. Based on those objects, we drive a Boolean outcome which is a true/false on/off outcome.
You see this all the time when you're looking at low temp enable or economizer enable, based on temp or comparison of return enthalpy versus outside air enthalpy. You're doing a comparative pattern to look at these two parameters, and you're comparing the two and then you're driving an output. If you learn this one pattern, you can apply it to so many different programming scenarios.
Folks ask me quite often, “How can you teach someone, who is brand new, to program?” Well, as long as they understand the HVAC control theory and HVAC sequencing, then they can learn the patterns that come with programming. So, let's talk through what that would look like.
The first thing that I just mentioned is the comparative pattern. We are going to go through a couple of patterns in this post, but we're primarily going to focus on our programming methodology and approach.
If we think about these patterns, and these patterns have corresponding logic blocks. When you write programs, you either write them in text, and there's a handful of manufacturers that do that, or using logical programming blocks, which is what most programming software is nowadays. It's graphical logical programming blocks. You have blocks that are And blocks, Or blocks, etc. You'll have PID loops, switches, gates, timers, etc. But what you learn is these patterns have specific blocks.
Now, comparative pattern is going to have two inputs into a comparative block with an output coming out of that comparative block. That is the pattern. That pattern can be applied to a switch to basically switch between two different set points. That pattern can be applied to an occupancy trigger, to an enable trigger, or a variety of different things.
You can even look at that pattern and say, “Hey, if our calls for heating or calls for cooling go above a certain point, or below a certain point, we're going to initiate a state change.” So, there's so many things you could do with that very simple pattern. In order to make sense of that, you have to identify the word requirements for the pattern in the first place.
So, what we need to do is to go into our sequence of operations or our submittal set documentation, and we need to start to parse through our sequences. The methodology I take is: Inputs, outputs, binary logic, analog logic, safeties. Sometimes I'll do:
- Step one: input, output, physical
- Step two: input, output, logical.
Sometimes I'll do:
- Step one: input, physical and logical
- Step two: output, physical and logical
It really just depends on how many physical points there are and how many logical points there are. I'll walk through the difference between a physical point and a logical point in just a second.
But I’ll do the inputs, outputs, the Boolean logic or binary logic. This is the logic that is going to result in a two-position state. It's either on, or it's off, it's true, or it's false. It's either greater than the setpoint, or it's not greater than the setpoint.
Then I move to my analog logic. This is going to be things like my PID loops, my floating, my sequencing, my resets, etc. This is all analog logic, and it's going to result in a numeric value that is not going to be true or false. It's going to be a what's called a floating object. That floating object is going to vary between a series of numbers.
So, once I've done that, then I move to safeties. I always do safeties last. Now people ask, “Why do you do safeties last?” It’s because you want to program your safeties last so that no other programming that you're doing overrides for safety conditions. Safety conditions exist for just that, the safety of the equipment as well as the safety of the people or occupants. The reason why we want to do our safety logic last is because if I do my safety logic first, and say I have a
disabling of the unit based on if the outside air damper’s open or not. I write that first and then I write some sort of economizer logic that overrides that or messes with that, then I could have some issues. So, I want to be cognizant of that safety logic, and that's going to be the last thing that I'm going to write from a programmatic perspective.
So, I have this sequence of operations in front of me, I have these inputs, and I have these outputs. I need to start sorting through them. This is where I get a series of different colored highlighters. I'll pick a color for my inputs, a color from outputs, a color for my binary logic, a color for my analog logic, and a color for my safeties. I'll take these different colors, and I will go through the sequence and mark things down. I will mark my inputs, I'll mark my outputs, I'll mark my binary logic, mark my analog logic, and by the time I come out of this exercise, I will have everything identified.
I now will start to build my points list. So, I will start to build my physical and logical points, inputs, and outputs. Physical point is a point that physically exists. It physically connects to the controller, and I can physically touch and feel it. A logical point would be a setpoint or a timer object, or a minimum threshold. These are things that are used logically, meaning programmatically, inside the control device that physical inputs or other logical objects are intertwined with.
So, a good example of this would be outside air temp, and an outside air enable setpoint. So, the enable setpoint is a logical point, it does not physically exist. I cannot physically hold an outdoor air enable setpoint in my hands, but I can hold an outside air temperature sensor in my hands. So that's typically how I determine between physical and logical points. It's important to identify these and highlight them as such. That way, you make sure you build your programs.
Now, what I do is, I will start writing my program. If I'm writing it from scratch, and ideally, you're not going to write it from scratch. You're going to be writing it from a template library, or you are going to have design pattern templates, which I recommend, or full-blown programming templates, like air handler and chiller templates, so you just modify them.
You should almost never write programs from scratch unless they are incredibly complex. Even then, you should be using design patterns, or you're trying to learn how to write programs. I highly recommend, if you're trying to write programs or learn how to write programs, that you're writing from scratch, so you get all the intricacies. Once you've learned how these things work, then you've learned the common design patterns, and there's roughly 30 common design patterns. Once you've learned this, then it's simply a matter of you using your design patterns.
Now as I was saying, we start with our inputs, I put those on the left. At least in the US, we read left to right, so I put those on the left of the programming page. The outputs, I put on the right, and the logical points are somewhere in the middle. I then move to my Boolean logic, this is my fan start/stop, my economizer enable, my status dependent starts, etc. I start to build out these design patterns, and I apply them. I put a line through each binary pattern, or each binary sequence trunk as I write the programs.
Now, I'm a big fan of state-based control, I like to write my programs in a state-based manner. So, I will have a cooling mode, a heating mode, an economizer mode, etc, and I will have logic that will switch between the modes. That way, I always know what mode I'm in and I can troubleshoot accordingly. However, not all sequences are written that way. So, just be cognizant of that, but that's how I like to write my sequences as well as my programs.
Now that I've done the Boolean logic, I start to move to the analog logic, and I start to implement that. So, I'll start to write out my PID loop patterns, my sequencer patterns, my resets, my timers, etc. Finally, I overlay everything with my safety logic.
It's at this point that I implement my safety logic. I will use one of my various test methods to test my programs. At the end of the day, following this pattern makes it quite simple to write programs, because the majority of the programs are going to fit in the majority of the design patterns that you're going to learn and use. Once you understand these patterns, and you understand the word triggers for them, then it's very easy to say, “Oh, that's a comparative pattern.”
For example, let's say that you come upon a sequence and the sequence says, “The economizer shall be enabled when outside air temp is greater than 65 degrees.” Well, you just came upon a comparative pattern, right? That is a Boolean logic pattern. All you have to do is remember your comparative pattern, your physical input, your logical input, and your output, and you're going to write that pattern. Boom, done.
You continue along and you see, “Fan shall start and shall detect status of whatever within 30 seconds; if not, shall be disabled.” So, you write that. That is a basic status pattern. Once you have these patterns established and identified, it becomes rather easy to write programs rather quickly.
Now, granted, there are little bits of nuances with every manufacturer software, but the one thing that will remain constant is understanding these patterns not just for programming, but also for troubleshooting perspective. This is why folks will say, “Hey, Phil, how do you gain the ability, the capability, to go to a site, look at someone's programming and figure out what's going on, even if you're not really familiar with that software?” Well, once you understand what the basic logic blocks are, the Ands, the Ors, the switches, the gates, etc, and understand what those are, those are fairly common across manufacturers. Then, once you understand patterns, that is pretty easy to detect as well.
So, you detect these patterns, and it's quite easy to say, “Oh, here's these patterns and I'm going to identify these patterns. Super easy to understand.” Once you identify those patterns, you're like, “Oh, that's super easy. I'm good to go! I know what I'm looking at. Now I know how to troubleshoot this.”
Alright folks, I hope this gave you a helpful perspective of how to program and understand the process around it. If you'd like more visual resources, check out the links below as well as our BAS Programming Fundamentals course.
Thanks a ton, and I will see you in our next post!
Here are those super helpful resources I promised!
