Open Ghostkeeper opened 3 years ago
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.
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:
Alternative reproduction steps:
Expected results:
Actual results:
You could approach a fix in two ways, I think:
M83
andM82
. During those regions you can have a wholly different algorithm to adjust the unretraction length. You will not want to track new summations toadjusted_e
in those regions. And you'll only want to adjust the E values of the unretractions.G92
instead, like:If printing in absolute mode, you can just insert
G1 E0.1
and don't need to follow up with a G92.