The subtitle above alludes to the notion that this month’s column is not necessarily a primer on the different methods of programming that are presently offered to compliment manufacturers’ DDC product lines. Instead, I would like to talk about programming methods, those of which I’m familiar with, those of which I’ve had experience with and the opportunity to work with. And although I don’t proclaim myself to be an expert in programming, I’ve had my experiences, and have been around long enough to see many different styles of programming throughout the years, and have watched them as they have evolved into what we now typically see in this day and age.

[an error occurred while processing this directive]

Back when I was a young engineer fresh from college and new to the industry, I had the opportunity to work for a mechanical contractor that performed its own control systems installations and was a dealer of a rather large line of DDC. My company sent me away for training to the manufacturer’s headquarters, and upon my return, I was appointed the control systems engineer for all projects using this line of controls. That meant generating the control drawings, drafting the Sequence of Operation, procuring all of the components, providing field installation support, and programming and commissioning the systems. Suffice it to say I had my hands full. What struck me odd at the time were the rather restrictive methods of programming that the manufacturer had in place for their product. I suppose it was just that point in time, when computer technology was really just beginning to be practically applied in our industry.

The programming methods of this manufacturer’s product consisted of templates and menus; really not programming per se, more like picking a template that most closely matches the application at hand, and customizing it to better fit the system. A cumbersome task indeed, especially for those “one-off” systems that didn’t really fit too neatly into any of the manufacturer’s offering of templates. And while the product line was very applicable to the zone level, where “canned” programs are to this day still very much the way to go, trying to apply the product and the programming to an equipment level app that it wasn’t designed for was like trying to jam a square peg into a round hole (or is it round peg into a square hole?). Anyway, imagine having an air handler with something out of the ordinary, say, two steam coils (not very common but it’ll suffice for this example!). Now choose a template from the manufacturer’s array of canned programs, and try to customize it to your application, by modifying the given parameters. Not much to work with here, in terms of flexibility. Needless to say I spent many a day on site, programming these systems, watching the computer monitor, hoping for stable, acceptable operation, and trying something different if I didn’t achieve my goal of “mediocre control”. I’m happy to say that those days are gone, but I do fear that some of my original creations are still in place to this day!

[an error occurred while processing this directive] After a few years, my company determined that our chosen DDC product line really didn’t fit the type of work that we were doing, so we dropped the line and searched for something else. We dabbled in off-the-shelf products, which were available to the common contractor through the local supply house. These products were perhaps more user-friendly, yet you still required a certain degree of expertise in that not every mechanical contractor could pick up some parts and create a functional control system. The programming style was “Q&A” (question & answer). Like with our previous line of controls, there were canned programs for typical applications such as terminal units, air handlers, and rooftop units. Also as with our previous line, you would choose an application that most closely fit. However instead of tweaking parameters, the software would actually guide you through a question/answer session, resulting in your custom application. A great concept on paper, and one that did have its merits, especially for the more typical applications. But come across one of those atypical systems, and you were stuck with something that didn’t perfectly match your application, and so you did what you could with it and hoped for the best!

As time went on my company grew, went through a merger and acquisition, and literally by default picked up a new line of DDC. Programming for this particular product was line-code programming, something that I was familiar with, seeing that I had taken a number of programming courses in college. This type of programming is the “traditional style” of programming, rooted in the old-school languages of BASIC and FORTRAN, and is still utilized by some manufacturers. It is extremely flexible, however very complex at the same time. The best that a contractor could do with this, is either acquire or build libraries of code for the more typical applications, and build upon or create new code for new applications. All in all, this was a superior product line with a solid, time-honored programming style, yet you almost needed a degree in computer science in order to actually implement it and service it.

As we approached the 21^st century (remember Y2K? Yikes!), I was enlisted to research a new DDC product line, one that would fit in well with our design-build approach on small to midrange projects. Alas we found the perfect fit with a small manufacturer that suitably complimented our in-house design philosophies. The hardware was rugged yet flexible, and the pricing was reasonable. We became the exclusive dealer of this product in our marketplace, and we enjoyed several years of this, designing, installing, and commissioning dozens and dozens of networked DDC systems throughout our territory.

The programming style, at the time for me, was a radical new concept, however one that had been around for some time already. The programming was/is referred to as graphical programming, to where one would actually create logical flow diagrams using AND gates and OR gates, along with other task-specific function blocks such as PID blocks and schedule blocks. The program flow is such that you have your inputs on the left, your outputs on the right, and the real meat of the programming in between. Flow lines connect the inputs to the function blocks, and connect the function blocks to other function blocks and ultimately to the outputs, all of course in a meaningful manner. Programming is in essence “self-documenting”, in that once the logic diagram is created, what you see can be printed out and serve as a record. And that’s not even the best part. When you “go live” with a functional program, real values within the logic diagram become dynamic, representing real-time data of real-world parameters. This is where this type of programming really begins to shine, as you can follow the logic diagram from left to right and truly understand the structure of the program. Commissioning and validation, troubleshooting, and future adjustments and modifications, all are facilitated via the utilization of the real-time logic diagram.

In all that I’ve seen in my career thus far, this graphical method of programming is truly the 21^st century way of getting it done. Many manufacturers seem to agree, as seemingly more and more are abandoning their old-school methods and hopping on the bandwagon…or at least, in my not-so-humble opinion, they should be!

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]