Adding G10 Temperature Support to PrusaSlicer

I have submitted a pull request for PrusaSlicer to add basic G10 temperature support for RepRapFirmware. I'm trying to minimise what I include in this for now to increase the likelyhood that it will get accepted. This absolutely won't replace the post processing scripts such as the great one created by @mkudzia which does all sorts of other clever stuff, the idea here is just to get better RepRapFirmware style G-code out of the box. The main changes are:

• Do not add M104/M109 automatically if there is already a G10 G-code line in the start custom start G-code. This removes the need for the hack of putting in a blank M104 line to suppress this behaviour.
• When automatically adding tool temperature too start G-code (if the user did not include G10 or M104/M109), use G10 style temperature G-code if the firmware flavour is RepRapFirmware.
• Use G10 style temperature G-code when adding all other temperature commands (e.g., on rest of layers or layers with temperature changes set) if the firmware flavour is RepRapFirmware.
• Use the G10 P parameter to specify tool number in temperature commands when there are multiple extruders and the firmware flavour is RepRapFirmware (if there is only one then you get no tool numbers at all in the output, which is what you probably want on a single extruder machine).

This should (if I can get the pull request through) remove the need for post processing tools to hunt down the M104/M109 commands and replace them, at least meaning less work for post-processing scripts to do and more functional default G-code.

In my start G-code currently I use the standby_temperature_delta variable from the Ooze Prevention section to set the standby temperatures. I will likely do another pull request for adding real standby temperature support in the future since this should really be part of the filament not the print settings. For now though it gives me a way to use it.

I know there are likely all sorts of things people would want to see change in PrusaSlicer with respect to the Toolchanger but right now for me lack of G10 support was the most problematic for me. I've implemented the above changes in my fork and have submitted a pull request. If you are familiar with building PrusaSlicer from source already you can build it from the branch for this change in my fork here:

https://github.com/ardenpm/PrusaSlicer/tree/pa_reprap_g10_temperature_support

If anyone thinks of any G10 gotchas not covered above let me know. If you want to comment directly on the pull request you can find it here:

https://github.com/prusa3d/PrusaSlicer/pull/4553

I don't think this would ever get priority from the internal team (there are request from back in 2017 still for this), so hopefully it's able to get through.

 

That looks pretty interesting. I've got four Prusa machines so I'm pretty motivated to use PrusaSlicer but some of those settings look pretty interesting. I've been looking at at least adding stand-by temperatures to PrusaSlicer but it is a bit tricky since it looks like they actually had it at some point and removed it and now explicitly ignore the parameters.

 

The pull request has been merged! It is now also available in the latest PrusaSlicer alpha so you don’t need to compile yourself.

https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.3.0-alpha2

You need to use the new ‘RepRapFirmware’ firmware flavour to access the G10 functionality.

 

I will check that, however if you put in your own G10 commands to set the temperature it should then not insert any automatically.\

Do you have different first layer temps set?

 

I am reproducing the issue where there are more G10 commands inserted automatically if you don't have your own G10 temperature commands in the start G-code. It also looks like it is heating up the tools one at a time which isn't desirable. I'll need to investigate further, however for me at least it uses the first layer temperature in both cases (and then uses the other layers temperature later in the print as expected).

None of this is an issue if you use your own start G-code with G10 commands, which I'd recommend in any case for the tool changer. Mine looks like this currently:

Code:

G29 S1 ; use mesh bed compensation

T-1 ; drop active tool if any

; set tool active and stand-by temperatures
G10 P0 R{first_layer_temperature[0] + standby_temperature_delta} S{first_layer_temperature[0]}
G10 P1 R{first_layer_temperature[1] + standby_temperature_delta} S{first_layer_temperature[1]}
G10 P2 R{first_layer_temperature[2] + standby_temperature_delta} S{first_layer_temperature[2]}
G10 P3 R{first_layer_temperature[3] + standby_temperature_delta} S{first_layer_temperature[3]}

; turn on the tools but do not execute tool change macros
T0 P0
T1 P0
T2 P0
T3 P0

M116 ; wait for tools to reach temperature

Though I am still refining. I abuse the Ooze prevention delta temperature for setting my stand-by temperature. In any case, I'll check out the automatic temperature commands further.

EDIT: Issue created to track https://github.com/prusa3d/PrusaSlicer/issues/4991

 

The ooze prevention value should only be used if ooze prevention is turned on, just to check, did you actually have it enabled?

You'll see a bit of a back and forth in the Github issue now, it looks like the way it works now is by design, it just looks even messier with G10 since you need a G10 and M116 for the wait. Not raising the temperature though I'd need to check, looking at the code it doesn't seem to raise it again, I haven't checked if it does so before the layer start.

 

That ooze issue looks like a general bug (nothing to do with the G10 support), I'm going to report that after some more testing.

 

Attached. However please note this was more about fleshing out the structure than actually having workable settings.

From what I understand @Greg Holloway may be looking at adding this now so he might be interested in this as a starting point.

I also had not read the Vendor Profile Creation guide when I did these. So there might be some things that are not best practice.

 

This is related to the unfinished nature of the profile if I recall, I was in the middle of a RRF2 to RRF3 migration (I am on 3 now). I seem to remember I had issues with the different tool states RRF has (off, active, standby) and heating not occurring by just setting the temperature alone. Definitely a lot of changes still need to be made.

 

@Rene actually re-reading your note, are you saying that what you do is set all tools to active on startup of the machine (presumably with the temperatures at 0) and then select no tool? If I understand correctly in that case the machine would then start with all tools in set to standby rather than off as they currently do.