Yesterday I install a new closet door in our front entrance hall, and discovered a problem which I then solved with 3D Printing. The door is a standard bi-fold type, with pins in the top and bottom of one side for rotation, a central vertical hinge, and a track along the top to keep the far side in alignment.
The problem was – with the volume of coats we need to survive a the winter on the ice planet Hoth (Chicago) and the positioning of the hanger rail, the coats push the door out and prevent it from staying fulling closed. Given that this is immediately adjacent to the front door, not an ideal solution at all.
There are lots of types of locks/clasps/magnets designed to solve this problem, but the one I chose to emulated is this over-the-door babyproofing product. It’s essentially a c-channel of plastic that slides over the middle-hinge when the door is closed, to prevent it from swinging open. Genius.
I created my own variant in Fusion360, thinking about how to make the design rigid, printable, and aesthetically pleasing. I added ridges along the sides to increase its lateral strength, and little pull-tabs to make it easier to grip. I trussed-out the top to give it some additional strength and reduce weight. Here’s how it ended up after about an hour of drafting:
Printing took a little over 10 hours, and the final result works great. I selected a blue-green PLA+ for ease of printing and aesthetic considerations:
What follows is a list of output-counts for ETC Eos Family consoles. Because I’m always needing to reference this information, and I want to be lazy when I need to find it. So, without further ado, here’s the current output capacity for different ETC consoles, as of July 24, 2019:
Base Output Count
Unlocked Output Count
Legacy Consoles Upgraded to 2.6 Software
4096 (8 * 512)
24,576 (48 * 512)
Eos Ti DisplayPort at 5K or higher now @ 24,576
4096 (8 * 512)
16,384 (32 * 512)
Eos Ti DVI at 5K or higher now @ 12,228*
4096 (8 * 512)
24,576 (48 * 512)
4096 (8 * 512)
12,228 (24 * 512)
4096 (8 * 512)
8192 (8 * 512)
Eos Classic at 5K or higher now @ 8192
Eos Classic RPU
4096 (8 * 512)
8192 (8 * 512)
Eos Classic RPU at 5K or higher now @ 8192
4096 (8 * 512)
24,576 (48 * 512)
Gio Displayport at 5K or higher now @ 24,576
4096 (8 * 512)
12,228 (24 * 512)
Gio DVI at 5K or higher now @ 12,228
4096 (8 * 512)
24,576 (48 * 512)
@5 at 5K or higher now @ 24,576
2048 (2* 512)
12,228 (24 * 512)
1024 (2 * 512)
6144 (12 * 512)
Ion Win 7 at 1536 or higher now @ 6144
1024 (2 * 512)
3072 (6 * 512)
Ion XP at 1536 or higher now @ 3072
2048 (2* 512)
6144 (12 * 512)
2048 (2* 512)
3072 (6 * 512)
6144 (12 * 512)
Nomad 256 now @ 512; Nomad 1024 or higher now @ 6144
6144 (12 * 512)
Nomad Puck 256 (3 USB) now @ 512; Nomad Puck 1024 (4 USB) or higher now @ 6144
2048 (2* 512)
Nomad Puck 256 (4 USB) now @ 512; Nomad Puck 1024 (4 USB) or higher now @ 2048
1024 (2 * 512)
6144 (12 * 512)
1024 (2 * 512)
ETC Nomad “256“
1024 (2 * 512)
*The listed Eos Ti DVI count for previously-smaller-output-count consoles doesn’t match the new Unlocked output count. This may be a typo by ETC.
The legacy consoles section indicates the new output counts for consoles that were available before Eos software version 2.6, when consoles were available for purchase with much more granular output counts. The 2.6 software upgrade standardized all consoles to either a Base model or Unlocked, with all consoles moving to the next higher output count available (e.g. no one lost output capability with this upgrade).
Some background, and an explanation of why output counts aren’t round numbers: ETC’s line of Eos-family lighting control consoles can be purchased with different numbers of parameter outputs. In an older way of thinking of things, one might have had a limited number of universes. As I’ve featured in my post about lighting control protocols, each universe contains 512 “slots” of information, and individual devices (dimmers, intelligent lights, other controllers) can be told which slots to listen to by giving each device an “address” (or range of addresses).
The key difference is that now, with lighting data being largely distributed over a network and only turned back into ‘hard’ serial DMX near its endpoint, limiting a controller’s output to only 2 or 6 or 24 physical universes would be a little unnecessarily constraining. Instead, the output count is how many total DMX slots one can control, spread across as many universes as the user desires. So, a basic Nomad, for example, could control all 512 slots in a single DMX universe, or a single address in each of 512 universes, or anything in between. Only addresses which are patched count toward the total output count.
Over the past week, I got to the point with the mini moving light that I needed some way to consistently pump DMX into my prototypes to test their functionality. Thankfully, the first set of PCBs I built for this project function as both DMX receivers and transmitters, so whipping together a basic DMX controller only took about 20 minutes.
So here it is: my tiny DMX controlled “light board”:
Not much to look at, really. It’s just the DMX Control Shield I build earlier, with its Arduino Pro Mini, and 3 potentiometers from the junk box. The ends of each pot are tied to +5V and ground, and the wipers are tied to three analog pins.
Originally, I had the Arduino just reading the straight value from the analog pins, mapping those 10-bit (0 to 1023) values from the ADC to 8 bit (0 to 255) values suitable for DMX, and shoving those out as DMX addresses 1,2, and 3 as fast as possible. But I found that some inconsistency in the analog readings caused the servos and LED to twitch and flicker noticeably. So I modified the code to read the values from the pots every 20 milliseconds and average the last 10 readings when outputting. The output values calmed right down.
The result is a reasonably stable controller, and plenty to test the mini moving-light with:
I also made some specific improvements to the physical design of the light, including:
Lengthening the body to accommodate the Carclo optic and heatsink
Adding vents to the body for heat-removal
Including some new wire-routing holes in the base and widening others for improved cable routing.
I also designed and printed some (really adorable) 1″ triangle truss and some hanging brackets to mount this thing on. Here’s the moment from my Sunday night livestream where I hung the light on its truss for the first time:
Just today, I got in another couple orders from DigiKey, and my latest batch of PCBs from JLCPCB should arrive tomorrow. The notable improvements to the PCB and parts include:
Separating the Pan and Tilt servo pads (doh!)
Switching to a stout-er 5V regulator
I also ordered a few VX7805-1000’s to play with. They’re a self-contained, fixed-output buck converter that’s meant to be a drop-in replacement for a 7805 linear regulator. Neat part if it works, and not horribly expensive.
Switching to an inductor spec’d for 1A forward current instead of 500mA.
Switching to a schottky diode rated for 30V instead of 20V.
Assuming this assembly goes well, I hope to build two or three of this version (which I’m calling version 0.4) and set them up for a little DMX-controlled dance party. Here’s hoping!
As I hinted to in my original post about the Arduino Pro Mini DMX Shield, and then talked some about in my PCB Assembly Livestream, the latest version of my DMX shield is geared toward driving in miniature moving light. This means that, in addition to being able to receive DMX, the Arduino driving the device will need to be able to drive a couple of servos and dim a relatively high power LED. There are many way of skinning both of those cats, so let’s look at the solutions that are present in V0.3 of the DMX shield.
Of LED dimming and Servo control, the latter is the easier problem to solve. While there are dedicated servo-driving IC’s, and modules, almost any microcontroller, including the ATMEGA238/Arduino can control a hobby servo in a straightforward way using minimal additional hardware.
A typical hobby servo needs only three wires running to it – +5 for power, Ground, and a control line. The control line carries the position data for the servo in the form of pulse width modulation. The servo expects to see a pulse every 20 milliseconds. A pulse of 1.5 ms corresponds to the center (90°) position of the servo. A 1 ms pulse rotates all the way in one direction (0°) and a 2 ms pulse rotates fully the other direction (180°). There is a standard Arduino Servo Library that translates degrees inputted into the appropriate duration Servo pulses.
The only additional hardware present on the V0.3 board for Servo control is, therefore, a bulkier 5V regulator. The 5V regulator on an Arduino Pro Mini isn’t particularly stout to begin with, and I’ve had issues on previous projects with “off brand” Pro Minis having even less 5V oomph than that. So there’s a pair of DC input pads and a TO-220 packaged 7805 to provide a healthy amount of current for the servos.
The LED dimming half of this project has a wider solution space than servo control. The typical solution is MOSFET dimming. A FET is switched on and off rapidly, with a variable duty cycle to control brightness. This is the solution that commercial DMX LED decoders use, with a bank of 3A-5A fets, one per driven channel. It’s simple and inexpensive.
The problem is heat. MOSFETS with super-low on-DC resistances are expensive, and those with higher DC resistances create more heat. There’s always a balance being struck between cost and current carrying capacity. Which is why most commercial DMX led dimmers sit in a sweet spot between 3A and 5A. And all of them come in metal cases, sometimes mounted to large heatsinks, to help with heat dissipation. Less than ideal for what is ultimately meant to be a 3D-printed moving light made of thermoplastic.
The other problem is overcurrent regulation. For typical, inexpensive 3A per channel DMX LED driver, there’s nothing to protect the FETs if you load up a channel with, say, 5A of load, there’s nothing in the drivers to prevent the FETs heating up to their failure point. Or worse. See, for example, this example from a local theater:
After some investigation, it turned out that there was a wiring error causing a dead-short across one of the channels. Which subsequently burst into flames. No kidding. The Stage Manager reported seeing a cloud of smoke roll out of the vom, which it turned out was discharge from the fire extinguisher the crew was using. Yikes!
With a controlled environment and a defined load, an overcurrent load is slightly less of a concern, but it seemed like there must be a more elegant solution to both the heat and overcurrent issues.
The solution I’m currently trying is the the AL8860 Buck LED Driver. It is essentially a DC-DC step-down converter which derives the average current through its load from a SET resistor between a couple of its pins. It has an input voltage from 4.5V to 40V, and in TSOT-25 form factor a maximum current of 1A. A TTL PWM signal applied to its CTRL pin brings the average current down from the maximum SET current to between 0 and 100% of maximum, depending on duty cycle.
While the IC itself ultimately uses an NDMOS FET to do its switching with a relatively high on-state resistance (200 mOhm), its incorporation of current management and a step-down converter directly into the IC makes it an attractive option. And for the form factors I’m looking at, I’m not likely to be pushing more than 1A through an LED star anyway.
The AL8860 requires a few external components as a buck converter would – an inductor and a schottky diode – as well as a bypass cap and the SET resistor(s). These altogether take up about as much PCB space as a decently sized FET switch would, let a long the voltage conversation IC’s that would allow this to run on a variable voltage.
I made the bold choice of testing this IC and hardware on a livestream recently. But not before an unscucessful attempt test attempt.
In an attempt to validate this IC idea before committing to it, I purchased a handful of AL8860s, schottky diodes, 0.1 Ohm resistors, and inductors, and tried to piece together this idea on a piece of copper-clad. That did not, in short, go well. Without proper pads, I couldn’t get the IC to stay in place well enough to solder magnet-wire to it. Even after I super-glued it down, the heat from my soldering iron weakened the super glue and caused it to come unstuck. And release superglue fumes. Fun!
So I pulled the trigger on ordering a batch of the V0.3 PCB’s, this time from JLCPCB. But in my rush, I didn’t run a final Design Rule Check, and the pads for my Pan and Tilt servos overlap. Ah well, this was mostly to validate the LED dimming circuit.
And validate it did! Check out this gif from my testing session:
Now that’s some light! The arduino was just running a simple ramp-up/ramp-down for validation.
The LEDs are from LEDSupply, a vendor on the east coast that I haven’t used before, but stumbled upon while looking for LED options. They happen to be having a closeout sale on some Luxeon R 3-LED stars, which seemed like a good option for something I might smoke or blow up. The LEDs themselves are Luxeon LXA7-PW40s. And with the appropriate Carclo optic, the beam width is fairly narrow. The heatsink is just something from the junk bin.
At 1000mA forward current (which LEDSupply recommends as the maximum allowed current), they emit around 975 lumens total, around what a 75W PAR16 lamp emits. Even testing at 500mA as I was, it’s a punchy little package!
There’s some CAD time in my future. I’ll need to whip up a case to hold the PCB and accommodate a pan servo. I think the arm and body components I will be able to mostly re-use from my previous design, possibly with a little extra room in the head for a proper heatsink.
At some point, I’ll have to re-order PCB’s with the errors corrected, especially the overlapping servo-control pads. I may also want to rethink the mounting hole locations, and possibly bring the DC and DMX inputs out onto their own little tabs to solder connectors onto. But first, I think it will be satisfying to bring this version of the LED to life.
Last night, as I started to assemble V0.3 of my DMX Mini-Mover Shield, I thought it might be fun to switch on my webcam and stream the assembly live to the World Wide Web. What follows is about 80 minutes of unstructured benchwork, chatting about DMX, sACN, and circuitry, and a first test of the new LED dimming circuit. Will it light up, or will it go boom? Watch the video to find out:
In my dayjob as the lighting supervisor of a midsize regional theater, we get to play with all kinds of fancy (and expensive) lighting equipment – moving lights, high-power color changing LED units, ultra-compact wireless dimmers, and so on. But it’s also fun to build inexpensive, maker-size versions of of this equipment, and it can be done on a shoestring budget.
About a year ago, I built a couple versions of tiny moving lights – one directly from a design from Thingiverse, the other of my own making. The end result was super cute!
The thing with this tiny light compared to real moving lights was… I cheated a bit. The light itself only contains the servos and LED chip itself, while the controller, LED driver and ballast were all external. The full setup took up almost 3 times the volume of the individual light:
Not only did I cheat on size, I cheated on control a bit too. The unit has a number of ‘test’ modes that run simple movement and color patterns, but there was no means of controlling the light externally. While there are It was basically a fancy keychain toy. And there are DMX Shields in the Arduino Uno form factor, they themselves would have outsized the lights by another 200%. It was all getting too bulky to be reasonable.
But after many months away from this project, I’ve been devoting some time to scaling down both the dimming and DMX control sides of the circuitry. The result is a shield for an Arduino Pro Mini.
As described in my previous write-up of contemporary lighting control protocols, the core standard for modern stage and event lighting is DMX, or properly, ANSI E1.11 DMX 512-A Digital Multiplex. In short, DMX is a serial protocol and physical spec that caries up to 512 one-byte values over each individual cable, usually with 5-pin DMX connectors. One set of 512 values is termed a “universe,” and to carry additional values, additional cables carrying different universes of information may be added.
More formally, DMX is a 250 kbps serial protocol transmitted over a 2-wire bus following RS-485 standards. The ESTA standard standards also dictate standardized connectors (XLR5 for temporary installations, RJ45 for permanent infrastructure), network topologies, impedances, terminations, and so on. The standard is pretty readable, if you enjoy that sort of thing.
DMX was developed in the late 80’s/early 90’s as a replacement for systems in which lighting equipment was controlled via analog control voltages, meaning each parameter (each individual dimmer, say) required one wire. A rack of 96 dimmers would have 100+ pin wiring harness attached to it, each with an analog voltage specifying level. With the introduction and adoption of DMX, all that was replaced with a single 3-conductor cable. All modern stage lighting controllers speak DMX, although most rely on transporting universes of DMX over Ethernet and using ‘DMX Nodes’ to turn that digital data back into ‘hard’ DMX close to the fixtures being controlled.
There is really only on piece of hardware required to add to an Arduino-compatible design to allow it to send/receive DMX: an RS485 transceiver chip. There are many of these on the market, the common ones being the MAX485 and the SN75176.
These take a single-ended input and turn it into a balanced output or, conversely, receive a differential RS485-compatible input and convert it to a single ended signal to a microcontroller. There are two control pins which determine whether the chip is a receiver or a driver. The control circuitry is essentially the same at both the transmitting and receiving end:
The circuit is ultimately very simple – a couple headers, some resistors, a MAX485 IC, and some pads to connect the DMX connectors to. And a switch – the DMX library I’m using abuses the Arduino’s built-in Serial library for some of its functionality, which means it has to use pins D0 and D1. Which means you can’t reprogram the Arduino with DMX coming in. The DPDT switch just removes the connection between the DMX connectors and pins D0 and D1 of the Arduino to allow for programming.
Mostly for my own reference, the connections between a standard XLR3 or XLR5 connector and the Max485 pin are:
XLR Connector Pin
Here’s what draft one of version 0.1 looked like when it came back from OSHPark and following assembly
All the passives are 0603 and the max485 is an SOIC, both of which are pretty easy to solder by hand. The SMD switches are adorable! They’re these little guys from C&K.
The major flaw with version 0.1 is: one you’ve attached headers, where do you attach anything else?? So version 0.2 added an additional row of thru-hole pads, cleaned up some labeling, and added some mounting holes for M2 screws:
And once its all assembled, it looks something like this:
I’ve been making use of the Conceptinetics DMX library, which I’ve found to be both functional and stable. I haven’t yet experimented with the RDM capabilities of that library.
The library is very easy to use, and its usage is described well on the Conceptinetics Documentation page. Essentially, one defines a DMX_Slave object, which has enable(), setStartAddress(), and getChannelValue() methods.
For example, once the object is set up and addressed, a loop() with the single command analogWrite(LED_PIN, getChannelValue(1)); will dim an LED attached to pin 9 dim in response to incoming DMX. Easy as pi.
So, what can one do with an Arduino Pro Mini that can receive DMX? Well…
You can make a DMX level monitor, a DMX controlled LED source. And really, anything else you can think of to do with an Arduino – drive servos, WS2812s, solenoids, relays…
The shield can also transmit DMX, though I haven’t thoroughly tested this yet. But it’s possible to make a miniature DMX controller, itty bitty light board, or testing tool. Or wire up some interesting input devices and make an interesting lighting controller.
The shield has been a useful proving ground for the Conceptinetics DMX library (though we’ve used it onstage before), as well as for OSHPark’s manufacturing tolerances. I wasn’t sure that having holes as close to the edge of the PCB as both V0.1 and V0.2 have would be manufacturable, but they came back no problem.
This all started for me with a miniature moving light project, and while that’s not quite ready for a write-up, I’ll just leave V0.3 of the DMX shield here. Not without errors/improvements to be made, but I’m excited to try out some new LED dimming tech:
With the bulk of the shelving and organization overhaul complete as of last week, I’ve spent the last week starting to personalize my home workshop space, mostly using my 3D Printer. This is definitely a situation of “when your favorite tool is a hammer, everything looks like a nail.” And the 3D printer is an awfully nice hammer…
There are some things that 3D printed plastic parts are perfect for, including:
Brackets to attach/connect unusual shapes
Containers/guides for specific materials and tools
Stands and supports for lightweight goods
But of course, there are some properties that 3D printed thermoplastics are always going to be underachievers in, like:
Brute strength (compared to metal or wood)
Tiny mechanical details (like screw threading)
In my mind, an ideal setup picks and chooses the materials that are right for each job. There’s not much point in printing, say, a 24″ wide shelf when a wooden one with be stronger, cheaper, and easier to make or buy. Conversely, welding a microphone stand together out of metal would be a nightmare, where it’s easy to print an existing plastic design that will hold up just fine.
The thrust of this is that, with the ELFA shelving (wood and metal) providing the backbone of my setup, there’s lots of space to fill in the operational edges with 3D printing. I can’t possibly cover every print, but in no particular order, here are the new additions to the setup, and some most-useful oldies:
ELFA Corner Bumpers
I designed and printed these the same day I finished the shelving install, after my partner nearly beaned herself on the corner of a shelf by the doorway as she was getting up. They’re a tight enough fit that they stay out without adhesive or fasteners. The design is now on Thingiverse.
ELFA Cable Guides
With the number of things that plug into AC power on my bench, I figured cable management would be useful. I started by putting together an ELFA Shelf Hook Profile, which can be used as a basis for anything that hooks into the ELFA vertical standards. I then added an L-hook shape to one side of the profile, which captures any cable that are hooked into it before the piece is installed. This is the result.
I’m trying out using a piece of 2020 extruded aluminum as a generic mounting rail for some desk equipment, including the camera arm below. Maybe I’m being precious because the shelving is still new, but I couldn’t bring myself to put holes into the front of the shelves to mount this rail in place. I designed and printed these brackets, which are a tight fit to both the front of an ELFA solid shelf and the 2020 piece, and further secure to the 2020 with a screw and a hammer nut. A small piece of blue-tak can be fitted to the slots on the underside to prevent the bracket from sliding off.
This will probably need a second draft, as I realized after installation that they don’t leave room for the LED lighting I intend to install under each shelf.
Lighting PSU Wall-Standoffs
I’ll get into the lighting for the room more once all the parts arrive on the slow boat and I can get it all installed. In the meantime, I’m starting by mounting the 30A, 12V PSU. The positioning of the vertical standards on my wall didn’t leave an obvious place to mount the PSU, but the unit does have four M4 threaded holes on the sides. I designed and printed these mounts to accept up to three drywall screws each, with a slot and countersink for an M4 screw.
Articulating Camera Arm
Having a semi-permanent camera on my desk has been useful for project documentation. This is an assembly of two prints by other makers – RaffoSan’s Universal Camera Mount and Felwats’ C920 Adapter. The adapter actually fully replaces a piece of metal that sits between the camera and its original hinged arm. The arm mounts to the 2020 rail previously mentioned, which is mounted on the front of the lowest shelves.
Oscilloscope Probe Holders
This design popped up on the FunctionalPrint subreddit just in time. I was struggling with what to do with my scope probes – coil them next to the scope, keep them in a bin and pull them as needed… this solves that problem. The design comes from JRucks and is now on Thingiverse.
‘Hot Shoe’ Microphone Mount
I’ve had this one kicking around for awhile to hold my cheapy Takstar SGC-598 microphone. It’s not the fanciest setup, but for my casual purposes it’s more than enough. The design comes from Asgeirom on Thingiverse.
Solder Roll Holder
I didn’t really see the point of having a solder-roll holder until I printed one. Never again will that 1 lbs roll go walking across the desk (or onto the floor) in the middle of a tricky joint. This design comes from Phredie on Thingiverse.
These multi-purpose cup was one of the first designs I ever printed, and it’s still my go-to print for sampling the color of a new filament. It’s meant to print in spiraled-contour mode, which means that the outer perimeter (after the base) prints in one continuous revolving motion, instead of stepping up layer by layer like a typical print. There are perhaps a dozen of these scattered around the apartment, but since the reorganization, most live just above my desk holding, individually: pens/pencils, colored sharpies, black/silver sharpies, screwdrivers, pliers, flush cutters, cutting tools, and misc tools.
The next improvement to my setup is definitely a lighting improvement – its not terribly bright in the room to start with, and the shade from the shelves doesn’t help. 3D printing will be involved.
I also put my new setup to the test for the first time last night as I laid out a version of a DMX shield for the Arduino Pro Mini. Having all my tools organized and close at hand, and plenty of space to work it, makes working in my new setup a joy. The cleaning, the organization, the installing of new systems and setups: all worth it. It’s now fun to sit at my workbench, instead of a kind-of cramped pain. Onward!
You may get the impression from this blog that I like to dabble in a lot of different projects. You’re not wrong – I love trying new hobbies, new technologies, new recipies, new stuff. But one of the issues is that the old projects (and the pieces and tools that come with them) tend to pile up in my workspace. So with a kindly nudge from my partner, I decided it was time to overhaul my home office setup.
I wish I had taken a better series of before-during-after photos, but this photo that my partner took of me in the Fall certainly conveys the depths of the clutter of my old setup. It wasn’t always this bad… but sometimes it was:
The workspace in september, such as it was.
There were many inconveniences with this setup, but the chief one was a lack of actual open flat work area. This was mostly a result of:
The 3D Printer sitting on the desktop (and its control box)
The stack of test gear (oscilloscope, PSUs, SigGen) and my FT-767gx radio sitting in prime working area
This is/was my primary computer workspace as well, so any project that necessitated having a laptop on the desk meant almost no workspace leftover.
Additionally, a lot of the organizational systems that I had going were leftovers from days gone by, when I was doing more carpentry/assembly as part of a freelance career. The pegboard of hand tools, for example. But these days, while I’m glad I own, say, a carpenter’s square and a hammer, I only use them at home every 3-6 months. Removing the pegboard and the red pick bins you see in the photo above freed up valuable wall space. All my “carpentry” tools live in one large bin tucked underneath the desk.
I took inspiration from a couple of creative-types in my sphere: Jeremy KF7IJZ, ham radio nerd and one of the producers of the Ham Radio Workbench podcast; and Lee Fiskness, a fellow stage lighting colleague. Both have redone their home workspaces in the past couple years, and I know both pursue a variety of hobbies in relatively confined space.
While both Jeremy and Lee used the Algot System from Ikea, I ended up going with the Container Store’s version of wall-mounted shelves called ELFA. The primary reason for this is that it seems ELFA may be getting phased out – many of the specific components (metal shelves, certain size brackets) are no longer available. Additionally, ELFA’s two-slot metal vertical standards are compatible with lots of other generic brands (Rubbermaid, Closetmaid, Home Depot, Menards, etc.), and seemed more easy to create customized pieces for than Algot’s slotted-tab connectors.
Here’s the design I came up with, laid out in Fusion360:
This makes use of my existing metal shelves and 72″x30″ desktop. The grey square on the floor represents the footprint of our elliptical, which also typically lives in this room.
The first step was to Marie Kondo the crap out of setup. I’ve tossed, condensed, consolidated so many things that I no longer needed, or that someone else who have better use for. I also purchased a bunch more plastic bins and part boxes, to try to break things down into manageable storage sizes.
After a few weeks of cleaning and clearing, I went to the container store this weekend and picked up the major pieces for the shelving. The consultants at the ELFA counter are really expecting folks to walk in with not much of an idea of what they need to fill out their closet – I think they were surprised when I had a parts list and a drafting. But my consultant, who’s also a math teach, was a great help, and got me squared away in about 20 minutes. I did have to come back later in the week to pick up all the pieces, I think mostly because the store was slammed with patrons getting in on the ELFA sale.
The ELFA system is pretty straightforward – everything hangs off of dual-slot vertical “standards”. There are two types of standards – those that hang purely off a top rail, and those that don’t hang off a top rail but instead mount to the wall every 16″ vertically or so. I went with the first type, but being concerned about weight, I didn’t trust the Container Store’s claim that everything could just be hung from drywall anchors. Instead, I screwed a stained piece of 1×4 directly to the studs the whole length of the wall, and mounted the top rail to that. I also added 3 other matching 1×4’s down the wall, so the rails would have something to hang flush against.
As of March third, things have come a long way!
There a a few significant things I mean to add to this setup. One is some under-shelf lighting – I’ve ordered come WW/CW LED tape and aluminum channel to arrive soon, which will be a project in and of itself. And as for control, I think I’ll start with everything just wired to some switches, and then decide if I want to get fancy. (I had a long think in the shower about an Arduino-controlled, touchscreen connected dimming system, but that may be getting ahead of myself). Not sure yet if I’ll re-use the 2′ Fluorescent fixtures that had hung above the pegboard before.
The other thing I’m jonesing for is a whiteboard. Especially when trying to reason out a problem, I find doodling on a whiteboard to be both relaxing and clarifying. There’s now a big empty space on the far wall that I think will do nicely.
The world of stage lighting uses a variety of communication protocols to link control devices (computers, light boards, houselighting systems) to endpoint devices (lights, dimmers, effects). These run the gamut from basic analog control through legacy serial protocols to modern packetized, ethernet-based protocols.
E1.3 0-10V Control: Specifies control of dimmers/luminaries via individual analog control lines. 0 volts is always off, or one extreme of a parameter (e.g. full pan left; minimum blue; focus all the way in, etc). 10V is always on, or the other extreme of a parameter. “0V” is really -0.2V to 0.3V. “10V” is really “9.8V to 30V”. Control lines must be stable to ± 20mV. Minimum load impedance is 50 kOhms. Passive controls have max 2.5 kOhms output impedance; active controls have max 100 Ohm output impedance. Short circuit protection, overvoltage protection, and current supply are also specified.
E1.11 DMX 512:(“Digital MultipleX“) Specifies a 250 kbps serial protocol for controlling equipment, the EIA-485 transmission techniques for the same, physical cable specifications, and appropriate connectors (XLR5). The 5-conductor cables are common, data 1±, and data 2± (rarely used), each not to exceed 6V above common. Data lines are balanced in pairs. Signal line impedance is 120 ohms nominal. Each “packet” of serial data begins with a break, mark, and start code, followed by up to 512 slots of data, each of which has an 8-bit value. No error checking/correction is provided.
E.1.17 ACN:(Architecture for Control Networks) Specifies a series of protocol formats for (generally network-based) interchangeability between control systems and endpoint devices. Generally: the Device Management Protocol (DMP) encapsulates the Getting and Setting of device parameters; a set of Device Description Language standards (DDL) defines the format and language for component description to allow common control and identification; and the Session Data Transport (SDT) protocol allows for multicast delivery of messages with ordering and verification not present in generic UDP multicasting. The Protocol Data Unit is the singular message format for DMP messages.
ACN also provides for device discovery. While typically used with TCP/IP and 802.3 Ethernet or 802.11 WiFi, other physical/link/transport/network layers are incorporated as possibilities, including various serial and RS485 standards, via interoperability profiles.
E1.20 RDM: (Remote Device Management) Specifies an extension to a DMX512 link permitting intelligent, bi-directional communication between devices. An alternative start code in a DMX packet identifies an RDM packet. RDM uses a binary-tree or similar search to identify devices on a DMX512 line. Controllers can use RDM messages to Get or Set parameters of endpoint devices, and communicate to individual endpoints when they may drive the line to respond to Controller commands. Device configuration and monitoring are primary goals, as is identification.
E1.31 sACN (Streaming ACN): Describes a lightweight mechanism for streaming DMX packets over an IP network using a (small) subset of the ACN suite. Describes data format, protocol, addressing, and network management, as well as a synchronization method for ensuring that data arrives concurrently at multiple endpoints.
E1.27-1 – Standard for portable control cables for use with DMX512
E1.27-2 – Standard for Permanently Installed Control Cables for use with DMX512
E1.30-1 – EPI 23, Device Identification Subdevice
E1.30-3 – EPI 25, Time Reference in ACN Systems using SNTP and NTP
E1.30-4 – EPI 26, DDL Extensions for DMX512 and sACN Devices
E1.30-7 – EPI 29, Allocation of IPv4 Addresses to ACN Hosts
E1.37-1 – Additional Message Sets for E1.20 RDM Part 1 – Dimmer Message Sets
In addition to the published ESTA standards, it’s worth mentioning two that are not currently maintained as standards:
The standard for E1.33, RDMNet, has been in draft review since at least 2011. It defines a suite of protocols for the types of device discovery, device management and configuration, and automatic device configuration that RDM provides on a DMX512 link, but across a network. It defines a broad scalable architecture that allows for multiple controllers and “tens of thousands of responders,” as well as a minimal protocol for carrying non-RDM data over the same protocol. The spec defines
A Low Level Recovery Protocol (LLRP), used to configure IP settings so that E1.33 equipment achieves connectivity
A Broker protocol, which allows for discovery and many-to-many message transport
The RDM Packet Transport Protocol (RPT), which defines the primary packet formats and messages, as well as topology and functional requirements for controllers and endpoints
The Extensible Packet Transport protocol (EPT), which may be used to carry non-DMX data in a similar way to RPT.
BSR E1.33 Concluded its fifth public review in January 2018 with 68 pages of public comments; no date is known for the next public review session. As noted below, ETC has its own mechanism for transporting RDM and RDM-like data over ethernet via its NET3 suite.
The second ‘standard’ of interest is the former E.1.45, “Unidirectional Transport of IEEE 802 Data Frames over ANSI E1.11 (DMX512). This provided a mechanism for transmitting IEEE 802 packets – including Ethernet (802.3), Wireless LAN (802.11), and Bluetooth (802.15.1) – over a DMX512 link by using an alternative start code, stuffing the packet data into the DMX “payload” area, prepending two byte of sequence numbers and appending a two octet CRC for error checking. Interestingly, it seems that this standard was aimed specifically at Visible Light Communication (802.15.7), for transmission of data in the visible spectrum.
After publication, it was established that key parts of the E1.45 standard were covered by US and Korean patents, and the patent holder would not guarantee that licensing could be made “under reasonable terms and conditions that are demonstrably free of any unfair discrimination.” Therefore, in October 2015, the ESTA withdrew this document as a standard.
Beyond the ESTA-specified standards, there are a handful other vendor-specific or genre-specific communications protocols in use. Electronic Theatre Controls (ETC) has used a number of protocols all their own over the years, including:
ETCnet (Net1): Originally called ETCNet and retroactively renamed to Net1, this was ETC’s first Ethernet based control protocol. It is proprietary, without publicly available specification. It is a raw Ethernet protocol (layer 2), meaning that routers and certain types of switches do not pass Net1 traffic. A hub is recommended. Net1 provdes transport of console video information, up to 4 universes of DMX, tracking backup data, and keyboard command information to ETC products of the era, including Express/Expression/Insight and Obsession 1. Many Net2 DMX nodes can also be configured to operate in Net1 mode, with the concomitant loss of function.
ETCLink: ETC’s Sensor dimmers with a CEM classic controller use this protocol to provide dimmer feedback to the console. Express/Expression and Obsessions 1/2 consoles could receive this data. Connections were commonly a 6-pin XLR connector. This functionality has been supplanted by ethernet-based feedback in modern systems.
ETC Net2: Introduced with the Obsession II console, ETC’s second networked control solution incorporated IP addressing, this allowing network traffic to be switched or routed. Sends DMX data as eDMX, which in its final version incorporates per-“range” priority. Includes EDIMI, ESMPTE, FTP for ETC devices, and video data for remote video units.
ETC Net3: ETC’s current suite of network-based communication. Sends DMX data over sACN. Uses a non-public RDM-over-ethernet protocol to receive RDM data from Net3 DMX Nodes. Incorporates network video data as Net2 did. Many ETC products (Sensor Dimming, Paradigm, Mosaic, Unison, etc) have ethernet functionality, but it is nebulous which of these fall under “Net3” and which are their own Ethernet-based communication system.
ETC also uses LonBus-based networking devices to control various legacy architectural control stations – while their modern counterparts can also usually take LonBus, they are typically served by an Ethernet connection.
Other situation-specific lighting communication protocols include:
Art-Net: A simple implementation for streaming DMX512 and RDM information over IP networks, typically ethernet. Multiple versions exist (1 thru 4) with significant differences – version 1 uses only broadcast packets; version 2 uses broadcast for discovery of endpoints and unicast for data delviery. Version 3 introduced the ability to expand to up to 32,000 universes, and further refinements were made to version 4. Artnet uses specific IP ranges for much of its configuration, which can present integration challenges when it needs to exist alongside other switched protocols.
HogNet and Fixturenet: High End Systems uses its proprietary HogNet ethernet suite of protocols to link its line of Whole Hog lighting consoles, as well as their DMX processors and optionally other lighting control PC’s. These connect to a specific HogNet RJ45 connector on the back of most Whole Hog consoles, with its own NIC. A secondary connection, the FixtureNet ethernet connection, is used for connecting to Art-Net/sACN(E1.31) DMX gateways.
CITP (Controller Interface Transport Protocol): Used by some lighting and video controllers to exchange pictures and video streams over a network. The standard is maintained by Capture.
PosiStageNet (PSN): An open protocol developed by MA Lighting to transmit realtime position information over a network, for example from a tracking device on a moving actor, scenic piece, or prop to allow for video, lighting, or motion-control tracking.
So what does the future of lighting control look like? Clearly, we are living in an increasingly-connected theatrical world, and most of that connectivity is Ethernet-based. I don’t expect to see an entirely new paradigm at the link layer any time soon.
I have expected for many years to see an additional level of automation and abstraction in how we set up lighting systems. When all of the devices in a system can talk to each other, is there still a need to individually plan, address, patch, and coordinate the ID’s of individual fixtures or dimmers? Or can we automate ourselves out of the time consuming business of managing how the devices talk to each other and let the system set up its communication network automatically? We shall see.
No matter what the future holds, we’ve come a long way from Piano Board dimming.
Update: After posting this on Facebook, a friend asked about the AMX protocol that he remembered from high school. Here’s the brief answer I gave him:
AMX (Analog MultipleX) was one of a bunch of protocols (AMX192, CMX, MPX) that appeared in the late 80’s as people were trying to solve the “one dimmer = one wire” problem of E1.3 0-10v. It used 4 wires – two for a (balanced) clock signal, one ground, and a signal line which carried a succession of analog voltages (0-5V) that represented the levels of up to 192 parameters.
Acceptable connectors were 4-pin XLR or TY4F (mini-stupid!). Interestingly, the spec requires “sound-style” Male XLR connectors on the controller and female connectors on endpoints.
The AMX192 standard was developed and published in 1987 by the United States Institute for Theatre Technology (USITT), instead of the ESTA.