I share my dumb adventure to hopefully help others.

I have been printing a lot of material lately and the printer is working great (thanks SZP!). I started a new project and suddenly I was getting random heater faults. I had changed nothing on the printer, same hardware, same firmware, same config files. Literally KGs of filament had been printed fine. So I assumed some hw starting to fail, like a wire. I could just clear the fault and hit resume and it would print fine for a bit then fault again.

I noticed the first layer (slow) would go down fine and then when it sped up for the remaining layers I would get random faults. So I slowed the prints down and that helped! I also lowered the print cooling fan rate. I could sometimes get through a whole print without a fault, but not always. I checked the wires and thermistor and all was fine. So what changed? I was now printing PLA. I had been printing ASA. I have printed lots of PLA before without issue.

That's when I figured it out. The ASA I was printing was CF and GF so I had switched to a vanadium nozzle (this is a long while back at this point). Importantly, ASA requires a heated chamber. The thermal conductivity of vanadium is lower than brass. I had not retuned PID! But the higher ambient temperature of the heated chamber made that moot. I had gotten away with it. When I switched back to PLA for the current project I did not change the nozzle back. Now I was apparently right on the edge of PID control with normal ambients. When I slowed the print down the lower plastic rate cooled the nozzle a bit less which helped.

I switched back to the brass nozzle and printing fine again. I could instead have run PID tuning on the vanadium nozzle. Lesson: I was sure I had changed nothing, but in fact I had made a change a while ago and had gotten away with it.

Well that was quick. I found if I right click there is a reload menu which caused it to come alive. All works great now! Hope this helps someone else.

Ok, it was as simple as using raspi-config to boot to terminal (CLI) instead of desktop (GUI). I'm new to RPi so this was probably obvious to all.

BTW, fun fact, the desktop uses about 600 KB RAM at 1280x900. That leaves me with about 960 KB free which I hope is sufficient.

Bonus side effect was switching to CLI and back seems to have resolved my system instability. So I am happy.

OK, I may have inadvertently resolved it.

I found how to remove the desktop and boot to terminal using raspi-config. I wanted to understand the RAM cost. I have an RPi4b with 2GB RAM.

FYI:
in terminal mode after boot I have 1.5 GB free.
In desktop gui with DWC running at 1280x900 I have 960 KB free.

Anyway, after switching back to GUI mode everything boots as expected and DWC starts. So I suspect my config was whacked somehow (I touched nothing!) and running the rasp-config corrected the situation.

Sorry for all the bother.

@micaheli I got bed leveling to work using the latest unreleased firmware. See this thread. Note that I am NOT using touch mode. There are still some mysteries but it appears to be working.

https://forum.duet3d.com/topic/37755/szp-for-bed-level-in-3-6-rc1/19?_=1742942881479

@sebkritikel Awesome news! Thank you.

@jltx

third try was the charm. working now. sorry for the noise

@jay_s_uk Thanks for clearing that up. Too bad because the Pi antenna is poop. But at least I can simplify things.

spoke too soon. I ran it again and it made odd adjustments to the Z motors and then the head crashed into the bed pretty bad. I also noticed that it only does the first dive, not the second, e.g. 15 but not 5.

; Clear any bed transform
M561

; Turn off noisy Extruder motor
M84 E0


; Lower currents, speed & accel
M98 P"/macros/print_scripts/setup_probing.g"

;if !move.axes[2].homed
  ; Home all axes
  G28

  G1 Y240 Z6      ; move coil over bed and higher than trigger point
  M558.1 K1 S1.5  ; calibrate height coeff

  ; Probe the bed at 3 points, x3 for more precision
  M558 K1 H15:5 F800 T15000; increase the depth range, gets the gantry mostly level immediately
  M98 P"/sys/bed_probe_points.g"
  M558 K1 H4:2 F400 T15000  ; reduce depth range, probe slower for better repeatability
  M98 P"/sys/bed_probe_points.g"
  ; last attempt will be auto-repeated


M558 K1 H1 F60 T15000   ; reduce depth range, probe slower for better repeatability
while move.calibration.initial.deviation > 0.01 ; 0.003
  if iterations > 3
    abort "Too many leveling attempts! Canceling print."
  M98 P"/sys/bed_probe_points.g"
  echo "Current deviation: " ^ move.calibration.initial.deviation ^ "mm"
echo "Leveling complete"

;use mechanical instead? G30 S-2 ; Z=0

; Restore high currents, speed & accel
M98 P"/macros/print_scripts/setup_printing.g"

@fcwilt Yes, this is a surprising discovery. I have been using PrusaSlicer for years but just switched to Orca. To me this is a serious Orca bug. The slicer should NOT control the machine without consent. There are custom gcode sections for a reason.

For anyone who stumbles on this, Orca looks at your start gcode and if it doesn't see any heater command (because you use a macro, for example) then it injects its own before any of your own gcode is emitted. There is NO WAY to disable directly. You can hack around this by putting M190 S0 and G10 S0 (those are the commands it is looking for, M140 also works) at the start of your start gcode and then it will not emit its own.

@dc42 ignore. I found the problem: the slicer is emitting its own gcode outside of the start g-code. Sorry for the bother! The expression does work.

@droftarts said in Where can I access persistent state?:

@infiniteloop @jltx There is also @OwenD 's Conditional G Code best practice.pdf (last updated Feb 2024 I think) from https://forum.duet3d.com/post/155650. I don't know if this is up to date with any changes in RRF 3.6, though.

Ian

Thanks for the pointer! I will digest that.

I realize I have built a quantum printer. When I am not observing it then it can print anything, but when I observe it the wave function collapses and the cat is definitely dead.

@dc42 glad I asked. Would love to see the LaPlace transfer function because I am thinking about this wrong. I ended up with MZV @50 Hz with 0.05 because my X and Y have separate peaks and I can kill both.

@dc42 said in help with optimizing heater temperature:

@jltx said in help with optimizing heater temperature:

I am trying to optimize my print start times by kicking off some prep work just prior to the bed reaching temperature (the long pole).

I pass the bed temp as param.B and use an expression to subtract 5 degrees. I wait for that to reach the then set final bed temp and nozzle temp without waiting, and kick off bed leveling, etc while those finish.

However, this does not work. It just heats up the bed to full temp every time before anything else. So either the expression does not work here or I don't understand how heater requests are queued by the firmware. Any help? This is 3.6 but behaved the same on 3.5.

; set bed and hotend temps
M190 S{param.B-5} ; set bed up to last 10 degress
M568 P0 R170 S{param.A} ; set nozzle to first layer temp

M140 S{param.B} ; finish bed to first layer temp
T0  ; select tool 0

...

That should work, unless either your tpre0.g or tpost0.g file waits for heating to finish. Do they?

My tpost0.g does have M116 P0, but that isn't triggered until the T0 command, correct? the very first M190 should be blocking and wait for the set temperature. Which it does, btw, because the nozzle temp does not change at all until after the bed completes. The problem is the value passed to the M190 is always param.B without offset. Even this mod still passes the full param.B, which seems impossible.

var bed_temp = {param.B}
var start_bed = var.bed_temp - 10.0
M190 S{var.start_bed} ; set bed up to last 10 degress

param.B is passed in from the gcode file thusly:

M98 P"0:/macros/print_scripts/print_start.g" A220 B55 

Another trick you can do to speed up hot end heating is to set the hot end standby temperature to the active temperature minus e.g. 50C (low enough to avoid oozing) and switch the heater to standby. Then set the bed temperature and wait for it. When that command completes, probe the bed, then select the tool, which will switch the heater to active.

I will try this but would still like to resolve the expression issue above since I would like to use those reliably in other areas.

@dc42

I forgot those are macros. I copied these from somewhere way back. Is the first G1 R1 resetting the restore point such that the second one should be G1 R1 Z-5? Presumably this worked on an older firmware for whoever set it up.

pause.g

; pause.g
; called when a print from SD card is paused

M300 S2500 P300 ; beep when done

M83          ; relative extruder moves
G1 E-2 F3600 ; retract 2mm of filament
G91          ; relative positioning
G1 Z5 F360   ; lift Z by 5mm
G90          ; absolute positioning

; Go to back right position for easy access
G1 X310 Y310 F6000 

resume.g

; resume.g
; called before a print from SD card is resumed

M83            ; relative extruder moves
G1 E2 F3600    ; Extrude some stock to counter oozing
G1 R1 Z5 F6000 ; go to 5mm above position of the last print move
G1 R1          ; go back to the last print move

@infiniteloop said in Where can I access persistent state?:.

If every macro had to preserve the complete machine state when called, the Duet would run out of steam memory very fast.

This is the opposite of what my mental model has been. I thought there were just a few global bits that got altered by the most recent call and stuck until changed. I do see that is documented clearly in the dictionary. I normally read all of any new commands but I was already familiar (so I thought) with G91 that has no arguments so didn’t dig in to the details. My bad.

To be clear, I don’t have a problem with this but it is a large change to how I was assuming it worked and I need to correct my debug strategy. In particular, the eye opening part, is that when I make a change through DWC and then walk over to the room with the printer to visually observe and use the LCD interface for further commands I am not using the same state I had just altered. And that explains some very odd behavior I was observing.

@fcwilt Wow, now it's getting ridiculous. I thought you had it. I used the double variable and the original value still passes through, and I tried more than one. I also tried with and without {}. I tried integer and fixed point literal. The numeric expression just does not evaluate it seems. I have used math in other places successfully. There must be something super simple I'm overlooking.

@dc42 this is eye opening and explains some things. Just to confirm, each source of gcode maintains a separate state. In addition, it looks like the state of a macro is local and not persistent? So if I leave one macro with G91 (relative) it flips back to absolute when the macro ends. So if I chain macros I need to assume the state is not preserved? What about nested macros?

@fcwilt said in help with optimizing heater temperature:

@fcwilt said in help with optimizing heater temperature:

@jltx

How about using the daemon to monitor the bed temp and start the hotend to heating at an appropriate time?

Frederick

OK then I suggest you include "sanity checks" in your code to verify that the parameters exist and that the values make sense.

Perhaps the code is not seeing the values you think.

Frederick

I have done more debug. I changed it to the following and it still ignores the subtraction. Any form I try, the initial requested temperature is the full temperature. The value comes in via param.B and it is getting the correct value. I just cannot modify it.

; set bed and hotend temps
var start_bed = {param.B}
M190 S{var.start_bed - 10} ; set bed up to last 10 degress