New firmware bundle 3.2beta2

dc42

@GrodanB said in New firmware bundle 3.2beta2:

Why?
And just for my curiosity when does it affect the extrusion?

So that adjusting the extrusion factor doesn't affect the retract or reprime length, or filament loading/unloading. The extrusion factor affects moves with simultaneous XY motion and extrusion.

Nuramori

@dc42

I’m not sure what changed, but I went from a well functioning printer (blv cube) to a hot mess of bed crashes and inability to properly probe the bed for leveling using the bltouch. Nothing changed in hardware or config.sys. I was only able to get it working again by fully reverting to 3.1.1. The bed probing did double probes, the movement from probe point to probe point would be erratic with a strange pause and slow movement, and almost always would at the third probe point, return to 0,0 then go back to probing. It would never really finish the bed mesh probe. It would probe the three mount points (independent three z-axis) but wouldn’t adjust the bed level. I nearly wrecked the thing on one probe where it just drove itself into the bed and then slide to the back to home the y axis.

The bltouch is on a toolboard 0.6 if it matters. Yes I had updated the firmware on the toolboard. I have a panel due but that was not updated.

This was a bad release and I am nervous about trying another beta at this point.

oozeBot

@Nuramori said in New firmware bundle 3.2beta2:

@dc42

I’m not sure what changed, but I went from a well functioning printer (blv cube) to a hot mess of bed crashes and inability to properly probe the bed for leveling using the bltouch. Nothing changed in hardware or config.sys. I was only able to get it working again by fully reverting to 3.1.1. The bed probing did double probes, the movement from probe point to probe point would be erratic with a strange pause and slow movement, and almost always would at the third probe point, return to 0,0 then go back to probing. It would never really finish the bed mesh probe. It would probe the three mount points (independent three z-axis) but wouldn’t adjust the bed level. I nearly wrecked the thing on one probe where it just drove itself into the bed and then slide to the back to home the y axis.

The bltouch is on a toolboard 0.6 if it matters. Yes I had updated the firmware on the toolboard. I have a panel due but that was not updated.

This was a bad release and I am nervous about trying another beta at this point.

I experienced nearly the same thing with a Duet3/RPi and a toolboard. I was only able to resolve it by rolling back to 3.2b1.. but, I spent a bit of time on it again this morning only to realize that rrf hadn't been properly updated. Can you validate yours has been updated? I wasn't able to reproduce the issue you described after running M997 again and validating rrf was properly updated on my Duet 3..

Nuramori

I had double checked that it was updated, using M115 and M122 for both the board and tool board. I'm hesitant to try it again, but I can if it will help. I upgraded via "apt update" followed by "apt upgrade.' I have the source.list for the duet repository set to unstable prior to this, and had changed it to stable after reverting.

oozeBot

@Nuramori this morning, as a safeguard after rolling forward, I uploaded the 3.2b2 firmware through DWC.. and I haven’t seen the issue again. I don’t think I screwed the upgrade up, but yeah.. I dunno. It was doing all sorts of strange things- G30 would probe once, lift way too high, and fail on the second pass. Or it wouldn’t deploy the probe at all and dive into the bed.. I plan on rolling back and forth a few more times to see if I can recreate it, but I think I must have somehow not properly upgraded the firmware.

seraser

Duetwifi, tested fysetc mini 12864 version 1.2 and 2.1 and dont work, only backlight in version 1.2 nothing in version 2.1, rotate encoder and restart in two versions, connected direct exp1 mini to LCD exp and exp2 mini to sd exp.

Tested many M918 configurations but if rotate encoder restart duet is not config related.

Maybe bad pin asignement in firmware?

Thank you.

GrodanB

@dc42 said in New firmware bundle 3.2beta2:

@GrodanB said in New firmware bundle 3.2beta2:

Why?
And just for my curiosity when does it affect the extrusion?

So that adjusting the extrusion factor doesn't affect the retract or reprime length, or filament loading/unloading. The extrusion factor affects moves with simultaneous XY motion and extrusion.

Ahh, ok I see... This could explain my improved print quality on my start and stops in RRF3.2...

But that makes calibration harder then.

Would it be possible to have some sort of "force/apply compensation" feature to use in the calibration?
(I guess no slicer will use this...) Because I would like to make sure I applied the correct calibration.

My workflow for a new filament is to do this controlled extrusion, check the error, enter the compensation, verify that the compensation is correct... if not start over until correct amount is extruded.

For now I need to either use e-steps (so I can verify but then I guess I get back my start stop issues) or hope that I did not miscalculate and blindly use the value. I think I'll use the value blindly even if I'll risk that not seeing any mistake until the part is done.

GrodanB

@dc42 said in New firmware bundle 3.2beta2:

@GrodanB said in New firmware bundle 3.2beta2:

The bed temp reaches 85 and when the heater PT element reports 223.8 (reading the documentation this is the expected behaviour that now M701 call is done and M703 shall be run) my printer resets and all temperatures are set to 0 and tool 1 is set to inactive.

If you can reproduce that, please run M122 immediately after the uncommanded reset and post the result here.

Easy to reproduce but M122 seems to do nothing... Or I do something wrong...
But I there is a failure message I previously missed... may be a hint at least.

update... seemed I was to quick... resend M122 gave this:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2-beta2 running on Duet WiFi 1.0 or 1.01 + DueX5
Board ID: 08DAM-999TL-MQ4SD-6J9F0-3S86T-14A7Y
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 24028
Dynamic ram: 101188 of which 44 recycled
Exception stack ram used: 264
Never used ram: 5548
Tasks: NETWORK(ready,139) HEAT(blocked,308) DUEX(blocked,36) MAIN(running,451) IDLE(ready,19)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:06:14 ago, cause: software
Last software reset at 2020-10-08 10:07, reason: AssertionFailed, GCodes spinning, available RAM 5196, slot 0
Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x20004264 Task MAIN
Stack: 0000059e 004716a8 00450849 00000008 ffffffff 20000e10 4d454144 200032a8 ffffffff 00000000 20002eb4 a5a5a5a5 004508cb 200042b0 0045e98c 20007940 0044e14f 200042cc 00446049 2000329c 200042cc 00000001 200042d4 00000000 004460b3 000000c8 200042d4
Error status: 0x04
MCU temperature: min 22.5, current 23.0, max 23.3
Supply voltage: min 24.3, current 24.5, max 24.7, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 0, standstill, SG min/max not available
Driver 1: position 0, standstill, SG min/max not available
Driver 2: position 0, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0, standstill, SG min/max not available
Driver 6: position 0, standstill, SG min/max not available
Driver 7: position 0, standstill, SG min/max not available
Driver 8: position 0, standstill, SG min/max not available
Driver 9: position 0, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-10-08 10:14:18
Cache data hit count 620253408
Slowest loop: 19.32ms; fastest: 0.17ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 12.0MBytes/sec
SD card longest read time 1.4ms, write time 6.1ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle 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 idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 201.84ms; fastest: 0.11ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 1
WiFi firmware version 1.24beta2-05b1
WiFi MAC address 5c:cf:7f:2b:e6:9b
WiFi Vcc 3.31, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25184
WiFi IP address 192.168.1.15
WiFi signal strength -47dBm, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 4 0 0 0 0 0 0
=== DueX ===
Read count 0, 0.00 reads/min

A Former User

Is it not an idea to use the Mk1 eyeball while printing a small test piece to allow you to adjust the extrusion factor for that particular material on the fly ?

T3P3Tony

@deckingman the work on the can support for mini 5+ did not change the functionality on any of the expansion boards.

A Former User

@T3P3Tony said in New firmware bundle 3.2beta2:

@deckingman the work on the can support for mini 5+ did not change the functionality on any of the expansion boards.

I think it should read :

The work on the can support for mini 5+ has not removed any of the current limitations on any of the expansion boards.

deckingman

@CaLviNx said in New firmware bundle 3.2beta2:

@T3P3Tony said in New firmware bundle 3.2beta2:

@deckingman the work on the can support for mini 5+ did not change the functionality on any of the expansion boards.

I think it should read :

The work on the can support for mini 5+ has not removed any of the current limitations on any of the expansion boards.

Or perhaps the release notes should say

"Supports Duet 3 Mini version 0.4 prototypes including limited CAN expansion" or "Supports Duet 3 Mini version 0.4 prototypes including CAN expansion (with limitations)." Either statement would be honest IMO.

oozeBot

@Nuramori @dc42 - the homing issues have reappeared this morning on 3.2b2. This is with a Duet3/RPi and a toolboard. Here is the relevant section from my config that has worked without issue until 3.2b2:

G1 X130 Y130 F24000			; aligns BLTouch in center of build plate
...
G30	Z-99999				; sets z-height relative to print bed
M561					; clear any bed transforms
G30 P0 X20 Y150 Z-99999			; probe midway between front and rear belt on left side
G30 P1 X280 Y150 Z-99999 S2		; probe midway between front and rear belt on right side

Now, on 3.2b2, sometimes it only probes once during G30 Z-99999. Sometimes it doesn't probe at all, then moves to the next G30 and fails. Sometimes, it makes it this far, then goes to X0 Y0 and does a probe there? That isn't even in the code..

@dc42 - There is definitely something wrong here. Please tell me how I can assist with testing to provide you better details.. I can also start another thread for the issue.

Stephen6309

@dc42 The BLTouch is doing a double tab on homing, like it does on G29 S0. Original BLTouch with a metal pin. It appears to be messing up the G31 offset. I change the offset and nothing changes. Also, when called in a macro: M117 and M118 to http, never displays the message, but it does when being called with M98. I use a macro to set the pla offset.

FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.2-beta2 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2020-10-05b2

Using a PI 4.

For emaple, I changed the offset from 2.5 to 2.8, and the first layer thickness never changes.
PLAOffset macro:
M118 P3 S"PLAOffset"
G31 P500 X0 Y-55 Z2.8 ; Set Z probe trigger value, offset and trigger height; increase to get closer

; homeall.g
; called to home all axes
;
M98 P"/sys/homex.g"
M98 P"/sys/homey.g"
M98 P"/sys/homez.g"

; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Tue Jul 21 2020 16:28:37 GMT-0400 (Eastern Daylight Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G1 H1 X-450 F3000 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000 ; go back a few mm
G1 H1 X-405 F360 ; move slowly to X axis endstop once more (second pass)
G1 H2 Z-5 F6000 ; lower Z again
G90 ; absolute positioning

; homey.g
; called to home the Y axis
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Tue Jul 21 2020 16:28:37 GMT-0400 (Eastern Daylight Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G1 H1 Y-350 F3000 ; move quickly to Y axis endstop and stop there (first pass)
G1 Y5 F6000 ; go back a few mm
G1 H1 Y-350 F360 ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z-5 F6000 ; lower Z again
G90 ; absolute positioning

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Tue Jul 21 2020 16:28:37 GMT-0400 (Eastern Daylight Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G90 ; absolute positioning
G1 X200 Y200 F6000 ; go to first probe point
G30 ; home Z by probing the bed

TC

@GrodanB I have the exact same problem. Seems like the M701 causes a reboot no matter where it is used. Even when selecting a filament in DWC

Here is my diagnostics:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2-beta2 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-917NK-F2MSW-6JKDG-3S86T-KZ5ND
Used output buffers: 1 of 24 (13 max)
=== RTOS ===
Static ram: 24028
Dynamic ram: 96364 of which 44 recycled
Exception stack ram used: 200
Never used ram: 10436
Tasks: NETWORK(ready,137) HEAT(blocked,308) DUEX(blocked,36) MAIN(running,445) IDLE(ready,19)
Owned mutexes:
=== Platform ===
Last reset 00:01:36 ago, cause: software
Last software reset at 2020-10-08 18:22, reason: AssertionFailed, GCodes spinning, available RAM 10436, slot 0
Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0x20004264 Task MAIN
Stack: 0000059e 004716a8 00450849 0000000d ffffffff 20000db0 4d454144 200032a8 ffffffff 00000000 20002eb4 a5a5a5a5 004508cb 200042b0 0045e98c 20007940 0044e14f 200042cc 00446049 2000329c 200042cc 00000001 200042d4 00000000 004460b3 000000c8 200042d4
Error status: 0x00
MCU temperature: min 34.4, current 35.2, max 35.4
Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 0, standstill, SG min/max not available
Driver 1: position 0, standstill, SG min/max not available
Driver 2: position 0, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0, standstill, SG min/max not available
Driver 6: position 0, standstill, SG min/max not available
Driver 7: position 0, standstill, SG min/max not available
Driver 8: position 0, standstill, SG min/max not available
Driver 9: position 0, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-10-08 18:24:23
Cache data hit count 187762902
Slowest loop: 11.53ms; fastest: 0.17ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.4ms, write time 13.9ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle 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 idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 50.53ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
Interface state active, link 100Mbps full duplex
=== DueX ===
Read count 1, 0.62 reads/min

GrodanB

@TC
Yes, seems like the same assert as I have.

That gives me hope that this is possible to recreate at duet3d.

@dc42 If you need to run special firmware to get extended diagnosis or if there is a logfile or similar please just tell me and I test it for you. So far the failure rate for this is 100%.

Other than this the firmware works rock solid on my Cartesian printer.

Another thing, have looked in the setting up documentation and the M221 G-Code reference page. I find no note of the updated/changed behaviour. I guess this is then a minor "bug report" for the documentation.

TC

@GrodanB Yes and I can confirm it is working in 3.2beta1

Touchthebitum

Hello
I just updated my firmware and I get this when I want to upload or modify my config.g file :
Operation failed (Reason: Access to the path '/opt/dsf/sd/sys/DuetWiFiServer-1.24beta2.bin' is denied.)
Here is the general info :
Board: Duet 3 MB6HC (MB6HC)
DSF Version: 3.2.0-beta2
Firmware: RepRapFirmware for Duet 3 MB6HC 3.2-beta2 (2020-10-05b2)
I made update and upgrade on my Raspberry Pi too.
Where am I wrong ?
Thanks

dc42

For those of you experiencing an unexpected reboot when M701 or M702 is used, there is a binary for Duet WiFi/Ethernet to fix this at https://www.dropbox.com/s/5vhjjz4a28hu33g/Duet2CombinedFirmware.bin?dl=0.

OwenD

@dc42
This update has fixed the M701 crashes for me.