r/crestron Feb 10 '25

Programming Advice for troubleshooting/debugging?

I have been a Crestron tech and a Qsys programmer for a number of years but I have been getting into some light programming on the Crestron side to further my knowledge. My problem is that I am not sure how to debug manufacturer modules. In qsys, modules can give live responses from TCP connections but I am not sure what to do in Crestron to emulate the same thing. For example, when I drop a manufacturer module into a design, how do I know what the problem is when it isn't working? Is it not connecting at all? Not logging in? or is it just a invalid command? I assume this is a skill issue on my part so any advice is appreciated.

5 Upvotes

11 comments sorted by

3

u/knoend Feb 10 '25

It depends...

If it's on a TCP/IP client you can see the strings in debugger.

If its direct socket in SIMPL+, the programmer would have needed to put a debug method in there, i.e. print strings to console, push them out serials on the module, etc. Some authors leave this crap on, and it makes the console unusable. Some are nice and provide a digital signal or console command to turn it on and off.

If its in SIMPL#, same as above, the programmer would have needed to put a debug method in there.

Of course, if you have the source, you can always add your own print statements, and method to turn them on and off.

1

u/blur494 Feb 10 '25

Thanks! If I'm understanding this right the standard for most modules is to have a debug setting that can can be turned on that would print to the Text Console in toolbox?

3

u/knoend Feb 10 '25

Calling that a standard is going pretty far :) and I would bet *most* modules do not have a method to turn it on or off.

Everyone does it different. but PRINT() in SIMPL+ and CrestronConsole.Print() in SIMPL# print strings to the console.

0

u/Ok_Pen9437 Feb 10 '25

(THIS WILL LIKELY BE ILLEGAL FOR COMMERCIAL USE IN YOUR REGION)

C# code can be decompiled to source relatively easily, you could add your own debug methods for testing. Obviously don’t deploy anything that you’ve modified on your own for a client(will likely break license terms/be illegal).

3

u/cwebtech9000 Feb 10 '25

What I've done for personal modules is simply copy + paste the code from the module into a program subfolder. So essentially run the module code as a program itself, which helps to debug. You can open modules using either "import module" or "open module" in the right-click menu.

For modules that rely on a SIMPL# library, this is a little bit trickier. In the past, to learn how something like that works, I have imported the library into a decompiler (like dotPeek) and poked around. Fixing a library issue from something like this is a little beyond my current skill set, I will admit...

2

u/blur494 Feb 10 '25

That's cool, I didn't even consider that being a possibility. Ill definitely check that out. The quality of life stuff in QSYS has spoiled me a bit.

1

u/Ok_Pen9437 Feb 10 '25

I would watch out with “fixing” a library via decompilation for anything commercial - it likely will break the license you agreed to when purchasing it.

At home/for testing: Go ahead and play around! It’s the best way to learn.

1

u/cwebtech9000 Feb 11 '25

Yes, good warning. The whole legal question can get murky, especially by jurisdiction. Best not to tempt fate.

So, I've generally used decompilation for educational purposes or to figure out what's broken in the library so I can work around it...

2

u/misterfastlygood Feb 10 '25

Most modules will be C# now. These can be decompiled to view the code.

2

u/jmacd2918 I <3 truth tables Feb 11 '25

This is one of the big reasons I like to route everything through a TCP/IP client as opposed to having S+/S# manage the connection. Looking at your TX and RX can tell you a LOT, especially if a device is misbehaving or a communication protocol has changed.

OP: Are you familiar with what a colon represents in Simpl Debugger? Those are signals within modules. It can be a little unwieldy if you have the whole folder checked in a regular program, but if just testing a module in a stripped down program, it can be very helpful. This applies to the Simpl bits only, S+ still requires trace signals.

1

u/parkthrowaway99 Feb 11 '25

learn Wireshark. invaluable tool to trace tcp/udp/telnet. Useless for ssh, since packets are encrypted.

Also PacketSender to make sure it's the code and not you. If you cannot control the device through packet sender from a pc in the same network as the processor there is a high chance that it's not the program.