Magnetic Filament Monitor noDataReceived

[Gamefanatic3D]

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.

[Gamefanatic3D]

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