The original lighting console was rushed together overnight for submission and needs work before it has all the features of a standard console. Some things I’ve learned, on reflection though:
- Capacitive buttons are terrible for this – you need the force feedback to be sure you’ve pressed the button.
- An X86 PC was overkill to drive a theatrical console. Realistically, an AVR would have done a better job than the PC running PHP.
- The case is far too dodgy (due to the rush to finish). And I still can’t quite get over the fact that I had to make it out of wood.
- The connection from inputs to the PC wasn’t nearly fast enough. I think I may use MIDI rather than USB serial next time.
- Where I should use capacitive touch, is in detecting which fader is touched (like the MA2).
So, my new plan, is a combination of aluminium panel and black matte plastic base. I’d have to 3D-model it to explain it properly. Slightly complex shape.
I need to find some good buttons too. All in all, I don’t think I can fabricate this myself – will get professional prototyping I think.
We’ll see how it goes.
I feel I ought to clarify the $8k figure mentioned for a comparable console in my email to HaD. This figure was based upon a quoted price for an LSC Maxim LP, which I had misread as an LSC Maxim L – the difference being moving light abstraction and about $3k. When ML abstraction is eventually added to the console, then I may claim the former figure. In the meantime however, I apologise for the innacuracy – it was the result of rushed documentation at a rather late hour.
I thought I should probably contextualise this project:
Initially, as many projects do, it began as a desire to own a piece of technology too expensive for me to purchase (especially with no reliable source of income). However, the idea of developing a lighting control system from scratch also offered learning opportunities in electronics and particularly the Arduino platform (which I’m still very new to). The opportunity to create a free-choice “major work” for Design & Technology arose at a similar time as I was considering this, and I settled on the idea.
As for why the interest in lighting – I’ve been involved in shows for 5 years now (probably around three dozen) and am now operating school and community events and (tentatively) corporate. The ability to shape the audience’s response to a performance through light has always appealed to me, as has the “wow” factor that lighting can often achieve.
Following this interest, I’ve read many books on the subject, along with online research and have near-memorised the DMX protocol (although I still can’t get a MAX485 chip to play nicely) and so experimentation in DIY lighting control has developed into a full-scale lighting console.
As I said, this has been very much a learning experience for me, most of the code and electrical implementations are improvised based on knowledge that is likely very limited compared to the readers (e.g. those directed from HaD) and as such a lot of the decisions I’ve made may not make sense in the context of wider knowledge. In other cases, good practice has been compromised to meet financial and time pressures.
Any improvements or constructive criticism you can contribute would be very, very much appreciated as it can only add to what I gain from this build.
Just letting you know, on September 23rd (ish), I’ll have the opportunity to test out the console with 28 led par 64s, 4 led bars, 2 mac 550s, 7 technobeams, an atomic strobe and 24 channels of conventional dimming.
Obviously, the direct-fader control (even with softpatching and scenes recorded) makes operation difficult, but the aim is really to stress-test the console by running as many chases as possible simultaneously.
The show itself will be run on a Jands Vista i3, as I don’t yet trust my console enough.
I hope to post videos from the event demonstrating the console’s capabilities.
I’m posting all the code used for this project at Google Code, here.
Their code formatting and SVN tools will hopefully make the code more accessible, than WordPress posts but I’m very much open to other suggestions.
FYI I haven’t used Google Code before, so I’m still finding my way around it.
I’ll be uploading schematics and Eagle files here as they’re finalised – the CNC didn’t play nicely with Gerber files so everything ended up being constructed on veroboard (twisting a leatherman blade in a hole seems to work well, in my case better than the traditional drill bit – but that may just be my drill bits).
Bear in mind, I’m new to almost everything I’m doing here, including Eagle designs, so the schematics are somewhat messy. I’ve tried to keep the lines fairly separate.
Fader Module – .tiff here, .sch here. – this is currently missing the connections to the MCP23017 i2c-GPIO chip and the connections to the SparkFun capacitive touch module.
This post will be updated with all the latest build photos and such.
- The parts start arriving (Motor Faders in this case) – better get cracking on construction.
- CNCing out the capacitive buttons using a Denford CNC milling machine.
- See (2).
- The reason we’re using a floating head and not trying to use the CNC to cut the boards to size.
- A completed button board wired up to one of the Sparkfun capacitive boards, following the guide here. – The board eventually stopped working as the internal i2c pullups were sending through 5V. In later versions, I’ve disabled the internal pullups and now pull-up to 3.3V.
- CNCing the panels for the faders to be mounted in.
- The reason we decided to use acrylic – cooling is an issue with aluminium.
- A fader panel with motor faders mounted and all wired up, spaghetti-style.
- The wooden case coming together with a fader panel resting on it.
- The wooden case completed with a black panel of acrylic mounted on the base. The motherboard is now mounted securely into the acrylic base panel. The other components are yet to be mounted.
Photos yet to be uploaded: functioning Fader Module Slave IC.