Relative Extrusion CuraEngine

Actually a bit more on the retraction on the first layer issue. If I have a simple object with no interior perimeters, then it retracts from the end of the skirt to the beginning of the object perimeter. If, however, I have an interior perimeter that is large enough, Cura will actually produce a skirt within that. This is when it doesn't retract - when it is moving from one skirt section to another.

Regarding the bridging issue, I was printing a piece that had 3 downward-facing nut traps. When I have this, I always add a 0.25mm high cylinder where the the holes meet. This creates a membrane that later needs to be drilled out, but it allows for a smaller hole to be printed above a larger hole. Cura recognized this, but it just gave me a solid fill there, parallel with the rest of the infill. But you know the way Cura does solid infill in the midst of sparse infill: sometimes it leaves gaps in the printing and comes back and fills them in later. It is not treated any differently than any other infill on the layer. I don't think Cura "considered" it to be a bridging situation. The net result here was that there was almost no material that needed to be drilled out. The final "bridge" if you want to call it that was just a few sagging threads. (the good news was that the print was fine) Both Skeinforge and Slic3r currently handle this better and result in good strong bridges..

Perhaps I should be posting these issues over on Daid's repo. I certainly would like these two branches to merge together at some point.

My intent has never been to make an alternative Cura but rather just a branch to test things that will hopefully get in to the main version. So in the end getting Daid to make the changes would be better then me doing it. But in the event he is not interested I will do my best to maintain at least some version with my options.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

It is a pity you did not get this merged. The argument about accumulating error due tu use of relative coordinates is silly. There are 4 decimal places after the dot in the *.gcode files. This may lead to volume error of about 2.4e-4 mm³ per one E movement. But filament diameter typically varies at least in the range like 1.74 to 1.76 mm. This leads to error of about 5.5e-2 mm³ per one 1 mm of E movement. That is about 200 times more. We should always use only relative coordinates for E movement (and absolute only for X/Y/Z movement). No need for an option in GUI.

Quote
hercek
It is a pity you did not get this merged. The argument about accumulating error due to use of relative coordinates is silly. There are 4 decimal places after the dot in the *.gcode files. This may lead to volume error of about 2.4e-4 mm³ per one E movement. But filament diameter typically varies at least in the range like 1.74 to 1.76 mm. This leads to error of about 5.5e-2 mm³ per one 1 mm of E movement. That is about 200 times more. We should always use only relative coordinates for E movement (and absolute only for X/Y/Z movement). No need for an option in GUI.

I would have to agree 100%.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

After being frustrated by the print quality of Slicer over the weekend, I eventually tried Cura by using a relative extrusion plugin created by Cash from this forum. Had to make an additional change since Cura seems to use T0 as the extruder, and on my DC42 firmware it's T1, but in any event.
I was astounded at the quality difference. The quality of Cura is superb, where Slicer, frankly, was horrendous on a small object I was trying to print.

I tried numerous settings to avoid z-scars on Slicer, none of which worked. With Cura, the print was perfect. I still need to do one final test where I set the Slicer setting exactly to what my Cura settings are, but I am not expecting a difference.

I am not sure what the argument about accumulating error refers to, was it used an an excuse not to pull your change? Irrespective, the argument is completely irrelevant - the fact is that some printers (like my Ormerod) uses relative extrusion. It is not up to the developer of a slicer to decide for me that I must switch to absolute - it's built into my firmware.

Secondly, the number of decimal places after the comma in g-code does not mean one needs to use the same number of decimal places in the C code to calculate the overall lengths. Frankly, if it was such an issue, they should use a Decimal (lossless) class in C, instead of a lossy float or double C type anyway.

In any event, I have not tried your branch of Cura yet Sublime, I will try do so in the next week or so, and if it works, I will be happy to also motivate for a pull request.

PS. I'm planning to start printing your mini-Lathe soon

btw using my fork of RepRapFirmware, you don't have to use the relative extruder plugin for Cura, because I fixed the bug with absolute extruder moves in the original firmware many months ago. Also, you can get round the T1/T0 numbering using the an extension to the M563 in your start gcode - see the note towards the end of [reprap.org].

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks for the info DC, I didn't know that! Will check it out!

Having said that, relative IS useful if you're going to be editing the gcode manually, so the plugin may still have some benefit for me in the future.