5.3 KiB
| title | description | published | date | tags | editor | dateCreated |
|---|---|---|---|---|---|---|
| Stupid Crestron Quirks | Crestron can be stupid sometimes. These are the undocumented ways. | false | 2024-03-08T01:24:44.827Z | markdown | 2024-03-07T23:22:27.431Z |
When creating a SIMPL Windows program for a 2 Series DMPS, DO NOT select the control system at program creation
When you create a new SIMPL Windows program, you get the option to select which control system this program is being created for. Without selecting this option, you won't be able to connect any of your logic to any of the hardware, and your program won't do anything useful. You can create a program without a control system, but this is usually to create a SIMPL Macro, which is then completed and added to a different SIMPL program. All this to say, a SIMPL Windows program without a control system at the top of the hardware tree is not useful on its own.
So, when I create a program that's supposed to run on a 2 Series DMPS (model DMPS-*, not DMPS3-*), and I understand all the above, naturally I select the model number of the control system I'm writing a program for.
The program gets created, and I get started creating the program. I get hung up on the part of the program that deals with switching video and audio sources, so I naturally look at the help file for the device that I'm trying to control. It's probably the most unhelpful help file in the history of helping people.
Here's where it's valuable to understand a little about the hardware. Crestron has a long history of design-recycling masquerading as backwards-compatibility. Basically, whenever they create a new product, they take an existing product and its tech, modify it to do what they want to market, and throw it out there. In this case, they took a 2 Series processor and a paired-down DM chassis, shoehorned them into the same case, and rushed it to market. The result is a disjointed attempt at providing the advertized functionality. Instead of providing the programmer with the appropriate controls for input switching in the hardware tree (you know, where you control the hardware), they instead had a whole bunch of undocumented nonsense nodes in a jumble of confusing unreadable card-based slot structure, and then a macro (yes, quite literally like the macro that I alluded to earlier), which connects itself to all the right spots in the hardware tree, and provides a littany of actually useful controls in the logic tree.
The perceptive reader might ask how such a macro does the attaching by itself (as the attaching of signals is usually the exclusive job of the Crestron programmer/dealer). Well, the answer came to me after 45 minutes of troubleshooting on my own and with my manager, and then after an hour-long phone call with Crestron True Blue support: I created the program wrong.
See, if you select a 2 Series DMPS at program creation, this macro doesn't get automatically added and connected to the appropriate places in order to be useful. Instead you have to create the program with no control system, then add the control system in configure mode. Apparently there is some sort of script that bootstraps the module to the hardware, and if you add the control system to the project at program creation, this script doesn't get to run, and your program is SOL. And since I had put the switching problem aside and finished creating the rest of the program, the tech on the phone had to tell me that I had to create a new program from scratch, and copy/pase my code into my new project to get it to work.
Now, I'm hesitant to rag solely on Crestron's developers for this convoluted mess of what-the-fuckery, but this situation does make it obvious that there is definitely a cultural reluctance to modernize and refactor their systems for the good of the programmers that have to put these systems together for their customers. Further, I'm sure that the decision to base their control systems on Windows CE and .NET Compact Framework 3.5 was not made by the developers, and they are certainly making the best of the hand they're dealt (especially now that their current control systems are running on these discontinued products). I think the blame for this particular circuis goes to their exec team who didn't give enough time to make this project the right way. It's a classic case of a product being rushed to market, but here's the important part: It seems that way only from the perspective of the programmer.
See, if there's anything that I would commend Crestron's Dev team for, it would be stability. It takes a lot to get a big system with hundreds of finicky pieces to work together just right, but by god, once you get it right, it will do the exact same thing in the exact same way every freakin time until the hardware gives out. This is no small feat, and I recognize that for what it is. I take issue with all the other cruft and bullshittery that collects after years and years of the "Backwards Compatibility and Stability above all" doctrine. It's a doctrine that creates a focus on marketing and sales above product quality. From the end-user's perspective, the product works as desired, but this is at the cost of programming time due to the complexity of these systems and the necessity of a programmer with the appropriate experience. All part of the bill that the customer has to pay.
And this is one of the many reasons Crestron can be stupid.