Today I want to talk about some of the challenges programming control systems. I’m going to pick on Crestron since that is what I spend most of my time with. In traditional programming, over the years things have moved very heavily towards an object-oriented paradigm. To understand how far we’ve come let’s go back to the beginning (it will just take a minute).

Microprocessors are devices that are essentially able to perform mathematical operations. In it’s most raw form, a computer system moves information around bit by bit depending on various input conditions. All microprocessor based systems rely on very low level programming commands to move the bits through different registers. Not every programmer knows how to program in machine code. Nor should they endeavor to. A very simple analogy is that you don’t have to know how to build a car to drive one.

Okay…so what’s the challenge?

I suggest that programming AV control systems has taken a different evolutionary path. Being very closed systems, we are at the mercy of the manufacturers of the hardware to tell us how to program it and provide tools to do so. The problem is that in an attempt to satisfy both power users and beginners, we have various ways to mess things up in our code. It has been left to us as programmers to determine how we want to set things up.

Being someone versed in procedural based code, the concept of “object oriented” programming did not come easily to me but has had profound insights into why things are always harder than they have to be. The main premise of an object oriented language is that systems can be compartmentalized into objects which contain properties describing their behavior and also strict methods to retrieve or modify the properties.

One of the main benefits of object oriented programming is that you can’t just go in and modify an object’s data. Everything falls into a hierarchy and interactions between different objects is controlled, not just left to chance.

With Crestron specifically, it is just too easy to interject logic into existing code to add an additional feature, or hack out a bug. There is nothing stopping you from painting yourself into a painful corner, in my experience this usually happens late in the day when brain power isn’t at 100%. Sure, you will get compiler warnings but can always jam a few signals together via a buffer and you are well on your way to a long struggle.

It doesn’t have to be this way!

In many programming languages, there is a concept of local and global variables. Simpl Windows does not have this, with the exception of placing logic into Simpl or Simpl+ modules.
For programmers, this is very important but for people who aren’t “traditionally” well versed in programming it makes thing more complicated – maybe this is why they don’t do it?

You can create your own global and local variables though, and keep your logic clean. This is a personal coding style since no standards that I know of exist (closed ecosystem).

In this example, I have a buffer in my device driver section of code that acts very much like an argument definition in a module. It is up to the programmer to follow the programming style (it can’t be enforced) but the [Projector] signals are essentially my method variables (or global variables if you will) that can be accessed from outside the “function”. Note that these are not special names, you can use anything you want – there is no special behavior attributed with the naming of a signal.

With my code set up this way, I could have the [Projector]_set_on command do many things. For example, it could trigger a start-up timer, wait for the projector to warm up, and then switch inputs when it is ready. Any changes to what happens when the projector starts up only has to be changed it in this section of the code…much better than hitting different commands from various spots in the program and then having to debug various small issues.