Greetings after a bit of a break in the action in terms of blog posts. Those of you who follow the blog know that I can be a bit inconsistent in terms of my posting rate. That’s mostly driven by what’s been going on in my personal and professional life, and there has been quite a bit of activity on both fronts the past month or so.

While this may sound like a “plug” for a manufacturer, its actually not. No matter what you think about ALC, at its core, Eikon simply is a tool that allows you to draw logic diagrams. Logic diagrams are a powerful way to communicate your control sequence requirements and while the diagram you develop in Eikon for Educators could in fact be downloaded to an ALC controller, it could also serve as the basis to describe the control logic for the same program in anyone’s control system.

To give you a feel for this, here is a logic diagram I developed in Eikon for discharge temperature control in a typical VAV air handling system.

(Incidentally, for those who are interested, I have saved .jpgs of the logic diagrams in this post in the public folder of my Picasa web album. And, if you double click on any of the images in the blog, you should get them opened up in a separate window at a larger scale with the ability to zoom in a bit; how much depends on the browser you are using)

Bear in mind that this is just one way to control discharge temperature. It certainly is not the only way and may not even be the best way. Its just an example I created to support a class I recently taught on the subject at the Pacific Energy Center.

If you haven’t been down this path before, the diagram above may seem a bit complex and overwhelming. So, if that is the case, this may be a simpler example of a logic diagram for you to consider.

This is a little home project I am working on. Its a modification to the logic that controls a set of outdoor lights at my house. Currently, the lights are controlled through a little wireless mesh/power line carrier based system. The controller is manufactured by Universal Devices and the devices using the technology are available from a number of manufacturers, many of whom can be found through a company called Smart Home. Here is a picture of the panel with the controller which is installed in the closet off of my office.

The controller and related hardware I am talking about are the black box and two off-white boxes towards the bottom of the panel, The “ice cube” relay, dc power supply (green rectangle), and gray box above them are a different experiment that monitors the operation of my furnace using a little web enabled controller that Mamac manufactures (the gray box). More on that in a different post maybe.

Anyway, the lights in question are currently controlled based on motion sensed on the sidewalk between our garage and our house and are allowed to operate any time between sunset and sunrise. Kathy (my bride) pointed out that if I wasn’t here and she wanted the light to be on, maybe because she or Riley (our faithful watch-puppy) …

… and Hobbes, his co-worker, heard a noise outside or something, she kind of had a problem. Short of going outside and walking into the field of view of the motion detector (something she would not be inclined to do if Riley or Hobbes were on “high alert”) she had no options with regard to shedding some light on the situation.

So, I decided to add the ability to turn the lights on using the switch that controls the deck lights and also the ability to turn them on or return them to the motion based control via a remote control that she can keep on the night stand by the bed or where-ever she happens to be. The logic to make all of that happen is a bit more complicated than what is currently in place, so I decided to use Eikon to work it out before coding it into the controller, which uses a very basic line oriented programming language.

Here is a screen shot of a portion of the current program, which does not have the enhancements added as of yet.

Here is the logic that is implemented by the current program and the the other program (Back Garage Light Dim) that it calls under some conditions.

There are a number of things that I like about the logic diagram. One is that it puts the entire logic sequence in front of me in a graphic format, which for my mind at least, is much easier to work with and analyze as compared to looking at multiple programs in the Universal Devices programming tool.

I find the graphic portrayal of the logic to be fairly powerful. Turning to an HVAC system example for a minute, contrast this logic diagram for a PID loop controlling a hot water valve …

… with the same software element as it would be called out in Siemen’s PPCL, a line oriented programming language.

LOOP (0,HWSupTmp, HwVlv,HWStPnt,HWPG, HWIG,HWDG,15,0,100,0)

When loaded into a controller, both program elements will perform the same function and perform it well. But for many people, “yours truly” included (who spent two years working for Siemens – then MCC Powers – writing PPCL and having a blast doing it), its easier to see what the intent is in the graphic format. In fact, before I wrote PPCL, I would do some version of a flow chart to guide my development process. Flow charts are essentially the same thing as a logic diagram.

For me, having a picture of the logic in front of me makes it easier to verify the logic will work as intended and also troubleshoot it if there is a problem. And, towards that end, one of the really cool features of the Eikon tool is that it allows you to simulate the logic in operation. Here is the current logic diagram for my outside light running in simulation mode with the time set to tonight and the motion detector triggered.

Granted, I probably don’t need to simulate such a simple program to verify that it works. But the ability to do that will probably come in handy for verifying the enhancements I plan to make, which add some complexity to the situation.

And I suspect that you can see how the ability to simulate the logic for the AHU discharge temperature control example would come in handy, especially when you consider that the logic in the example would probably interact with other control processes in the program controlling the AHU, all of which could be developed as logic diagrams and then verified by simulation before deploying them to the field.

So that begs the question; Does simulating the logic successfully guarantee a perfectly functioning system right from the start? The answer is “no” because when you develop and install the software, a number of other things come into play.

For one thing, the simulation does not provide any direct accommodation for the dynamics of the building as it interacts with the environment, the occupants, or the other systems in the building. It only verifies how the “dominoes” will (or will not) fall when you flick the first one. Tuning things to accommodate all of the building dynamics is, to a large extent, what the commissioning process is all about. Knowing that the logic is correct is a big step down the complex path to success, but not the solution in and of itself.

For another thing, if you are working with a system besides ALC, you still need to translate the logic into the actual programming language. For simple functions like an “Or” statement or an “And” statement, the translation is pretty direct; the truth table for boolean functions is the truth table, no matter who’s logic is implementing it.

But for more complex functions, there are probably vendor specific requirements for programming and implementation. For instance, ALC uses a different icon for a direct acting vs. a reverse acting loop, where as in the Siemens line code version, you just change the first parameter from “0” to “128”. Plus, there are multiple ways to actually implement the PID algorithm.

That’s why a symbol list is important, especially if you decide to use the Eikon tool as a way to communicate you program logic as a basis of design. Here are screen shots of the symbol list for the AHU logic that I showed previously.

There are a couple of things worth noting.

The symbol list defines a few things that I think are important but would be accomplished sort of automatically if I were to load the program directly into an ALC controller. This is in contrast with using the Eikon generated logic diagram to communicate intent in a competitive bid environment for a generic control system by a generic manufacturer.

For instance, almost by default, an ALC system trends all physical points. In other words, when you put the symbol for an input or output into the logic diagram (which basically establishes that object in the ALC data base for a project where you are using Eikon to program the system), one of the parameters available for you to set is the trending requirement, as illustrated below.

So, including the trend requirement symbolically for an ALC system would redundant.

But, if I am using a logic diagram to convey intent in a competitive bid environment, that one little symbol …

… says a lot. If I enforce the requirement, it says that the system needs to be structured in a manner that will support trending the point once a minute and archiving that data. That, in turn, will have some very specific meaning (cost) for many vendors in terms of how they structure their network architecture.

This added first cost will pay for itself by several orders of magnitude over the life of the system due to the operating and performance capabilities it provides. And, if I don’t ask for it as a part of the design, adding it as an after thought will cost several orders of magnitude of what it would have cost had I incorporated it from the start.

If I start out with the requirement as a basis for the design, then I am talking about (maybe) slightly more expensive communications cards and wiring. If I have to go back and upgrade the system after it has been installed because the “as installed” performance does not meet my needs, then I am talking about having to replace hardware and wiring that I already have purchased and installed. Thus the potential multiple order of magnitude jump in cost relative to getting it right the first time. The simple little “trend this point at least once a minute” symbol on the logic diagram, if enforced, gets it right the first time.

I might reinforce that with some language in the spec that requires a functional test that demonstrates compliance. But even with out that, its fairly clear from the logic diagram and related symbol list what my intent and requirements are, no matter who ends up getting the job.

In the ALC world, the Hi and Lo Alarm feature described by my symbols of the same name (the purple symbols on the 2nd page of the list) are actually standard. But not so for all manufactures. So, I made some custom symbols to define a specific function that I happen to used a lot; redundant if I happen to be using an ALC system, but documenting a requirement if I am asking someone else to bid the work.

In Eikon, you can actually create custom symbols that, if you “step inside them”, simply package up logic you might use a lot. Here is what it looks like if you “step inside” one of my custom alarm symbols.

So, ALC system or not, its important that my symbol list define what I mean by my custom symbol. If I used the logic diagram to actually program and ALC system, then the logic I had embedded in my custom symbol would (right or wrong) be downloaded to the controller as a part of the program, irrespective of what the symbol list said.

But in the general case (using the logic diagram to communicate intent), the symbol list is a crucial link for conveying my ideas.

So, my bottom line here is to say that I think the free Eikon tool is a powerful way to develop, verify, and communicate your control requirements, regardless of whose system you favor or who ends up getting the job. By working through the logic and making sure it does what you want, and then communicating that information to the people bidding your work, you ensure that the system you designed will deliver the results as intended.

Some might argue that going this extra step might take more time than simply writing a short narrative sequence. My response to that is to say that if that turns out to be true, then you narrative may not be delivering everything you intended it to deliver. My personal opinion is that narratives are a great way to communicate how the system is supposed to work if you write them to describe the logic diagram that you developed and verified. But with out going through that first step, you are at risk for doing the same thing I did years (decades) ago in my Fortran class back in college when I skipped the flow chart and went directly to punching the cards.

The program that I thought would do what the assignment asked for (write a line of text, do a carriage return, write a second line of text, do a page feed, and exit) ended up shooting a box full of printer paper through the line printer as fast as IBM mainframe could cycle through the lines. I discovered my error by making a flow chart (a.k.a. a logic diagram) of my program, which revealed that I left out a simple step that, as a result of the omission, cause the program to lock into an infinite loop until the printer ran out of paper (and the computer lab assistant ran out of patience). Incidentally, this illustrates another advantage of the logic diagram; if you work through it backwards, its a troubleshooting guide.

By providing Eikon free of charge to the design community, ALC has provided a tool that lets you verify your logic before your write your narrative and saved you the time it would take to develop the symbol library let alone the time it would take to develop a simulator. It also means that your projects are more likely to deliver the intended performance and do it with out a lot of arguments and change orders, so there are savings to be achieved on a number of fronts. (Owners take note, you are probably well advised to pay a bit more to have your consultant go this extra step if they are not already doing it; the design fee added will pay for itself many times over during construction and the operating life of the facility).

So, was I lying when I said earlier that this was not a plug for a manufacturer? Well, maybe a little bit. After all, given what I believe about how to go about developing HVAC software, the ALC tool and system is the perfect solution and will save me some time if ‘m actually working with an ALC system. But, as you will see if you follow the link at the beginning of the post, they have made a sophisticated development tool available to the design community for their use irrespective of whose control system is the target of the logic. And while there system is a great system (my perspective), there are also other great systems out there that I am happy to work with. I just want to get the logic right before I start using them.

And ALC isn’t the only manufacturer to recognize the value of logic diagrams; to the best of my knowledge (in no particular order as they say), TAC America, Alerton, Invensys, and Johnson Controls all have a graphic programming language or at least the option of doing that for some of their devices. But to the best of my knowledge, ALC is the only company that has made their programming tool available to the design community for use as a design and development tool.

As Jay Santos might observe, ALC may have “put bazooka’s in the hands of monkeys” by providing this as a free resource. (Don’t be offended; I quote Jay having myself been a monkey with a bazooka on more than one occasion). But I suspect that they figured if it was good for the industry, it would probably be good for them. So everyone wins.