In this episode we discuss how to write building automation programs from scratch.
We discuss the programming process, how to use design patterns, and strategies for writing programs from sequences.
Click here to download or listen to this episode now.
Resources mentioned in this episode
- Ultimate Guide to BAS Programming
- BAS Programming Mini-Course
- BAS Programming Bootcamp
- BAS Training Resources
Transcript
Phil Zito 0:00
This is the smart buildings Academy podcast with Phil Zito Episode 291. Hey folks, Phil Zito here Welcome to Episode 291 of the smart buildings Academy podcast. In this episode, we're going to be discussing 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've started at releasing information from sales to operations all the way now into actually writing some programs. Now some of you may be wondering the question I asked myself, which is, how in the world am I gonna go and teach people how to program from submittals. With a podcast, I mean, this is audio, and of all the things we do programming is definitely one of the most visual besides for maybe graphics. So how do we teach this? Well, we're gonna teach this by having a bunch of bonus resources for one at podcast, smart buildings academy.com, forward slash 291. Once again, this podcast smart buildings academy.com, forward slash 291, it's there, you'll find our guide to programming, you'll also see a link to our programming mini course you can take both of those, they will help you out, they're completely free. In addition to that, we're just 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 absolutely have zero experience with any building automation, software, and programming at all, or 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 talking to 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 would be as programming software, either, this is still going to be valuable to you, as well as the resources at podcasts, smart buildings Academy comm four slash 291. Alright, so let's dive through this programming is one of the highest paying skills in building automation, besides from maybe integration in 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. And 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's key. So 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, right, most cars have four wheels, two to four doors, they have the engine in the front, the trunk in the back, right, they follow a pattern now the interiors and exteriors 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 numeric objects or two numbers. And we compare the two and it doesn't have to be numbers, it can be Boolean objects, etc. But we compare these two objects to one another. And 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 tamper comparison of enthalpy versus return enthalpy versus outside air enthalpy. And you're doing a comparative pattern to go and look at these two kind of
Phil Zito 4:41
objects, for lack of a better word, these two parameters and you're comparing the two and then you're driving an output and if you learn this one pattern, you can apply it to so many different programming scenarios and folks asked me quite often How can you teach someone who is brand new to program well as well long as they understand the HV AC control theory and hv AC sequencing, then they can learn the patterns that come with programming. So let's talk through what that would look like. Well, the first thing that I just mentioned right is the comparative pattern. And we are going to go through a couple patterns in this podcast. But we're primarily going to focus on our programming methodology and approach. But we think about these patterns, right. And these patterns have corresponding logic blocks. When you write programs, you either write them in text, and there's a handful of manufacturers do that, or using logical programming blocks, which is what most programming software is nowadays, it's graphical logical programming box, you have blocks that are like and blocks or blocks, etc, you'll have p ID loops, you'll have switches, you have gates, you have timers, etc. But what you learn is these patterns, 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 that to basically switch between two different set points, that pattern can be applied to a occupancy trigger to an enabled trigger a variety of different things, right, 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. But in order to make sense of that, you have to identify the word requirements for the panel, or for the pattern rather, in the first place. So what we need to do is we need to go into our sequence of operations or our submittal set documentation. And we need to start to parse through our sequences. And the methodology I take his inputs, outputs, binary logic, analog logic, safeties, so step one is inputs, step two is outputs. And sometimes I'll do it, maybe I'll do step one, input output, physical, and step two, input output logical. And sometimes I'll do step one is input physical and logical. Step two is output physical and logical, it really just depends on how many physical points there are, and how many logical points that are. And I'll talk through the difference between a physical point and a logical point in just a second. But I do the inputs outputs, I do 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 moved to my analog logic, this is going to be things like my P ID loops, my floating, my sequencing, etc. My resets, 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 actually going to be a what's called a floating object. And that floating object is going to vary between us series of numbers. So once I've done that, then I moved to safeties, I always do safeties last. Now people ask, why do you do safeties last, 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, so or occupants. And the reason why we want to do our safety logic. Last is because if I do my safety logic, first, maybe I have a
Phil Zito 8:56
disabling of the unit based on if the outside air dampers open or not. And 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 I want to, that's going to be the last thing that I'm going to write from a programmatic perspective. So I've got this sequence of operations in front of me, I've got these inputs, and I've got these outputs, and 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, color for my analog logic and a color for my safeties. I'll take these different colors. I will go through the sequence and I will start marking things down. I will mark my inputs I'll mark my outputs. I'll mark my binary logical 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 like a setpoint or a timer object, or you know, 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 basically. So a good example 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 a 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. And 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 go and I'll start writing my program. If I'm writing it from scratch, ideally, you're not going to write it from scratch, you're going to be writing it from a template library, you are going to either have design pattern templates, which is what I recommend, or you'll have full blown programming templates, like air handler and chiller templates, and you just modify them. You should almost never write programs from scratch, unless they're 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, you get all the intricacies. But once you've learned how these things kind of 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 going and 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 the 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 economiser enable my status dependent starts etc. And 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, a economizer mode, etc. And I will have logic that will go and 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 write 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 pod loop patterns, my sequencer patterns, my resets, etc, my timers, etc. And then finally,
Phil Zito 13:09
I overlay everything with my safety logic. It's at this point that I go and I implement my safety logic. And I will use one of my various test methods to test my programs. But 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. And 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 temperature is greater than 65 degrees. Well, you just came upon a comparative pattern, right? That is a Boolean logic block, or a Boolean logic pattern. And all you got to do is remember your comparative pattern, your physical input, and your logical input and your output. And you're going to go and write that pattern, boom done. And you continue along and you see you know fan shall start and shall detect status of whatever within 30 seconds if not shall be disabled. And 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 be like, hey, Phil, how do you gain the ability? How do you gain 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, right, the ands, the ORS, the switches, the gates, etc. Once you 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 yeah, I'm good to go implement these patterns super easy to understand. And you're good to go. And or rather not implement these patterns. I'm going to identify sorry, identify these patterns. And once you identify those patterns, you're like, Oh, that's super easy. I'm good. 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 kind of the process around it. If you'd like more visual resources, go to podcast at smart buildings academy.com forward slash 291. Once again, that is podcasts at smart buildings academy.com for slash 291. And there you will find some free as well as paid resources that you can use to better learn how to program. Thanks a ton and I will see you in our next episode.
