The problem this project was aiming to solve was this: how can you automate the control of a number of motors (around 12), DMX lighting and various other devices, based on a schedule that runs over the course of several weeks without any human intervention?
The particular application of this system was for an large installation, which housed a number of motors which drove some elements of a sculpture around at a low speed. The installation also had lighting, controlled via DMX, which needed to change based on the motions of the sculpture. There were to be a number of sequences of motor runs, to change the speeds in a pattern which was interesting for viewers, based on a schedule.
The system needed to be reliable, and run for days and weeks at a time without any attention. It should also automatically turn off overnight.
A number of solutions were considered, with varying degrees of complexity. They boiled down to the following:
PC Based System
A PC running an OS with some custom code could be used to send commands to motors, and with a DMX interface could also control lighting.
- Hardware is mostly COTS (Common Off the Shelf) products
- Industrial enclosures already exist for PCs (ATX rackmount cases)
- Several possibilities for maintenance using common system admin software
- Power distribution would be required as a separate element
- Integrating isolated DMX and GPIO would require interfacing with pre-existing hardware may take some time.
- Reliability limited by OS, not totally within my control.
An embedded system could be used to perform the same tasks - including custom designed I/O which meets our exact specs.
- Only running the code we write - we have (almost) complete control.
- Interfaces can be designed to spec, not relying on a COTS interface with USB/serial.
- Power distribution can be integrated and monitored as part of the same system.
- Requires a fair amount of PCB design/manufacture
- More tricky to debug (needs a serial connection to a laptop, for example)
Based on the fact that our needs were fairly specific, it was decided that a better approach would be to design the system from an embedded platform - which we know isn't going to decide to reboot itself in the middle of the night for to updates or something (*cough*windows*cough*), and if it does, then it's our fault :). Also it would alleviate the pain of writing software to interface with a variety of interfaces relying on the OS's selection of drivers, and generally not have to worry about the myriad of other things that go on in a modern PC apart from running our code.
I'll go into more details about the choice of processor in a future log, but this seemed like the best way forward. Or at least a way forward!