search

Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework
GNU Lesser General Public License v3.0
6.13k stars 2.07k forks source link

Does not render some gcode correctly #6128

Open probonopd opened 5 years ago

probonopd commented 5 years ago

Application version 4.1.0 AppImage

Platform Linux

Printer Creality Ender 3

Reproduction steps Load attached gcode and compare Cura's rendering to e.g., Repetier Host's rendering

Actual results See right-hand side of screenshot

Expected results See left-hand side of screenshot

Additional information

cura

wing.zip

I created this using the instructions from https://github.com/makertum/non-planar-layer-fdm/tree/master/examples using Slic3rPE-1.41.1+linux64-full-201810261150.AppImage.

rburema commented 5 years ago

In the color-scheme legend, turn on 'travels'. It still won't look as you probably intented, but at least you can see all movements.

If the extrusion rate is low enough, it is seen as a travel-move.

Ghostkeeper commented 5 years ago

The reason this is going wrong is because Cura is unable to detect the layer height when the layers are not planar. The layer height is necessary because the g-code only contains the amount of extrusion and line length. Cura only knows the relation of width length height = volume, so with 2 of these variables set, the other two are ambiguous. As such, if the layer height is guessed too high, the lines will be too thin. If the layer height is guessed too low, the lines will be too thick.

I think that Repetier may be assuming a different layer height as default, making it render better or more consistently to the eye. Otherwise they could be using a different sort of algorithm that is able to detect locally how high a layer (or just part of it) is, but I wouldn't know what that is since it almost requires physical modelling of how far the line will droop down to get there.

Going by my guess that Repetier is using a fixed layer height for all lines, I don't think that'd be something that we want to implement since it'd cause problems with our own Adaptive Layer Height g-code. If they're doing something more clever I'd be curious.