1. Got a question or need help troubleshooting? Post to the troubleshooting forum or Search the forums!

Change internal gcode header?

Discussion in 'Troubleshooting' started by Lazytron, May 14, 2024.

  1. Lazytron

    Lazytron New Member

    Joined:
    Feb 17, 2018
    Messages:
    17
    Likes Received:
    1
    I have been rehabbing my old R2, and its back to working, which is exciting. It seems like there is a gcode header baked into the firmware or something though that does a purge line and then waits for temps to normalize.

    Is there any way to modify this? There is a stage where it's waiting for the bed to heat and holding the hotend at purge temperatures, just oozing garbage and not extruding to compensate, leaving a blob and thin extrusion both at the start of prints. So far it has only caused minor issues in practice, but it really seems like something that could be improved.

    Thanks!
     
    #1 Lazytron, May 14, 2024
  2. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,948
    Likes Received:
    7,343
    Well, a bit more info...
    How are you printing? What slicer or host program is doling the printing for you?
    Are you using the internal OctoPi (with a web browser pointed to the printer IP address)? That can be changed by changing the start GCode in OctoPi.

    Need to know so we know which part is potentially adding the gcode. The firmware doesn't do that by itself normally. Sounds like the code in the LCD controller? Some of it may be adjustable via the LCD, other parts... no you would need to recompile it.
     
    #2 mark tomlinson, May 16, 2024
    Last edited: May 16, 2024
  3. Lazytron

    Lazytron New Member

    Joined:
    Feb 17, 2018
    Messages:
    17
    Likes Received:
    1
    Yeah, of course.

    I'm running straight from newest Cura (5.x from like the last 2 weeks) to a usb. Blank start and end fields in Cura, so maybe they're defaulting to something on null?

    I seem to recall this was always the behavior even years ago when I first got frustrated with the machine because of my own expectations. I might have been using Cura then as well though. System info from the LCD on the R2 claims 2.0.0-r2.6.

    Thanks!
     
    #3 Lazytron, May 16, 2024
  4. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,948
    Likes Received:
    7,343
    If you are printing directly from Cura via USB, try slicing it in Cura, save the GCode to a file and then use a browser to load that into the OctoPi instance on the printer and have it print it. See if it behaves the same way. If you are already doing it via the OctoPi in the printer then check the start and end GCode in the OctoPi config... that might be a good idea regardless :) It has been years since I directly printed via USB so if that is how you are rolling it is likely something we can change via the LCD menus. That priming line you see it print is controllable...
     
    #4 mark tomlinson, May 16, 2024
  5. Lazytron

    Lazytron New Member

    Joined:
    Feb 17, 2018
    Messages:
    17
    Likes Received:
    1
    Found it! Thanks for the guidance.

    I am guessing these headers are just concatenated at runtime, does gcode evaluate before running? i.e. is there a way to steal the intended hotend temp from Cura's file for this header? Maybe give it a M104 {cura target temp} during the purge line so gooping gets reduced?

    Current header looks like this for reference:
    Code:
    ; set to millimeters
G21
; set to absolute mode
G90
; zero extruder
G92 E0
; turn off fans
M107
;non blocking heatup of extruder and bed
M104 S230
M140 S60
; Robo Leveling
G36
; pause for 2 seconds
G4 S2
; move bed down 15mm
G1 Z15 F300
; move to front left corner
G1 X10 Y1 F7200
; heat to priming line temp
M109 S230
M140 S60
; move bed to printing position
G1 Z0.3
; print 190mm priming line
G1 X190 E15.0 F500
; move bed down
G1 Z15 F300
; zero extruder
G92 E0
; set movement speed
G1 F7200
     
    #5 Lazytron, May 23, 2024
  6. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,948
    Likes Received:
    7,343
    Macros like:
    {cura target temp}

    Only have meaning when the slicer is running/printing (assuming you re trying to print from Cura directly) so that should work in Cura, (if you are then loading the sliced file into OctoPrint for example). GCode is parsed live by the printer line-by-line as it is received from the host program (Cura or another slicer if printing directly or if would be OctoPrint if you are loading it to that). When you slice it the slicer will substitute numbers for the macros.

    [OctoPrint can be configured to use a slicer and do the slicing for you, but I have never configured it that way]
     
    #6 mark tomlinson, May 26, 2024
    Last edited: May 27, 2024
  7. Lazytron

    Lazytron New Member

    Joined:
    Feb 17, 2018
    Messages:
    17
    Likes Received:
    1
    Cool, I will play with it in Cura then. Thanks again for the help!
     
    #7 Lazytron, May 28, 2024
    mark tomlinson likes this.

Share This Page