Best Practice – Logic Modules on the Bus

Simon-BuddleBy Simon Buddle, KNXtoday.

As many small systems integration companies grow, the likelihood is that each year they will add another product or technical capability to their armoury. This gradual growth enables us to navigate successfully through the shark-infested waters of the larger project. Over-stretching a company in resources or technical capabilities, by trying to land the golden egg that is the big project, has been the downfall of many a business owner, whereas growing the company organically is usually the route to success.

Technically, there are times when we have to make that big leap; from lighting system to BMS, from consumer board to energy management. These steps are sometimes necessary and can be extremely scary – the land where the bitten finger nails and waking in the night in sheer panic exist side by side with the midnight oil.

Making the leap to a more complex type of installation can be nerve-racking.

Making the leap to a more complex type of installation can be nerve-racking.

Each KNX product has a set of functions that it can do, and these can be matched with another product’s set of functions so that, for example, one of a keypad’s group objects can turn on or off a lighting circuit on an actuator, or maybe dim the lamp up or down. This is really as far as the initial training takes you – after that it is down to trial and error or ‘learning on the job’ as it’s more commonly known! The training focuses solely on the bus and its capabilities.

Example of complex logic functions for building control.

Example of complex logic functions for building control.

A Reliable Bus

One of the many great values of the KNX platform is the bus; a single wire that connects all devices to provide real time control, feedback, and reporting. In the midst of it all there are no dongles, bridges, cross-platform interfaces or secondary protocols. This fully intentional limit on functions is one of the reasons why the bus is so robust. It is not affected by the Internet router’s status, it will continue to work at its own prosaic pace as all around it collapses under the weight of the bits and bytes being force-fed down the wire.

Each device’s features exactly match the control requirements either as an input or output signal. When the room temperature sensor reaches set point it closes the valve – all done very simply using the device’s parameters.

But those same parameter sets can be incredibly frustrating – often they do not quite do what you want them to do. Maybe they output a bit instead of a byte, or you need a time delay or a variable function such as ‘if{night}else’ and it just isn’t possible within the product’s parameters.

At this point I’m sure everyone is thinking ‘Homeserver’, and of course it is the perfect solution. The UI abilities aside – reason enough to install one for most clients – it contains a blank canvas that we can use as a logic engine for any and all devices on the system. But sometimes it may be a sledge hammer to crack a nut. In more price-sensitive projects, it may not be the best option. Even on relatively small jobs, it is usual to need at least some piece of logic or a macro.

Even on relatively small jobs, it is usual to need at least some piece of logic (left) or a macro (right).

Even on relatively small jobs, it is usual to need at least some piece of logic (left) or a macro (right).

Logic Modules

ABB, Gira and others offer affordable logic modules that enable simple logic that is native to the KNX bus. A unit might be used to provide a boost facility for secondary-stage heating by use of a ‘temperature comparator’ used alongside logic gates. This would mean that the radiators, for example, could run the everyday background primary heating, but the system could put the trench heaters (second-stage heating) into boost mode if the temperature dropped quickly, bringing the room back up to the correct temperature very quickly.

Example of a logic module, the ABB LM/S 1.1 Logic Module MDRC makes 12 different functions available in one device, up to three of which can be implemented at the same time.

Example of a logic module, the ABB LM/S 1.1 Logic Module MDRC makes 12 different functions available in one device, up to three of which can be implemented at the same time.

Planning and Testing

It is always a good idea to write down and then draw out what you are trying to achieve with the logic before implementing it onsite. Test thoroughly on one device, make any changes to your code, and then test it again. Check what will happen to the logic if the bus fails or for some reason it receives a value that is outside of its control parameters.

Ensuring the robust operation of the logic is as important as any other part of the bus. Once you are happy with what you have written, copy and paste the logic across all of the required devices.

Once you are happy with what you have written, copy and paste the logic across all of the required devices.

Once you are happy with what you have written, copy and paste the logic across all of the required devices.

Conclusion

Logic modules need some understanding of programming principles, including truth tables for logic functions such as NOR, NAND and the like. In my view, they are a good half-way house between device parameters and the full PC-based controller, offering an inexpensive route into more advanced programming.

Logic modules are not the answer to complex logic functions such as the one at the start of this article, but they are an invaluable part of the KNX system that will enable you to get that bit extra out of the system. Importantly, they will enable your company to make that step into the field of control logic which might just win you the next job.

Simon Buddle is a systems integration consultant and installer. Simon is also a regular contributor to KNXtoday magazine and HiddenWires magazine, and the first winner of the CEDIA Region 1 Special Recognition Award.

You are welcome to comment on this article. See below.



Leave a reply (comments are moderated)