RepRapFirmware 3.6.0-alpha.2 for Duet main boards available
-
@DonStauffer said in RepRapFirmware 3.6.0-alpha.2 for Duet main boards available:
@ProteanReverie Sorry I'm not up to speed on the latest features, but is there some particular feature that has to be enabled or configured to get that improvement in the ringing, or is it just improvements to the RFF code?
The difference between my pictures is only an update to the RFF code, but the difference in the code pertains to how input shaping is handled. So, if you are using input shaping the update should improve things. If not, you would likely need to configure input shaping as well as applying the update. You can learn more about Input Shaping for Duet here https://docs.duet3d.com/en/User_manual/Tuning/Input_shaping
-
Haven't used my RRF printer in a few months due to it not printing as well as the Qidi. I saw this post and decided to dust off the Jubilee and load up 3.6 alpha and give it a go. I only have a few prints in but see a big improvement in print quality over the 3.5 version it replaced. So far not having an issues but have only used a single tool. Will try to do a multi color this weekend.
-
@ProteanReverie said in RepRapFirmware 3.6.0-alpha.2 for Duet main boards available:
These tests were done with a Hemera Revo 0.4HF nozzle and PETG material. I am also starting tests with a 1.0 nozzle but do not have that data yet.
Here is data from my 1.0 nozzle tests.
Duet 2
accel test
3.5.2 = Never used RAM 11736, free system stack 112 words
3.6A2+3 = Never used RAM 22616, free system stack 116 wordsbenchy
3.5.2 = Never used RAM 11664, free system stack 122 words
3.6A2+3 = Never used RAM 18992, free system stack 116 wordsghost text
3.5.2 = Never used RAM 11808, free system stack 114 words
3.6A2+3 = Never used RAM 22112, free system stack 114 words
Duet 3
accel test
3.5.2 = Never used RAM 12068, free system stack 130 words
3.6A2+3 = Never used RAM 40076, free system stack 130 wordsbenchy
3.5.2 = Never used RAM 11972, free system stack 128 words
3.6A2+3 = Never used RAM 36236, free system stack 130 wordsghost text
3.5.2 = Never used RAM 12092, free system stack 128 words
3.6A2+3 = Never used RAM 39788, free system stack 130 words
additionally, here is data from the duet 3 using a 0.4 nozzle for the accel test model, since that data wasn't ready for my prior post
3.5.2 = Never used RAM 11876, free system stack 128 words
3.6A2+3 = Never used RAM 39884, free system stack 130 words
I have still not encountered any noticeable issues on either the Duet 2 Wi-Fi or Duet 3 Mini 5+ setups when using 3.6A2+3.
-
@dc42 I've been having major problems with bed leveling. One Z stepper either adjusts the wrong direction, or doesn't move at all. I had been doing extensive work on bed.g a few weeks ago and got it working perfectly. This problem doesn't correspond with that, but it gives a time frame which indicates to me there's something with this alpha version since that's the only major change since then. At that time I had probably run the routine 100 times in a row, working on LED issues. The actual leveling worked well.
-
@DonStauffer I too am having a similar problem with bed levelling. Printing with 3.6.0-alpha2+3 works fine and the input shaping is absolutely awesome! BTW, the printer I have is a delta.
The input shaping is so good that I am able to increase the accleration and jerk, without any artefacts. I was also able to drop the pressure advance value. I went from 0.21 to 0.14.
-
@balajiramani I need to look into input shaping. The pics I've seen a really awesome.
-
I've put new 3.6.0 alpha RRF builds at https://www.dropbox.com/scl/fo/yc7mnauicu5vqw6yegeq7/AKnV4j8k1MCADG4VE4EIG6Y?rlkey=skjxh23i9c953yvxm2tb8qr36&dl=0. Some notes:
- The issue with bed tramming might be fixed. I don't have a suitable machine to test it on.
- Scanning Z probes are fixed (they didn't work in previous 3.6.0 alpha releases)
- Also included are 3.6.0 alpha versions of some expansion board firmware (not EXP1HCL or M23CL). You can revert to 3.5.2 versions if you have any issues with them.
See https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-beta1-in-preparation for more details.
-
@dc42 Im just about to start deploying and testing 3.6.A2+4. and in a few weeks I should have a handful of Duet3 equipped machines ready for testing the firmware on.
Regarding the bed tramming bug on A2+3 I have not been able to repeat this bug using Duet2 hardware on a 2 z-motor setup. I have not tried this on my 3 z-motor setup yet. -
@Notepad the latest build is 3.6.0-alpha.4 which you can find at https://www.dropbox.com/scl/fo/cckwiq91gn16hvl1zdjnp/AF0SMEtkVfiArSPeYaBDGPY?rlkey=kqkknk9q1kiq684u4s55ce8d4&dl=0. Release notes are at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-alpha4-in-preparation,
-
@dc42 M260 lines in my initialization macro called by config.g in alpha 4 generate a message "Error: Command is not supported"
;------------------------------------------------------------------------------- ; InitNeoPix ;------------------------------------------------------------------------------- ; To disable NeoPixel LEDs, in config.g comment out the call to this macro. ; You must restart afterward (don't just run config.g). ;------------------------------------------------------------------------------- ; Defines global data, initializes NeoDriver and turns off LEDs. Preventing ; this macro from running at machine startup should effectively disable all ; NeoPixel=related macros. ; ; Parameters: ; A I2C Address (default: 0x60) ; N Number of LEDs (default: 28) ;------------------------------------------------------------------------------- ; Don Stauffer August, 2024 ;------------------------------------------------------------------------------- if global.DebugLevel >= 1200 echo "InitNeoPix" ;------------------------------------------------------------------------------- ; Enumeration Constants ;------------------------------------------------------------------------------- var FUNC_REG_PIN = 0x01 var FUNC_REG_SPEED = 0x02 var FUNC_REG_BUF_LENGTH = 0x03 var NEO_DRIVER_PIN_NUM = 0x0F var SPEED400khz = 0 var SPEED800khz = 1 ;------------------------------------------------------------------------------- ; Other Constants ;------------------------------------------------------------------------------- var ADDR_BASE = 0x0E ;------------------------------------------------------------------------------- ; Parameters ;------------------------------------------------------------------------------- var AddrI2C = (exists(param.A) ? param. A : 0x60) var LEDCount = (exists(param.N) ? param.N : 28) ;------------------------------------------------------------------------------- ; Define global NeoPixel array ;------------------------------------------------------------------------------- if exists(global.NeoPix) set global.NeoPix = vector(2, vector(var.LEDCount, null)) else global NeoPix = vector(2, vector(var.LEDCount, null)) ;------------------------------------------------------------------------------- ; Initialize NeoDriver card settings ;------------------------------------------------------------------------------- M260 A{var.AddrI2C} B{var.ADDR_BASE, var.FUNC_REG_PIN, var.NEO_DRIVER_PIN_NUM} M260 A{var.AddrI2C} B{var.ADDR_BASE, var.FUNC_REG_SPEED, var.SPEED800khz} M260 A{var.AddrI2C} B{var.ADDR_BASE, var.FUNC_REG_BUF_LENGTH, 3 *var.LEDCount,0} ;------------------------------------------------------------------------------- ; Turn all LEDs off ;------------------------------------------------------------------------------- G4 P500 echo "5" M98 P"/macros/Lights/NeoPixel/TurnOffAll" A{var.AddrI2C} ;------------------------------------------------------------------------------- if global.DebugLevel >= 1200 echo "Leaving InitNeoPix" ;-------------------------------------------------------------------------------
-
@dc42 I am still seeing failures and head crashing into the bed on running G32 calibration on a delta. Is this a known issue?
-
@balajiramani are you definitely running the 3.6.0-alpha.4 build? There was a minor bug in G32 calibration on deltas in early 3.6.0 alpha builds but I fixed that some time ago.
-
@DonStauffer does that same macro work if you invoke it from the DWC command line using M98?
-
@dc42 Yes, I downloaded it from the latest link you posted. Here is a screenshot.
-
@balajiramani my delta is working perfectly with alpha.4. Please post your bed.g file and provide more details about when the probing sequence goes wrong.
-
@dc42 Here is a video that shows the crash - https://forum.duet3d.com/assets/uploads/files/1721977512327-pxl_20240726_065615215-2.mp4. The motion from from one probe point to the other is more of a 'U' shaped travel, instead of a straight line.
Let me know if you need any other information.
Here is bed.g file.
M561 ; clear any bed transform, otherwise homing may be at the wrong height M290 R0 S0 ; Remove any baby stepping ; bed.g file for RepRapFirmware, generated by Escher3D calculator ; 16 points, 4 factors, probing radius: 150, probe offset (0, 0) ; If the printer hasn't been homed, home it if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed G28 ; Probe the bed and do auto calibration G1 X0 Y0 Z10 F10000 ; go to just above the first probe point while true if iterations = 5 abort "Too many auto calibration attempts" G30 P0 X0.00 Y150.00 Z-99999 H0 if result != 0 continue G30 P1 X96.42 Y114.91 Z-99999 H0 if result != 0 continue G30 P2 X147.72 Y26.05 Z-99999 H0 if result != 0 continue G30 P3 X129.90 Y-75.00 Z-99999 H0 if result != 0 continue G30 P4 X51.30 Y-140.95 Z-99999 H0 if result != 0 continue G30 P5 X-51.30 Y-140.95 Z-99999 H0 if result != 0 continue G30 P6 X-129.90 Y-75.00 Z-99999 H0 if result != 0 continue G30 P7 X-147.72 Y26.05 Z-99999 H0 if result != 0 continue G30 P8 X-96.42 Y114.91 Z-99999 H0 if result != 0 continue G30 P9 X0.00 Y75.00 Z-99999 H0 if result != 0 continue G30 P10 X64.95 Y37.50 Z-99999 H0 if result != 0 continue G30 P11 X64.95 Y-37.50 Z-99999 H0 if result != 0 continue G30 P12 X0.00 Y-75.00 Z-99999 H0 if result != 0 continue G30 P13 X-64.95 Y-37.50 Z-99999 H0 if result != 0 continue G30 P14 X-64.95 Y37.50 Z-99999 H0 if result != 0 continue G30 P15 X0 Y0 Z-99999 S6 if result != 0 continue if move.calibration.initial.deviation <= 0.03 break echo "Repeating calibration because deviation is too high (" ^ move.calibration.initial.deviation ^ "mm)" ; end loop echo "Auto calibration successful, deviation", move.calibration.final.deviation ^ "mm"
-
@balajiramani it sounds to me that segmentation is not working on those moves. If you send M669 without parameters, what does it report?
-
@dc42 Here is what I see:
M669 Kinematics is Linear delta, 100 segments/sec, min. segment length 0.20mm
-
@dc42 Just had time to TRY a print with the
alpha.4
binaries you uploaded the other day (on both the D3 Mini & the 1LC), and the bed leveling seems to be working.BUT now the extruder won't extrude (or retract for that matter), either through G-code or if I to use the "extrude buttons" in DWC & PD.
When I canceled the print on PD i got these error messages:
CAN response timeout: board 121, req type 6044, RID 220. Error: at column 2: G10: hA CAN response timeout: board 121, req type 6029, RID 222 CAN response timeout: board 121, req type 6044, RID 223
Which is new behaviour from
alpha.2+3
.AND the hotend heater (connected to the 1LC) won't turn off. Both DWC & PD show active/standby heat to be
0
, but the heater is still at working temp (255c).
If i manually try to input0
in active on DWC and push enter i get this error:M568 P0 S0 Error: at column 2: M568: P
The only way I've found to actually make it turn off/adjust the temp down is to power toggle or restart the printer.
-
@Exerqtor What version of the firmware do you have installed on the 1LC?