Relative E option for Gcode

[richgain]

I would like to request an option, which seems to be standard in most others slicers, to export gcode using Absolute coordinates for X, Y and Z, but Relative coordinates for E movements.

[nallath]

Why would you want such an option? We would like some more reasoning before implementing new features. See; https://github.com/daid/Cura/wiki/Issue-policies

[nophead]

With relative E it is much easier to pause and change filament then continue. It is also much easier to hand edit the g-code and for example slice twice with different settings and then pick some bits from one version and the others from the other.

[hg42]

I second that...

I think, in general E-movement isn't an absolute thing like x/y/z.
It doesn't matter how much filament was extruded measured from the start of the print.
It only matters how much is extruded in a time unit, so this is a relative concept.

Relative E allows all kinds of gcode manipulations (e.g. by plugins), and most of them get very complicated with absolute E.
With absolute E you are usually forced to recalculate all E-values in the whole gcode, whereas with relative E you can simply insert some E-movement here and there without invalidating all following E-values.

[Kenzu]

+1 from here too. I use Relative E with Simplify3D and would like to se it
in Cura.

2014-03-07 2:30 GMT+01:00 hg42 notifications@github.com:

I second that...

I think, in general E-movement isn't an absolute thing like x/y/z.
It doesn't matter how much filament was extruded measured from the start
of the print.
It only matters how much is extruded in a time unit, so this is a relative
concept.

Relative E allows all kinds of gcode manipulations (e.g. by plugins), and
most of them get very complicated with absolute E.
With absolute E you are usually forced to recalculate all E-values in the
whole gcode, whereas with relative E you can simply insert some E-movement
here and there without invalidating all following E-values.

Reply to this email directly or view it on GitHubhttps://github.com/daid/Cura/issues/514#issuecomment-36959090
.

Mvh Jesper Lindeberg

[averter]

+1 from me too. Whenever I have to pause a print the lack of this feature is a pain.

[BagelOrb]

@averter can you specify your problem more clearly?

It sounds to me to be more of a problem of the printer that it cannot
handle pausing correctly.
What type of printer do you have?

Op 27 aug. 2016 22:39 schreef "Averter" notifications@github.com:

+1 from me too. Whenever I have to pause a print the lack of this feature
is a pain.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/daid/Cura/issues/514#issuecomment-242939531, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIe9EX8qvS7h8ZyZ2Qf3MJ9hCvcqGPQ_ks5qkKB1gaJpZM4A2gZj
.

[averter]

@BagelOrb If you see this related issue OctoPrint/OctoPrint#779 (comment) mentioned above by nophead you'll see. Essentially most people want the flexibility to retract and extrude filament during pause, without rewinding back to the same E position after unpausing. I have a Prusa i3 Rework controlled by Octoprint.

[BagelOrb]

Interesting.
I still think this should be solved in the printer, though.
The printer should not count the extrusion made during a pause as real extrusion.

This will probably be fixed in our next generation of printers.

[Ghostkeeper]

As I understand it, this issue is not specific to any single problem (like retract and unretract at pausing) but to make the g-code more easy to modify by hand, to tinker with it more easily.

[BagelOrb]

I think people should use G92 Ex more.
I don't think it's that hard to tinker with the gcode once you know how to
properly use it.

2016-09-05 1:13 GMT+02:00 Ghostkeeper notifications@github.com:

As I understand it, this issue is not specific to any single problem (like
retract and unretract at pausing) but to make the g-code more easy to
modify by hand, to tinker with it more easily.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#514 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIe9EeY-QAQ1dEFQ11eaU5rHTJzAbjvmks5qm1CKgaJpZM4A2gZj
.

Kind regards,

Tim Kuipers

Ultimaker BV

www.ultimaker.com

[hg42]

I already said above:
"
Relative E allows all kinds of gcode manipulations (e.g. by plugins), and most of them get very complicated with absolute E.
With absolute E you are usually forced to recalculate all E-values in the whole gcode, whereas with relative E you can simply insert some E-movement here and there without invalidating all following E-values.
"

it's simply more modular.
You are right, that G92 can help (I use it myself, when fiddling with generated gcode, e.g. continuing a failed print), but it's a workaround more like a trick, not a clean solution.

Also, relative E should be easy to implement, I think.
I assume the absolute value being an additional step in the slicer engine?
Just make summation optional.

[daid]

You are right, that relative GCode can help, but it's a workaround more like a trick, not a clean solution.

[hg42]

:-)

with relative E you can insert gcode without correcting the E position before and after by G92.
It makes the gcode parts independent from each other.
The correction steps are fixes to a problem only existing because of using absolute E.

On the other hand, what are advantages of absolute E?
I don't see any...

[daid]

With absolute E, the E axis behaves like a normal axis, just like all the other. You also don't have a rounding conversion error buildup due to float->string->float conversions.
It's also the default standard behavior that does not depend on any custom M codes that haven't been standardized in any way.

[hg42]

ok, thanks for the answer, seems there are some good reasons.
However, an option would not hurt...

[daid]

An option wouldn't hurt?

[averter]

@daid is that a screenshot from Simplify3D? XD

[nallath]

No, its from skeinforge.

[hg42]

I am not familiar with skeinforge, because I skipped it because it is way too slow for me.

But these options are very well structured.
E.g. you have a set of parameters for interface, first layer and so on.
Each set is clearly defined and understandable (flow rate multiplier, infill density etc.).

IMHO, the sheer amount of options doesn't hurt as long as you understand what they mean.

I like that several parameters are separated by physical meaning.
E.g. filament diameter is separated from filament packing density instead of joining them into one.

Skeinforge is very old. Those parameters seem to be directly from the algorithm. So all the slicer can do is accessible. It's low level. This makes it very powerful. So, I often heard sentences like "in skeinforge we can set parameter x" to solve problems other slicers have.

Most modern slicers try to simplify the user experience, but they fail here and there.
E.g. holes are still too small. Skeinforge has a parameter for this.

Komplex algorithms have complex parameters. That's it.

It's all about good defaults and ways of hiding most parameters for non experts.

[hg42]

I think we are still pioneers.
In this phase we don't fully understand what's going on.

So you cannot determine all parameters of the algorithm automatically (which generally should be possible using all physical knowledge).

Another problem is that most printers have severe problems.
And you never know all physical parameters of them.
You would need a kind of calibration procedure. Probably a very complex procedure.

Given that, you need access to lower levels of the algorithm.

[hg42]

@daid I thought a bit about your arguments.

"With absolute E, the E axis behaves like a normal axis"

this probably simplifies programming. But in this case the calculation can be the same with an additional step at the end (determining the relative value). Or, in the other case, if the absolute value is calculated from the last value and a relative amount, you simply use the relative value instead.

"You also don't have a rounding conversion error buildup due to float->string->float conversions"

seems to be unbeatable. But...there is a difference between XYZ and E.
For XYZ which are absolute in nature, summing up many small errors would result in wrong positions.
Instead the E value is relative in nature. Each error only results in a wrong flow in this segment.

"It's also the default standard behavior that does not depend on any custom M codes that haven't been standardized in any way."

this is plain true given the reprap definition on
G-code - RepRapWiki
http://reprap.org/wiki/G-code

However, if your printer firmware can handle relative E, you have a code for that and can configure it in start.gcode
Also, there already is an option for the gcode flavour or firmware.

[Ghostkeeper]

The floating point problem would be lessened in relative E because the numbers are closer to 0, where floats are more accurate.

The trade-off is that the total material cost/weight can float off due to rounding errors, instead of compensating for one round-up by rounding down in the next move.

[nophead]

ASCII gcode is actually fixed point. I.e. there are a fixed number of
digits after the decimal point, so small values are not more accurate.

The slicer could keep track of the sum of the rounded values it has output
and always send the difference between that and the new absolute value.
That way there would be no cumulative error.

On 6 September 2016 at 10:28, Ghostkeeper notifications@github.com wrote:

The floating point problem would be lessened in relative E because the
numbers are closer to 0, where floats are more accurate.

The trade-off is that the total material cost/weight can float off due to
rounding errors, instead of compensating for one round-up by rounding down
in the next move.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#514 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAijhUNfMTxcHKlnuOo3fUzGO2JRtB3Pks5qnTIjgaJpZM4A2gZj
.

[BagelOrb]

This idea is never going to be fixed in legacy Cura. As for Cura 2, please submit your pull request at https://github.com/Ultimaker/CuraEngine and https://github.com/Ultimaker/Cura

[Ghostkeeper]

This feature was just rejected by our change control board.