Michael Brown, production designer for Grizzly Bear’s international tour, contacted us a few weeks ago with what seemed like an impossible request: he needed 20 DMX-controlled winches built and ready to go on tour in a matter of weeks. We sketched out some designs, called around to make sure we could get all the parts we needed in time, and gave him a quote for the job. After some discussion (they didn’t actually believe that what they were asking for was possible), they accepted our quote and we were underway.
The winches needed to lift about 20 pounds at around 60fpm, with variable speed, and the ability to control them via a moving light console. We’re no stranger to DMX control, and the concept of building the control systems for the winches didn’t seem too troubling to us; however, as a company, we’d never built a winch. Due to the short lead time, we went with a very overbuilt system that we knew we could make work.
The original design used 1/8″ aircraft cable for the liftline. We changed that to 1/8″ black dacron due to noise issues with the cable, and it was also fantastically easier to work with – re-terminating a line was as easy as tying a knot in it. As an added bonus, the dacron also disappeared completely into the backdrop.
The only part that needed to be machined, which is classically the hardest part to acquire, was a grooved drum. We called every machine shop within 50 miles of Pittsburgh and found one that had the capacity and capability to do it with a quick turnaround.
Read on below for more technical details and videos of everything in operation!
Motors and Drives
Once we were sure we could procure the drums, we turned to motors and drives. These winches don’t go very fast, or lift very much weight, so we could get pretty creative here. We decided to go with a stepper motor, a type of 2-phase motor that has a few neat features that we thought we could take advantage of:
- Very accurate positioning — the base full-step positioning on the motor is 1.8 degrees. On our 4″ drums, that’s a full-step resolution of 0.06 inches. Using the microstepping driver we ended up with, we were actually working in terms of 1/10th steps, or 0.006 inches per step.
- Zero-speed torque — the motor actually generates more torque the slower it’s going, so it generates full rated torque at 0 speed, decreasing with added speed. This means we were able to eliminate the need for a brake for load holding as long as there was power applied to the motor.
- Very simple digital control interface — the drivers we used take two inputs from the controller: direction and step. Each time you send a step pulse, the motor rotates 1/2000th of a rotation. This meant that we didn’t need to generate a 0-10V input to a motor controller.
Open loop vs. Closed loop
When thinking about motion control systems, there are two ways to approach them. Open loop control systems work by dead-reckoning: they know they’ve told the motor to rotate 10 turns, so they assume that’s where the motor is. Closed loop control systems measure the motor’s position in either absolute or relative terms, so you know how much the motor has rotated. We decided that for these winches, at least on the first version, we’d work completely in terms of closed loop absolute positioning.
An open loop stepper system counts pulses going to the motor. If you send it 2000 pulses, you know it’s rotated one turn; multiply that by the number of inches per revolution, and you know how many inches it has traveled. The problem with this is that when the power comes on, you don’t know where the motor is. This is why moving lights do that little dance when you turn them on – they are driving their axes until they are 100% sure they are at a known position. After that, they can just keep counting pulses, and they know where the head is. With a winch, you can’t necessarily do this. We could have put a mark on the line and had it hoist up until it found that mark, or we could have put a little weight or magnet on the line that tripped a switch; however, having a winch home every time you turn it on could be dangerous, or at the very least, less than ideal.
A lot of winches and motors work with a counting encoder. These work by incrementing a counter as the motor turns; as long as the motor never moves with the power off (which is true of a lot of winches), you never lose location. With a flock of touring winches, we thought that hoping nothing would get moved in transit was a bit too much to ask for.
Instead, we went with an absolute encoder. This encoder is a 10-turn potentiometer, chained to the drive shaft in such a way that the 10 turns equate to 35 turns of the drum. We read the pot with a 10-bit ADC, so our values varied from 0-1023. This equates to about 0.4″ of positioning accuracy, which was accurate enough for this project.
One thing we could have done was a combination of open- and closed-loop: by interpolating between encoder positions, we could have greatly increased the accuracy of the hoists. However, that would have required many more hours of debugging and testing that we just didn’t have time for on this project.
Putting it all Together
The basic machine works like this:
- The control system outputs a frequency and direction to the motor driver, which tells the motor which way to go and how fast.
- The motor is connected to the main drive shaft with a 1:2 chain stage reduction, which means that the motor spins 2x for each time the drum spins once.
- The encoder is chained off the drive shaft, with a 3.5:1 ratio; for each time the drum rotates 3.5 times, the encoder rotates once.
- A spring-applied, electrically released brake is attached to the end of the drive shaft with a lovejoy coupler.
There are two power supplies — the big one you can see in this image is a 48VDC supply for the motor power; there’s also a smaller 12VDC supply that handles the logic side. As we were testing, we found a problem with the 48V power supply: at 60fpm, going down, the motor generated a higher voltage than the power supply could deal with. This caused the power supply to simply shut off, dropping the load. With some testing we found that 47fpm was the fastest we could go without risk of the power supply cutting out. This was slower than we originally thought we could go, but better than having a sudden and catastrophic load drop.
DMX Operation
DMX is a great protocol for controlling dimmers. It’s a reasonable protocol (the one we have) for controlling things like moving lights. It’s a terrible protocol for motion control. Two key factors keep it from being useful for motion control:
- Lack of data signing — there are no checksums on transmitted data, so there is no way to know whether you’ve received a valid packet or just noise that looks like a valid packet.
- Lack of talkback – there is no way for a motor to tell the console “Hey, I’m broken!” — the operator has to notice the problem and deal with it.
Additionally, the logic of a control console is not necessarily ideal for a motor. A winch hauling a load wants to know two things: how fast it should be going, and where it should stop. You do not want to just instantly decelerate into a stop, or instantly accelerate into a start: you need to ramp up and back down. Spinning a moving light around its center of gravity, you can have very sharp acceleration curves, making this less of an issue with them; with a 20# load on 30 feet of line, you need to slowly start and slowly stop your moves. We dealt with this in our motion control algorithms, which we’ll discuss in more detail in a future blog post.
To make the winches work with a moving light console, we ended up with 5 DMX channels for each winch:
- Channel 1: Enable/Mode
- Channel 2: Speed
- Channel 3: Position target
- Channel 4: Program bottom soft limit
- Channel 5: Program top soft limit
Channel 1: Mode
This was the first layer in the “safety system” we implemented in DMX. For the winches to release their brakes or think about moving the motor, Channel 1 had to be in a narrow range — roughly set to 45% — for anything to happen. There was also a “program mode” that required the channel to be around 65% in order to change soft limits. Between 49% and 60%, and below 40% or above 70%, the brakes were on, no movement. We were curious if this was enough, or if it was possible that some strange case could cause movement, so we tested the system by sending it random noise. The brake triggered on and off, but the winch never moved.
Using the values we did ensured that if everything got set to 0, 50% or full, we wouldn’t accidentally enable the winches.
Channel 2: Speed
This is the second layer in the “safety system” — speed must be above 0 for motion to occur. Speed is a linear 8-bit channel from 0fpm to maximum speed. In the original shipping firmware, we set the up speed to 60fpm and the down speed to 47fpm, but this turned out to be a problem for programming. There were several looks that needed to cross fade, and having the speed channel mean different things depending on which direction the lanterns were going made it inelegant. We decided to ditch it, and we updated the firmware to be 47fpm in both directions.
Channel 3: Target
This is another 8-bit channel, where top (255) was the top of travel and bottom (0) was the bottom of travel. In normal mode, this scaled between the soft limits. As the show tours into new spaces (and sometimes can’t get the trusses out to full height), the bottom soft limits can be reset, and all the effects will scale automatically between the new low and high trims.
Channels 4 and 5: Soft Limits
These channels allow the user to set soft limits. The machine has a total travel of 30 feet available, but driving your lights through the floor because you zeroed out the Target channel is just not desirable. With the Mode channel in “program mode”, the soft limit channels allow you to drive the winch through its normal soft limits, and then program the limits to the current position.
The way this works is that once you enter soft limit program mode for each limit, exiting the mode saves the current position as the new soft limit. You basically jog the winch into the position you want, then zero out speed to lock it there while you save the new position.
Brakes
The brakes we were able to get our hands on in the time available were nice — big industrial units bigger than the motors – but they turned on and off with a horrific BANG. Luckily, we were able to use the motor to hold the load for the most part; the main reason the brakes are there is for when the power is turned off (or if the power goes out).
In the next version of these winches, we’ll be using a Weston brake. These brakes were invented in the 19th century and use a clever arrangement of ratchets and brake pads to provide a completely passive brake. When the motor stops (or is disconnected), the load actually engages the brake. This eliminates the need for a relay, or any sort of electromechanical brake. These brakes are less common on the market as discrete items because they are only useful in hoisting operations – they are essentially gravity-applied brakes.
Testing it all
We did some bench testing in the shop as we were building these winches, but there was no way to do a full debugging run in Pittsburgh before they went to the theatre, so I went with the winches to the tech location in Knoxville. We had Friday, Saturday, and most of Sunday before the show to get everything teched out, working, and debugged (plus the designer needed some of that time to actually program the show).
The winches were buggy and flaky until about 5pm on Saturday, losing soft limits and randomly crashing. We had two little bits of code to blame for this; once we found and fixed this code, we were able to reflash the firmware on all the winches, and we suddenly had a working rig!
Actually, it wasn’t quite that easy. When we reflashed all the winches, it reset all the soft limits (top and bottom) to ultimate down, so running the winches in any direction at any speed caused them to head downward, letting out their 30 feet of line. Tracking this down (it was a problem with how we were reprogramming the controllers, although that wasn’t obvious at first) took a little while, but once we changed our firmware updates so they were updating the controllers with a good copy of the limit settings, we were solid.
Touring is different
As anyone who has worked on a touring show will tell you, the requirements are vastly different than any show that sits somewhere for a while. This show starts load in each day 12 hours or less before the house opens, and the winches are loaded on and off a truck every day. The main thing we did to accommodate this was to keep the outer housing (made of steel angle and plywood) as isolated as possible from the machinery. The other thing was to have as few parts as possible to break. There are about 5 or 6 “moving parts” on these winches, and most of those are operating at 1/20th to 1/30th of their ultimate failure strength. There are no gearboxes, and no high speed parts that require extreme precision.
While I wouldn’t recommend it, these winches are sturdy enough that you could probably put casters on them and just make them into their own road cases.
Videos
I don’t recommend that you watch these videos if you’re planning on going to the Grizzly Bear show – they do contain spoilers! But if you’re not going to see the show live, check them out to see the winches in action.
Here’s a brief move under worklight:
and another:
Here’s a fantastic move under show light:
and another view:
and another one: