FiveD - is Z really necessary?

how often do we combine Z axis moves with XY and extruding, or speed changes? Would the firmware be faster or simpler if the Z axis was removed from the DDA and instead treated as an axis that only moves when everything else is stopped or homing?

It may help the CNC folk, maybe.

z may change more often in programing in the future. slanted extrusion and stress relief are some 3axis at once examples, if anything for compliance to g code we should still have z especially to reference tool position. yep I'm a CNC person. gcode is a set of standards that have been around a long time and tweaked to be adaptable. I'd hate to loose that flexibility.

Slanted extrusion is key to do higher quality overhangs without support, and also would be useful to increase finish quality of many objects. We're only scratching the surface of what we can get out of our machines when we improve the software.

Also, there really is no reason why the Z should add processing delays in the common situation where it is unchanged. For one thing, while parsing the Gcode, we shouldn't be using floating-point at all, but instead scaled integer arithmetic. The basic processing that needs to be done for a byte of input is either a simple state-machine update, or a multiplication by 10 and an addition. For current systems, 16-bits would be sufficient (0.01mm resolution and a 650mm (25.5") square build area)

A multiplication by ten is the same as a 3-bit shift left, and two adds (X << 3 + X + X) and this can be done in just a few cycles. So, parsing of coordinates in 16-bit X, Y and Z device coordinates shouldn't tax the AVR. The fact that currently we do have issues just means we have to spend more time on streamlining the firmware.

-Geert

Generally Atmel processors perform one instruction per clock cycle, so 20 MHz yields 20 MIPS, and has full support for MUL and DIV in the ALU.

Given the speed of the processor, and the fact that most of the time the processor will be idling, waiting for a step to be completed by the motor, I doubt contemplating performance tweaking on the line calculation makes any real sense. Of course I don't have any performance measurements to back this up, does anybody have any performance data on the firmware?