By now you should be a pro at creating new SIMPL# Pro projects. Let’s create another one, but we’re going to set this one up slightly different this time. We’ll still call it Part3, but change the solution name to Primer:

By now you should be a pro at creating new SIMPL# Pro projects. Let’s create another one, but we’re going to set this one up slightly different this time. We’ll still call it Part3, but change the solution name to Primer:

In Part 2 of this primer, we’re going to keep things simple… another Hello World program. Sorry, maybe Part 3 will cover something more exciting?
Continue reading “SIMPL# Pro Primer: Part 2”In Part 1 of this primer, we’re going to look at how to create a new SIMPL# Pro project. This series assumes you have a copy of Visual Studio 2008 SP1 installed as well as the Crestron SIMPL# Plug-In. If you need to install the plug-in, it can be downloaded from Crestron. The current version is 2.000.0058.01.
Continue reading “SIMPL# Pro Primer: Part 1”This is one part in a series of posts about my journey through the AV world. I’ve broken these up into bite-sized portions that shouldn’t take more than 10 minutes to read. I’m hoping to explore the future of systems programming in the Audio/Visual sense. Let me know if I wander off into a tangent somewhere, I tend to forget where I’m going.
I went to ITT Tech and studied subjects designed so I could land a job in IT. Instead, I took a left turn and ended up in AV. Well, joke’s on me because AV and IT ended up merging anyways. I may have traded away my knowledge about ASN.1 for the Inverse Square Law, but I think you can agree I’m the winner there.
This is one part in a series of posts about my journey through the AV world. I’ve broken these up into bite-sized portions that shouldn’t take more than 10 minutes to read. I’m hoping to explore the future of systems programming in the Audio/Visual sense. Let me know if I wander off into a tangent somewhere, I tend to forget where I’m going.
Last time, I talked about my aspirations of one day becoming a professional programmer. I hadn’t touched on the AV industry at all since it was largely unknown to me then. I had a few interviews lined up the week before graduating, and I ended up accepting an entry-level position at an AV company. They were primarily a TANDBERG reseller who also did occasional system integration work.
This is one part in a series of posts about my journey through the AV world. I’ve broken these up into bite-sized portions that shouldn’t take more than 10 minutes to read. I’m hoping to explore the future of systems programming in the Audio/Visual sense. Let me know if I wander off into a tangent somewhere, I tend to forget where I’m going.
Hi. My name’s Kiel. How you pronounce it is all on YOU, but to me it’s Kyle. I’ll accept anything with a K sound since at least you tried.
I sort of fell into AV programming 12 years ago, but let me start back at the very beginning.
This tip is going to cover Crestron modules–specifically, writing your own. As a new Crestron programmer, I shied away from doing this for years. It wasn’t the style used by the other programmers I worked with, and I never felt that I had enough time between projects to revisit how I would have done it differently. Over time, things change. Our team of programmers changed, new styles replaced the old; I became more familiar with the tool set; I could turn around new work much quicker than when I started; and I found I finally had time to apply some retrospection. Since I started incorporating my own modules into my programming, I’ve been able to increase my productivity even more and make the initial program almost bug-free.
I just finished watching the videos posted of Toine lecturing at Crestron Masters 2017. Sadly, this was a session I really wanted to sit in, but the space was reserved for veteran programmers (and this was my first time attending Masters).
He has many good points about how SIMPL+ has many bottlenecks to understand and work with, but one of his talks at the end covered GatherAsync. He prefaced this section by quickly covering what he considers the best practice for writing a CHANGE event in SIMPL+.
Here’s an example showing the design pattern:
THREADSAFE CHANGE From_Device { String Temp[MAX_LINE_LENGTH]; While (1) { Temp = Gather("\r", From_Device); MakeString(To_Device, "RX: %s", Temp); } }
This pattern works for 2-series and 3-series processors. Toine even says he can’t think of a better way to process incoming data from a device.
Normally, SIMPL+ operates at the lowest thread priority. The Gather function, however, runs at a higher priority so it can quickly service data coming in from devices. I wanted to pull this one idea out of his talk and put it into a blog post so I could easily remind myself that this is Crestron’s best practice.
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.
I’ve spent the last week or so diving into Crestron SIMPL+ and have been reminded what a quirky language it is. Here are some of the concepts I’ve been bitten by.