Not taking relative extrusion into account

[Ghostkeeper]

Hi, I'm posting here after receiving the plug-in submission to the Cura Marketplace. The field we get there for feedback when a plug-in is rejected is really small and doesn't allow for attachments, so I'd like to post my feedback here.

This plug-in breaks the print when the user prints in relative extrusion mode. The plug-in adds incremental deltas to the E values in the g-code. E.g. if the first travel move needs an extra prime of 0.1mm, then all E values afterwards get incremented by 0.1mm. If there are 4000 travel moves in the print, each with an average extra prime of 0.1mm, then the last extrusion move will have an E value that's 400mm shifted from the original g-code. For absolute extrusion mode that works fine.

Many RepRap-descendant printers use relative extrusion, and some other printers too. For those printers Cura puts an M83 command in the g-code, after which all E values are interpreted relatively to the previous E value. This plug-in still increments all E values the same way though, so in the previous example the final couple of extrusion moves would EACH dump 400mm of filament into the build volume. This just leads to a gigantic blob.

Reproduction steps:

• Add Custom FFF Printer to Cura.
• Enable Scalable Extra Prime.
• Set Max Extra Prime to 3mm.
• Enable Relative Extrusion.
• Load a model that involves some travel moves.
• Let it slice, save the g-code and open it with a text editor or g-code visualiser.

Alternative reproduction steps:

• Load this project file (unzip first): scalable_extra_prime_relative.zip

Expected results:

• In between M83 and M82, only the unretraction moves are altered, to add minute amounts of extrusion to them.

Actual results:

• All extrusion moves are altered with increasingly large extrusions.

You could approach a fix in two ways, I think:

• You could detect regions after M83 and M82. During those regions you can have a wholly different algorithm to adjust the unretraction length. You will not want to track new summations to adjusted_e in those regions. And you'll only want to adjust the E values of the unretractions.
• You could adjust the current algorithm to work with G92 instead, like:

  ...
  G1 X100 Y90 E52.21105
  G1 X105 Y90 E52.38521 ; <-- Track last-used E value before travel.
  G0 F6000 X30 Y122
  G1 E52.48521 ; <-- Extra prime inserted by your plug-in.
  G92 E52.38521 ; <-- Reset E value to what it was before your plug-in interfered.
  G1 X41 Y124 E52.40124 ; <-- Rest of g-code is unmodified.
  G1 X43 Y122 E52.40321
  ...

  If printing in absolute mode, you can just insert G1 E0.1 and don't need to follow up with a G92.

[Funkton]

Hello Ghostkeeper, Thank you for taking the time to review and post the detailed issue documenting this issue. I am not the original plugin author, so this will be a good learning exercise to bring it up to standards.