How to Choose the Right Control Platform for Programming Projects

Read this before exploring control and automation options at InfoComm 2015.>

Steve Greenblatt

As a company that programs a variety of control platforms, we are often asked which platform we ‘prefer’ or what platform is better. Of course, we all know that this is a trick question, especially if you derive an income from said platforms. 

If I were to answer this question, the first response that I would provide is to work with the platform with which you feel most comfortable. Every system has its strengths, quirks and unique characteristics. The key is to follow the best practices, to be up-to-date on the tips and tricks, to know where to find help and to be able to troubleshoot effectively.

Define Expectations

Another response to the question ‘what system is better’ is to consider application and functionality expectations. Certain platforms perform better in installed presentation or conferencing systems, while others specialize in live performances or show control. Some may be better suited for commercial applications, while others can be better for residential systems.

Some platforms are geared more toward smaller systems; others specialize in larger systems. And some systems require more knowledge and experience, while others require less technical expertise.

Consider Depth of Driver and Module Libraries

One of the key elements to consider when determining the right control platform for you is the library of “drivers” or “modules” available to you. These are the device-specific or application-specific interfaces that make integrating devices with a complex API or performing a challenging function simple to implement by incorporating a pre-developed piece of code in your program. 

Related: Redefining the Control Systems Programmer

The availability of “drivers” or “modules” are a difference maker in simplifying a programming effort and in saving time and cost of the overall project. The power of a platform can be a direct correlation to the third-party devices that support it and the depth of “drivers” or “modules” available to it.

Look for Flexibility

Another key element is the flexibility of the platform, specifically the ability to make changes to the programming. As we know, all systems require updates and modifications to address user preferences, adjustments in functionality, equipment upgrades and ongoing maintenance. 

The ability to address these requests easily is important to gaining system acceptance. If user perception is that a request is an easy change, the resulting cost should be consistent with that expectation. Additionally, the need to overhaul or reprogram a system in order to field a reasonable change request is not a sign of a successful solution.

Choose the Right Approach: Configurable or Programmable Solution

When looking at languages and approaches to control systems, there is a distinction between systems that are “configured” and systems that are “programmed.” 

In general, configured systems are understood to require less complex programming and to take less time. Prevailing wisdom says that configured systems can be handled by a non-programmer. The configured approach is typically used for smaller, more simplistic projects, projects for which budget needs and customization needs are extremely limited. 

Related: What Comes First, System Design or Functionality?

On the other hand, the programmable approach is more complicated. This approach requires more programming knowledge, can be more time consuming, and is best suited for more moderate to complex systems whose users expect customization, changes, and growth.

Although the cost of a programmable solution may be higher on average, there are reasons why a programmable system may be the solution of choice over a configurable solution for the same project. These criteria have to do with the experience and comfort level of the person doing the programming/configuring, similar past projects that can be leveraged as a starting point, and the anticipated requests and needs of the client.

Line Coding Languages or Symbolic Languages

Within “programmed” systems, there are also distinctions between line coding languages and symbolic languages. Line coding languages more closely parallel mainstream programming languages that are text-based and readable. Experience with most coding environments can be translated to a line coding language. 

A symbolic language is a bit more unique. It is based on logic and signal flow that may be better understood by an engineer or non-traditional programmer. Prior programming experience has less benefit in learning a symbolic language; non-programmers may feel more comfortable in this environment.

As someone who has worked in various platforms and oversees a team of engineers and programmers that have different strengths and preferences, what I find most often is that control programmers typically stick to what they know and what they learned first.  They tend toward the language and platform that they feel most comfortable using, or the platform with which they have the most experience. They tend to seek low-risk opportunities when they are working in newly learned platforms to give themselves time and experience to feel comfortable. 

There are reasons and benefits for choosing a configurable or a programmable solution or in choosing one control platform over another, but nothing is steadfast. There is no clear determination that one is better than the other. Ultimately, it is up to the specific application and to personal preference.