Category: programming

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.

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.

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.

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

In the last post, we got started by making sure our tools worked and blinked some lights. In this post, we’ll dive deeper into how the NetLinx language works and write a legitimate program.

I want to write a few posts about programming AMX NetLinx controllers. While I started my career programming AMX systems, I’m lucky now if I see 1 or 2 in a year. Strangely, every time I’ve started with (or returned to) a company, I’ve been handed a NetLinx system to figure out. It’s sort of a welcoming return to AV because programming in the NetLinx language is well-suited to automation tasks and something about it brings me joy.