Adding G10 Temperature Support to PrusaSlicer

Discussion in 'Getting Started' started by Paul Arden, Jul 20, 2020.

  1. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    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.
     
    Nibbels and Olle Wreede like this.
  2. Olle Wreede

    Olle Wreede Member

    Joined:
    Aug 30, 2019
    Messages:
    7
    Likes Received:
    0
    Great work! Much appreciated.
     
  3. Krayn

    Krayn Well-Known Member

    Joined:
    Aug 11, 2019
    Messages:
    49
    Likes Received:
    13
    If you don't end up getting your pull request accepted, you might want to submit the request to SuperSlicer to see if they will accept it instead. Its a fork of PrusaSlicer I just found out about this week. They have a bunch of small little features that I'm going to play around with, but one of the ones of interest is how they have a separate section for toolchange temperature. I have no idea how it works yet but at the very least there will be some extra variables to play with in the custom gcode section.

    [​IMG]
     
    Michael Pearson and Paul Arden like this.
  4. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    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.
     
  5. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    Olle Wreede likes this.
  6. Olle Wreede

    Olle Wreede Member

    Joined:
    Aug 30, 2019
    Messages:
    7
    Likes Received:
    0
    Thank you! Will check it out.
     
  7. Olle Wreede

    Olle Wreede Member

    Joined:
    Aug 30, 2019
    Messages:
    7
    Likes Received:
    0
    I just tried it out and it seems to work. Great job!

    It seems to add two G10 commands at the start though, one just before the custom start gcode, and one just after it. And they are set to 190 even though the filament temperature is set to 195.
     
  8. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    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?
     
  9. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    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
     
    #9 Paul Arden, Oct 27, 2020
    Last edited: Oct 27, 2020
  10. Olle Wreede

    Olle Wreede Member

    Joined:
    Aug 30, 2019
    Messages:
    7
    Likes Received:
    0
    Tried it out a bit more, it turns out it sets the initial layer temp with ooze prevention subtracted. Which I assume is by design. But it isn't raising the temp to the initial layer temp before starting the print. Or is that what the second set of temp commands should be?

    Thanks for the start gcode, I'll try that out.
     
  11. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    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.
     
  12. Olle Wreede

    Olle Wreede Member

    Joined:
    Aug 30, 2019
    Messages:
    7
    Likes Received:
    0
    Yes, ooze prevention was enabled. If I disable it, the value does not change the initial layer temp.

    Setting G10 in the start gcode seems to work well.
     
  13. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    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.
     
  14. Rene

    Rene Active Member

    Joined:
    Sep 1, 2019
    Messages:
    29
    Likes Received:
    13
    A little off-topic, but would you mind sharing that TC-machine-configuration you showed off via twitter yesterday?
     
  15. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    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.
     

    Attached Files:

    • E3D.zip
      File size:
      275.8 KB
      Views:
      4
    Greg Holloway and Olle Wreede like this.
  16. Rene

    Rene Active Member

    Joined:
    Sep 1, 2019
    Messages:
    29
    Likes Received:
    13
    Thank you very much, I just have a look at it. So far, it seems to be a good base to start with. :)

    A minor flaw you maybe want to fix in your settings to avoid possible hickups/damage:

    You included into the start-G-Code
    Code:
    ; turn on the tools but do not execute tool change macros
    T0 P0
    T1 P0
    T2 P0
    T3 P0
    I totally get what you are trying to do, but you really should add a
    Code:
    T-1
    at the end of it. In its current state, T3 is active and would start extruding without getting picked up, if you ever happen to start a printjob with T3 first.

    Anyways, I don't recommend to put code like that into a print-job. Rather, put it into a macro to get called when the machine is booted or something like that.
     
    Akiross and Paul Arden like this.
  17. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    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.
     
  18. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    @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.
     

Share This Page