Slic3r GCode Compatibility

[ThatWileyGuy]

I'm creating this as a reference for GCodes we need to implement so we can use the Prusa Slic3r with no modifications.

• M201 (needs investigation - what we have is triggering errors when Slic3r tries to use it)
• M203 (example is M203 X1000 Y1000 Z1000 E200)
• M205 (example is M205 X25.00 Y25.00 Z25.00 E1.00)

[ThatWileyGuy]

Need to check M204
G28 with the W option
Need to check G80
M900

[ThatWileyGuy]

M907 - Prusa Slic3r seems to be using this completely differently than we expect in Redeem, which causes the stepper amperage to max out

[Wackerbarth]

Is it the place of the slicer to be changing the stepper currents, maximum acceleration, etc. ? If these are properties of the mechanical hardware, the slicer has no business changing those configuration parameters. I feel that it is both inappropriate and error inducing to have two mechanisms to set the configuration.
perhaps we should make those codes non-functional. If we do so, I would recommend that we extend the configuration to have them create a warning message (with flags to suppress such message on an individual basis).

[goeland86]

Is it the place of the slicer to be changing the stepper currents, maximum acceleration, etc. ? If these are properties of the mechanical hardware, the slicer has no business changing those configuration parameters. I feel that it is both inappropriate and error inducing to have two mechanisms to set the configuration.
perhaps we should make those codes non-functional. If we do so, I would recommend that we extend the configuration to have them create a warning message (with flags to suppress such message on an individual basis).

The point that @ThatWileyGuy is making is that the Slic3r Marlin gcode definition has a different function assignment for G-Codes than Redeem does. Slic3r is never changing current or stepper modes on a RAMPS-based Marlin.

[ThatWileyGuy]

In general, I tend to give Prusa the benefit of the doubt here. They're a 3d printing R&D juggernaut with their own firmware and slicer development teams in-house, so if they've found that manipulating acceleration and current during a print improves things, I'm generally willing to believe them. Certainly they've invested significantly into figuring out things like multi-material print quality and how to do reliable color changes, and the level of firmware expertise they've shown in the past for things like calibration techniques makes me believe that if they could have solved these problems in firmware, they probably would have.

I think it does make sense to only let the slicer manipulate these parameters within firmware-defined limits, and I think a good argument could be made for a global "don't let the slicer change anything but speed" setting. I don't think it makes sense to ignore everything from the slicer by default.

[goeland86]

@ThatWileyGuy this is the official Marlin doc for M907 - http://marlinfw.org/docs/gcode/M907.html - from what you're saying though, it sounds as though the Slic3r generated GCode is setting values out of bounds for most TMC drivers, no?

[ThatWileyGuy]

Our M907 seems to be interpreting the arguments as amperages, which makes M907 E750 (from the gcode I'm trying) completely insane. Unfortunately, it doesn't look like Marlin ever actually specifies their units in the docs.

[goeland86]

Any chance we can get official clarification from either the Slic3r devs or the Marlin devs what the unit is meant to be? It seems like for everything else G-Code related they're again using the milli version of the SI unit, probably to avoid floating-point errors that would be significant using an 8-bit atmel chip.

[Wackerbarth]

Well, I still question WHY Slic3r is outputting these codes. Is it really trying to control various parts of the print with different settings? Or is it just providing a storage/initialization mechanism so that it can work with very "dumb" printer controllers by using the power of the "PC" which does the slicing to provide capability that we already handle on the BBB?

[goeland86]

As mentioned by NickParker in Slack, this is Slic3r switching between normal and silent mode during a print, based on user options given apparently.

[Wackerbarth]

So, it is the case that Slic3r is treating the printer as a "dumb" device. I assume that silent mode reduces the power and slows everything down accordingly. That seems to me to call for using a different operating configuration rather than having the slicer reprogramming the details of it "on the fly".