PrusaSlicer
PrusaSlicer copied to clipboard
prusa3d
Prusaslicer does not track Absolute E in Custom G Code
Version
2.2.0+
Operating system type + version
MacOS Catalina
3D printer brand / version + firmware version (if known)
Does not matter
Behavior
Uncheck Relative E. Print something with retractions, easiest to see if check retractions between layers. Hotend will drop a little "turd" with each retraction.
The cause is the between layer G Code. Prusaslicer does not recognize that E has been reset to 0.0, even though the firmware does.
So when you issue the retraction, it is actually a very large positive number. So large that it is rejected by the firmware.
Next a de-retract occurs, which increments E by the retraction distance. This lays a "turd" on the model.
Example G Code:
G1 X177.041 Y80.495 E386.08469 ; infill ;BEFORE_LAYER_CHANGE G92 E0.0 ; Firmware thinks E is Zero ;0.4 G1 E385.84469 F2100.00000 ; retract - Firmware rejects this G1 F6240.000 G1 X175.860 Y79.322 E385.31269 ; wipe and retract - Firmware rejects this G1 E385.28469 F2100.00000 ; retract - Firmware rejects this G92 E0 ; reset extrusion distance --Prusaslicer and Firmware agree again G1 Z0.800 F7800.000 ; lift Z G1 X179.102 Y127.246 ; move to first perimeter point G1 Z0.400 ; restore layer Z G1 E0.80000 F2100.00000 ; unretract - printer lays turd on model G1 F3600.000
That is exactly what happened here https://github.com/prusa3d/PrusaSlicer/issues/4327.
Personally, I don't see it as a big issue, since situation like this is mainly an user error. It might happen quite often though, since people tend to use our printer profiles as a template without checking all the details about it.
Hmm.. I think this would break a print on my mk3s. It’s busy right now, but unless the PRUSA firmware traps for the condition, it will behave the same way.
Users should be able to uncheck that box without breaking prints. They shouldn’t even have to know that somewhere in the slicer there is a setting called “custom g code” which is not even custom but really default g code. The only reason I found the field was because I was trying to disable linear_advance while I was troubleshooting and then I look down and see the box, and there’s the code.
On Jun 10, 2020, at 5:26 PM, rtyr [email protected] wrote:
That is exactly what happened here #4327 https://github.com/prusa3d/PrusaSlicer/issues/4327.
Personally, I don't see it as a big issue, since situation like this is mainly an user error. It might happen quite often though, since people tend to use our print profiles as a template without checking all the details about it.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/4379#issuecomment-642276759, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSKD4HK2NOHUJHILPQF5QTRV73CBANCNFSM4N2XV7XQ.
Of course it will behave the same way with the configuration like this. Firmware will only prevent extra long extrusions (longer than limit set in the firmware).
Actually, whoever changes extrusion mode should know what is he doing and why. There is a reason why is this setting visible only in expert mode. This custom command is used only in printer profiles for our printers, it is not default for PrusaSlicer.
The reason why is as simple as wanting to be able to want absolute numbers in the g code. I don’t understand why use of that checkbox should require comprehensive knowledge of prusaslicer.
If printing Relative E only works when G92 E0.0 is written in the custom g code,
and printing Absolute E only works when G92 E0.0 is deleted from the custom g code,
then logic demands that the slicer needs to generate this code based on the value of the checkbox, and not via copying it from a custom g code block.
On Jun 10, 2020, at 8:35 PM, rtyr [email protected] wrote:
Of course it will behave the same way with the configuration like this. Firmware will only prevent extra long extrusions (longer than limit set in the firmware).
Actually, whoever changes extrusion mode should know what is he doing and why. There is a reason why is this setting visible only in expert mode. This custom command is used only in printer profiles for our printers, it is not default for PrusaSlicer.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/4379#issuecomment-642337179, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSKD4CBVPAMHVAMFBN3VBLRWARDTANCNFSM4N2XV7XQ.
The reason why is as simple as wanting to be able to want absolute numbers in the g code. I don’t understand why use of that checkbox should require comprehensive knowledge of prusaslicer.
Again, this particular "G92 E0" is custom gcode, which is used only in our printer profiles. If you are going to change something in somebody else's profile, you should know what are you doing and what additional steps may be required (for example modifying start g-code, intro line g-code, etc.).
If printing Relative E only works when G92 E0.0 is written in the custom g code.
No, it is not the case. It works without it, but it should be added to prevent acumulation of the errors.
Anyway the truth is, that situation like this might happen so we may discuss internally how to prevent it.
FYI, I posted the issue you linked to, and have since tried absolute E again (it's for testing purposes, I don't print with absolute E), and can confirm that the problem still exists. Also, I am unsure why exactly you have G92 E0 in the profile by default since it has zero impact on relative E axis coordinates. In fact, it should ONLY affect absolutely positioned E, not relatively positioned E coordinates.
Edit: I misread your post, sorry. I basically read the opposite thing you said. Still, I'm struggling to figure out what purpose having G92 E0 in your default profile serves.
I was also curious about it and I got this answer:
The firmware internally maintains an absolute counter even if it is addressed relatively in the g-code. This G92 E0 resets the internal counter, thus preventing the accumulation of errors.
I understand the idea of rounding errors when dealing with relative extrusion, but I don't understand why that matters. What is the internal counter doing that needs such a level of precision that the rounding errors would play any role? If one wanted to switch to absolute coordinates at some points, it would almost be a requirement to use G92 so that you know where the absolute coordinates start.
@FormerLurker Please read #6336 #5073.
Shortly, Marlin reads relative E, adds it to its accumulator, then calculates the difference against the previous accumulator and passes the difference to the planner to move the E motor. Because of the accumulator loses accuracy if many meters of E are extruded, one has to reset the accumulator with G92 E0 time to time. It may be a Marlin quirk, it may be a quirk of some other legacy firmwares.
Regarding absolute E and custom G-code blocks, it is about a contract of the slicer and the author of custom G-code blocks. Currently there is none, thus PrusaSlicer expects that the user did not modify the E axis. If you need that, switch to relative E addressing or propose a contract.
In absolute E mode, PrusaSlicer currently emits G92 E0 on each retraction. The E axis accumulator at the start of a custom G-code block is unknown and it must not be changed by the custom G-code block.
In absolute E mode, PrusaSlicer currently emits G92 E0 on each retraction.
@bubnikv Is there a reason for this? It makes extrusion-based gcode post-processing needlessly difficult.
@bitingsock
In absolute E mode, PrusaSlicer currently emits G92 E0 on each retraction. Is there a reason for this? It makes extrusion-based gcode post-processing needlessly difficult.
The same reason applies to absolute E mode as to relative E mode. Errors would accumulate.
BTW you may now negotiate your extruder position with slicing engine using an extension to the scripting language. https://github.com/prusa3d/PrusaSlicer/wiki/PrusaSlicer-Macro-Language#special-variables-for-exchanging-printer-state-with-the-slicing-engine
I believe this solves your issue. Closing.