The error is likely in another file that is being called by config.g
There is already a feature request to show the name of the macro in error messages
https://github.com/Duet3D/RepRapFirmware/issues/761
The error is likely in another file that is being called by config.g
There is already a feature request to show the name of the macro in error messages
https://github.com/Duet3D/RepRapFirmware/issues/761
@GratefulAbyss37
What you are seeing is a warning, not an error.
Somewhere, either in your config.g or in another file, there is a call to G29 which loads a bed height compensation map.
https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g29-mesh-bed-probe
This should only be done AFTER homing the Z axis ( G28 ) so that a zero reference point has been properly established.
Search your files and remove the G29.
In general, when asking for help you should post your config.g and any other files which might relate such as homeall.g and homez.g
https://forum.duet3d.com/topic/5909/guide-for-posting-requests-for-help/10
@Macgyver
It's a pity M587.2 doesn't have an option to return an array with just SSID names.
Then you could cut out incorrect entries.
Unfortunately it only gives a text output full of unnecessary information (for a macro) or a json return
Aside from the previous comments, a few things.
If you want to use variables in the M291 then use something like
var choice= [-1,-1]
var options1 = ["A","B","C","D"]
M291 K{options1} .....
if input >=0
set var.choice[0]= input
Note that input is the returned index so it is zero based
So it will be 0,1,2,3 or cancelled
Depending on firmware version, the result of a cancellation or timeout is different so you'll need to consider that
I would put your two choices into another array rather than a number as it will be easier to do your compatibility tests.
I would also work out my choice arrays so that after choosing the first, the M291 on the second only presents valid choices
Lastly, you can't use line breaks and mixed comments in your Boolean OR logic like that
You'd need to change it to
if
blah
elif
blah blah
@St-Taw
The mesh offset is typically set to taper off as the Z height increases.
This is set by M376 in config.g (usually)
https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m376-set-bed-compensation-taper
Any baby steps applied will also result in a difference between user and machine positions.
Last stop height reports the Z height when the sensor triggered. No mesh offset is applied. However for it to be accurate, you must calibrate it.
https://docs.duet3d.com/User_manual/Connecting_hardware/Z_probe_testing
@SonnyD1
I'm afraid I know nothing about scanning probes, so I'll leave that for someone else
You have M557 commented out in your config so I'm guessing it's (the probe grid) undefined when you access the object model variables in your home.z
; Mesh Bed Compensation
;M557 X25:175 Y25:175 S40:40 ; define grid for mesh bed compensation
Try echoing the variable positions to confirm
; home Z
var xCenter = move.compensation.probeGrid.mins[0] + (move.compensation.probeGrid.maxs[0] - move.compensation.probeGrid.mins[0]) / 2 - sensors.probes[0].offsets[0]
var yCenter = move.compensation.probeGrid.mins[1] + (move.compensation.probeGrid.maxs[1] - move.compensation.probeGrid.mins[1]) / 2 - sensors.probes[0].offsets[1]
echo "x position " , var.Center
echo "y position " , var.yCenter
G1 X{var.xCenter} Y{var.yCenter} F6000 ; go to bed centre
M558 F4000:150
@dc42 said in metacode rread-only variables:
@OwenD using 'const' wouldn't affect the memory usage.
Ah well.
In that case I can dress in either direction.
Can't hurt anyone and may help some.
@dc42 said in metacode rread-only variables:
maybe "global const" could create a global constant and "const" by itself create a local constant.
This is probably closest to convention with most languages.
If it resulted in lower memory usage then I'd vote for it.
@Surgikill said in Triggering 'Load Filament' prompt with a macro:
@dc42 Yes, I am doing that now. However, I want the prompt to contain options that are dynamically created based on the content of "0:/filaments". I don't want to update the prompt every time I add a filament, or modify the name of a filament. Just like how DWC creates the prompt when pressing the 'Load Filament' button.
At present RRF doesn't have any string handling routines and no way of extracting file information or file lists.
The best you can do is use the object model item
move.extruders[0].filament
which will show the currently loaded filament (or null)
I ran into a similar issue trying to create a filament change macro to use from PanelDue as my printer is in the shed and my computer inside.
I had to manually list all the filament types I use in an array.
This is what I came up with.
It may (or may not) help in your case.
; ChangeFilament.g
; requires RRF 3.5 or later!
; list of filaments must follow rules for array
; https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands#array-expressions
var filaments = {"ABS","ABS-CF","ABS-GF","ASA","EDGE","eFlex","eLastic","FLEX","HIPS","NGEN","NYLON","PA-CF","PC","PCABS","PDVF","PEEK","PEI","PEKK","PET","PETG","PLA","POM","PP","PSU","PVA","SCAFF","TPE","TPU",} ; list your filaments here
var maxBtns = 10; Max number of buttons per page on PanelDue. Adjust as required. 5 works OK on 7"paneldue - 9 is max!
; don't change below here
var thisTool = state.currentTool
var allTools = vector(#tools,null)
if var.thisTool = -1
if #tools > 1
while iterations < #tools
set var.allTools[iterations] = tools[iterations].name ^ ""
M291 S4 P"Select tool" K{var.allTools} F0
T{input}
G4 S1
if state.currentTool = -1
abort "No tool selected"
else
set var.thisTool = state.currentTool
else
T1
var thisExtruder = 0
var allExtruders = vector(#tools[var.thisTool].extruders,null)
if #tools[var.thisTool].extruders > 1
while iterations < #tools[var.thisTool].extruders
set var.allExtruders[iterations] = iterations ^ ""
M291 P"Select extruder" S4 K{var.allExtruders} F0
set var.thisExtruder = input
var thisFilament = move.extruders[tools[var.thisTool].extruders[var.thisExtruder]].filament
var newFilament = null
if var.maxBtns > 10
set var.maxBtns = 10
echo "Paneldue can only display 10 buttons in total"
echo "Max buttons has been reset"
var thisPage = vector(var.maxBtns,"")
var numPages = floor(#var.filaments / (var.maxBtns - 1))
if mod(#var.filaments , var.maxBtns - 1) > 0
set var.numPages = var.numPages + 1
var pagesDone = 0;
var btnsDone = 0
var nextFilament = ""
var nextItem = 0
while var.pagesDone < var.numPages
set var.thisPage = vector(var.maxBtns,"")
set var.btnsDone = 0
while var.btnsDone < var.maxBtns-1
set var.nextItem = iterations + (var.pagesDone * (var.maxBtns-1))
if var.nextItem = #var.filaments
break
set var.thisPage[var.btnsDone] = var.filaments[var.nextItem]
set var.nextFilament = var.filaments[var.nextItem]
set var.btnsDone = var.btnsDone + 1
if var.pagesDone = var.numPages - 1
set var.thisPage[{var.maxBtns-1}] = "Cancel"
else
set var.thisPage[{var.maxBtns-1}] = "Next"
set var.pagesDone = var.pagesDone + 1
M291 P"Select filament" S4 K{var.thisPage}
if input = var.maxBtns-1
continue
else
set var.newFilament = var.thisPage[input]
break
if (var.newFilament = null) || (var.newFilament = "")
abort "No filaments chosen"
else
echo "Filament chosen : ", var.newFilament, " : commence change"
; M701 only works if the tool only has one extruder
; If more than one extruder is present on the tool, we'll directly call the macros for load, unload and config
; It's unclear if the filament will be marked as loaded in DWC after this approach.
if var.newFilament = "noFilament"
if #tools[var.thisTool].extruders > 1
M98 P{directories.filaments ^ var.newFilament ^ "/load.g"} S{var.thisExtruder}
M98 P{directories.filaments ^ var.newFilament ^ "/config.g"} S{var.thisExtruder}
else
M701 S{var.newFilament}
if result != 0
abort "Error during loading"
M703
else
if (var.thisFilament != "noFilament") && (var.thisFilament != null)
if #tools[var.thisTool].extruders > 1 ; M701 only works if the too only has one extruder
M98 P{directories.filaments ^ var.newFilament ^ "/unload.g"} S{var.thisExtruder}
M98 P{directories.filaments ^ var.newFilament ^ "/load.g"} S{var.thisExtruder}
M98 P{directories.filaments ^ var.newFilament ^ "/config.g"} S{var.thisExtruder}
else
M702
M701 S{var.newFilament}
if result != 0
abort "Error during loading"
M703
From the docs..,
The H parameter defines the Z probe dive height, which is the height above the trigger height from which probing starts. The default is 3mm or 5mm depending on firmware version. You may wish to increase it during initial calibration. When using mesh bed compensation or running G30 commands with specified XY coordinates (for example from the bed.g file), the firmware moves the Z probe to this height above where it expects the bed to be before commencing probing. The maximum depth of probing from this position is twice the dive height.
I think you'll find on straight G30 Z home, the dive height is ignored as the height is unknown.
Otherwise you would never be able to home from any height.
About the best you can do is check for typical errors before you start using the object model.
I use this macro which is called before any Z homing or bed leveling
check BL Touch
var probeOK = true
if sensors.probes[0].value[0]=1000 ; if probe is in error state
set var.probeOK = false
echo "Probe in error state- resetting"
M280 P0 S160 ; reset BL Touch
G4 S0.5
if state.gpOut[0].pwm < 0.05
set var.probeOK = false
echo "Probe is already deployed - retracting"
M98 P"0:/sys/retractprobe.g"
G4 S0.5
if sensors.endstops[2].triggered
set var.probeOK = false
echo "Probe is already triggered - resetting"
M280 P0 S160 ; reset BL Touch
G4 S0.5
I also use this check in my homeall.g to cancel the print if any errors occur during homing
Any successful command should return a value of 0
G30 ; home Z by probing the bed
if result !=0
abort "Print cancelled due to probe error"
Outside that, you'd have to have a secondary switch, pressure sensor or similar attached I'd think.
@dc42
I have attached the config.g and the other macros called.
Also the filament config.g as that is where I am setting pressure advance if that's relevant.
config(ABS).g
set_max_speeds.g
config.g
setInputShaping.g
config-override.g
daemon.g
@curieos
I've found that if you have much going on in daemon.g the any "songs" will be very erratic in behaviour.
I have a variable at the start of daemon.g which allows me to temporarily skip it, which helps, but doesn't make it perfect.
I suspect there's so much going on in the firmware now that's taking up cycles that M300 will not be useful for much more than single tones.
Just had this error occur again.
It's not 100% repeatable as I've had it fail twice on the same print (with two firmware versions) but print successfully the next try.
Both failures were 5-6 hours into the print.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-beta.1 (2024-09-24 10:07:04) running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F2MS4-7J1DA-3S86T-TZTWD
Used output buffers: 10 of 26 (26 max)
=== RTOS ===
Static ram: 23360
Dynamic ram: 71876 of which 12 recycled
Never used RAM 8860, free system stack 100 words
Tasks: NETWORK(2,nWait 6,15.7%,181) ACCEL(6,nWait 5,0.0%,345) HEAT(3,nWait 5,0.1%,307) Move(4,invalid,3.6%,266) MAIN(1,running,80.1%,630) IDLE(0,ready,0.5%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 09:14:16 ago, cause: software
Last software reset at 2024-09-22 17:49, reason: User, Gcodes spinning, available RAM 22200, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x1c
Aux0 errors 0,0,0
MCU temperature: min 19.6, current 26.3, max 26.7
Supply voltage: min 0.4, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/22, heap memory allocated/used/recyclable 2048/596/212, gc cycles 945
Events: 0 queued, 0 completed
Date/time: 2024-09-28 16:07:45
Slowest loop: 1122.06ms; fastest: 0.10ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 13.0ms, write time 417.1ms, max retries 0
=== Move ===
Segments created 582, maxWait 3825401ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0 (0.00ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 8937.00/8893/0.97 7099.00/7144/-0.16 48408.00/48408/0.00
no step interrupt scheduled
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min 201
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min 228
Driver 5:
Driver 6:
Driver 7:
Driver 8:
Driver 9:
Driver 10:
Driver 11:
=== DDARing 0 ===
Scheduled moves 2520037, completed 2520035, LaErrors 0, Underruns [21, 0, 0]
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 3
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is doing "G4 S2" in state(s) 0 0, running macro
Autopause is idle in state(s) 0
Q0 segments left 9
Code queue 0 is empty
=== Filament sensors ===
check 107327487 clear 16019414
Extruder 0 sensor: ok
=== Network ===
Slowest loop: 1253.54ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(4) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1.0
MAC address bc:dd:c2:89:a0:bb
Module reset reason: Power up, Vcc 3.38, flash size 4194304, free heap 40588
WiFi IP address 192.168.1.163
Signal strength -41dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
EDIT
One difference this time is that when I shut the power off, no resurrect.g was created, so it looks like I've lost this print.
Now the print is finished I have just tested sending G94 from the command line and it gives no errors, so I've answered that half of the question.
Whilst recovering from a power outage I got an error message saying something like
"Missing or bad parameter"
Whilst searching for a possible cause I noticed that resurrect.g contains G94, which according to the docs is CNC specific
G94: Feed Rate Mode (Units per Minute)
CNC specific. Supported from firmware version 3.5
Parameters
No additional parameters
Should this command be there and would it cause that error in FFF mode?
; Resume printing file "0:/gcodes/teaser float v9_0.2mm_ABS.gcode" after print paused at 2024-09-22 14:38
M140 P0 S100.0
G29 S1
M568 P0 A2 S260 R215
M486 S0 A"teaser float v9"
G21
M98 P"resurrect-prologue.g" X79.673 Y147.873 Z101.620
M290 R0 X0.000 Y0.000 Z0.000
; Workplace coordinates
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
M486 S0
T0
G54
M106 S0.00
M116
G92 E0.00000
M83
G94
G17
M23 "0:/gcodes/teaser float v9_0.2mm_ABS.gcode"
M26 S19492739
G0 F6000 Z103.620
G0 F6000 X79.673 Y147.873
G0 F6000 Z101.620
G1 F3732.2 P0
M204 P50000.0 T50000.0
G21
M106 P0 S0.00
M302 P0
M24
I have just had the same error about 3 hours into a 5 hour print.
22/09/2024, 1:55:16 pm Error: Movement halted because a step timing error occurred (code 3). Please reset the controller.
Duet 2 WiFi 3.6.0-alpha.5+1
M122 after error
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-alpha.5+1 (2024-08-31 17:50:58) running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F2MS4-7J1DA-3S86T-TZTWD
Used output buffers: 7 of 26 (24 max)
=== RTOS ===
Static ram: 23360
Dynamic ram: 72224 of which 12 recycled
Never used RAM 8368, free system stack 106 words
Tasks: NETWORK(2,nWait 6,16.3%,202) ACCEL(6,nWait 5,0.0%,345) HEAT(3,nWait 5,0.1%,315) Move(4,invalid,3.3%,266) MAIN(1,running,79.8%,672) IDLE(0,ready,0.5%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 05:49:08 ago, cause: software
Last software reset time unknown, reason: User, Gcodes spinning, available RAM 19896, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x08
Aux0 errors 0,2,0
MCU temperature: min 23.6, current 31.4, max 31.9
Supply voltage: min 1.1, current 24.3, max 24.6, under voltage events: 1, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/22, heap memory allocated/used/recyclable 2048/1704/1320, gc cycles 572
Events: 0 queued, 0 completed
Date/time: 2024-09-22 14:34:22
Slowest loop: 451.79ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 10.1ms, write time 97.4ms, max retries 0
=== Move ===
Segments created 588, maxWait 153529ms, bed comp in use: mesh, height map offset 0.000, hiccups added 276 (8.29ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 6390.00/6368/0.76 14761.00/14757/0.70 40648.00/40648/0.00
no step interrupt scheduled
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min 241
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min 228
Driver 5:
Driver 6:
Driver 7:
Driver 8:
Driver 9:
Driver 10:
Driver 11:
=== DDARing 0 ===
Scheduled moves 1473967, completed 1473965, LaErrors 0, Underruns [9, 0, 0]
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X80.404 Y147.896 E.00085" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is doing "G4 S2" in state(s) 0 0, running macro
Autopause is idle in state(s) 0
Q0 segments left 1
Code queue 0 is empty
=== Filament sensors ===
check 79464683 clear 1287376
Extruder 0 sensor: ok
=== Network ===
Slowest loop: 117.01ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1.0
MAC address bc:dd:c2:89:a0:bb
Module reset reason: Power up, Vcc 3.38, flash size 4194304, free heap 38948
WiFi IP address 192.168.1.163
Signal strength -52dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 4 5 0 0 0 0 0 0
EDIT:
Of interest to anyone testing , I think I've saved the print by turning off the power and recovering from power failure.
@amimafe
The firmware essentially already does that.
You just need to monitor your extruder and trigger a pause when it's not extruding.
As you've given no details on what you're "extruding" or how you're doing it, it's impossible for anyone to offer any more than equally vague answers.
There is no facility in RRF currently to reverse along previous moves to a point.
That would be the domain of external software which streams gcode to the duet in individual strings.
It is relatively common in plasma cnc cutting controllers for example, but there is no extrusion at play there.
You can use the object model to get the current file position in bytes, but I don't see any way in a macro to extract lines from the job file and pass them as movement commands.
You also have the issue of having to work out what to do with the extruder moves. Do you want the extruder reversing at each move?
What about I/O's, fan or heater commands?
Far better to identify a fault and pause immediately as is already implemented.
The list of object model values is at
https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation
The list of meta commands is at
https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands
You should be able to use state.machineMode
in the object model.