Posts made by jp.douarvil 0

Hi,

@Diamondback Does any of your tool change routine (tpre#.g, tfree#.g, tpost#.g) contains G92 command?

I am also fighting with similar Z axis drift issue. At this point of my investigations it seems like this issue is related to the use of the G92 command, with or without Z argument, in the RRF3.5.0rc1 firmware.

In my case, the issue occurs quasi-randomly whenever using the G92 command in either a gcode print file or a system macro.
I say "quasi-randomly" in the sense that not every execution of a G92 triggers the bug, but when the bug occurs printer coherently acts as if the last movement of the Z axis before the G92 command was properly executed but not being tracked ( @dc42 ms.coords[Z_AXIS] variable not updated at some point between the beta4 and rc1 ?), not as if one board had randomly hung, or executed some corrupted data. I say "coherently act" because:

• on system ①, I am using 2 separated 1HCL boards each controlling 1 of the 2 independent Z axis motors of the printer. From time to time I observed Z axis drift higher than 6mm upon executing a single system macro. Random data corruption or system interrupt on a single board would surely result in randomly tilting the bed left or right, which I do not observe at all
• on system ②, the 2 independent Z axis motors are controlled by the same 3HC board. "Expectedly" no bed tilt is observed here too. Meaning this issue is probably independent from the board use (i haven't tried to plug both Z motors on the 6HC main board though).
• both systems ① and ② exhibit the issue with RRF 3.5.0rc1, not with 3.5.0b4 or 3.4.xxx

@Diamondback Note that I have no intention on hijacking your thread, I am only providing additional info relevant to your problem which I suspect could help RRF developers to quickly find the origin of the problem and come with a solution.

My profuse apologies for:

• my (very) late answer
• digging up this old topic (Halloween trick or treat ?!)

but my answer is still relevant (based on the code base of the RRF 3.5.0 rc1 and 3.4.6).

@dc42 said in G30: unexpected probe dive motion range:

If you set the dive height to some value H [...] the code starts the dive at (trigger_height + H) and ends it if the probe is not triggered first at (trigger_height - H)

That is my expectation, but not what the G30 command currently does.

You will notice in the code of G30 command the mention of platform.AxisMinimum(Z_AXIS), variable which I can't make sense of:

ms.coords[Z_AXIS] = (IsAxisHomed(Z_AXIS)) ? platform.AxisMinimum(Z_AXIS) - zp->GetDiveHeight() + zp->GetActualTriggerHeight()

This is in contrast to the probing code of the G29 command, which works as you described without ever using platform.AxisMinimum(Z_AXIS):

ms.coords[Z_AXIS] = -zp->GetDiveHeight() + zp->GetActualTriggerHeight();

Hence my (old yet still relevant) pull request.

Hopefully this patch would not bring any regression, however it might save multiple RRF user from less than desirable unexpected nozzle crashes.

@dc42 said in G30: unexpected probe dive motion range:

@jp-douarvil-0 said in G30: unexpected probe dive motion range:

I personally like the principle of probing the height range extending from Z = triggerHeight + diveHeight to Z = triggerHeight - diveHeight.

That is the intention of the current code in RRF when the trigger height is not less than zero. Isn't it working that way?

Thank you for the feedback.

I noticed that in practice the nozzle systematically dive below Z=0. Hence I assume the observed behavior to be a bug.

I proposed a patch but I haven't personally compiled and tested the patched firmware. Patch is based on the code for the G29 command.

Could this fix the issue? If so it might be nice to patch the 3.4 as well for non-beta testers.

@Phaedrux actually, I tried posting the same message without link at all to no avail. Limiting the length of each message was the only effective solution.

Below is my attempted workaround:

; bed.g
; called to perform automatic bed tilt correction via G32

M400    ; wait until end of motions

var probTrigHeight = 9.0
var hoverHeight = 4.0
var deltaZ = 0.0
var zMin = move.axes[2].min

M671 X-105:405 Y0:0 S1.5                      ; set position of Z leadscrews
G29 S2                                        ; disable mesh compensation
;G31 Z{var.probTrigHeight}                     ; set trigger height

; temporary workaround the dive range non-centered around the trigger height "bug"
;;
M400
G31 Z0	; reset probe trigger height
M208 Z0 S1
G92 Z{move.axes[2].machinePosition - var.probTrigHght}
;;
M558 K0 H{var.probTrigHeight-var.hoverHeight} ; set dive height so nozzle never dives below the "hover height" (nozzle crash prevention)


while true
    G30 P0 X10 Y5 Z-99999    ; probe near -X leadscrew
    set var.deltaZ = sensors.probes[0].lastStopHeight
    G30 P1 X290 Y5 Z-99999  ; probe near left leadscrew
    set var.deltaZ = 0.5*(var.deltaZ - sensors.probes[0].lastStopHeight)
    
    if {(var.deltaZ < 0.1) || (iterations > 5)}
        break

    ; correct only the bed tilt
    G30 P0 X10.0 Y0.0 Z{var.deltaZ} H0.0
    G30 P1 X290.0 Y0.0 Z{-var.deltaZ} H0.0 S2

; temporary workaround the dive range non-centered around the trigger height "bug"
;;
M400
G31 Z{var.probTrigHght}	; reset probe trigger height
M208 Z{var.zMin} S1
G92 Z{move.axes[2].machinePosition + var.probTrigHght}
;;
M400    ; wait until end of motions

It works as expected but as you can tell it makes the code a bit confusing and long (i.e. seed for a difficult to debug spaghetti-code).

I don't know how to connect the second wire to the duet to take direction into account. A quick and dirty work-around might be to post-process your g-code so to deactivate filament tracking just before a retraction move and reactivate it immediately afterward.

@Tinchus
RRF is a multipurpose firmware, it is supposed to be very tunable. Hence, depending on your specific hardware, sending negative E value does not necessarily equate to a retraction move (it could be just for unjamming, for backlash compensation, for a special tool change move or who knows what). So, unless you specifically indicate the firmware to retract/unretract filament (G11 command) the firmware will not assume by default that negative E value means a retraction which tracking value mustn't be taken into account.

Is the described unexpected behavior unintended or did I misunderstood something about the use of the G30 command.

I personally like the principle of probing the height range extending from Z = triggerHeight + diveHeight to Z = triggerHeight - diveHeight.
Given that both the trigger height and dive height are GCODE configurable floats (signed), it makes for very versatile and comprehensive implementation of custom probing moves in bed.g , mesh.g or any other configuration file for that matter.

Thank you in advance for your help.

Below is a bed.g configuration exhibiting the described behavior:

; bed.g
; called to perform automatic bed tilt correction via G32

M400    ; wait until end of motions

var probTrigHeight = 9.0
var hoverHeight = 4.0
var deltaZ = 0.0

M671 X-105:405 Y0:0 S1.5                      ; set position of Z leadscrews
G29 S2                                        ; disable mesh compensation
G31 Z{var.probTrigHeight}                     ; set trigger height
M558 K0 H{var.probTrigHeight-var.hoverHeight} ; set dive height so nozzle never dives below the "hover height" (nozzle crash prevention)

while true
    G30 P0 X10 Y5 Z-99999    ; probe near -X leadscrew
    set var.deltaZ = sensors.probes[0].lastStopHeight
    G30 P1 X290 Y5 Z-99999  ; probe near left leadscrew
    ;set var.deltaZ = {var.deltaZ - (var.deltaZ + sensors.probes[0].lastStopHeight)/2}
    set var.deltaZ = 0.5*(var.deltaZ - sensors.probes[0].lastStopHeight) ; edit: just simplified the assignment above
    
    if {(var.deltaZ < 0.1) || (iterations > 5)}
        break

    ; correct only the bed tilt
    G30 P0 X10.0 Y0.0 Z{var.deltaZ} H0.0
    G30 P1 X290.0 Y0.0 Z{-var.deltaZ} H0.0 S2

M400    ; wait until end of motions

Regarding the odd probing start height experienced with RRF3.5 however I haven't found the origin of the issue. But it seems like I am not the only one scratching my head on it. Using large dive height value is a good enough temporary band-aid but doesn't make for very robust/maintainable configuration files in my opinion.

Further investigating, I realized that the odd probing stop height was already a thing, however that I hadn't noticed, on RRF3.4. I am fairly confident that this issue is indeed related to the herementioned unexpected behavior. Diving into the origin of the problem, it looks like the odd stop height for the G30 command when the Z axis is already homed is computed differently than for G29 moves.

Hi everybody,

(sorry for the multiple posts, Akismet seems quite angry at long posts)

Upon migrating from RRF3.4.5 to RRF3.5.0B2 & B3 I started running into bed tilt correction (customized G32 using G30 single point probing) issues:

• probing starting height is Z = diveHeight instead of the expected Z = triggerHeight + diveHeight
• probing stop height is somewhat in the ballpark of Z = zMin - diveHeight - 2 rather than the expected Z = triggerHeight - diveHeight (according the documentation for the H parameter of the M558 command)

@droftarts , @chrishamm Hello,

The single bed control tip allows for controling the bed temperature via the dashboard at least, I can live with that .

Thank you very much for the explanations.

On the heater fault, its OK . I hadn't even connected the heater to the board as it was just a "unit test" built for the purpose of diagnosing the specific dashboard control issue.

@droftarts Hello,

Thank you for the feedback.

I profusely apologize for posting an erroneous config.g file.

The issue doesn't actually go away after correcting it.

Let me share the corrected config.g and the corresponding eventlog after:

• execution of M122
• execution of M98 P"config.g"
• set the temperature to 70C via the dashboard --> error
• set the temperature to 60C via a test print file BedHeaterTest.gcode containing only the command M140 S60 P10 --> error
• set the temperature via M140 S50 --> no error but the set temperature (50C) is not reflected on the dashboard as show on the capture below

config.g

eventlog.txt

2023-03-29 17:01:50 [info] Event logging started at level debug


;M122 response


2023-03-29 17:01:50 [info] Running: Duet 3 MB6HC v1.01: 3.5beta2 (2023-02-08 17:43:01)
2023-03-29 17:01:56 [debug] === Diagnostics ===
2023-03-29 17:01:56 [debug] RepRapFirmware for Duet 3 MB6HC version 3.5beta2 (2023-02-08 17:43:01) running on Duet 3 MB6HC v1.01 (standalone mode)
2023-03-29 17:01:56 [debug] Board ID: 08DJM-956BA-NA3TN-6JKDG-3S86S-TUB6S
2023-03-29 17:01:56 [debug] Used output buffers: 1 of 40 (29 max)
2023-03-29 17:01:56 [debug] === RTOS ===
2023-03-29 17:01:56 [debug] Static ram: 154344
2023-03-29 17:01:56 [debug] Dynamic ram: 117436 of which 0 recycled
2023-03-29 17:01:56 [debug] Never used RAM 73692, free system stack 200 words
2023-03-29 17:01:56 [debug] Tasks:
2023-03-29 17:01:56 [debug]  NETWORK(ready,30.6%,194)
2023-03-29 17:01:56 [debug]  ETHERNET(notifyWait,0.1%,441)
2023-03-29 17:01:56 [debug]  HEAT(notifyWait,0.0%,318)
2023-03-29 17:01:56 [debug]  Move(notifyWait,0.0%,342)
2023-03-29 17:01:56 [debug]  CanReceiv(notifyWait,0.0%,773)
2023-03-29 17:01:56 [debug]  CanSender(notifyWait,0.0%,335)
2023-03-29 17:01:56 [debug]  CanClock(delaying,0.0%,340)
2023-03-29 17:01:56 [debug]  TMC(notifyWait,8.1%,90)
2023-03-29 17:01:56 [debug]  MAIN(running,61.2%,446)
2023-03-29 17:01:56 [debug]  IDLE(ready,0.0%,30)
2023-03-29 17:01:56 [debug] , total 100.0%
Owned mutexes:
2023-03-29 17:01:56 [debug]  LwipCore(NETWORK)
2023-03-29 17:01:56 [debug] === Platform ===
2023-03-29 17:01:56 [debug] Last reset 00:28:25 ago, cause: software
2023-03-29 17:01:56 [debug] Last software reset at 2023-03-29 16:33, reason: User, Gcodes spinning, available RAM 69940, slot 0
2023-03-29 17:01:56 [debug] Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
2023-03-29 17:01:56 [debug] Error status: 0x00
2023-03-29 17:01:56 [debug] Step timer max interval 129
2023-03-29 17:01:56 [debug] MCU temperature: min 35.8, current 36.0, max 36.6
2023-03-29 17:01:56 [debug] Supply voltage: min 23.8, current 23.8, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
2023-03-29 17:01:56 [debug] 12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0
2023-03-29 17:01:56 [debug] Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
2023-03-29 17:01:56 [debug] Events: 2 queued, 2 completed
2023-03-29 17:01:56 [debug] Driver 0: standstill, SG min n/a, mspos 8, reads 35243, writes 3 timeouts 0
2023-03-29 17:01:56 [debug] Driver 1: standstill, SG min n/a, mspos 8, reads 35242, writes 3 timeouts 0
2023-03-29 17:01:56 [debug] Driver 2: standstill, SG min n/a, mspos 8, reads 35243, writes 3 timeouts 0
2023-03-29 17:01:56 [debug] Driver 3: standstill, SG min n/a, mspos 8, reads 35243, writes 3 timeouts 0
2023-03-29 17:01:56 [debug] Driver 4: standstill, SG min n/a, mspos 8, reads 35246, writes 0 timeouts 0
2023-03-29 17:01:56 [debug] Driver 5: standstill, SG min n/a, mspos 8, reads 35246, writes 0 timeouts 0
2023-03-29 17:01:56 [debug] Date/time: 
2023-03-29 17:01:56 [debug] 2023-03-29 17:01:56
2023-03-29 17:01:56 [debug] Slowest loop: 18.15ms; fastest: 0.06ms
2023-03-29 17:01:56 [debug] === Storage ===
Free file entries: 19
2023-03-29 17:01:56 [debug] SD card 0 detected, interface speed: 25.0MBytes/sec
2023-03-29 17:01:56 [debug] SD card longest read time 2.9ms, write time 3.8ms, max retries 0
2023-03-29 17:01:56 [debug] === Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
2023-03-29 17:01:56 [debug] no step interrupt scheduled
2023-03-29 17:01:56 [debug] === DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
2023-03-29 17:01:56 [debug] === DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
2023-03-29 17:01:56 [debug] === Heat ===
2023-03-29 17:01:56 [debug] Bed heaters 10 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
2023-03-29 17:01:56 [debug] === GCodes ===
2023-03-29 17:01:56 [debug] Movement locks held by null, null
2023-03-29 17:01:56 [debug] HTTP is idle in state(s) 0
2023-03-29 17:01:56 [debug] Telnet is idle in state(s) 0
2023-03-29 17:01:56 [debug] File is idle in state(s) 0
2023-03-29 17:01:56 [debug] USB is idle in state(s) 0
2023-03-29 17:01:56 [debug] Aux is idle in state(s) 0
2023-03-29 17:01:56 [debug] Trigger is idle in state(s) 0
2023-03-29 17:01:56 [debug] Queue is idle in state(s) 0
2023-03-29 17:01:56 [debug] LCD is idle in state(s) 0
2023-03-29 17:01:56 [debug] SBC is idle in state(s) 0
2023-03-29 17:01:56 [debug] Daemon is idle in state(s) 0
2023-03-29 17:01:56 [debug] Aux2 is idle in state(s) 0
2023-03-29 17:01:56 [debug] Autopause is idle in state(s) 0
2023-03-29 17:01:56 [debug] File2 is idle in state(s) 0
2023-03-29 17:01:56 [debug] Queue2 is idle in state(s) 0
2023-03-29 17:01:56 [debug] Q0 segments left 0, axes/extruders owned 0x0000000
2023-03-29 17:01:56 [debug] Code queue 0 is empty
2023-03-29 17:01:56 [debug] Q1 segments left 0, axes/extruders owned 0x0000000
2023-03-29 17:01:56 [debug] Code queue 1 is empty
2023-03-29 17:01:56 [debug] === CAN ===
2023-03-29 17:01:56 [debug] Messages queued 7789, received 6922, lost 0, boc 0
2023-03-29 17:01:56 [debug] Longest wait 0ms for reply type 0, peak Tx sync delay 21, free buffers 50 (min 50), ts 4327/4327/0
2023-03-29 17:01:56 [debug] Tx timeouts 0,0,0,0,0,0
2023-03-29 17:01:56 [debug] === Network ===
2023-03-29 17:01:56 [debug] Slowest loop: 34.82ms; fastest: 0.03ms
2023-03-29 17:01:56 [debug] Responder states:
2023-03-29 17:01:56 [debug]  MQTT(0)
2023-03-29 17:01:56 [debug]  HTTP(0)
2023-03-29 17:01:56 [debug]  HTTP(0)
2023-03-29 17:01:56 [debug]  HTTP(0)
2023-03-29 17:01:56 [debug]  HTTP(0)
2023-03-29 17:01:56 [debug]  HTTP(0)
2023-03-29 17:01:56 [debug]  HTTP(0)
2023-03-29 17:01:56 [debug]  FTP(0)
2023-03-29 17:01:56 [debug]  Telnet(0)
2023-03-29 17:01:56 [debug]  Telnet(0)
2023-03-29 17:01:56 [debug] HTTP sessions: 1 of 8
2023-03-29 17:01:56 [debug] = Ethernet =
State: active
2023-03-29 17:01:56 [debug] Error counts: 0 0 0 0 0 0
Socket states:
2023-03-29 17:01:56 [debug]  5
2023-03-29 17:01:56 [debug]  2
2023-03-29 17:01:56 [debug]  2
2023-03-29 17:01:56 [debug]  2
2023-03-29 17:01:56 [debug]  2
2023-03-29 17:01:56 [debug]  0
2023-03-29 17:01:56 [debug]  0
2023-03-29 17:01:56 [debug]  0
2023-03-29 17:01:56 [debug] === Multicast handler ===
Responder is inactive, messages received 0, responses 0


; M98 P"config.g" response


2023-03-29 17:01:58 [debug] HTTP is enabled on port 80
2023-03-29 17:01:58 [debug] FTP is disabled
2023-03-29 17:01:58 [debug] TELNET is disabled
2023-03-29 17:01:58 [info] G10 P0 X0 Y0 Z0                              
2023-03-29 17:01:58 [info] G10 P0 R0 S0                                 


; set the temperature to 70deg via the dashboard


2023-03-29 17:02:04 [warn] Error: M140: No bed heater has been configured for slot 10


; set the temperature to 60C via a test print file containing only "M140 S60 P10"


2023-03-29 17:02:06 [debug] File BedHeaterTest.gcode selected for printing
2023-03-29 17:02:10 [warn] Started printing file 0:/gcodes/BedHeaterTest.gcode
2023-03-29 17:02:10 [warn] Error: No bed heater has been configured for slot 10
2023-03-29 17:02:10 [debug] Done printing file
2023-03-29 17:02:10 [debug] Done printing file
2023-03-29 17:02:10 [warn] Finished printing file 0:/gcodes/BedHeaterTest.gcode, print time was 0h 0m


; set the temperature to 50C via console command "M140 S50"


2023-03-29 17:02:33 [warn] Error: Heater 10 fault: temperature rising too slowly: expected 2.32°C/sec measured -0.02°C/sec
2023-03-29 17:02:33 [info] M291: - Event notification - Heater 10 fault: temperature rising too slowly: expected 2.32°C/sec measured -0.02°C/sec
2023-03-29 17:02:33 [debug] - Event notification -
2023-03-29 17:02:33 [debug] Heater 10 fault: temperature rising too slowly: expected 2.32°C/sec measured -0.02°C/sec

Thank you very much for your help.

edit: attached config.g file is erroneous, this post may be ignored.

original post:

@Phaedrux Hello,

Attached is a "minimal" configuration exhibiting the issue.
config.g

And below the extract of the eventlog in debug mode following the >execution of an M122 and M98 P"config.g".

2023-03-27 17:51:17 [info] Event logging started at level debug

;M122 response

2023-03-27 17:51:17 [info] Running: Duet 3 MB6HC v1.01: 3.5beta2 (2023-02-08 17:43:01)
2023-03-27 17:51:49 [debug] === Diagnostics ===
2023-03-27 17:51:49 [debug] RepRapFirmware for Duet 3 MB6HC version 3.5beta2 (2023-02-08 17:43:01) running on Duet 3 MB6HC v1.01 (standalone mode)
2023-03-27 17:51:49 [debug] Board ID: 08DJM-956BA-NA3TN-6JKDG-3S86S-TUB6S
2023-03-27 17:51:49 [debug] Used output buffers: 1 of 40 (18 max)
2023-03-27 17:51:49 [debug] === RTOS ===
2023-03-27 17:51:49 [debug] Static ram: 154344
2023-03-27 17:51:49 [debug] Dynamic ram: 117024 of which 0 recycled
2023-03-27 17:51:49 [debug] Never used RAM 71248, free system stack 206 words
2023-03-27 17:51:49 [debug] Tasks:
2023-03-27 17:51:49 [debug]  NETWORK(ready,30.4%,254)
2023-03-27 17:51:49 [debug]  ETHERNET(notifyWait,0.1%,443)
2023-03-27 17:51:49 [debug]  HEAT(notifyWait,0.0%,321)
2023-03-27 17:51:49 [debug]  Move(notifyWait,0.0%,342)
2023-03-27 17:51:49 [debug]  CanReceiv(notifyWait,0.0%,943)
2023-03-27 17:51:49 [debug]  CanSender(notifyWait,0.0%,335)
2023-03-27 17:51:49 [debug]  CanClock(delaying,0.0%,334)
2023-03-27 17:51:49 [debug]  TMC(notifyWait,8.1%,90)
2023-03-27 17:51:49 [debug]  MAIN(running,61.3%,446)
2023-03-27 17:51:49 [debug]  IDLE(ready,0.0%,30)
2023-03-27 17:51:49 [debug] , total 100.0%
Owned mutexes:
2023-03-27 17:51:49 [debug] === Platform ===
2023-03-27 17:51:49 [debug] Last reset 00:07:05 ago, cause: software
2023-03-27 17:51:49 [debug] Last software reset at 2023-03-27 17:44, reason: User, Gcodes spinning, available RAM 71396, slot 2
2023-03-27 17:51:49 [debug] Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
2023-03-27 17:51:49 [debug] Error status: 0x00
2023-03-27 17:51:49 [debug] Step timer max interval 150
2023-03-27 17:51:49 [debug] MCU temperature: min 32.7, current 33.6, max 33.8
2023-03-27 17:51:49 [debug] Supply voltage: min 23.8, current 23.8, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
2023-03-27 17:51:49 [debug] 12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
2023-03-27 17:51:49 [debug] Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/12/12, gc cycles 0
2023-03-27 17:51:49 [debug] Events: 0 queued, 0 completed
2023-03-27 17:51:49 [debug] Driver 0: standstill, SG min n/a, mspos 8, reads 11201, writes 14 timeouts 0
2023-03-27 17:51:49 [debug] Driver 1: standstill, SG min n/a, mspos 8, reads 11202, writes 14 timeouts 0
2023-03-27 17:51:49 [debug] Driver 2: standstill, SG min n/a, mspos 8, reads 11211, writes 14 timeouts 0
2023-03-27 17:51:49 [debug] Driver 3: standstill, SG min n/a, mspos 8, reads 11212, writes 14 timeouts 0
2023-03-27 17:51:49 [debug] Driver 4: standstill, SG min n/a, mspos 8, reads 11215, writes 11 timeouts 0
2023-03-27 17:51:49 [debug] Driver 5: standstill, SG min n/a, mspos 8, reads 11216, writes 11 timeouts 0
2023-03-27 17:51:49 [debug] Date/time: 
2023-03-27 17:51:49 [debug] 2023-03-27 17:51:49
2023-03-27 17:51:49 [debug] Slowest loop: 12.85ms; fastest: 0.06ms
2023-03-27 17:51:49 [debug] === Storage ===
Free file entries: 19
2023-03-27 17:51:49 [debug] SD card 0 detected, interface speed: 25.0MBytes/sec
2023-03-27 17:51:49 [debug] SD card longest read time 2.8ms, write time 1.7ms, max retries 0
2023-03-27 17:51:49 [debug] === Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
2023-03-27 17:51:49 [debug] no step interrupt scheduled
2023-03-27 17:51:49 [debug] === DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
2023-03-27 17:51:49 [debug] === DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
2023-03-27 17:51:49 [debug] === Heat ===
2023-03-27 17:51:49 [debug] Bed heaters 10 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
2023-03-27 17:51:49 [debug] === GCodes ===
2023-03-27 17:51:49 [debug] Movement locks held by null, null
2023-03-27 17:51:49 [debug] HTTP is idle in state(s) 0
2023-03-27 17:51:49 [debug] Telnet is idle in state(s) 0
2023-03-27 17:51:49 [debug] File is idle in state(s) 0
2023-03-27 17:51:49 [debug] USB is idle in state(s) 0
2023-03-27 17:51:49 [debug] Aux is idle in state(s) 0
2023-03-27 17:51:49 [debug] Trigger is idle in state(s) 0
2023-03-27 17:51:49 [debug] Queue is idle in state(s) 0
2023-03-27 17:51:49 [debug] LCD is idle in state(s) 0
2023-03-27 17:51:49 [debug] SBC is idle in state(s) 0
2023-03-27 17:51:49 [debug] Daemon is idle in state(s) 0
2023-03-27 17:51:49 [debug] Aux2 is idle in state(s) 0
2023-03-27 17:51:49 [debug] Autopause is idle in state(s) 0
2023-03-27 17:51:49 [debug] File2 is idle in state(s) 0
2023-03-27 17:51:49 [debug] Queue2 is idle in state(s) 0
2023-03-27 17:51:49 [debug] Q0 segments left 0, axes/extruders owned 0x0000000
2023-03-27 17:51:49 [debug] Code queue 0 is empty
2023-03-27 17:51:49 [debug] Q1 segments left 0, axes/extruders owned 0x0000000
2023-03-27 17:51:49 [debug] Code queue 1 is empty
2023-03-27 17:51:49 [debug] === CAN ===
2023-03-27 17:51:49 [debug] Messages queued 3832, received 0, lost 0, boc 0
2023-03-27 17:51:49 [debug] Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 2130/0/0
2023-03-27 17:51:49 [debug] Tx timeouts 0,0,2129,0,0,1701 last cancelled message type 30 dest 127
2023-03-27 17:51:49 [debug] === Network ===
2023-03-27 17:51:49 [debug] Slowest loop: 4.63ms; fastest: 0.03ms
2023-03-27 17:51:49 [debug] Responder states:
2023-03-27 17:51:49 [debug]  MQTT(0)
2023-03-27 17:51:49 [debug]  HTTP(0)
2023-03-27 17:51:49 [debug]  HTTP(0)
2023-03-27 17:51:49 [debug]  HTTP(0)
2023-03-27 17:51:49 [debug]  HTTP(0)
2023-03-27 17:51:49 [debug]  HTTP(0)
2023-03-27 17:51:49 [debug]  HTTP(0)
2023-03-27 17:51:49 [debug]  FTP(0)
2023-03-27 17:51:49 [debug]  Telnet(0)
2023-03-27 17:51:49 [debug]  Telnet(0)
2023-03-27 17:51:49 [debug] HTTP sessions: 1 of 8
2023-03-27 17:51:49 [debug] = Ethernet =
State: active
2023-03-27 17:51:49 [debug] Error counts: 0 0 0 1 0 0
Socket states:
2023-03-27 17:51:49 [debug]  5
2023-03-27 17:51:49 [debug]  2
2023-03-27 17:51:49 [debug]  2
2023-03-27 17:51:49 [debug]  2
2023-03-27 17:51:49 [debug]  2
2023-03-27 17:51:49 [debug]  0
2023-03-27 17:51:49 [debug]  0
2023-03-27 17:51:49 [debug]  0
2023-03-27 17:51:49 [debug] === Multicast handler ===
Responder is inactive, messages received 0, responses 0



;M98 P"config.g" response


2023-03-27 17:51:58 [warn] Warning: M918: Command is not supported
2023-03-27 17:51:58 [debug] HTTP is enabled on port 80
2023-03-27 17:51:58 [debug] FTP is disabled
2023-03-27 17:51:58 [debug] TELNET is disabled
2023-03-27 17:51:58 [warn] Warning: Sensor number 0 has not been defined
2023-03-27 17:51:58 [info] G10 P0 X0 Y0 Z0                              
2023-03-27 17:51:58 [info] G10 P0 R0 S0                                 

@Phaedrux Hello,

According to the info in Settings > General I am currently using the version Duet Web Control 3.5.0-beta.2. It is the version delivered with RRF Beta2 I took from there:
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.0beta2
I haven't tried the 3.5.0-b2+ yet, should I?

Prior to that, when DWC was working as expected, I was using the version Duet Web Control 3.4.2.

Hello all,

I use RRF 3.5B2 on Duet 3 in standalone mode on a cartesian FFF machine. I used to reserve the heater slot 0~9 for the extruder heaters and 10 for the bed. In my case, this way of allocating the heater number makes the difference between extruders and bed heater very clear for the users.

The below configuration worked smoothly on RRF 3.4

; Bed heater
M308 S10 P... Y...	; configure bed temperature sensor
M950 H10 C... T10 	; create bed heater
M140 H10		; map temp sensor to heater
;M140 H10 P0		; same as above
M143 H10 S...		; set bed temperature limit
M307 H10 R... K... D... E... S1.00 B0	; heater tuning parameters

; Extruder 0 heater
M308 S0 P... Y...	; configure E0 temperature sensor
M950 H0 C... T0		; create nozzle heater
M143 P0 H0 S...		; set heater temperature limit
M307 H0 R... K... D... E... S1.00 B0 V...	; heater tuning parameters
M570 H0 P10 T15	; configure heater fault detection

; Extruder 1 heater
M308 S1 P... Y...	; configure E1 temperature sensor
M950 H1 C... T1		; create nozzle heater
M143 P1 H1 S...		; set heater temperature limit
M307 H1 R... K... D... E... S1.00 B0 V...	; heater tuning parameters
M570 H1 P10 T15	; configure heater fault detection

...

The same configuration still works (M140 behavior hasn't changed) on the 3.5B2 but the bed heater does not appears properly on the dashboard, as you can see below.

The dashboard temperature command does not work as expected:

• bed heater is not recognized by the dashboard (shows heater #-1)
  -> temperatures set up using the M140 SXXX RYYY commands are not being reflected on the corresponding active/standby controls of the dashboard
  -> dashboard's bed heater controls are unresponsive (can't turn ON/OFF/Standby, can't set up the temperature using the dashboard)

On the other hand replacing the line 4 with M140 H10 with M140 P10 H10 will solve the dashboard control issue. But then, everytime I need to setup the bed temperature through GCODE, I have to remember to indicate the slot number (M140 P10 SXXX RYYY) to avoid triggering an Error: No bed heater has been configured for slot 0 error.
This new behavior appears to needlessly complicate user's experience without obvious benefit. Plus, depending on the slicer used, the P10 parameter can be quite annoying to robustly implement.

Is that a bug or is there a practical reason why the DWC's behavior changed in the way described above?

Thank you in advance for your help.

Regards,

Hello all,

I run RRF 3.5B2 on Duet 3 in standalone mode.

I am puzzled by an unexpected "unknown variable error".

Here is an extract from "G103.g":

var uClean = false
...
if {var.uClean}
	G90 G1 H2 Y{125+random(226)} X{var.xForth} U{var.uForth}
else
	G90 G1 H2 Y{125+random(226)} X{var.xForth}
if {var.uClean && var.xClean && {global.ioMotV!=null} && {global.ioMotW!=null}}
	G90 G1 H2 V{var.vDive} W{var.wDive} F{move.axes[4].speed}
elif {var.xClean && {global.ioMotV!=null}}
...

And there the extract from the "eventlog.txt":

YYYY-MM-DD HH:MM:SS [warn] Error: in file macro line 7 column 16: meta command: unknown variable 'uClean'

However the "var.uClean" variable is being called (several times in the full "G103g" file) between its declaration line 1 and its call line 7 the error occurs line 7 nonetheless.

Has anybody an idea of the possible reason for this issue?

Thank you in advance for your help.

Regards,

@Adrian52 just for info if that can help, you can use M302 P0 S0 R0 in the mean time.
@dc42 Thank you very much for the tremendous work.

@dc42 Thank you very much for your valuable answers. I will modify the wiring in accordance to your recommendations.

Regards,

Hello.

I have what seems to be a damaged 3HC CAN transceiver: CAN DIAG LED blinks 4 times however their is absolutely no software issue or 6HC board hardware issue (the printer works fine with replacement 3HC boards)

I have 4 questions intended for:

• a confirmation/correction of the diagnostics
• information to
  • understand the origin of the issue
  • solve the problem
  • prevent improper ground management related issues
• curiosity

Below are more elements of context:

The 3D printer control system is built around one 6HC and one 3HC board.
Each board is powered by a separated 24V DC power supply due to the system total power requirement (large format printer).

Power supplies has independent floating output ground. Per the manufacturer specifications, they are not meant to be plugged in parallel. Serial connection (for 48V) is OK per the manufacturer specification. Common ground is OK too (requires to carefully layout the electrical path to prevent running the supplies in parallel). A power diode can be added inline with each power supply output to build a "supply backup" configuration.

After about 3 or 4 month of "flawless" operation in this configuration, the printer suddenly notified being unable to find whichever device plugged on the 3HC board.

Long story short, I strongly suspect that the above described issue comes from a damaged 3HC board CAN transceiver (MCP2542WFD):

• the same firmware, bootloader, fuse bits configuration worked in the past and still worked once the 3HC is replaced
• below are the comparative "CANH <-> Vdd" and "CANL <-> Vss" measurement taken with a multimeter in Diode check mode (chip soldered, termination jumpers removed)

Those result seems to indicate faulty transceiver.
1) Is that a sound conclusion?

The only connection point between the board is the non-shielded RJ11 cable. Which is the reason why I think that the problem comes from the use of independent floating ground supplies: power supply ground level balance is done through the sole CAN transceiver.
2) Is that a sound hypothesis? Do you think of other more probable cause of failure?

If point 2 correct, then running a common ground should solve the issue. But I fear that:

• a) candidly connecting the grounds together could do create tricky ground loop issue through the CAN bus
• b) connect the board using shielded RJ11 cable would hardly solve any issue given the 100kOhm resistor between the shield and the ground

3) Are either of the concern a) or b) legitimate or not? Do you have wiring advice to prevent long term reliability issue?

I noticed that the CAN common mode choke part reference changed on the V1.01 3HC board (from "DR331-104AE" to "???").
4) What is the new common mode choke reference? Why is that change?

Thank you in advance for your help.

Regards,