Retract incorrect for LinuxCNC #1289

Closed
cdsteinkuehler opened this Issue Jul 3, 2013 · 29 comments

Comments

Projects
None yet
8 participants
@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?

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jul 3, 2013

Member

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

Member

alexrj commented Jul 3, 2013

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

@cdsteinkuehler

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Jul 3, 2013

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

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

@cdsteinkuehler

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Jul 3, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Jul 3, 2013

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.

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.

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jul 6, 2013

Member

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

Member

alexrj commented Jul 6, 2013

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

@cdsteinkuehler

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Jul 6, 2013

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.

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.

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jul 7, 2013

Member

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?

Member

alexrj commented Jul 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Jul 7, 2013

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?

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

This comment has been minimized.

Show comment
Hide comment
@nophead

nophead Jul 7, 2013

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
.

nophead commented Jul 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Jul 7, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@nophead

nophead Jul 7, 2013

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
.

nophead commented Jul 7, 2013

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
.

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jul 7, 2013

Member

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?

Member

alexrj commented Jul 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Jul 7, 2013

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

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

@brandonheller

This comment has been minimized.

Show comment
Hide comment
@brandonheller

brandonheller Oct 5, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Oct 8, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@brandonheller

brandonheller Oct 8, 2013

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

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

@cdsteinkuehler

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Oct 9, 2013

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).

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

This comment has been minimized.

Show comment
Hide comment
@PlanetCNC

PlanetCNC Oct 11, 2013

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.

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.

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Oct 13, 2013

Member

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!

Member

alexrj commented Oct 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@brandonheller

brandonheller Oct 13, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@cdsteinkuehler

cdsteinkuehler Oct 13, 2013

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"

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

This comment has been minimized.

Show comment
Hide comment
@machinekoder

machinekoder Oct 26, 2013

Contributor

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.

Contributor

machinekoder commented Oct 26, 2013

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

This comment has been minimized.

Show comment
Hide comment
@brandonheller

brandonheller Oct 26, 2013

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

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

@machinekoder

This comment has been minimized.

Show comment
Hide comment
@machinekoder

machinekoder Oct 26, 2013

Contributor

Mach/EMC

Contributor

machinekoder commented Oct 26, 2013

Mach/EMC

@lordofhyphens

This comment has been minimized.

Show comment
Hide comment
@lordofhyphens

lordofhyphens Jun 3, 2016

Member

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

Member

lordofhyphens commented Jun 3, 2016

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

@mrvn

This comment has been minimized.

Show comment
Hide comment
@mrvn

mrvn Jun 6, 2016

@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

mrvn commented Jun 6, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@nophead

nophead Jun 6, 2016

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

nophead commented Jun 6, 2016

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

@lordofhyphens

This comment has been minimized.

Show comment
Hide comment
@lordofhyphens

lordofhyphens Mar 1, 2017

Member

@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.

Member

lordofhyphens commented Mar 1, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@lordofhyphens

lordofhyphens Mar 11, 2017

Member

@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.

Member

lordofhyphens commented Mar 11, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment