Lee Hollaar <firstname.lastname@example.org>
Since I became an emeritus professor of computer science in 2014, I've been using my experience as a computer designer and programmer to develop microprocessor-based system for use in theater, primarily the University of Utah's Pioneer Theatre Company where I am a volunteer stage electrician.
The first project was to control a Sony EVI-HD1 camera using the VISCA protocol. At about that time, I was looking for a reason to play with the just-announced Raspberry Pi 2, which seemed perfect for the task. Rather than develop a user interface for controlling the camera (and requiring a person to run it), I decided to make it look like a moving light to Pioneer's ETC Gio lighting console, getting information using the sACN Ethernet protocol. The resulting program is over 1,750 lines of heavily-commented C code, and has been running without software problems since Spring 2015.
I'm not posting the program here. If you are interested in it, contact me at the email address above.
At the end of the 2015-2016 season, for The Count of Monte Cristo, we needed to have five free-standing candelabra that could easily be moved on and off stage. Rather than use a commercially-available "flicker bulb," we decided to use LEDs with a 3D-printed flame powered by a 12 volt battery in the base. Control would be wireless, again using sACN but this time over WiFi. The Adafruit HUZZAH provides a low-cost processor with integral WiFi, based on the ESP8266 and supported by the Arduino development environment.
It was simple to port the sACN code from the camera control program, since the standard Arduino WiFi support included the needed multicast reception. Since Pioneer's lighting control was on its own WiFi channel, there was little interference, and multiple access points provided good coverage everywhere on stage. We have seen no problems with using WiFi instead of proprietary wireless systems, and it allowed us to use very low cost processors. The initial HUZZAH costs about $10. Recently, we have been using the WeMos D1 Mini, which not only has a lower price but has an integral USB connection which is easier to use with the Arduino development system.
The success of the original LED controller led to controlling different types of LEDs. While it was simple to copy the original program and then change a few lines of code to the new control mechanism, this resulted in a proliferation of programs. Luckily, I haven't discovered any bugs in the original sACN receiver code, but finding all the various programs that used it and fixing them wouldn't be fun. And having it predominate every source code file obscured what was actually needed to control something.
So, as part of the development of this web page, I've put the sACN receiver code in its own files (WiFi-sACN.cpp and WiFi-DMX.h) that can be included in the directory for any Arduino sketch. Be sure to change the lines in WiFi-DMX.h to your network's SSID and password.
I've also written another file (WiFi-ArtNet.cpp) that implements a subset of the ArtNet protocol, in particular the broadcast of ArtDMX messages that is implemented on ETC lighting consoles. Because the function calls are identical to the ones for sACN, is uses the same WiFi-DMX.h file and does not require any changes to the controller program. Just include WiFi-ArtNet.cpp in the sketch directory instead of WiFi-sACN.cpp. Normally, I'd have routines which would do either, depending on the initialization, but doing it this way saves program memory because only what you are using is included, a consideration with microcontrollers that don't have much memory.
I've also rewritten many of the controller programs to take advantage of these receivers. In particular:
When you order these from overseas, it takes as long as a month for them to arrive. Some are available from US sources (particular the Sonoff) with faster shipping, so keep that in mind when you search for a supplier.
One big warning about using relays controlled over WiFi: The signal to turn off the device controlled by the relay may be delayed or lost, so don't use them for things where safety requires an immediate shut-off. Also, be very careful when working with devices that are using or controlling line power.
I've also used the sACN receiver in the code for a simple DMX gateway. It requires only the ESP8266 processor and a single integrated circuit (some thing with two NAND gates, like a 74HC00) used as a differential driver and to generate the DMX protocol's break signal. Here's a drawing of how to hook it up, and a picture of my prototype.
At present, I'm playing around with wired DMX using the Atmel AVR microcontollers that are used for the original Arduino boards. In particular, I have both a DMX receiver and a DMX transmitter, and am about to combining them as the starting point for a low-cost DMX tester.
I'm also planning on extending my simple ArtNet receiver to handle more of the protocol, in particular polling and point-to-point transmissions based on the poll results. And I'm looking at an implementation of both that and the sACN receiver for wired Ethernet instead of WiFi. The problem there is that there aren't microprocessors that have integrated Ethernet, like the EXP8266 integrates WiFi, so a variety of chips are used, some of whose software doesn't support the multicasting required for sACN or handles broadcast well as required by ArtNet.
When I have all those things done, I'll put together a new version of the DMX receiver routines that work with sACN and ArtNet, connected using WiFi, Ethernet, or wired DMX-512. Your program will work with all those DMX sources, depending only on the particular receiver you include in your sketch subdirectory.
And suggestions of other useful things to do are always welcome.
It seems like most computer programs come with some sort of license today. So ...
You are free to use these programs for your production without any royalty payment, and to modify them as necessary. Enjoy!
Please let the author know how you are using them, especially if you are doing something fun with them. Definitely let him know if you find a bug or change it to work better, so future users can benefit. Email: email@example.com
And, of course, no warranty and no liability for damages.
Last modified 2017-06-05