I thought I see what sort of support this idea has.
Sorry this is a long post. If its too long, please feel free to TL;DR and move to the next thread.
Observations:
- there are currently a number of people in the process of designing different 32bit ARM single board printer controllers
- there are a huge number of people already with Arduino-based 3d printer controller boards who will be reluctant to throw them away unless they need to
- there are also quite a number of people experimenting with interfacing cheap, microPC boards (such as the Raspberry Pi) to interface to existing Arduino-based controllers.
- so there are many different software & firmware projects being developed concurrently to support all these different hardware permutations (e.g., new ARM firmwares, Repetier-Server on Pi, etc)
- currently all standardization across different platforms is done at the G-code level (although there are slight differences in implementations most of the slicers and host programs can handle these differences).
- the Arduino is fine for running motors and interfacing I/O, however,
- the Arduino controllers are being pushed to their processing limits at the G-code level and might even be a limiting factor for the introduction of more complicated motion planning or co-ordinate remapping features (such as to support auto bed levelling)
- it is difficult to port the Arduino current firmwares because their are so tied to the real-time register organisation of the target platform
- yet, the majority of the complexity & smarts in driving the system is not associated with the direct real time components.
- many of the Linux kernels available are not proper real-time operating systems, and the ones which are are then less compatible or general purpose.
Proposal:
It seems to me that there would be some merit in defining a common command protocol for interfacing at a lower level than the G-code.
The goals of this "direct drive" protocol would be to:
- to provide a common interface for the control of tool-heads, extruders, temperature controls & GPIO of a 3D printer.
- to encapsulate all real-time requirements and specific platform i/o idiosyncrasies.
- to minimise the processing which needs to be done in the real-time component.
- to have a simple interface which can be extended easily for different systems within the same framework (e.g., to address inputs or outputs specific to the printer)
- to minimize the configuration needed to be stored by the direct drive component (runtime configuration would be provided by the layer above)
- to separate protocol framing from transport framing to allow efficient use of anything from direct memory mapped interfaces (e.g., on a single CPU) or master/slave protocols such as SPI/I2C or plain vanilla RX/TX.
Benefits:
The benefits I see would be:
- ARM printer controller designers would be able to easily get direct-drive supporting firmwares to compile on their system (because there are little or no CPU architecture specific components).
- Firmware designers can get their firmware to run on more printer platforms easily (on platforms which implement a direct drive interface).
- The large number of people with Arduino controllers already can cheaply upgrade using a Raspberry Pi or ARM platform without throwing away their controller (just by uploading a direct drive interface firmware). [Increasing initial critical mass.]
- Even within single chip ARM controller boards, the implementation of all real-time components in a separate library then frees the designers to use higher level languages (Java, Ruby, C#) to implement the higher layers without concern for performance.
- Hopefully resulting in a less fragmented community with everyone tuning the firmware just for their board (that's been the one blessing of the Arduino)
Implementation:
So what would the direct drive protocol look like?
- I think that a binary, extensible command protocol would be appropriate. Transport framing would be a layer on top of this so that multiple commands can be sent in the same transport frame.
- From a motion drive point of view I was thinking that sequences of trapezoid speed curves should be sufficient, that is, where each motion block has a (pre-calculated) initial acceleration, maximum speed, and final deceleration (to a junction speed) with all x/yz/e movement being specified directly in steps (i.e., all motion planning is done outside of the direct drive component). In comparison to today's firmwares this would be like having just the Marlin/Sprinter stepper.cpp code components being implemented by the Arduino and all higher G-code & planner.cpp functions implemented off-board.
I think you would also want homing to be supported natively (possibly simply through movement flags).
PID & bang-bang algorithms would be implemented for extruder and hotbed control.
It should be possible to set/read temperature, set/read state and GPIO pins through a standard "virtual register" mechanism (as is common for machine-to-machine interfaces).
Aborting queued motion commands should possible (with the ability to determine the point at which queue was flushed).
What are people thoughts on this? Is this a good direction? Would developers adopt it?
Do you think that the RepRap community could actually agree on such a common protocol? Or would everyone just end up implementing their own thing?
I imagine it would need buy in from at least a core number of platforms and at least one solid firmware effort (more would follow if successful). [Having said that much could be initially borrowed from the current Arduino-based firmwares for both the generic motion planning side and the real-time components (Arduino-specific anyway).]
Does a trapezoid speed function give sufficient flexibility in motion control for future needs?
Edited 4 time(s). Last edit at 03/05/2013 08:05AM by buildrob.