This is not a problem, but more of a kudo's!
I had just recently purchased the Magnetic Filament sensor for one of my extruders and was working on calibration. I had a fairly long (12 hour) print going. During the print, the sensor kept telling me the extrusion amount was low. At first, I thought it was something I was doing. I kept checking the sensor and the machine. Finally, I ran a print where it wasn't extruding anything. It appears my extruder motor was going out slowly. Every time I looked it was working, but when I walked away it stopped.

I replaced the motor and everything was running smoothly again! So glad I purchased this, will be getting more in the future!

I just went ahead and updated to 3.0 (2020-01-03b3) and everything is working so far. Probably just a bug or bad update, because it was working before and after the 2.05.1 update.

@fcwilt

I am running v3.3, eagerly awaiting a stable 3.4 with the accelerometer.
I don't recall why I used M98, but I think it was due to an issue with calling G28 a few versions ago and never changed it back.

As I have been looking into this more, it may be related to a specific print file. I never had this problem before. However, a specific print had some GCode that specified the hot-end change temps for extruder 1 (T1) at the time of tool change. This was actually a problem as it was setting my "cooldown" temps to the active extruder, but it immediately set the working temp after. When it would pause and then I hit resume it would sometimes show the correct working temps, but other times not.
I manually went through the GCode to fix this problem rather than re-slicing and uploaded to the Duet. It ran through the entire print without a hitch. Once I get enough of the parts pushed out I will attempt to go back to the unmodified GCode and see if it actually had anything to do with the G10 codes occurring in succession or if the code was just messed up. OR look for Gremlins...

The GCode I removed throughout the file was as follows:

G10 P0 S210
G10 P0 S240

and

G10 P1 S210
G10 P1 S245

@fcwilt

Well that was a simple trick. I put a small calibration square on the bed to the right side and it quickly polled it. Definitely showing it on the correct side.

So not sure what direction to go from here. I know my probe is good, but the results of the mesh compensation isn't.

@fcwilt
I'm not sure if you saw my comment, but I have performed the procedure. I didn't drag the head across the bed, but rather my feeler gauge. The result was there was a gap at the end as I expected. Rather that was coming from the gantry or the bed height I could not tell you, but there was a variation in the height from when it started to when it finished.

I'm not sure if your goal in this was to prove there was variation in the bed or that mesh leveling had been turned off successfully. I know that my bed leveling measures at X180 Y200 and my typical measuring point is X200 Y200, and have tested the gap at both locations with and without the mesh compensation engaged. Each time I get the same result.

If it seems that I'm not providing you the feedback you are looking for, I may just be miss understanding the intended goal or I may not be describing it correctly?

@fcwilt
I think this issue is related to a failing Z-Axis motor. I heard a noise once when letting things sit idle earlier today which resulted in an obvious deviation in the Z-Level. I thought this might be due to the motors going idle and possibly the bed falling. Normally with power off, I don't get more than 0.08 of drift between the two lead screws.

However, I was printing just a moment ago and hit the pause button, but when I resumed I heard that noise again when the bed was lifting. So instead of continuing, I paused again and moved the X-Gantry to dead center between the lead screws and measured with my calipers from the top of the rails on either side with an approximately 2.3 mm deviation.

I'm really hoping this is the root cause. They are the original motors operating for over 4 years on my inexpensive starter kit!
I have to take a bit of it apart to get after them so that will have to wait until next weekend, time permitting!

@fcwilt

Going with where you are headed I did 3 heightmaps. All will use the same points and were done with the bed at 70°C.

Map1
Normal height map

 -0.050, -0.086,  0.053
  0.067,  0.007,  0.090
  0.251,  0.020, -0.019

Map2
Normal level with 0.8 feeler gauge put in after in the middle:

 -0.031, -0.124, -0.038
  0.061,  0.836, -0.013
  0.242, -0.035, -0.120

Map3
0.8 feeler gauge in place when G30 performed:

 -0.927, -0.969, -0.847
 -0.833, -0.004, -0.807
 -0.653, -0.874, -0.904

Now taking a look at just the difference between Map1 and Map2 we can see the obvious and expected difference at the middle point. I am a little plagued by the right values being nearly 0.1mm difference. I now wonder if this is my probe or my hardware.

When I run my Dial Guage out from the middle I get a negative value of ~ -0.14 after setting its Z-0 at my middle probing point. This is about what I expect based on my manual leveling.

https://youtu.be/GCf9Ta9aJSo

@fcwilt

Thank you for your help up until now. I'll continue to do some testing later this week to see if this is motor-related.

I got my Lead Screws from ZYLTech a few years ago. Never thought to look at McMaster. I suspect if there were variations I should see those in my layer lines, which I don't normally have an issue with since upgrading to these. However the anti-backlash nuts are brass and could have some play. I do my best to keep them greased.

I am thinking there may be some play in my Tool Carrier. I know that I can get flex up to 0.14mm when I put some pressure on it, but it does want to return back to 0. Today looking into this further I dove the tool into the bed and found it didn't want to return to its normal height. So I docked and undocked it and picked it up again, the tool height was back to normal. I'm suspecting that it's shifting in the kinematics and even though it's a ball bearing and has no scoring it's not able to return. This would not explain the BLTouch variation, but maybe a factor when it comes to printing.

@dc42 That's an interesting idea. I do have io3 available on each board that I could put to some use.

I'm just curious if it's plausible to store a tool's configuration file on the Duet Toolboard itself through the DWC?

While I know I can have several configurations stored on the duet SDCard, I'm moving to streamline my toolsets. There are situations where I might pull a tool out, say a "Revo6," and swap in a tool such as a Mosquito into the same location. While I could utilize a different CAN address, the complication comes with determining which tool slot it's in specifically.
Without having to add more hardware to detect tools in the slot. I thought it might work to be able to pull the config straight from the tool and utilize the CAN addresses to assign the tool numbers accordingly.

I'm already detecting if a tool is loaded successfully using a TCRT5000 on my tool changer so it seems a bit overkill to have to now detect the tool in the tool slot. But that might be the next direction I go.

@dc42 Tracking the syntax. However with the example at the bottom of the page not following the syntax it's not clear, so I thought it worth reporting such that either the "Examples of Use" section or the syntax would be updated.

Saving and restoring variables across a reset

• persistentGlobal.g
• loadPersistentGlobal.g

@gloomyandy Stand-alone mode.

I was working with the echo syntax to incorporate the ">" & ">>" capabilities and was using the persistentGlobal.g file identified in the "GCode Meta Commands. However, when executing the file I receive the error:

Error: in file macro line 6 column 7: meta command: expected a string expression

file: _TestVar1

M98 P"/sys/scripts/persistentGlobal.g" V"testVar" X"one"

After some back-and-forth, I found the root cause to be that the example had a space the ">" Removing the space resolved the problem. I only noticed this after looking at the earlier examples in the documentation which did not have the additional space where the filename was being provided.

Old code:

var id = param.V                    ; name of the global variable
var value = param.X                 ; value to save
var filepath = "globals/"^{var.id}  ; internal file path where the global variable is saved

; Save the global variable as a file so it is persistent
echo > {var.filepath} "if exists(global."^{var.id}^")"
echo >> {var.filepath} "    set global."^{var.id}^" = "^{var.value}
echo >> {var.filepath} "else"
echo >> {var.filepath} "    global "^{var.id}^" = "^{var.value}

M98 P{var.filepath} ; load the global variable

Working code:

var id = param.V                    ; name of the global variable
var value = param.X                 ; value to save
var filepath = "globals/"^{var.id}  ; internal file path where the global variable is saved

; Save the global variable as a file so it is persistent
echo >{var.filepath} "if exists(global."^{var.id}^")"
echo >>{var.filepath} "    set global."^{var.id}^" = "^{var.value}
echo >>{var.filepath} "else"
echo >>{var.filepath} "    global "^{var.id}^" = "^{var.value}

M98 P{var.filepath} ; load the global variable

I just thought I'd pass this along.

Using v3.6 rc1 & rc2 both produced the error.

@droftarts
There is a sticker right under that driver.

This was a brand new board, but puchased in August 2024. I believe this might have been my fault. When creating my initial power cable to the Tool Distribution board about a month ago and got the PINs reversed in the circuit layout. I immediately powered off and reversed things at one end and plugged it in and didn't notice any issues. At least not until now...

None of the other boards had this issue since I had updated the build guide for those circuits.

@Gamefanatic3D
Okay so I'm certain the driver is blown by the look in this picture.

Swapped out the board, and now to the next problem I'm sure I will have!

I knew I'd figure it out once I asked for help!

@Gamefanatic3D
Okay, so I went through and tested each 1LC board without them all connected at the same time. It appears the issue is only with the (21.0) board. The other boards (22.0, 23.0) all work to include (20.0) which is running the tool head.

I believe this may be an issue with the single board. Does this sound like a hardware issue?

I'll swap out this board soon to validate my assumption.

I am standing up a Duet3 Mini 5+ and 3 x 1LC (v1.3) boards that are connected to Obriter 2.0 extruders.

I'm banging my head against the printer trying to figure out what I am missing here.

I am unable to get the Orbiter motor to engage when connected to the 1LC. If I connect the motor to an open driver on the Duet (driver 0.4) I can get it to engage.

I am running the following Macro to test the motor operations:

M302 P1
T0 P0

echo "Begin Move"
G1 E100 F100
echo "End Move"

T-1 P0
M302 P0

When doing this with the motor connected to (0.4) on the Mini I see the motor turn. However, when I put the motor back to the 1LC (21.0) and execute the macro above I see the system show "Busy" in the web browser, but the motor never turns.

I've tried unplugging the motor and getting the same effect, the system never tells me any errors or wiring problems when on (21.0), but when on (0.4) it returns the expected error:

Warning: Driver 0.4 warning: phase A may be disconnected, phase B may be disconnected

I attempted to probe the B- & B+ / A- & A+ terminals after executing the Macro above on while connected to (21.0) I see no voltage. When I perform the same test with the motor connected to (0.4) I can see voltage.

I don't have everything configured on the 1LC, but so far I have validated all the other components are working so I know that the board is still good (same issue across 3 x 1LC's so far).

Any suggestions on what I can do to get some feedback from the 1LC as to why it's not working?

Below is the diagnostics right after attempting a move while the motor is connected to (21.0)

M122 B21
Diagnostics for board 21:
Duet TOOL1LC rev 1.1 or later firmware version 3.6.0-rc.1 (2025-02-28 15:03:36)
Bootloader ID: SAMC21 bootloader version 2.8 (2023-07-25)
All averaging filters OK
Never used RAM 7528, free system stack 94 words
Tasks: Move(3,nWait 7,0.0%,96) TMC(2,nWait 6,0.5%,52) HEAT(2,nWait 6,0.3%,112) CanAsync(5,nWait 4,0.0%,58) CanRecv(3,nWait 1,0.0%,70) CanClock(5,nWait 1,0.0%,58) ACCEL(3,nWait 6,0.0%,72) MAIN(1,running,94.4%,318) IDLE(0,ready,0.0%,26) AIN(2,delaying,4.8%,112), total 100.0%
Owned mutexes:
Last reset 00:11:33 ago, cause: power up
Last software reset data not available
Moves scheduled 1, hiccups 0 (0.00/0.00ms), segs 3, step errors 0 (types 0x0), maxLate 0 maxPrep 95, ebfmin 0.00 max 0.00
Peak sync jitter -3/8, peak Rx sync delay 212, resyncs 0/0, no timer interrupt scheduled, next step interrupt due in 3867598156 ticks, disabled
VIN voltage: min 24.3, current 24.4, max 24.4
MCU temperature: min 20.4C, current 36.4C, max 36.4C
Driver 0: pos 68999, 690.0 steps/mm, not present
Last sensors broadcast 0x00000002 found 1 173 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 13892, send timeouts 0, received 6086, lost 0, ignored 0, errs 0, boc 0, free buffers 18, min 18, error reg 0
dup 0, oos 0/0/0/0, rxMotionDelay 292, adv 37067/37067
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 3, contentions 0, other errors 0

config.g (while connected to 1LC)

G90                     ; absolute coordinates
M83                     ; relative extruder moves
M911 S19.8 R22 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; set voltage thresholds and actions to run on power loss


;;;;;;;;;;;;;;;;;;;
;;;   Network   ;;;
;;;;;;;;;;;;;;;;;;;
M552 S1     ; configure WiFi adapter
M586 P0 S1  ; configure HTTP

;;;;;;;;;;;;;;;;;;;;;;;;;
;;;   Smart Drivers   ;;;
;;;;;;;;;;;;;;;;;;;;;;;;;
M569 P0.0 S0 D2     ; driver 0.0 goes forwards (Z0 axis)
M569 P0.1 S0 D2     ; driver 0.1 goes forwards (Z1 axis)
M569 P0.2 S1 D2     ; driver 0.2 goes forwards (X axis)
M569 P0.3 S1 D2     ; driver 0.3 goes forwards (Y axis)
M569 P20.0 S0 D3 V4000   ; Tool Changer

; Motor Idle Current Reduction
M906 I30            ; set motor current idle factor
M84 S30             ; set motor current idle timeout

;;;;;;;;;;;;;;;;
;;;   Axes   ;;;
;;;;;;;;;;;;;;;;
M584 X0.2 Y0.3 Z0.0:0.1                 ; set axis mapping
M350 X16 Y16 Z16 I1                     ; configure microstepping with interpolation
M906 X800 Y800 Z800                     ; set axis driver currents
M92 X200.0157 Y200.0157 Z1601.584008    ; configure steps per mm
M208 X0:427 Y0:410 Z0:380               ; set minimum and maximum axis limits
M566 X900 Y900 Z12                      ; set maximum instantaneous speed changes (mm/min)
M203 X6000 Y6000 Z180                   ; set maximum speeds (mm/min)
M201 X500 Y500 Z20                      ; set accelerations (mm/s^2)

; Tool Changer Start (C-Axis) ;
M584 C20.0              ; Set Axis Motor
M906 C400               ; Set Motor Currents (mA)
M350 C8 I0              ; Set Interpolation
M92 C100                ; Set Microstepping
M201 C500               ; Set Accellerations
M203 C5000              ; Set Maximum speed (mm/min)
M566 C2                 ; Set maximum instantaneous speed changes (mm/min)
M208 C0:240             ; Set axis Min/Max travel
;M915 C S3 F0 H200 R0    ; Stall Detection
; Tool Changer End ;

; Kinematics
M669 K1 ; configure CoreXY kinematics

M575 P1 B115200 S1						  ; PanelDue communications

;;;;;;;;;;;;;;;;;;
;;;   Probes   ;;;
;;;;;;;;;;;;;;;;;;
; Z-Axis (BLTouch)
M558 K0 P9 C"20.io0.in" H5 F120 T6000 ; configure BLTouch probe via slot #0
G31 P500 X0 Y0 Z0.7                   ; set Z probe trigger value, offset and trigger height
M950 S0 C"20.io0.out"                 ; create servo #0 for BLtouch
; Z-Axis End

;; Sensor to right (negative X) of hotend
G31 P25 K0 X31.75 Y-34.4 Z0.90		; Z probe trigger value, offset in relation to nozzle. Larger trigger brings hotend closer to bed.
M557 X40:360 Y40:340 S40			; Define mesh grid Offset X to account for Z-Trigger.


;;;;;;;;;;;;;;;;;;
;;;  Endstops  ;;;
;;;;;;;;;;;;;;;;;;
;M574 X1 S3                 ; configure X axis endstop
;M574 Y1 S3                 ; configure Y axis endstop
M574 X1 S1 P"!20.io1.in"    ; X-Axis Switch High Trigger
M574 Y1 S1 P"io6.in"        ; Y-Axis Switch High Trigger
M574 Z1 S2                  ; Z-Axis end stop is probe.

;;;;;;;;;;;;;;;;;;;
;;;   SENSORS   ;;;
;;;;;;;;;;;;;;;;;;;
M308 S0 P"temp0" Y"thermistor" A"Heated Bed" T100000 B4725 C7.06e-8 ; configure sensor #0
M308 S10 Y"mcu-temp" A"MCU"

M950 J0 C"!20.io3.in"        ; Tool Optical Sensor



;;;;;;;;;;;;;;;;;;;
;;;   Heaters   ;;;
;;;;;;;;;;;;;;;;;;;
M950 H0 C"out0" T0 ; create heater #0
M143 H0 P0 T0 C0 S140 A0 ; configure heater monitor #0 for heater #0
M307 H0 R2.43 D5.5 E1.35 K0.56 B1 ; configure model of heater #0
G4 S1

; Heated beds
M140 P0 H0 ; configure heated bed #0


;;;;;;;;;;;;;;;;;
;;;   Tools   ;;;
;;;;;;;;;;;;;;;;;

;; Tool0 ;;
; !!! DEFINE MOTOR FOR EXTRUDER !!!

M584 E21.0      ; set extruder mapping
M906 E1000 I10
M350 E16 I1     ; configure microstepping with interpolation
; NOTE: See Smart Drivers section for motor currents
M92 E690        ; configure steps per mm
M566 E300       ; set maximum instantaneous speed changes (mm/min)
M203 E7200      ; set maximum speeds (mm/min)
M201 E3000      ; set accelerations (mm/s^2)

;; TEMP SENSOR
M308 S1 P"21.temp0" Y"thermistor" A"Nozzle" T100000 B4725 C7.06e-8  ; configure sensor #1
;M308 S2 P"21.temp1" Y"thermistor" A"Tool0_Temp_Extruder" T100000 B4725 C7.06e-8        ; configure sensor #1

;; Heater
M950 H1 C"21.out0" T1             ; create heater #1
M143 H1 P0 T1 C0 S285 A0          ; configure heater monitor #0 for heater #1
M307 H1 R2.43 D5.5 E1.35 K0.56 B0 ; configure model of heater #1

;; FANS
;;; Tool Fan
M950 F0 C"21.out2"     ; create fan #0
M106 P0 S0 B0.3 H1 T45 ; configure fan #0

;;; Extruder Fan
;M950 F1 C"21.out1"                            ; create fan #1
;M106 P1 C"Tool0_Fan_Extruder" S0 L0 X1 B0.1 H2 T45 ; configure fan #1
;;; Extruder Fan

;; Create Tool0
M563 P0 D0 H1 ; create tool #0
M568 P0 R0 S0    ; set initial tool #0 active and standby temperatures to 0C


;; Tool0 End ;;
;M98 P"/sys/CAN_22.g"
;M98 P"/sys/CAN_23.g"

; Miscellaneous
M501 ; load saved parameters from non-volatile memory

;M98 P"/sys/custom_global_vars.g"

I was running v3.5.4, but upgraded to 3.6.1 rc1 last night in an attempt to see if maybe it was just a bug, but no change.

@T3P3Tony I'm in the process of converting that machine from a Duet2 Wifi to Duet3. I'm conceding I've gone beyond the limits of a Duet2 and looking to move to 5 tools, plus filament box sensors and possibly even filament changers. I'll test once I get it FoC, but I can't guarantee when that will be with my hectic schedule.