av – Kiel the Coder

Planar Z6

Sometimes you have to deal with equipment that has little, no, or misleading documentation. On my latest project I had to control a few things on a Planar (ColorLight) Z6 wall controller. A little trial-and-error, and I’m happy to share the commands that actually worked.

Scopes of Work

I’ve been programming professionally for 20 years, and there is one elusive document that still escapes me: the scope of work.

I have seen them… just rarely. There have been Bills of Materials wearing the SOW name tag, but open them up, and it’s just a parts list. Usually I gather scraps of information from meetings and phone calls and jot them down in a notes.txt file that lives with the other project documentation. It’s not great but it’s something, and plain text will outlive all of us.

I’ve written previously about the need for proper documentation to program “correctly,” and I stand behind those words. How can we hope to end up in the right place without a map to where we’re going?

Silent Errors and RS-485

This post isn’t so much about RS-485 as it is about running into “silent errors” in your program that either break things in mysterious ways or flat out crash the whole thing. This is a tale of the latter.

Crestron Masters 2024

Masters 2024 is a wrap! Great sessions this year. The 3 hour blocks worked well to cover topics with just enough lecture and lab.

The Future of AV Programming: Part 7

2023 is coming to an end, and I’m so glad. This year has felt like I’ve stumbled out of one bad project right into the next. It’s been a constant battle of double-booking, short timelines, and delayed product. Everyone’s unhappy.

I thought it would be a good time to reflect on the challenges this year, but also to weave in my thoughts on where this is all headed in Part 7 of my Future of AV Programming saga.

Tools of the Trade

Being in the field again for the past week has been a good reminder that every AV programmer should equip themselves with some essential tools. I foolishly cleaned out my backpack last week because I wanted to have an easier time passing through security at the airport. Normally I take everything out of my backpack, dump it into my checked bag, then when I get where I’m going, transfer everything back into my backpack. Oh well, lesson learned.

NetLinx: A Real Program

This is the final post in this series, and we’re going to add some finishing touches to the user interface. One thing that’s been bothering me is that our system instantly turns on and off. This doesn’t work in the real world: equipment takes a moment to turn on and off. Even if we don’t match the exact status of the equipment (it’s all faked in our program anyway), it’s good to have a minimal startup and shutdown time to prevent the user from getting things into an unknown state.

NetLinx: Modules

Using and writing modules has some tangible benefits:

They are reusable code that we can polish over time
They break up large programs into smaller, testable units
They abstract away details we don’t need to worry about

Grab the code for this post from the GitHub repo.

NetLinx: SNAPI

In this post, we’ll explore the Standard NetLinx API–or SNAPI, for short. This is one of those topics I didn’t fully embrace when I started programming AMX, but over time, I grew to appreciate the benefits of adhering to a standard.

I’ve updated the touchpanel layout in this post, so if you want to grab the latest code, it’s available on GitHub.

NetLinx: Testing

This post will cover how we can use NetLinx Studio to test our program, especially in the absence of real equipment.