Reset to default settings before/after print?

deckingman

@jbjhjm said in Reset to default settings before/after print?:

Hi everyone,

just had a situation were some printer settings were modified during printing in a way that starting another print would lead to failure due to the changed initial settings. .....................

I absolutely hate that slicers can be set to do that - but other people love it. Personally, I don't let slicers do anything other than generate the print moves, and call my "pre-print" and "post-print" macros. The slicer cannot know what settings you have in config.g so it cannot "automatically" restore them.

Therefore you have a choice of two strategies. Either set things like speeds, accelerations, jerk etc in config.g and don't let the slicer mess with them. Or don't set them in config.g but use the slicer instead. Pick a strategy and stick to it.

As you have discovered, setting them in two places is a recipe for disaster because when you turn the printer on config.g will run and override the previous slicer generated settings, while running a print will override the config.g settings. Sooner or later this will bite you (oh - it just did)

Phaedrux

@deckingman The user can change things during a print as well, not just the slicer.

@jbjhjm M98 P"config.g" may be the easiest way to get everything set back to normal settings depending on what you've altered. You might also consider having separate macros for those settings like acceleration and jerk etc and then calling those again which would be less disruptive that reloading the full config.g. Your slicer end gcode could be changed to simply M0 and then you can have a macro called stop.g that gets run at the end of the print and you could reset your values there.

There are many ways to do things.

jbjhjm

@fcwilt In this case it was acceleration limit. However I would prefer a solution where I do not have to re-state everything EXPLICITLY. Of course I could copy all relevant lines of config.g into a macro or into print initialization.
But it would again be prone to hidden errors, a missed setting, managing two copies of the settings...

To formulate it differently: Is there a command to do a "soft" reset that is able to restore initial/config.g settings without restarting the whole board?

Phaedrux

@jbjhjm said in Reset to default settings before/after print?:

Is there a command to do a "soft" reset that is able to restore initial/config.g settings without restarting the whole board?

Yes, M98 P"config.g"

@jbjhjm said in Reset to default settings before/after print?:

managing two copies of the settings...

Well if you split those settings off to separate macro files you would probably want to just call those files from config.g as well.

Everything in RRF is gcode based and can be configured on the fly. Even config.g is just a macro.

jbjhjm

@deckingman said in Reset to default settings before/after print?:

Therefore you have a choice of two strategies. Either set things like speeds, accelerations, jerk etc in config.g and don't let the slicer mess with them. Or don't set them in config.g but use the slicer instead. Pick a strategy and stick to it.

As you have discovered, setting them in two places is a recipe for disaster because when you turn the printer on config.g will run and override the previous slicer generated settings, while running a print will override the config.g settings. Sooner or later this will bite you (oh - it just did)

100 % true. But in a few situations values must change over print time, just think of all the calibration prints. And that's where issues are sneaking in, leaving you wondering what the heck's wrong with your printer. Until you realize it's because the state at print start is still altered by settings from another print. Doing a state reset for reliable and replicateable results is good practice. If all prints start with the sam printer configuration state, there will be no unpleasant surprises no matter what settings they may change.

@Phaedrux guess I will try my luck with calling config.g as macro and then I'll see where it takes me!

gloomyandy

@phaedrux Unfortunately re-running config.g (which is about as close to a soft reset as you can get) will not restore any settings that are not in config.g to the default state. If you really want to get back to the original state you probably need a full reset (and even that may not be enough because the gcode file could have done something like change your WiFi password or even deleted your config.g file!).

Phaedrux

Here's what I use for start.g and stop.g to ensure that any changes made during a print have been reset.

M140 S65		; set heated bed to 65 and release
T0			; Select Tool 0
M291 P"Print Started. Preheating and Homing." T10
G4 S1
M98 P"0:/macros/Musical Tunes/LuckyTune.g" ; Lucky tune to start print off on the right foot
G4 S1
M220 S100		; Set speed factor back to 100% in case it was changed
M221 S100		; Set extrusion factor back to 100% in case it was changed
M290 R0 S0		; clear babystepping
M106 S0			; Turn part cooling blower off if it is on
G10 P0 R0 S80		; Set extruder to 80 and release
M190 S65		; set heated bed to 65 and wait
M116 S5			; wait until within 5c of target
G28			; home XYZ
G29 S1			; load heightmap
G10 P0 R180 S200	; Set extruder to 180 and release
M98 P"0:/sys/ZSpeedsPrint.g"	; Load Z speeds for printing
M98 P"0:/sys/CurrentsPrint.g"	; Load print motor currents
M566 P1 ; jerk between all moves

; Slicer Start Gcode begins.

; stop.g
; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)
; Also called by slicer end gcode by M0
;
M106 S255 		; Fan at 100 to cool nozzle and bed
M400			; Finish move queue
M104 S0 		; Extruder heater off
M140 S0 		; Bed heater off
M220 S100		; Set speed factor back to 100% in case it was changed
M221 S100		; Set extrusion factor back to 100% in case it was changed
M566 P0         ; uses jerk between all moves. yes or no.
G91			; Relative positioning
G1 E-2 F9000			; Retract filament 2mm
M204 P2600 T2600
G1 X5 Y5 Z-0.2 F12000		; Wipe nozzle 
G1 Z20 F500			; raise nozzle 5mm from printed part
M98 P"0:/macros/Calibration/Bed Leveling/1_Center Nozzle on Bed"		; Move x and Y axis so probe over bed center
;M104 S50		; Set hot end low and wait
;M116			; wait for temp to drop
G4 S60			; Wait 5 minutes
M107 ; stop fan
G28 X Y			; Home X and Y
;G28 X Y			; Home it again, Sam.
M290 R0 S0		; clear babystepping
M84			; Steppers off
M98 P"ZSpeedsNormal.g"	; Load normal z speed settings again.
M98 P"CurrentsNormal.g" ; load normal motor currents
M98 P"0:/macros/Musical Tunes/EndPrint.g" ; Thank god that's over! Let's Celebrate with a little ditty.

fcwilt

@jbjhjm said in Reset to default settings before/after print?:

@fcwilt In this case it was acceleration limit.

Oh.

I don't let the slicer change anything related to the hardware.

And to the extent it is possible the only code I have the slicer generate at the start of a print is M98 P"print_begin.g" to invoke my code.

Frederick

deckingman

@jbjhjm said in Reset to default settings before/after print?:

@deckingman said in Reset to default settings before/after print?:

Therefore you have a choice of two strategies. Either set things like speeds, accelerations, jerk etc in config.g and don't let the slicer mess with them. Or don't set them in config.g but use the slicer instead. Pick a strategy and stick to it.

As you have discovered, setting them in two places is a recipe for disaster because when you turn the printer on config.g will run and override the previous slicer generated settings, while running a print will override the config.g settings. Sooner or later this will bite you (oh - it just did)

100 % true. But in a few situations values must change over print time, just think of all the calibration prints. And that's where issues are sneaking in, leaving you wondering what the heck's wrong with your printer. Until you realize it's because the state at print start is still altered by settings from another print. Doing a state reset for reliable and replicateable results is good practice. If all prints start with the sam printer configuration state, there will be no unpleasant surprises no matter what settings they may change.

@Phaedrux guess I will try my luck with calling config.g as macro and then I'll see where it takes me!

Ahh. The first sentence of your OP stated that "some printer settings were modified during printing......." so I assumed that the sliced gcode file contained those settings changes unnoticed by you (it can happen). But as @Phaedrux has pointed out, you can change pretty much anything "on the fly" and if I understand correctly, that is indeed what happened. In which case, the only way to ensure that you get back to a known datum point is to run all macros which normally get run when power is first applied. Running config.g is usually enough but cycling the power might be better. You do lose the homing datum as well but if you always home all as part of starting new print, that won't matter.

dc42

@jbjhjm M502 followed by M501 should return most values to the values after power up. Or you can reset specific values in the start.g file.

I have it in mind to add an option to prevent GCode print files running M201, M203 and other configuration commands.

jbjhjm

@dc42 wouldn't that make it quite complicated to run test prints for finding max well-working acceleration levels etc?

@deckingman yes right. I see. I guess than it's best to implement a reset macro for typical settings and live with the 1 % chance of getting a bugged follow-up print if not restarting the printer entirely.

@fcwilt that sounds very clean but I cannot see how you handle all filament specific settings? They cannot work with the same settings. On top one may need to handle different quality/speed settings per filament. Easy to manage using presets in the slicer.

@Phaedrux thanks for the code. I'm going to refactor my config.g contents to macros too. Running config.g as macro did work fine using manual input. But it errored when placed inside the print startup routine. Did not try to track down that error. Splitting should be the better option here.

fcwilt

@jbjhjm said in Reset to default settings before/after print?:

@fcwilt that sounds very clean but I cannot see how you handle all filament specific settings? They cannot work with the same settings. On top one may need to handle different quality/speed settings per filament. Easy to manage using presets in the slicer.

I handle all that in the Filament handling feature of the DWC.

I find that I can use different slicers (Simplify3D, Cura, Prusa, ideaMaker) without having to duplicate filament information in each one.

Frederick

jbjhjm

@fcwilt hey Frederick, thanks for the hints. Looked into it and I find it to be quite interesting. Thinking about doing a similar setup.

However I'm stuck at figuring out how to handle filament specific settings that may change during print.
For example, my PETG preset uses layer fan speeds of 0 for 3 layers, then 35 %, and 70% for bridges.
Of course these values had to change radically when using e.g. PA.
Do you know any trick for this or do I need to fall back to slicer-based settings for this?

fcwilt

@jbjhjm said in Reset to default settings before/after print?:

@fcwilt hey Frederick, thanks for the hints. Looked into it and I find it to be quite interesting. Thinking about doing a similar setup.

However I'm stuck at figuring out how to handle filament specific settings that may change during print.
For example, my PETG preset uses layer fan speeds of 0 for 3 layers, then 35 %, and 70% for bridges.
Of course these values had to change radically when using e.g. PA.
Do you know any trick for this or do I need to fall back to slicer-based settings for this?

Well Simplify3D, Prusa and ideaMaker all allow calling your own code at a layer change.

It would be easy to use that ability to make fan speed changes by layer.

But as to special types, like bridges, you are limited to the slicer. But generally I use 0 for the first few layers and 75%-100% after that.

Frederick

dc42

@jbjhjm said in Reset to default settings before/after print?:

@dc42 wouldn't that make it quite complicated to run test prints for finding max well-working acceleration levels etc?

Yes, so there would have to be a way to override it.