[FR] Faster/more precise slicing via support of STEPS_PER_UNIT

[Marlor]

The points a nozzle can reach is limited via Microstepping and STEPS_PER_UNIT, so for example a Printer with 100x100mm and 40 STEPS_PER_UNIT would be limited to a 4000x4000 point grid 0,025mm apart were the nozzle can move.

Slicing finer than this, would only be a waste of processing time and even in best case a deviation from the finished print.

Here is a snippet of random gcode i sliced with cura:

G1 X34.923 Y45.781 E1640.60189
G1 X35.186 Y45.635 E1640.61632
G1 X35.465 Y45.508 E1640.63104
G1 X35.708 Y45.417 E1640.64349
G1 X36.035 Y45.318 E1640.65989
G1 X36.347 Y45.248 E1640.67524

there is zero chance the printer above (or any printer i would bet) will hit these points. the precision is wasted

[chepo92]

In your example X Y points are all separated by more than 0.025, moreover, usual XY steps/mm values are 80+ (depending on transmission system and microstepping), so actual resolution is equal or smaller than 0.01mm for a 100step/mm, now for the Extruder, depening on the type, they also start from 80's steps (ender 3 is 93 step/mm), with a BMG extruder that gets x4, assume 400 steps/mm it will have a 0.0025mm resolution, again the moves in yout example are greater than that, also, AFAIK, printer firmwares do optimize and drop unnecesary precision (motion planner), but you do have a point in that any non exact multiple of minimum resolution would be approximated by the planner to the nearest feasible value that could make the print up to 0.0125mm inacurate (in theory)

[Ghostkeeper]

also, AFAIK, printer firmwares do optimize and drop unnecesary precision (motion planner), but you do have a point in that any non exact multiple of minimum resolution would be approximated by the planner to the nearest feasible value that could make the print up to 0.0125mm inacurate (in theory)

That's right, but it's more subtle than that too.

The firmware typically implements a variable microstep resolution depending on velocity. That means that you'll have a lower resolution if your print head is moving faster. What's more is that some firmware doesn't just snap to the nearest grid point they can represent in microsteps, but actually does dithering. Marlin doesn't do this yet, as far as I know (see also this feature request to implement it for the Z axis, which was built for 1.1 but not merged), but some printers do and Marlin could in the future.

This reduction of resolution is really specific to the firmware and the printer. The firmware knows more about that than Cura does, so I think it's best left for the firmware to implement this quantization. It'll cost a bit more bandwidth to send the g-code over in some cases, but it'll be more future proof if dithering becomes mainstream, and will allow the printer to make better choices when printing at high speeds.

[Marlor]

With 80 steps per mm that's still just a 8000x8000 grid vs curas standard 100000x100000 grid 12,5 times more complex than it needs to be

What's more is that some firmware doesn't just snap to the nearest grid point they can represent in microsteps, but actually does dithering. Marlin doesn't do this yet, as far as I know (see also this feature request to implement it for the Z axis, which was built for 1.1 but not merged), but some printers do and Marlin could in the future.

Dithering is the other way around. Upsampling a low resolution signal for high resolution hardware. I don't see how it could be used in 3D printing

The video from the feature request looks more like backlash compensation were the nozzle would dip into the print on every Zmovement

This reduction of resolution is really specific to the firmware and the printer. The firmware knows more about that than Cura does, so I think it's best left for the firmware to implement this quantization.

My idea was to slice on the right grid/resolution already on the beginning, to save time and added accuracy as a bonus, not to lower the resolution afterwards. You are right that would be the job of the Firmware

[Ghostkeeper]

With 80 steps per mm that's still just a 8000x8000 grid vs curas standard 100000x100000 grid 12,5 times more complex than it needs to be

That's true until you take microsteps into account. With 256x microstepping the 8000x8000 grid turns into a 2048000x2048000 grid. Except that the 256x may not be attainable when printing with high speeds. So for travel moves it's more likely to be 16000x16000 or something.

Dithering for hardware is a way to work around the limitation of low-resolution hardware. Such as when your monitor can only display 16 colours. In that case it uses human perception to allow the low-resolution output of the hardware to be interpreted with greater precision. In the case of converting analogue sound to digital signal, dithering is used to work around the low resolution of the digital signal, and the speaker then smooths out the signal to produce a high resolution analogue sound again. In the case of a 3D printer, the dithered signal is effectively PWMing between steps of the motor to smooth out the curve to eliminate aliasing.

The 1μm resolution of CuraEngine is currently a limitation of the range of a 64-bit integer. We can't increase that to the next logical step, nanometres. Increasing that to 0.1μm can be done though, but we haven't done that (yet) because most printers aren't able to achieve that order of magnitude in precision by a long shot, and because 0.1μm is not a very logical unit.

Reducing the resolution doesn't really improve performance since it still needs to work through all of the 64 bits of the coordinates. The only performance increase you'd get is that the conversion to decimal for the g-code output is slightly smaller, but that is a negligible fraction of the slicing time.