RepRapFirmware 3.6.0-alpha.4+3 available for testing
-
@dc42 I added M400 prior to macro calls for lock and unlock and stuck one in the macro as well... Following are the macros if that helps and a couple of pictures showing the pin when a failure occurs.. Pin should be horizontal when unlocked and stop should be at the limit switch, when there's a tool drop the stepper never reaches the limit switch...
tool_lock.g
; Engage the toolchanger lock. RepRap Firmware V2.0.1 version. G91 ; Set relative mode G1 U10 F5000 H0 ; Back off the limit switch with a small move M400 G1 U200 F5000 H1 ; Perform up to one rotation looking for the torque limit switch ;G1 U200 Y0.5 F5000 H1 ; Perform up to one rotation looking for the torque limit switch G90 ; Set absolute mode tool_unlock.g
; Disengage the toolchanger lock G91 ; Set relative movements G1 U-4 F9000 H2 ; Back off the limit switch with a small move M400 G1 U-360 F9000 H1 ; Perform up to one rotation looking for the home limit switch G90 ; Restore absolute movements 
-
Will try the M400 commands and if they don't help, I'll disable IS at start of tool change and re-enable it after tool is picked up.
Thanks for the assistance
-
A quickie follow up, several prints, maybe 50'ish tool changes and no issues. It appears as if the M400 is helping.
-
I want to chime in and report that the 3.6.0 5+1 alpha has been working well for me. I have not run any long prints, and I don't probe or tool change, but I changed over from 3.5.1 because I was hitting suspicious layer shifts at well below expected accelerations for printing moves only (not for travels) in speedboat testing. I have run 25 prints since changing over Sept 3rd, along with various non-printing tuning and tests, at accelerations from 50-200k and in-print speeds up to 900mm/s, on a 6WD delta at 400 steps/mm (6HC with a 3HC running a 2WD extruder), as I've been working into the three-minute range on regulation boats. (Yes, it's not a particularly useful pastime, but my machine is finally finished and I've gotta do it once -- plus I'm hoping it's a useful stress test of the new motion stuff in 3.6.0.) The new IS melts down print crispness at these accels, but after some deep breathing I've concluded that's not a bad thing -- if you want crispy prints, the answer is to print in the accel range that's sane for your machine, anyway.
Part of my testing has been aimed at stress testing the delta segmentation change -- I've tested from 100 to 400 seg/s with 0.1 to 0.2mm segment length, as well as accidentally 0.1seg/sec and 400mm min length, and apart from the latter booboo there is little observable difference in quality at high speeds and no difference I've yet found in terms of speed ceiling. I have found that high speeds with high-poly models are causing reports of underruns in the first array slot and, sometimes, very small numbers of LaErrors -- e.g., a 67-layer test vase print with a portion that is a 200-segment, 10mm-diameter circle, sliced at 350 x 100k x 20 jerk consistently reports back underruns [800+,0,0] -- but I don't have comparison data from before I updated, so I don't know if this has anything to do with the alpha. I do know that the circle in that stress test print shows evidence of slowdowns starting at about the same segment count as the move queue length, and that extending the queue length with M595 causes proportionately more reported underruns. (I changed SD cards, just to see if the originally-supplied card with its 4kb clusters was an issue, but a new 32GB card with 32kb clusters did not change anything.) For my foolishly-fast speedboat runs, I've dodged the issue by enabling Arc Welder, which seems to work just fine.
To date I have yet to see a single reported hiccup, regardless of LaError or underrun counts.
I hope the above is useful!
-
@Kiolia thanks for your report. It's good to hear when things are working well, not just when there are problems.
-
@dc42 Cheers! And if there's anything in particular I can look out for and/or try while I'm breaking in my delta, please let me know.
-
@Kiolia not really, just watch out for changes in behaviour. The only bug I am aware of in 3.6 that is not in 3.5.3-rc.1 relates to expansion boards and homing moves.
-
Day 3 without any tool drops so I'm going to say inserting M400 prior to tool lock/unlock macros is working. Out of curiosity, will this be addressed in the final release or will the M400 always be required? It won't matter much for me as I'll likely forget to remove it when the 3.6 is released but I am curious.
-
@edsped I haven't decided yet. We'd need to either disable IS throughout tool change files, or implicitly wait for motion to stop between certain pairs of moves - but what pairs, exactly? I'm not sure that either of those would be appropriate in all circumstances. We could add a means of specifying that a certain axis is used as a tool locking mechanism, but would that be any better than advising users where to use M400?
-
If people don't want to sprinkle M400s, they could also disable and re enable IS at the beginning and end of the macros.
-
@oliof yes. I am considering extending M593 to allow IS to be turned off and then turned on again without needing to specify the parameters.
-
Okay, I'm back with a problem report with my delta. I noticed during extrusion "blob" testing tonight that it was making a light clunking noise during each blob extrude. At first I assumed it was the extruder, but it was happening on all the blobs, and doing it the most on the lowest cubic (slowest) ones. To judge from finger-on-arms, it may only be the Z axis (AWD, so this is two steppers). IS on/off does not affect it. It is reproducible without extrusion, too, using a very slow move with Z component like G1 X3 Y1 Z20.5 F16.84 starting from X0 Y0 Z1. There is no discernible interval to the clunking; it sounds random, and it happened at least once on most of the blobs, which were done across the bulk of the bed area. M122 shows nothing amiss to my eyes. I can confirm that this wasn't happening with nigh-identical GCode in 3.5.1. I think I've seen this or something similar reported already, but I thought that was connected somehow to IS, and this doesn't seem to be.
-
@Kiolia Hi, thanks for your report. I think this may be related to this issue: https://github.com/Duet3D/RepRapFirmware/issues/1015. I don't think this has been fixed in 3.6.0 yet, so one for @dc42.
Ian
-
@droftarts Some additional test results. At least for me, it is new for 3.6.0 and specific to very slow moves, not IS or bed location-related. I executed the following sequence of moves this morning, starting from X0 Y0 Z1, and heard the noise (which sounds like a light motor skip) multiple times on all 6. With the exception of move number 4, which had many skip/clunk noises throughout, the starts of the moves did NOT make noises at first -- I would estimate at least the first 10-15 seconds of the other 5 were all noise-free.
-
@Kiolia thanks, I'll test this on my own delta next week. @droftarts can you test this too?
-
@dc42 If it's needed for repro, I'm running x32 on 0.9s / 16Ts for 400 steps / mm and set segmentation to 400/sec 0.2mm min length. (if you need the rest of my config let me know.) I haven't tested to see if there's a specific speed threshold for the behavior, but the way that the noises often don't start for some seconds makes me wonder if the duration of the move is a factor, rather than just the speed.
-
I just started a long print (6+ hours) and approximately 2.5 hours into the print, the job failed with the "Error: Movement halted because a step timing error occurred (code 3). Please reset the controller." error. This is with the 3.6.0-alpha.5+1 firmware.
Here is the output of M112 right after the error:
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-alpha.5+1 (2024-08-31 17:50:58) running on Duet WiFi 1.0 or 1.01 Board ID: 08DAM-999TL-MQ4SD-6JTDL-3SS6N-968BX Used output buffers: 13 of 26 (21 max) === RTOS === Static ram: 23360 Dynamic ram: 67504 of which 12 recycled Never used RAM 11864, free system stack 102 words Tasks: NETWORK(2,nWait 6,15.3%,195) HEAT(3,nWait 5,0.1%,309) Move(4,invalid,5.2%,266) MAIN(1,running,79.4%,752) IDLE(0,ready,0.0%,29), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 02:31:01 ago, cause: software Last software reset at 2024-09-16 11:25, reason: User, Gcodes spinning, available RAM 28192, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 MCU temperature: min 27.7, current 48.5, max 49.4 Supply voltage: min 23.5, current 24.2, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/2, heap memory allocated/used/recyclable 2048/1132/1072, gc cycles 1 Events: 0 queued, 0 completed Date/time: 2024-09-16 13:56:21 Slowest loop: 218.04ms; fastest: 0.13ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 9.4ms, write time 3.1ms, max retries 0 === Move === Segments created 639, maxWait 442509ms, bed comp in use: none, height map offset 0.000, hiccups added 5 (0.15ms), max steps late 1, ebfmin 0.00, ebfmax 0.00 Pos req/act/dcf: 68366.00/68371/-0.79 66822.00/66848/-0.92 76754.00/76740/0.84 no step interrupt scheduled Driver 0: standstill, SG min 0 Driver 1: standstill, SG min 0 Driver 2: standstill, SG min 0 Driver 3: standstill, SG min 0 Driver 4: standstill, SG min n/a Driver 5: Driver 6: Driver 7: Driver 8: Driver 9: Driver 10: Driver 11: === DDARing 0 === Scheduled moves 912010, completed 912008, LaErrors 0, Underruns [17, 0, 0] === Heat === Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.1 Heater 1 is on, I-accum = 0.2 === GCodes === Movement locks held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is doing "G1 X-6.539 Y47.848" 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 Q0 segments left 1 Code queue 0 is empty === Network === Slowest loop: 195.01ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(4) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 1 of 8 === WiFi === Interface state: active Module is connected to access point Failed messages: pending 0, notrdy 0, noresp 0 Firmware version 2.1.0 MAC address 5c:cf:7f:2c:25:00 Module reset reason: Turned on by main processor, Vcc 3.40, flash size 4194304, free heap 40984 WiFi IP address 192.168.1.61 Signal strength -28dBm, channel 6, mode 802.11n, reconnections 0 Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0 Here is config.g:
; Setup some global variables global power_fail_retract = 2 ; Retract 2mm when power fails ; Communication and general M550 P"BigDelta" ; Machine name and Netbios name (can be anything you like) M551 Preprap ; Machine password (used for FTP) M552 S1 ; Enable WiFi. Disabled for setup and testing. Enable once set up on your network. ; Enable telnet M586 S1 P2 ; Debugging M111 S0 ; Debug off M929 P"eventlog.txt" S1 ; Start logging to file eventlog.txt M555 P2 ; Set output to look like Marlin G21 ; Work in millimetres G90 ; Send absolute coordinates... M83 ; ...but relative extruder moves ; Axis and motor configuration M569 P0 S0 ; Drive 0 goes backwards M569 P1 S0 ; Drive 1 goes backwards M569 P2 S0 ; Drive 2 goes backwards M569 P3 S0 ; Drive 3 goes backwards ; Assign extruder drive M584 E3 ; Set homing switch config M574 X2 S1 P"!xstop" ; Set homing switch configuration on S1 = high-end, active-low M574 Y2 S1 P"!ystop" ; Set homing switch configuration on S1 = high-end, active-low M574 Z2 S1 P"!zstop" ; Set homing switch configuration on S1 = high-end, active-low ; Set it as a linear delta M669 K3 ; Setup paneldue 5i M575 P1 S1 B57600 M665 R215.062 L395.317:395.475:395.433 B160 H374.050 ; set delta radius, diagonal rod length, printable radius and homed height M666 X0 Y0 Z0 ; put your endstop adjustments here, or let auto calibration find them M350 X16 Y16 Z16 E16 I1 ; Set 16x microstepping with interpolation M92 X200 Y200 Z200 ; Set axis steps/mm M906 X1400 Y1400 Z1400 E1400 I60 ; Set motor currents (mA) and increase idle current to 60% M84 S60 ; Set idle timeout M201 X12000 Y12000 Z2000 E10000 ; Accelerations (mm/s^2) M203 X30000 Y30000 Z5000 E3600 ; Maximum speeds (mm/min) ;M566 X900 Y900 Z300 E1200 P1 ; Maximum instant speed changes mm/minute ;M566 X300 Y300 Z300 E450 P1 ; Maximum instant speed changes mm/minute M566 X600 Y600 Z300 E900 P1 ; Maximum instant speed changes mm/minute M204 P9000 T9000 ; Set acceleration for print and travel moves ; Configure Input shaping M593 P"zvdd" F45 ; Thermistors M308 S0 P"bed_temp" Y"thermistor" T100000 B3950 R4700 H30 L0 ; Put your own H and/or L values here to set the bed thermistor ADC correction M308 S1 P"e0_temp" Y"thermistor" T100000 B3950 R4700 H30 L0 ; 100K NTC ;M308 S1 P"e0_temp" Y"thermistor" T100000 B4658 C6.5338987554e-08 ; 104-NT Aliexpress thermistor M950 H0 C"bed_heat" T0 ; Set up H0 as the bed heater using T0 as the sensor M950 H1 C"e0_heat" T1 ; Set up H1 as the extruder heater using T1 as the sensor M140 H0 ; Map H0 as the bed heater ; Set temperature excursion warnings M570 H0 P20 M570 H1 P20 M308 S3 Y"mcu-temp" A"MCU" ; configure sensor 3 as thermistor on pin e1temp for left stepper M308 S4 Y"drivers" A"Drivers" ; configure sensor 4 as temperature warning and overheat flags on the TMC2660 on Duet M912 P0 S-3.5 ; Calibrate MCU temp ; Fan definitions M950 F0 C"fan0" M950 F1 C"fan1" M950 F2 C"fan2" ; Thermostatic fan on 1 for cooling the hotend M106 P1 T50 H1 ; Thermostatic fan on 2 for cooling the board M106 P2 H3:4 L.3 X1 B0.3 T35:70 ; set fan 2 value ; Tool definitions M563 P0 D0 H1 ; Define tool 0 G10 P0 S0 R0 ; Set tool 0 operating and standby temperatures ;M92 E1392 ; Based on https://www.thingiverse.com/thing:1359717; 2023/01/06 M92 E1077.1646 ; This is the new value for the hobb-goblin extruder. 03/07/2023 ;M92 E319.2005 ; Set extruder steps per mm. This is for the MK8 gear ; Z probe and compensation definition M558 P8 C"^!zprobe.in" R0.4 H4 F1200 T6000 A5 S0.01 ; Z probe is a piezo sensor G31 X0 Y0 Z-0.08 P100 ; Set the zprobe height and threshold M557 R150 S20 ; Probe within a radius of 150mm and mesh spacing of 20 M376 H5 ; Taper off bed compensation after 5mm ; Configure power failure and resume M911 S21.0 R23.0 P"G91 M83 G1 Z3 E{-global.power_fail_retract} F1000" ; Relative movement and extrusion. Move head up and retract 2mm filament. M208 S1 Z-0.5 ; set minimum Z T0 ; select first hot end M501 ; Load any config overrides -
@dc42 I just had the same error as reported by @balajiramani . In my case, the error occurred during the first layer of a print job.
=== Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.6.0-alpha.5+1 (2024-08-31 17:51:17) running on Duet 3 MB6HC v1.01 (SBC mode) Board ID: 0JD2M-999AL-D25S4-7J1D2-3SJ6K-T51V3 Used output buffers: 1 of 40 (18 max) === RTOS === Static ram: 135136 Dynamic ram: 96472 of which 0 recycled Never used RAM 68768, free system stack 198 words Tasks: SBC(2,ready,0.8%,796) HEAT(3,nWait 6,0.0%,369) Move(4,nWait 6,0.0%,333) TMC(4,nWait 6,2.8%,353) CanReceiv(6,nWait 1,0.1%,794) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,353) MAIN(2,running,93.9%,440) IDLE(0,ready,2.4%,29), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:00:37 ago, cause: software Last software reset at 2024-09-18 18:45, reason: User, Expansion spinning, available RAM 65064, slot 0 Software reset code 0x6012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 MCU temperature: min 33.9, current 34.3, max 34.5 Supply voltage: min 22.7, current 23.5, max 23.6, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.1, max 12.1, under voltage events: 0 Heap OK, handles allocated/used 99/4, heap memory allocated/used/recyclable 2048/88/40, gc cycles 0 Events: 0 queued, 0 completed Date/time: 2024-09-18 18:46:21 Slowest loop: 25.07ms; fastest: 0.07ms === Storage === Free file entries: 20 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 === Segments created 0, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00 Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00 next step interrupt due in 297 ticks, disabled Driver 0: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0 Driver 1: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0 Driver 2: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0 Driver 3: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0 Driver 4: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0 Driver 5: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0 Phase step loop runtime (us): min=0, max=2, frequency (Hz): min=1913, max=2089 === DDARing 0 === Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0] === DDARing 1 === Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0] === Heat === Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.0 Heater 1 is on, I-accum = 0.0 === GCodes === Movement locks held by null, null HTTP* is doing "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 File2 is idle in state(s) 0 Queue2 is idle in state(s) 0 Q0 segments left 0, axes/extruders owned 0x80000003 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === Filament sensors === check 0 clear 0 Extruder 0 sensor: no filament === CAN === Messages queued 252, received 2403, lost 0, ignored 0, errs 315, boc 0 Longest wait 55ms for reply type 6041, peak Tx sync delay 50472, free buffers 50 (min 49), ts 187/186/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 1854/1854 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2858c Buffer RX/TX: 0/0-0, open files: 0 === Duet Control Server === Duet Control Server version 3.5.2 (2024-06-12 07:09:26, 32-bit) HTTP+Executed: > Executing M122 Code buffer space: 4096 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 60.06, max time between full transfers: 125.2ms, max pin wait times: 33.5ms/14.1ms Codes per second: 2.94 Maximum length of RX/TX data transfers: 4476/1040 -
@MaxGyver is it repeatable? If so then please post your config.g file and the GCode file.
-
@dc42 I was wondering when we might a fix for this issue? I really like the quality of the prints with 3.6 and hence don't want to downgrade, but can't start a long print because of the step timing error.
