I just finished watching all the videos for the C# for Crestron – Crestron Drivers online course and feel like I absorbed very little of it. The driver abstraction seems overly complicated, and the overall presentation of their videos is very dull. I like to contrast them with Q-SYS videos which are short and focused enough to hold your attention. Something about Crestron’s videos feels too robotic and I find myself multitasking with them on in the background.
But anyway, back to Crestron’s driver model. I haven’t looked at it much, but I’ve seen several updates pushed out to the database recently, so figured I should invest some time with them. There’s a developer microsite that contains everything you need to know about working with drivers. You’ll also find links there to download the latest Driver SDK.
Initial Test
I think first I’d like to see if these drivers can control the Sharp Aquos LC-40LE653U display I have setup in my office. This model doesn’t have a serial port on it, so it’s not ideal for integration (but it was the right size and available for me to borrow indefinitely). So I’m going to search the drivers list to see if one exists. I couldn’t find an exact match, but they do have an IP driver for the LC-40LE835U, so I’ll give that one a shot.
Crestron documentation seems to be missing a very basic tutorial about how to use one of these drivers. It would be nice to see examples for AV Framework, Crestron Home, SIMPL Windows, and SIMPL# Pro. If you dig into the SDK package, there are example programs hiding in \SDK\TestTools\Program Files\.
Lets start with an empty program (since the examples have included the kitchen sink apparently). I’m going to drag in a Crestron Certified Drivers Display Ethernet v2.0 (cm) module into my program and assign some signals that I can play with in debugger:
Using File Manager in Toolbox, I copy the FlatPanelDisplay_Sharp_LC-52LE640U_IP.pkg file to the \User folder on my PRO3. Then when I start the program, I can simulate loading the driver. It takes a few seconds to load completely:
But I can’t seem to get the driver to actually control the display. It says it connects, but none of the controls seem to have any effect.
Second Test
Let me make sure I can even control this display without worrying about the driver aspect. Here’s a stupid simple program that took 2 minutes to write:
And it works!
So it could be the driver I picked is sending slightly different strings (Sharp protocol uses a couple different variations). I could pick a different driver and try again? Let me see if there’s another one listed that might work better.
This time I tried FlatPanelDisplay_Sharp_LC-60LE661U_IP.pkg and it works!
The Verdict
It definitely took me longer to figure out which driver to use than it did to just google how to control Sharp displays over TCP/IP. I do like the added benefit of if the display were swapped out in the future (very likely in my office lab), I just need to find the new module and drop it onto the PRO3. But then I’d need to update the program with the name of the new driver anyway (so still requires a recompile). I could switch to using a configuration file to load the name of the driver in, but then I need to provide a way to update that, too.
Kiel the Coder 
Awesome!!
LikeLiked by 1 person
an abstraction driver and Dynamic load is very interesting
LikeLiked by 1 person
Agreed! I like the idea but not the implementation. I should try again using SIMPL# to see how that experience is. AMX has a similar concept that I haven’t explored much either since I like how quickly it is to swap between modules as long as they follow SNAPI.
LikeLike
I’ve been trying the dynamic loading part because I fear at some point this Samsung monitor will die and be replaced, with what I will never know. However, I have serial signals from a module parsing a configuration file connected to an MSP and to the CCD v2.0 and in debugger I can see that the value on the serial signal for the driver file path is indeed correct (and even cased properly, although unneeded for a DMPS3), read from the config file and set prior to pulsing the “Load_Driver” signal, but the Crestron Certified Driver relentlessly says the driver file, properly uploaded and named, does not exist. I’m losing sleep over this one. Any thoughts on what I may be doing incorrectly?
LikeLiked by 1 person
I haven’t touched Crestron Drivers since this post, so I dug up that example program and loaded it to the DMPS3-300-C in my office and it says it loads the driver correctly. It takes a long time from hitting load to getting confirmation that it loaded: debugger says about 8 seconds. If you want to download a copy of mine and compare, here it is: https://www.dropbox.com/s/5vi485gvbvyqni3/Crestron%20Driver%20Display%20Control%20Demo_PRO3_v1.0.0_compiled.zip?dl=0
LikeLike
Just read the help file for the 2.0 module and there is a parameter named UseDefaultDirectory that changes where it looks for the file. I have it set to False in my program, maybe that’s messing up the driver finding the pkg file?
LikeLike
I must have missed that parameter from previous versions! I’ll check that when I get back on site tomorrow. Thanks!
LikeLike
So, I checked the UseDefaultDirectory parameter, and it is indeed FALSE.
And, I dropped in an MSEND with the file value, leaving the ipaddress and macaddress coming from the dynamic settings file, and the driver loads and connects. However, while the driver will turn the monitor off, it says it’s sending the WoL packet to turn it on but the monitor never turns on. I can send a WoL packet from another module and it turns on without fail, so I know I have the correct MAC address and the processor is working correctly.
Since I only need power off, power on, set HDMI1, and polling for power on, I think I’m going to cut my losses with CrestronCertifiedDrivers and just roll my own.
THANK YOU for the help!
LikeLiked by 1 person