New firmware bundle 3.2beta2
-
@Stephen6309 said in New firmware bundle 3.2beta2:
What happened to viewing the Height Map?
From the release notes: The Height Map has been moved to a built-in plugin (see Settings -> General -> Plugins)
-
@Phaedrux It would be the one I didn't read far enough.
-
Do not know if related to above but I cannot get any change in extrudes amount when sending
M221 S120.0 D1or
M221 S100.0 D1This is my calibration script. I measure 120 mm and put a marker on the filament run this script asking for 100mm extrusion... and the difference is put in the filament config file...
This has worked fine in 2.xT0 ; Select first hot end G21 ; Metric G90 ; Absolute positioning M83 ; Relative extrusion M118 S"Homing Axis." ; Output progress message G28 ; Home all axis M118 S"Docking Printhead." ; Output progress message G1 X70 Y200 F3000 ; Move first in front of docking notch G1 X70 Y235 F3000 ; Dock print head T1 ; Select second hot end M116 ; Wait until all set tempteratures are reached G92 E0 ; Set Position of extruder to zero G1 E100 F200 ; Extrude 100mm G92 E0 ; Set Position of extruder to zero M118 S"100mm Extruded." ; Output progress message G1 X70 Y0 F3000 ; Move to front to make it easier to measure amount extruded -
@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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@GrodanB said in New firmware bundle 3.2beta2:
This is my calibration script. I measure 120 mm and put a marker on the filament run this script asking for 100mm extrusion... and the difference is put in the filament config file...
This has worked fine in 2.xM221 no longer affects extruder-only moves.
-
@dc42 said in New firmware bundle 3.2beta2:
@GrodanB said in New firmware bundle 3.2beta2:
This is my calibration script. I measure 120 mm and put a marker on the filament run this script asking for 100mm extrusion... and the difference is put in the filament config file...
This has worked fine in 2.xM221 no longer affects extruder-only moves.
Why?
And just for my curiosity when does it affect the extrusion?
This was so great to have in my config and keep my e-steps for the extruder constant.
Is there an alternative?
Did miss that completely when upgrading.
-
@dc42 Yes, I'll test that ASAP. Just printing a my first larger part on 3.2 and after that I'll try.
So ASAP is probably very late or tomorrow...
So far everything else is working great.
-
I've been having similar issues - when it goes to pick up the tools when I start a print, it tells me that my there isn't any heaters or anything on Board 1 (3hc, where I have my tools) and cancels and forces (via webpage) a reset of the whole printer. I'm unable to pull a M122 from the web, so I'll have to give it a shot via a different utility to get better diagnostic data.
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.2-beta2 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode) Board ID: 08DGM-9T66A-G63SJ-6J1DG-3SD6K-9V0MA Used output buffers: 1 of 40 (14 max) === RTOS === Static ram: 157532 Dynamic ram: 138164 of which 44 recycled Exception stack ram used: 528 Never used ram: 96948 Tasks: Linux(ready,20) HEAT(blocked,278) CanReceiv(blocked,873) CanSender(blocked,352) CanClock(blocked,353) TMC(blocked,20) MAIN(running,1208) IDLE(ready,20) Owned mutexes: HTTP(MAIN) === Platform === Last reset 02:55:36 ago, cause: software Last software reset at 2020-10-06 18:29, reason: User, Platform spinning, available RAM 97344, slot 0 Software reset code 0x0000 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task Linu Error status: 0x00 MCU temperature: min 40.0, current 41.8, max 44.7 Supply voltage: min 23.8, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0 Driver 0: position 49600, standstill, reads 53251, writes 27 timeouts 0, SG min/max 0/349 Driver 1: position 46400, standstill, reads 53252, writes 27 timeouts 0, SG min/max 0/365 Driver 2: position 24000, standstill, reads 53256, writes 23 timeouts 0, SG min/max 0/65 Driver 3: position 12300, standstill, reads 53257, writes 23 timeouts 0, SG min/max 0/294 Driver 4: position 0, standstill, reads 53257, writes 23 timeouts 0, SG min/max 0/284 Driver 5: position 0, standstill, reads 53258, writes 23 timeouts 0, SG min/max 0/284 Date/time: 2020-10-06 21:25:17 Slowest loop: 7274.81ms; fastest: 0.21ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 373, MaxWait: 2570081ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 43, completed moves: 43, 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 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is ready with "M122" 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 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages sent 42212, send timeouts 42212, longest wait 2ms for type 6013, free CAN buffers 48 === SBC interface === State: 0, failed transfers: 0 Last transfer: 18ms ago RX/TX seq numbers: 44751/16533 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.0-beta2 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 32.68 -
@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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
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.
-
@Nuramori said in New firmware bundle 3.2beta2:
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..
-
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.
-
@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.
-
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.
-
@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.
-
@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 -
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 ?
-
@deckingman the work on the can support for mini 5+ did not change the functionality on any of the expansion boards.
-
@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.
-
@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.
