Hi Moriquendi,
I was thinking the same kind of thing. I think an object is ultimately defined by a series of step instructions for the X,Y, Z axes and the extruder(s). I don't think the timing between the steps needs to be stored. So
I figure that a small simple interrupt-driven stepper driver (one programmable timer for each stepper motor) would do for the printer controller. This device could also look after the nozzle & bed temperatures. This driver would be fed a stream of step instructions from some other, smarter processor. The stepper driver would be responsible for managing the stepper motors in real time.... it would issue the stream of steps at the right time for maximum acceleration, quality, etc. This would require some lookahead and buffering of the step stream. Generation of the step stream would be done by a bigger smarter processor (e.g. desktop PC, Raspberry Pi) which would stream it to the stepper driver. The source of this stream could be a Gcode file, or it could even be generated by a slicer program.
I don't think you need to store the whole object map on the printer. I think you could certainly get away with storing only the current layer. You would need at least a small buffer, because before accelerating you need to know when you need to begin decelerating, so you want some lookahead. If the buffer was too small, the driver would have to assume the next thing it received was an immediate stop, so couldn't accelerate too much. More buffer memory (up to enough for the entire current layer) would mean further lookahead and therefore faster printing.
Frank
I was thinking the same kind of thing. I think an object is ultimately defined by a series of step instructions for the X,Y, Z axes and the extruder(s). I don't think the timing between the steps needs to be stored. So
I figure that a small simple interrupt-driven stepper driver (one programmable timer for each stepper motor) would do for the printer controller. This device could also look after the nozzle & bed temperatures. This driver would be fed a stream of step instructions from some other, smarter processor. The stepper driver would be responsible for managing the stepper motors in real time.... it would issue the stream of steps at the right time for maximum acceleration, quality, etc. This would require some lookahead and buffering of the step stream. Generation of the step stream would be done by a bigger smarter processor (e.g. desktop PC, Raspberry Pi) which would stream it to the stepper driver. The source of this stream could be a Gcode file, or it could even be generated by a slicer program.
I don't think you need to store the whole object map on the printer. I think you could certainly get away with storing only the current layer. You would need at least a small buffer, because before accelerating you need to know when you need to begin decelerating, so you want some lookahead. If the buffer was too small, the driver would have to assume the next thing it received was an immediate stop, so couldn't accelerate too much. More buffer memory (up to enough for the entire current layer) would mean further lookahead and therefore faster printing.
Frank