Crestron SIMPL Windows uses “named signals” to wire up programming logic. These signals are referred to as digital (either high or low), analog (a 16-bit number), or serial (a string of characters). Color is used to distinguish what type a signal is–blue for digital, red for analog, black for serial, green for ambiguous–but otherwise, your only clue about what information a signal carries is left up to its name.
How then should you name your signals? Let’s look at a few examples and see why they are good choices for signal naming.
[dev][mode][function]action
I was introduced to this convention while attending one of the programmer classes at Crestron. You use brackets to delineate what device, mode, and function a signal drives. The action gets tacked on at the end. For example, a button on your panel may control the play function on the DVD player. You might name your signal:
[dvd][transport]play
Brackets are easy to type–they don’t require you to press the Shift key–and they help you quickly pick out what a signal does.
room_dev_func_act
When you start programming multiple rooms within the same program, consistent naming is very important. If you name your signals with corresponding room, device, function, they will all group together when you’re trying to debug. Say you have multiple rooms with projectors, how do you isolate down to just the part of the program you care about? You might try naming your signals like this:
cafe_proj1_power_on cafe_proj2_power_off cafe_tv1_input_hdmi1
When you’re watching in debugger, all you have to do is hide everything except the signals that begin with cafe_. Copying the logic to another room that has the same layout is easy to do as well since you can copy and replace cafe_ with the next room, maybe lounge_.
Patterns to avoid
You want to make sure you don’t choose names that will spread functionality all over your program. For example, say I use select_laptop1_presentation_source. This reads well left to right, but later when we look in debugger, we may have our other sources scattered around. select_doc_cam_presentation_source won’t be sitting next to our first signal, but it will at least be close by. A better flow would be:
presentation_source_doc_cam_select presentation_source_laptop1_select
This way, we always know where to go to find our presentation sources, and can quickly select between them if we need to.
Summary
Choose a pattern for your signal names that will cause them to line up easily for debugging purposes. This will help make it possible to keep programs with 1,000s of signals organized. The names should convey what device, mode, or action the signal controls. Later I’ll discuss modules which provide a way to create reusable code, which can also hide a lot of noise created when debugging a running program.
Kiel the Coder 