Retract incorrect for LinuxCNC

[cdsteinkuehler]

I have been having problems getting rid of blobs when using LinuxCNC to drive my MendelMax. I have finally traced this back to the use of G0 moves combining retract with travel when I select the "Mach3/EMC" gcode flavor. Apparently, Mach does uncoordinated G0 moves? LinuxCNC matches Mariln and does coordinated G0 moves, so retract works well for short distance moves, but fails (retracts too slowly to stop blobs) on longer moves.

I looked in the code and did not see an obvious way to disable G0 moves without switching to a different gcode flavor, which then produces a bunch of "illegal" codes (as per RS274D/ISO 6983).

Is there a way to force retract before move and still output RS274D compliant gcode?

[alranel]

Please, tell us at least what version are you using.

[cdsteinkuehler]

Oops! Latest stable version 0.9.10b on 32-bit Linux.

[cdsteinkuehler]

Hmm...according to issue #1212 it looks like Mach3 might have issues with G0 retract as well. I'm going to see if I can just remove the mach3 special case from sub retract in GCode.pm and see if that fixes things. Then you would have to manually add --g0 to get g0 move with retract, regardless of gcode flavor.

[cdsteinkuehler]

If I don't force the G0 retract-with-move option when selecting Mach3/LinuxCNC gcode output, retraction works as expected and my prints are clean again. Patch: http://lrp.steinkuehler.net/0001-Do-not-force-g0-retract-with-move-if-mach3-firmware-.patch

The patch is so you can see what I did. I'm not sure exactly how the code logic is supposed to work, or I would submit a pull request. It appears that the --g0 switch is actually a "force retract with move" switch. It is currently impossible to enable wipe if using --g0, which I understand (if --g0 is actually "retract with move"), but it is also currently impossible to implement wipe or to disable "retract with move/--g0" if using Mach3/LinuxCNC gcode, which I don't understand.

[alranel]

Can you elaborate on what illegal codes (for LinuxCNC, that is) does Slic3r produce when you select the 'reprap' G-code flavor?

[cdsteinkuehler]

If I export reprap flavored gcode and translate all the E axis moves to A, LinuxCNC complains about unknown mcode M82. When I was experimenting with LinuxCNC several weeks ago (and hadn't switched from the reprap to the Mach3 gcode flavor) I think there were a few other codes that caused problems, but I'm either not seeing them now or they were in the gcode prefix/postfix that I have since migrated to be "LinuxCNC friendly".

Going back to the retraction issue, IMHO the existing code should be refactored to support two command line switches. One, the --g0 switch which simply says to use g0 moves for travel, and a second switch (name to-be-determined) that means "Combine retract with travel". The "Combine retract with travel" option would force g0 travel moves (ie: imply --g0) and disable wipe. I am willing to code this and send a pull request if you like the idea and tell me what you'd like to use for the retract-with-travel switch. Caveat: I can definitely handle the gcode generation changes. I can probably handle the command line argument parsing, but I'm not a gui guy and probably can't manage adding a GUI button for the options.

[alranel]

So, from what I understand we have a LinuxCNC controller that works almost like Mach3 with the exception of G0 being synchronized. Is this right?

[cdsteinkuehler]

Well, yes, except it is my understanding that Mach also does synchronized g0 moves.

I'm not a Mach3 expert, but the manuals I've found for them online show g0 moves as synchronized, and everything I've found regarding gcode in general indicates synchronized g0 moves are an improvement over uncoordinated moves (no speed loss, and it makes programming easier as you know where the machine will be and can avoid obstacles). Perhaps some really ancient version of Mach did not do coordinated g0 moves?

[nophead]

G0 is definitely not synchronised on the version of LinuxCNC I use. As mentioned before, it will round off right angle corners.

On 7 July 2013 18:18, Alessandro Ranellucci notifications@github.comwrote:

So, from what I understand we have a LinuxCNC controller that works almost like Mach3 with the exception of G0 being synchronized. Is this right?

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1289#issuecomment-20573921 .

[cdsteinkuehler]

g0 moves in LinuxCNC are coordinated: http://www.linuxcnc.org/docs/html/gcode/gcode.html#sec:G0

What you are seeing is a very large permissible tracking error being used to keep speeds high while "going around the corner" In order to perfectly follow a commanded corner, the machine would have to physically come to a stop and then start off again on the new vector (or be capable of things like infinite acceleration). To avoid this, the LinuxCNC motion planner provides for an allowable following error, which is VERY LARGE when doing g0 rapids and allows the rounding of corners you describe to keep up machine speed.

But the g0 rapids are still coordinated, and the retract speed is dependent on X Y Z travel distance the way Slice3r currently generates combined retract-with-travel gcode, which is why retract is not working properly and I'm getting ooze.

[nophead]

I suppose it depends what you mean by "synchronised" but by rounding a corner, two G0 consecutive moves are overlapped.

On 7 July 2013 20:16, cdsteinkuehler notifications@github.com wrote:

g0 moves in LinuxCNC are coordinated: http://www.linuxcnc.org/docs/html/gcode/gcode.html#sec:G0

What you are seeing is a very large permissible tracking error being used to keep speeds high while "going around the corner" In order to perfectly follow a commanded corner, the machine would have to physically come to a stop and then start off again on the new vector (or be capable of things like infinite acceleration). To avoid this, the LinuxCNC motion planner provides for an allowable following error, which is VERY LARGE when doing g0 rapids and allows the rounding of corners you describe to keep up machine speed.

But the g0 rapids are still coordinated, and the retract speed is dependent on X Y Z travel distance the way Slice3r currently generates combined retract-with-travel gcode, which is why retract is not working properly and I'm getting ooze.

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1289#issuecomment-20575723 .

[alranel]

I will rephrase my last message to be more clear.

So, from what I understand we have a LinuxCNC controller that works almost like Mach3 with the exception of each G0 being synchronized among all of its axes. This means that if we issue a long travel and a retraction, retraction will happen at a very slow speed because it will be stretched to take the same time as the travel move. Infact, LinuxCNC docs talk about G0 doing "straight line" moves, which wouldn't be true if each axis just used its max speed. Is this right?

[cdsteinkuehler]

Yes, that is exactly correct. Long combined travel + retraction g0 moves cause retraction to happen too slowly, which creates ooze.

[brandonheller]

I'm also likely to incur this problem. Alex, do you have any plans for a resolution? I'm willing to test a patch if need-be. Thanks.

[cdsteinkuehler]

Besides the retraction (which is easy enough to fix even I muddled through it), there are apparently a LOT of other switches throughout slic3r that don't work properly if you select mach/emc as the firmware flavor. It's been a few months, but IIRC circular vase mode and the thicker infill layers both didn't work unless you pick the "reprap" gcode flavor. I now tell slic3r I'm running marlin, and post-process the gcode with sed to generate a LinuxCNC friendly ngc file.

[brandonheller]

Charles, do you have a link to the post-processor?

[cdsteinkuehler]

I'ts just a sed script I wrote. I'm away from the slicing machine at the moment (and I didn't leave it powered on for remote access), but I'll post the script in a day or two when I get back. IIRC, it just comments the unknown commands (like M28?) and changes the M1xx Syy parameters to M1xx Pyy, as required by LinuxCNC. I also wrote custom handlers for the M1xx codes to set temperature, etc. that match how Marlin behaves (available in my LinuxCNC github repo).

[PlanetCNC]

Hi, I'm Andrej and I'm from PlanetCNC. We make CNC software and controllers.

We had topic about this issue on PlanetCNC forum http://forum.planet-cnc.com/viewtopic.php?f=5&t=1068

I want to point out two things that Slic3r does incorrectly.

• G0 is coordinated move in Mach3 and in LinuxCNC/EMC.
• When F is used with G0 it is ignored by Mach3 and LinuxCNC/EMC

I just tried and confirmed this using default settings. You can see screenshots on our forum.

If you need any help with Mach3/LinuxCNC compatible g-code then I can help.

PlanetCNC software uses RS274D compliant gcode by default but if machine type is set to printer then all flavors of g-code are recognized and working.

[alranel]

So, I removed any code that uses G0 to combine retract and travel. G0 is now only used for simple travel moves, and retraction is always performed in a separate line using a G1 command.

Can you confirm this behavior works with your toolchain? Thank you!

[brandonheller]

Thanks, Alex!

Charles, can you post a link to the sed script here? Would love to try it out.

If I understand correctly, I have two options that should work:

• Use the mach/emc flavor w/Alex's latest fix, but avoid some advanced features like circ vase mode & thicker infill, and use Charles' lcnc branch
• Use the reprap flavor w/Alex's latest fix, add Charles' sed script, and use his lcnc branch.

[cdsteinkuehler]

I'll swear I posed the script here already...Bizzare. Oh well, here it is again. It isn't fool-proof, the regexs should really be more sophisticated to handle arbitrary (legal) gcode, not do substitutions in comments, etc., but it works for Slic3r output, which was sort of the point. I have this script hooked into my Slic3r config, so Slic3r generates a gcode file (useful for various visualization options, some of which don't understand LinuxCNC gcode or look for *.ngc files), then it gets converted to ngc.

charles@machinekit:~$ cat bin/gcode2ngc

#!/bin/sh

sed '
/^G/s/ E/ A/
/^M/s/ S/ P/
s/^M82/;M82/
' "$1" > "${1%gcode}ngc"

[machinekoder]

I have tested the latest development version of Slic3r. Works great with LinuxCNC except that Slic3r generates G1 command with E as extruder, however the extruder is always A in LinuxCNC (and all other commands seem to be correctly generated with A also) e.g.: G1 E0.00000 F1800.000 A simple replace all E with A with any text-editor solves this issue. It would also be great if the axis names could be selected anywhere because I can imagine having more than 3 axes for movement and 1 for extrusion.

Another thing: In the export dialog Slic3r always uses a file filter with GCode file name extension. LinuxCNC uses ngc as file extension. I know it is possible to select this file extension somewhere in the settings but in the export dialog the file filter is not update so it is not possible to see the already existing ngc files.

[brandonheller]

Strahlex, to confirm, which output type were you using - RepRap or Mach/EMC?

[machinekoder]

Mach/EMC

[lordofhyphens]

@strahlex Does this work in the current 1.2.9 or 1.3.0-dev?

[mrvn]

@nophead Rounded off corners are, as mentioned, to maintain speed while changing direction and happens for G1 too. But there is a G-code to switch to exact following (and coming to a full stop in corners): G61. Does that affect G0 too?

For more about rounded corners read http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TrajectoryControl

[nophead]

Yes I am aware why it rounds corners and of G61. My guess would be G61 doesn't affect G0

[lordofhyphens]

@machinekoder The default filename is an option in the Print Settings->Advanced.

I'll take a look at the LinuxCNC flavor behavior for the axis.

[lordofhyphens]

@machinekoder @strahlex

According to https://github.com/alexrj/Slic3r/blob/master/xs/src/libslic3r/PrintConfig.hpp#L354 and https://github.com/alexrj/Slic3r/blob/master/xs/src/libslic3r/GCodeWriter.cpp#L379 and https://github.com/alexrj/Slic3r/blob/master/xs/src/libslic3r/GCodeWriter.cpp#L448, the extrusion axis should be correctly defined for Mach3 firmware flavor. If you weren't in Mach3/LinuxCNC (or Machinekit) flavor and you still wanted the axis to be A you can override the extrusion axis on the command line with --extrusion-axis (those and no-extrusion override this presently).

If you can still reproduce the problem in current master (https://bintray.com/lordofhyphens/Slic3r/slic3r_dev/1.3.0-dev-25bcff3#files) I will reopen.