Posts made by Gamefanatic3D

@dc42 Let me know if you need anything from me. I realize I am probably apart a small few experiencing this issue.

@dc42 Wow, thank you for the second pair of eyes on this. Yes, it was stuck in the tconfig0.g. Putting the M400 just before the M98 command to load my configs is working!

I tested a bit further tonight on this. I ran a Debug log file and added a "M118 P3" in my Pickup macros so I can tell when they execute. I can confirm that it's not making it to the Pickup macro, but the Debug log shows an M568 P0 A2 which tells me it's executing the tpre0.g file. I cannot say as of yet if it's making it to tpost0.g. Will test further when I get a moment.

@chrishamm Changing AJAX to 5 seems to have worked.

@chrishamm Yes, I have a PanelDue. I don't know if it matters, but I am utilizing the CONN_LCD.3 for one of my MFM's.

I did increase the AJAX to 3 before, but I suppose I didn't go high enough. I'll set it to 5 and see how things go.

Updated to v3.5.1 again.

I ran the attached sliced file and it makes it all the way through to the second T0 (line 1637). Heaters all reach their nominal temperatures, even though my Macro's M116 is only looking at the T0 before it wants to pick it up. The bed will lower, but will not go further.

10x10x10_Cube-T0T1T2-S3D.gcode

• I cannot pause the print.
• M108 does nothing
• M25 - From Web just hangs waiting for a response from the printer.
• From the Web Control:
  • I can navigate around and send some commands IE) M122
  • I can upload a Macro and edit files
  • I can click the "Emergency Stop"
• From the PanelDue
  • I cannot pause the print
  • I can move around / navigate
  • I can execute Macro's
  • I can change the temperatures of all the tools / bed.
  • I can click the stop button.

5/5/2024, 2:58:24 PM	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.1 (2024-04-19 14:40:46) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S8-6J1F8-3SJ6S-1BL7H
Used output buffers: 3 of 26 (26 max)
=== RTOS ===
Static ram: 23256
Dynamic ram: 78496 of which 28 recycled
Never used RAM 7932, free system stack 108 words
Tasks: NETWORK(1,ready,12.6%,202) HEAT(3,nWait 5,0.2%,309) Move(4,nWait 5,0.4%,258) DUEX(5,nWait 5,0.0%,24) MAIN(1,running,86.7%,747) IDLE(0,ready,0.1%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:17:34 ago, cause: software
Last software reset at 2024-05-05 14:40, reason: User, Gcodes spinning, available RAM 8748, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
MCU temperature: min 41.8, current 46.1, max 46.5
Supply voltage: min 23.8, current 24.2, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/51, heap memory allocated/used/recyclable 2048/1348/140, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 167
Driver 1: standstill, SG min 119
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min 0
Driver 5: standstill, SG min 0
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min 0
Driver 8: standstill, SG min 0
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
Date/time: 2024-05-05 14:58:23
Cache data hit count 4294967295
Slowest loop: 241.50ms; fastest: 0.16ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 2.0ms, write time 5.2ms, max retries 0
=== Move ===
DMs created 83, segments created 24, maxWait 497256ms, bed compensation in use: mesh, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 1.00
no step interrupt scheduled
Moves shaped first try 150, on retry 35, too short 65, wrong shape 408, maybepossible 0
=== DDARing 0 ===
Scheduled moves 735, completed 735, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== 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.5
=== GCodes ===
Movement locks held by File
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 8
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is doing "G10 P0 X-6.71" in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Queue 0 has 'G10 P0 Y35.17' for move 735
Queue 0 has 'G10 P0 Z-1.55' for move 735
=== Filament sensors ===
check 7281348 clear 2324874
Extruder 0: pos 2469.73, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
Extruder 1: pos 13973.55, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
Extruder 2: pos 2390.27, errs: frame 0 parity 0 ovrun 0 pol 14549 ovdue 0
=== DueX ===
Read count 1, 0.06 reads/min
=== Network ===
Slowest loop: 131.31ms; 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 cc:50:e3:14:e3:17
Module reset reason: Turned on by main processor, Vcc 3.32, flash size 4194304, free heap 39504
WiFi IP address 192.168.0.90
Signal strength -48dBm, channel 2, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

@gloomyandy

Using the Duet2 Wifi + DUEX5. Hopefully, things are updated a bit better. The forum code interpreter seems to be having issues with some of the code I pasted and not giving it proper formatting.

The "tactive.g" file is generated by the "pickup.g" when a tool has been successfully picked up and deleted when it has been successfully returned. I use it in lieu of a switch on the tool to detect if a tool is loaded.

I'll upload an M122 once I get a chance to swap back to the 3.5.1 firmware and run through the paces again.

I upgraded to v3.5.1 from v3.4.5. When I attempt a test print utilizing multiple tools and find that at some point during the print when changing tools it hangs. At first, I thought it was due to waiting on a heater, but I could not reproduce the issue when manually changing tools. It only occurs when attempting to print.

When I revert to v3.4.5 I have no issues with the same prints.

Here is an example of one of my tool-changing scripts. I have been able to reproduce the issue with T0 and T2 (did not test against T1).

SYS Files

tfree0.g

; tfree0.g

; Runs at the start of a toolchange if the current tool is tool-0.
; Note: tool offsets are applied at this point unless we preempt commands with G53!
; called when tool 0 is freed
;
; Move Z out of way.
G91              ; relative positioning
G1 Z5 F6000 H2   ; lift Z relative to current position
G90              ; absolute positioning

M98 P"/macros/Tools/T0/Drop" ; Drop Tool

G91              ; relative positioning
G1 Z-5 F6000 H2  ; lift Z relative to current position
G90              ; absolute positioning

;fan off
M106 P1 S0

; Disable Filament Monitor
M591 D0 P3 c{global.tool0_mfm_PIN} S0	; Duet3D rotating magnet sensor disabled


; Clear Tool Specific variables
set global.currentTool_fan = ""

tpost0.g

; tpost0.g

; called after tool 0 has been selected
;
M703		; Load filament configuration

; Squeeze Filament out.
M116 P0 S3
M98 P"/sys/prime.g"

; Pickup Tool
M98 P"/macros/Tools/T0/Pickup"

; restore print cooling fan speed
;M106 P1 R2
M106 P1 S{state.restorePoints[2].fanPwm}

if global.restoreToolPosition = 1
	G0 R2 X0 Y0 F7000 ; Restore to X and Y position prior to tool change
	
G1 R2 Z0                     ; Restore prior Z position before tool change was initiated.
                             ; Note: tool tip position is automatically saved to slot 2 upon the start of a tool change.
                             ; Restore Z first so we don't crash the tool on retraction.
G1 E{tools[{state.currentTool}].retraction.length} ; Prime Nozzle.

tpre0.g

; tpre0.g

; called before tool 0 is selected
;
; Check if we have another tool selected
; Is this even necessary with our tool detection script in play?

M98 P"/sys/thome_check.g"

G60 S0 ; Save Current Position to Slot 0


;;;;;;;;;;;;;;;;;;;;;
;; FILAMENT SENSOR ;;
;;;;;;;;;;;;;;;;;;;;;
; Duet3D rotating magnet sensor extruder drive 0 is connected to E0, enabled, sensitivity 24.8mm.rev, 70% to 130% tolerance, 3mm detection length 'agc' of 50 to 105
if {global.tool0_mfm_defaults} == false
  M591 D0 P3 c{global.tool0_mfm_PIN} S{global.tool0_mfm_S} R{global.tool0_mfm_R_min}:{global.tool0_mfm_R_max} L{global.tool0_mfm_L} E{global.tool0_mfm_E}
else
  M591 D0 P3 c{global.tool0_mfm_PIN} S1 R20:180 L25.0 E3.0	

;;;;;;;;;;;;;;;;;;;;;;
;;  Tool Variables  ;;
;;;;;;;;;;;;;;;;;;;;;;
set global.currentTool_fan = 1

;;;;;;;;;;;;;;;;;;;;;;
;;    Load Tool     ;;
;;;;;;;;;;;;;;;;;;;;;;
; Turn on heater
if tools[0].active[0] > 0
  M568 P0 A2
elif tools[0].standby[0] > 0
  M568 P0 A1

; Wait for set temperatures to be reached
M116 P0 S2

; Note that commands preempted with G53 will NOT apply the tool offset.
if move.axes[2].machinePosition < abs(tools[0].offsets[2])
  G1 Z{(abs(tools[0].offsets[2])+5)}

; Load T0 Configuration
M98 P"/sys/tconfig0.g"

tconfig0.g

; tconfig0.g

; Retraction
M207 P0 S0.50

;; OFFSET
;; X ;;
; Set tool 0 axis offsets for X coordinate
G10 P0 X-6.71

;; Y ;;
; Set tool 0 axis offsets for Y coordinate
G10 P0 Y35.17

;; Z ;;
; Set tool 0 axis offsets for Z coordinate
G10 P0 Z-1.55

prime.g

; prime.g

if {global.primeTool}!=0
  G92 E0
  G1 F200
  G1 E10 F100
  M106 P{global.currentTool_fan} S255
  G4 S1
  G1 E20 F500
  M106 P{global.currentTool_fan} S0
  G92 E0
  G1 F200
  G1 E{-1*(tools[{state.currentTool}].retraction.length)} F100
  G4 S3

MACROS

Pickup

; Pickup

; This will grab the tool from the dock
;Open Coupler
M98 P"/macros/Tools/Tool-Unlock"

; Pickup Tool
M98 P"/macros/Tools/T0/Dock"

; Lock Coupler
M98 P"/macros/Tools/Tool-Lock"

;; Tool Wipe ;;
; Lock Coupler
M98 P"/macros/Tools/Tool-Wipe-Dock"

; Move away from dock
G1 Y320 F6000

; Identify tool has been picked up.
; We need to know if a tool is in hand.  This
; will execute code to drop tool enabling
; the next step of picking up a tool or homing Z
M28 "/sys/tactive.g"
; Play Alert Sound
M300 S500 P200
G4 P250
M300 S500 P200
G4 P250
M300 S500 P200
; Prompt we detected a tool and will dock (10 second default)
M291 S1 R"Tool Warning" P"Tool 0 detected in carriage.  Preparing to Dock..."
M98 P"/macros/Tools/T0/Drop"
M29

Dock

; Dock

; This file will align the tool head with the tool and

; Tool changer we want to home Y first to pull away from tools.
if !move.axes[0].homed
  ; Home Y
  G28 X
if !move.axes[1].homed
  ; Home X
  G28 Y

; move to prep for lock.
; move to Y 1st for safety
; Prefix commands with G53 to ignore offsets!!
; align with tool
G53 G1 Y300 F8000
G53 G1 Y300 X417


; move to tool
G53 G1 Y375 F4000
G53 G1 Y397 F2500

Drop

; Drop

; This will put the tool back in the dock.
; Dock Tool
M98 P"/macros/Tools/T0/Dock"

; Unlock Coupler
M98 P"/macros/Tools/Tool-Unlock"

; Move away from dock fast in hopes it shakes a sticky tool off like a string.
G53 G1 Y320.5 F12000

; Cleanup tool register
M30 "/sys/tactive.g"

Tool-Lock

; Tool-Lock

M400
M906 C600    ; Raise motor current a bit.
M400
G1 C206 F2500
M400
M906 C400    ; Put it back to normal
M400

Tool-UnLock

; Tool-UnLock

M400
M906 C600    ; Raise motor current a bit.
M400
if !move.axes[3].homed && move.axes[3].userPosition==0
	; We are assuming a tool is loaded and we want to unload it.
	; 
	echo "C-Axis not homed"
	G1 C-83 F2500 H2
else
	G1 C125 F2500
M400
M906 C400    ; Put it back to normal
M400

I believe the problem to be occurring during the tfree0.g as the tool has the active temperature set and I see the bed lower. I would expect it to attempt to pick up the tool at this point, so I'm expecting the hang is occuring between the first G90 and M98 Macro (which I do not see execute).

; Move Z out of way.
G91              ; relative positioning
G1 Z5 F6000 H2   ; lift Z relative to current position
G90              ; absolute positioning

M98 P"/macros/Tools/T0/Drop" ; Drop Tool

I have tried an M108 in hopes it was stuck in a temperature wait loop, but that does not stop it. The only way I have been able to make things work again at this point is to stop the machine through the emergency stop on the Duet PanelDue or Web Console.

No issues with a single tool print or manually cycling through the tools. It's only happening while printing and almost always after cycling through the tools at least once. It will occur in a print job in the same place each time, so it is reproducible.

I have tried to upload the firmware a second time, with the same results.

Moving back to v3.4.5 doing the same print jobs it works without a problem and no changes are required to any macros. Which at least gives me a solution to print, but was hoping to see if I was missing something.

I am getting the following error when connecting to the Duet 2 Wifi, after updating to the latest firmware. I get it approximately every 2 minutes if I have a single browser open, but if I open 2 browsers it happens every 5-10 seconds.

Connection interrupted, attempting to reconnect...
Operation failed (Reason: Service Unavailable)

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.1 (2024-04-19 14:40:46) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S8-6J1F8-3SJ6S-1BL7H
Used output buffers: 3 of 26 (26 max)
=== RTOS ===
Static ram: 23256
Dynamic ram: 78508 of which 0 recycled
Never used RAM 8260, free system stack 118 words
Tasks: NETWORK(1,ready,14.2%,200) HEAT(3,nWait 5,0.1%,328) Move(4,nWait 5,0.0%,258) DUEX(5,nWait 5,0.0%,24) MAIN(1,running,85.5%,743) IDLE(0,ready,0.2%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:16:34 ago, cause: software
Last software reset at 2024-05-03 22:27, reason: User, Gcodes spinning, available RAM 8604, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
MCU temperature: min 38.5, current 40.7, max 41.1
Supply voltage: min 24.0, current 24.0, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/48, heap memory allocated/used/recyclable 2048/1176/64, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 166
Driver 1: standstill, SG min 202
Driver 2: ok, SG min 0
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: ok, SG min 0
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
Date/time: 2024-05-03 22:43:43
Cache data hit count 4294967295
Slowest loop: 349.38ms; fastest: 0.20ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 7
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 8.5ms, write time 122.0ms, max retries 0
=== Move ===
DMs created 83, segments created 11, maxWait 964256ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
next step interrupt due in 43 ticks, disabled
Moves shaped first try 5, on retry 0, too short 2, wrong shape 2, maybepossible 0
=== DDARing 0 ===
Scheduled moves 27, completed 26, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.6
Heater 1 is on, I-accum = 0.5
Heater 3 is on, I-accum = 0.3
=== GCodes ===
Movement locks held by File
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 44 0 5, running macro
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 idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== Filament sensors ===
check 2500602 clear 7408764
Extruder 0: pos 2516.48, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
Extruder 1: pos 2160.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
Extruder 2: pos 2160.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
=== DueX ===
Read count 1, 0.06 reads/min
=== Network ===
Slowest loop: 345.81ms; 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 cc:50:e3:14:e3:17
Module reset reason: Turned on by main processor, Vcc 3.32, flash size 4194304, free heap 42948
WiFi IP address 192.168.0.90
Signal strength -42dBm, channel 2, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

I have attempted to download the firmware again and still the same issue persists.

Product	Short Name	Version
Duet 2 WiFi	2WiFi	3.5.1
Duet WiFi Server	n/a	2.1.0
Duet Web Control	DWC	3.5.1

Help and TIA!

@droftarts Thank you, I'll look into this. Might be the right solution. Alternatively I had planed to just setup a hardware thermistor, but it would be nice to just control things from the tool change macros. I had thought also going after the firmaware and changing the value, but seems like that might be more work overall.
I'll likely use the Duet3 for my larger format system in the future, but already have this one wired up. Yeah its more wires, but its working.

@stuartofmt I am not familiar with what you are referring? Do you have a link?

I'm on a Duet2/Duex5 and plan to have 4-5 tools on my system, but wanting to use 3 fans per tool (tool fan, part tool and a cooler for the extruder). I probably don't have enough ports to connect them all up to be controlled, but even if I could I can't define more than 12 (0-11). Is it possible to have more on a Duet3 platform possibly with tool boards?

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

I'm running 3.4 firmware and recently started having problems when changing tools. For the moment it appears when switching to a specific tool (T1) and it completes the TPost1.g the print pauses and I receive an error "Filament error on extruder 1: noDataReceived". When I resume the print all is fine, and monitoring continues.

As part of my Pause.g I have it report the data from the filament monitors and it never has an issue providing the data. I assume this means it's communicating with the MFM when it receives the error, showing it's communicating.

TPre1.g

; tpre1.g
; called before tool 1 is selected
;
; Check if we have another tool selected
; Is this even necessary with our tool detection script in play?

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Validate axes have been homed before picking up tool
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Home Y
if !move.axes[1].homed
  M98 P"/sys/homey.g"

; Home X
if !move.axes[0].homed
  M98 P"/sys/homex.g"

; Home Z
if !move.axes[2].homed
  M98 P"/sys/homez.g"

; Home C
if !move.axes[3].homed
  M98 P"/sys/homec.g"

G60 S0               ; Save this position as the reference point from which to later apply new tool offsets.


;;;;;;;;;;;;;;;;;;;;;
;; FILAMENT SENSOR ;;
;;;;;;;;;;;;;;;;;;;;;
; Dumb switch
;M591 D1 P2 c"e1_stop" S1			; Enable Extruder 1, Simple Sensor (High signal), Connected to E1 input
; Duet Magnetic Filament Monitor
; Duet3D rotating magnet sensor extruder drive 1 is connected to E1, enabled, sensitivity 24.8mm.rev, 70% to 130% tolerance, 3mm detection length 'agc' of 50 to 105
M591 D1 P3 c"e1_stop" S1 R10:190 L25.0 E3.0


;;;;;;;;;;;;;;;;;;;;;;
;;  Tool Variables  ;;
;;;;;;;;;;;;;;;;;;;;;;
; Set tool specific variables.
set global.currentTool_fan = 2


;;;;;;;;;;;;;;;;;;;;;;
;;    Load Tool     ;;
;;;;;;;;;;;;;;;;;;;;;;
; Turn on heater
if tools[1].active[0] > 0
  M568 P1 A2
elif tools[1].standby[0] > 0
  M568 P1 A1

; Set tool wiper height
G1 A56.4 F750         ; Typical V6 Tool height (just misses fan on brush)
; Save wiper height to file.
M28 "/sys/TriggerA.g"
G92 A56.4
M29

; Wait for set temperatures to be reached
M116 P1

if move.axes[2].machinePosition < abs(tools[1].offsets[2])
  G1 Z{(abs(tools[1].offsets[2])+5)}

; Load T1 Configuration
M98 P"/sys/tconfig1.g"

TConfig1.g

M207 P1 S0.50	; Retraction

;G10 P1 X-6.8 Y35.15 Z-1.85 A1.7           ; Set tool 0 axis offsets (-1.67)
G10 P1 X-6.8 Y35.05 Z-1.8 A1.65           ; Set tool 0 axis offsets (-1.8)

TPost1.g

; tpost1.g
; called after tool 1 has been selected
;
M703		; Load filament config

; Squeeze Filament Out
M98 P"/sys/prime.g"

; Pickup Tool
M98 P"/macros/Tools/T1-Pickup"


; Perform any wipe commands if nozzle is above extrusion temps.
if sensors.analog[2].lastReading > heat.coldExtrudeTemperature
;  M98 P"/macros/Tools/Tool-Wipe" ; Wipe nozzle

; restore print cooling fan speed
;M106 P2 R2
M106 P2 S{state.restorePoints[2].fanPwm}

G0 R2 X0 Y0 F6000
G1 R2 Z0                     ; Restore prior Z position before tool change was initiated.
                             ; Note: tool tip position is automatically saved to slot 2 upon the start of a tool change.
                             ; Restore Z first so we don't crash the tool on retraction.
G1 E{tools[{state.currentTool}].retraction.length} ; Prime Nozzle.

@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.

@fcwilt
So I'm not exactly sure how to move a single step, but mechanically this is how I am setup:
Dual 1.8° steppers w/ TR8*2 lead screws

M350 X16 Y16 Z16 E16:16 I1                ; Configure microstepping with interpolation
M92 X201.2499 Y201.2499 Z1601.584008 C100 E421.1332199:690    ; T8x2 1-Start Lead Screw

When I perform a single rotation of the Z motor my Dial Gauge reads 2mm at bed center, which is expected. It reads the same when moved to the lead screws and moved one full rotation.

Maybe I need to perform some tests for repeatability?

@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 said in Mesh compensation results backwards:

@gamefanatic3d

In your MyMeshCompStep1 file you have

if var.probezOne - var.probezTwo <= 0.005

Ignoring any floating point errors:

if var.probezOne = 1.006 and var.probeTwo = 1.000 then var.probezOne - var.probezTwo = 0.006 and the test fails.

if var.probezOne = 1.000 and var.probeTwo = 1.006 then var.probezOne - var.probezTwo = -0.006 and the test succeeds.

In both cases the difference is 0.006.

I don't understand what you are testing for.

---

Also the number returned by G30 S-1 does not have a fixed relationship to the probe Z Trigger Height setting.

Thanks.

Frederick

I'm attempting to get a height value from the BLTouch that represents the difference from Z-0 which I am interpreting to be in direct relation to when I run my G30.
In this case, I'm interested in the return values so I can better understand what is happening and see the variations. I'm not so sure how much it matters on the macro as it's not what's actually coming up with the heightmap values, I'm just using it to test my theory and why I can manually set my values in the heightmap vs using the BLTouch and the G29.

@phaedrux said in Mesh compensation results backwards:

@gamefanatic3d said in Mesh compensation results backwards:
Have you tried a homez.g without the conditional gcode?

I started off without the conditional code and only added it due to a recommendation by @fcwilt.

@gamefanatic3d

Okay I'm back and after much testing over the past week, I'm convinced there is nothing wrong with my Z-Motors, even though the issue I experienced was real. I believe the Duet may have just been having a moment as I was getting a homing error with negative values when performed the first homez.g after startup. Any future homing would be successful. This appears to have cleared itself up as easily as it came with me doing nothing to the system other than turning it off and back on a few times...

Moving back to the issue at hand here I have mounted a Dial Indicator tool to my system and validated my original statement that the Z-Probing being done and recorded is in fact opposite of what I would expect.

Note: I made the mount for the Dial Indicator such that I could probe with the BLTouch while having the Dial Indicator tool attached. I realize there is a tension that is created as the Dial Indicator gets closer to the end of its measuring.

Probing at a point with the BLTouch will return a positive value to the homing file when it should in fact be a negative value.

My BLTouch trigger value is 0.9.

I validated this by performing the following procedure:

Step 1: Setup

• G28
• Disable Mesh Compensation
• Attach Dial Indicator tool. (Manual process for now)
• G1 X180 Y227 Z6 (Move the BLTouch to a center point on bed)
• G30
• G1 X206.8 Y143.4 Z15 (Move Dial Indicator to same point on the bed with specific height/trigger point)
• Set the Dial Indicator to 0.000

Now I go to a spot on the bed shown on the heightmap that I know to be a low spot (further away from tools)

Step 2: Probing Low

• G1 X328.23 Y224.37 Z6
• M98 P"/macros/Homing/Bed/MyMeshCompStep1"
• G1 X355.03 Y140.77 Z15

The result of BLTouch

8/28/2021, 2:37:40 PM	G1 X355.03 Y140.77 Z15
8/28/2021, 2:37:29 PM	Stopped at height 0.987 mm
-0.085
8/28/2021, 2:37:28 PM	M98 P"/macros/Homing/Bed/MyMeshCompStep1"
Stopped at height 0.983 mm
8/28/2021, 2:36:46 PM	G1 X328.23 Y224.37 Z6
8/28/2021, 2:36:14 PM	G1 X206.8 Y143.4 Z15
8/28/2021, 2:36:03 PM	G30

Dial Indicator: -0.08

I repeat this procedure 3 times in the same spot to validate any potential mechanical issues. Keeping in mind the dial indicator is not as accurate as of the BLTouch and validate the numbers are still roughly the same.

The heightmap.g in this area is showing a positive value in this area. I believe this is due to the BLTouch returning a positive number when subtracting the two probing values which are greater than my trigger (Z-0) value.
IE)
Probe1 returns: 0.918
Probe2 returns: 0.923
The resulting value would be acceptable as it's within 0.005
The value returned should be:

-0.0205 = 0.9 - ((0.918+0.923)/2)

But what is recorded in the heightmap is 0.0205

This is my assumption of what is happening based on the heightmaps I am obtaining. I could be missing something here still...

MyMeshCompStep1

var probezHeight = 6
var TravelSpeed = 6000

var probezOne = 0
var probezTwo = 0

	while true
		if iterations = 5
			abort "Too many auto calibration attempts"

		G1 Z{var.probezHeight} F{var.TravelSpeed}
		G30 S-1
		set var.probezOne = sensors.probes[0].lastStopHeight
		G1 Z{var.probezHeight} F{var.TravelSpeed}
		G1 Z{var.probezHeight} F{var.TravelSpeed}
		G30 S-1
		set var.probezTwo = sensors.probes[0].lastStopHeight
		G1 Z{var.probezHeight} F{var.TravelSpeed}
		if var.probezOne - var.probezTwo <= 0.005
			echo sensors.probes[0].triggerHeight-((var.probezOne + var.probezTwo)/2)
			break