Dynamically expandable Bus Driven Approach

From RepRap
Jump to: navigation, search

I am currently having some thoughts and wished to document them somewhere - here seemed as good as anywhere as it will hopefully encourage some useful feedback and may even benefit others.

I am planning to build a multi axis making machine - It will probably not technically be a RepRap - as I plan to construct the frame from T section as others have done (RepStrap?).

Anyway, I wish to start simple and build up to more complex functionality. I have the following goals in mind :

  • Interchangeable work heads (drills, extruder's, etc)
  • potentially switch-able gearing, plastic extruding (fast little torque) vs milling (slow - more torque)
  • Simplified wiring
  • An approach to the electronics that does not require scrapping the lot and starting over when I want more Axis than the motherboard allows for.

Bus driven Axis


I am proposing a simple bus which connects to all Axis, potentially with only 4 wires :

  • GND
  • +V
  • TX (data)
  • #BUSY

Due to the power requirements on the Bus (to power heaters, motors etc) the TX Data and busy lines may need its own signal level GND return upping the number to at least 5, and I may decide to include bi-directional comms requiring a 6th pin (unless a 1-wire protocol is employed). Another method to reduce the wiring would be to employ a powered bus style approach such as that used by NMRA DCC systems. (I have actually made a DIY DCC system so am quite familiar with it).


Each Axis would then have its own very basic controller board with a basic MCU requiring minimal firmware. Each would be programmed with a unique address allowing it to be individually controlled via appropriately structured data packets. They would be sent very basic commands - a stepper motor Axis would potentially have just 5 :

  • Set Address (used when added to the machine to program a unique address - thereafter held in EEprom)
  • Find Home
  • Set step time interval
  • Set step count (including direction, -100, +22332 etc)
  • GO


For every operation all axis are addressed and told what to do, a broadcast packet (one to which they all respond) is then sent saying GO. This is hopefully sufficient for synchronised operation between Axis, but it may be that an Interrupt or clock packet or line is required.

The #BUSY line is pulled high via a resistor, and open collector outputs are used to pull it low by each busy Axis. Every busy Axis pulls low until they are done when they release it. When all Axis are done #BUSY goes high. The next operation can take place.

The Bus protocol I intend to use is well suited allowing for all manor of additional functions on new Axis to be added with out requiring all the existing axis firmware to be updated.

The data rate will need to be relatively high in order to prevent significant bottlenecks when performing complex operations such as curves which will comprise of many short operations.

Bus controller

The bus is driven by the controller board, possibly an Arduino style (ATmega 328) MCU, or maybe something more capable, maybe an ARM based SOM, which can attach to LAN or via wireless etc.

It will accept G-code or NC drill files, and potentially other formats also, converting them into series of commands sent over the bus to the individual Axis.

Interchangeable "heads"

I intend for the heads to be interchangeable whilst the machine operates - with the minimal wiring allowing for only a small number of contacts which can make on insertion and break when removed - Some locking mechanism will need to be devised that holds the heads securely in position.


I have been made aware of a key difference between the RepRap style machines and the milling ones, the milling ones as well as having a more rigid frame require more torque and operate at slower speeds - whilst the (plastic or other ) extruding machines under load benefit from speed. Using a mechanism similar to what can be found in some laser printers I intend to be able to switch between direct or geared down operation using a small solenoid.

I will use the sliding bed method in order to minimise the accumulated error between Axis.


Whilst I like the idea of the self replicating systems I think will need a more rigid frame than they can provide and will most likely construct the frame from T section aluminium. If and when it works I can then manufacture a (or many) RepRap(S) ;).

Some thoughts

It may be beneficial to include some Axis controllers with the main board. As suggested above the Bus may impose bottlenecks on operation. For this reason X and Y axis may well be better placed directly on the main control board leaving the Bus to drive auxiliary Axis where many very short operations in short succession are less likely to be required.

Further reading

  • SNAPComms has a very similar topology
  • If the communication bus is *very* simple, then perhaps each device can be very simple -- perhaps so simple that, when one who has an idea for some new device to throw on the bus, one can lash up a quick prototype, quick and dirty prototype, with a few things from the junkbox, something like BuildingAStripboardExtruderController.
  • The easy expandability of this approach looks like it would be useful for multi-head machines like Hydra-MMM Prototype.