[SBC mode] Random errors in macros with 3.5.2
-
My PrusaSlicer start gcode is:
M83 ; Relative Extruder mode M98 P"/sys/prepare-to-print.g" H{is_extruder_used[0] ? first_layer_temperature[0] : 0} B{is_extruder_used[0] ? first_layer_bed_temperature[0] : 0} T{initial_tool}
and the macro prepare-to-print.g is:
if exists(param.H) == false or exists(param.B) == false echo "Missing required parameter (H and B)" M99 var bed_temp = param.B var probing_temp = min(var.bed_temp, 60) ;echo "Hotend temperatures: ", param.H ;echo "Probing temperature: ", var.probing_temp ;echo "Bed temperature: ", var.bed_temp M220 S100 ; clear any speed changes M290 R0 S0 ; clear any baby stepping M106 S0 ; disable fans M568 A1 P0 R{param.H} S{param.H} M190 R{var.probing_temp+10} ; Wait to get up (or down!) to the right temperature M561 M98 P"/sys/homexy-if-needed.g" M401 G28 Z G32 G32 G28 Z G29 S1 M98 P"/sys/retractprobe-forced.g" if var.probing_temp < var.bed_temp M140 S{var.bed_temp+10} M116
Since upgrading to 3.5.2 on one printer and a new deployment of 3.5.2 on another printer, I'm sporatically seeing errors on both printers when this macro is invoked while starting a print. Both printers are running Duet 3 Mini 5+ control boards.
The most common error I get is:
Error: in file prepare-to-print.g line 31: unknown variable 'probing_temp'
where probing_temp is used extensively thoughout the macro and line 31 (I assume really line 30 but reported as 31) is always executed and therefore if it was an error in the macro then it should always report the error. I just recently also saw this warning:
Warning: Macro file has been started on channel File but none was requested
Possibly related to these errors I am getting situations where clicking Pause Print in the web interface hangs and does nothing (a page reload shows the print still running) and when I received the warning, my filament sensor didn't trigger which makes we think that the warning / error is causing RRF to think that the print is not running even though the print is running.
Note that on the machine I upgraded to 3.5.2, the prepare-to-print macro has been running for a long time without any changes without ever reporting an error until version 3.5.2.
Am I doing something incorrect in how I use macros inside of macros? Is something that I'm doing venturing into undefined behaviour? Note that the macro prepare-to-print will invoke the macro homexy-if-needed which will invoke the macro homexy. Prepare-to-print also invokes the macro retractprobe-forced which will invoke the macro retract-probe.
(edit to add that I looked at the 3.5.3-rc.1 changelog and git diff 3.5.2 3.5.3-rc.1 and nothing appears to be related to me)
-
@crpalmer are you running in standalone or SBC mode?
-
@dc42 sbc for both machines.
-
@crpalmer I ran your macro from a print file 10 times in a row with v3.5.2 and it completed every time as expected. Can you please share a print file and files
/sys/homexy-if-needed.g
and/sys/retractprobe-forced.g
as well? -
@chrishamm / @dc42 The two machines I am running 3.5.2 configs are:
https://github.com/crpalmer/3d-printing/tree/master/veho
https://github.com/crpalmer/3d-printing/tree/master/ender5For whatever reason, it happens much more frequently on "ender5" (don't be confused by the name, all that is left of the original ender-5 is the frame). It doesn't happen all the time and I'm starting to wonder if it happens more frequently when it has been running for awhile (perhaps some kind of subtle memory corruption?). It did happen again yesterday:
9/10/2024, 6:27:28 AM Error: in file prepare-to-print.g line 32: unknown variable 'probing_temp' 9/10/2024, 6:27:28 AM Error: in file prepare-to-print.g line 34: unknown variable 'probing_temp' 9/10/2024, 6:27:12 AM Warning: Macro file has been started on channel File but none was requested
and like before after the print finished (including M2 in the end.gcode) the machine thought that the print was still running and it was impossible to cancel the print. I end up just doing an Emergency Stop when this happens.
-
@crpalmer Can you please upload a demo G-code job as well? Then I could prepare a bench setup and attempt to reproduce it.
-
@chrishamm Here's a gcode file that I was running at around the time I last saw the error. I can't be sure it's the one I was running but the exact object probably doesn't matter given that the error happens before the print itself starts.
-
@chrishamm I was just browsing the "random restarts on mini" thread and wondered if my problems could be related. However, both of my machines are running Duet 3 Mini 5+ (Ethernet not WiFi).
Both machines have CAN boards attached. The one that encounters this error more frequently is using a EXP3HC and the other a TOOL1LC.
-
@crpalmer I think I've got a bug fix ready which will be part of v3.5.3.