Firmware 3.4b7 - firmware retraction bug
Firmware retraction/unretraction speed defined in M207 not respected.
It has been bugged in previous 3.4 versions as well. tried to open GitHub issue but issue template asking me to open forum post before posting an issue, so I didn’t want to bother reporting the issue prior.
@natthapol-vanasrivilai thanks for reporting this. How did you tell that it isn't being respected? Perhaps you set a long retraction at a very slow speed?
natthapol.v last edited by natthapol.v
@dc42 Hi, my printer has relatively long bowden tube. The retraction is set at around 8-12mm depending on the filament used. The retract/unretract speed is set to be around 6000mm/min. The wheezing sound of the bowden extruder driving the filament forward/reverse is pretty much in memory for the 3D printer I used. The sound of the retraction speed on v3.3 is consistent. On v3.4, it sometime retract at the set speed and unretract extremely fast (the motor sound higher due to faster speed). And this happened randomly between retract or unretract moves.
I've attached the filament config.g and the Duet config.g in case it help with debugging the behavior.
@natthapol-vanasrivilai are you certain that your slicer isn't inserting any direct retraction moves, i.e. G1 Exxx ? I can't see how the firmware retraction behaviour could have changed in recent firmware versions, because that code hasn't been touched.
@dc42 I've flashed back and forth between 3.3 and 3.4 before, and could confirm from the same print gcode that the retraction behavior differs in these two versions. I've also tried with Input Shaping/Pressure Advance turned off.
@dc42 I've attached a video of the issue.
The firmware retraction is set to
M207 S10 R0.0 F2400 Z0.2
No extra T parameter to specify the unretract speed.
The extruder is sometime retracting/unretracting at the speed way above the M207 definition.
Below is the M122 during this printing session.
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta7 (2021-12-16 12:22:11) running on Duet WiFi 1.02 or later + DueX5 Board ID: 0JD0M-9P6M2-NWNS0-7JTD2-3SN6Q-TV0RK Used output buffers: 3 of 24 (23 max) === RTOS === Static ram: 23804 Dynamic ram: 75784 of which 12 recycled Never used RAM 8808, free system stack 102 words Tasks: NETWORK(ready,14.0%,237) HEAT(notifyWait,0.1%,311) Move(notifyWait,1.4%,285) DUEX(notifyWait,0.0%,24) MAIN(running,84.4%,440) IDLE(ready,0.1%,30), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:26:10 ago, cause: software Last software reset at 2021-12-23 10:51, reason: User, GCodes spinning, available RAM 9952, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Step timer max interval 0 MCU temperature: min 37.6, current 42.0, max 43.1 Supply voltage: min 23.9, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/6, heap memory allocated/used/recyclable 2048/708/510, gc cycles 0 Events: 3 queued, 3 completed Driver 0: pos 38686, standstill, SG min 0 Driver 1: pos -867, standstill, SG min 0 Driver 2: pos 1425, standstill, SG min n/a Driver 3: pos 0, standstill, SG min n/a Driver 4: pos 0, standstill, SG min n/a Driver 5: pos 0, standstill, SG min 0 Driver 6: pos 0, standstill, SG min 0 Driver 7: pos 0, ok, SG min 0 Driver 8: pos 0, standstill, SG min n/a Driver 9: pos 0, standstill, SG min n/a Driver 10: pos 0 Driver 11: pos 0 Date/time: 2021-12-23 11:17:32 Cache data hit count 4294967295 Slowest loop: 134.83ms; fastest: 0.10ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 9 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 2.0ms, write time 116.3ms, max retries 0 === Move === DMs created 83, segments created 34, maxWait 342508ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 10138, completed 10113, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3 === AuxDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -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.7 === GCodes === Segments left: 1 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is doing "G1 X216.088 Y249.907 F30000" 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 === DueX === Read count 1, 0.04 reads/min === Network === Slowest loop: 134.14ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 2 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.26 WiFi MAC address f4:cf:a2:ea:89:e6 WiFi Vcc 3.38, reset reason Power up WiFi flash size 4194304, free heap 25776 WiFi IP address 192.168.1.49 WiFi signal strength -39dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0
Diamondback last edited by
I might have something to add to this.
I am using automatic filament load/unload macros with the DWC filament feature and I noticed that since a while (sorry, can't quite tell since when ) the unloading is sometimes weird.
My unloading works as follows:
- Retract 5mm
- Wait a bit
- Retract another 180mm to definitely get the filament out of the extruder
G91 G1 E-5 F2000 G4 S2 G1 E-180 F2000 G90
This generally works fine, but from time to time the extruder seems to spin at insane speeds during this code, I never found any pattern to it and it doesn't seem to skip lots of steps so things technically work and so far I didn't bother looking into it.
I am using firmware retraction as well for prints, but in this specific case, no firmware retraction is being asked for.
@diamondback Have you had any issue with firmware retraction as well?
Try printing the retraction calibration tower at around 30mm/s retraction speed and something the extruder retract/unretract faster than Formula 1.
Diamondback last edited by
@natthapol-vanasrivilai I personally haven't noticed any such issues, but then again, I don't print retraction towers very often and run just 0.6mm retraction on prints, so I probably wouldn't even notice if it messed up sometimes.
I'll try to print one when I find time and see if things go wrong.
@diamondback thanks for that datapoint. That confirms my feeling that this issue reported by @natthapol-vanasrivilai isn't to do with firmware retraction in particular.
@natthapol-vanasrivilai are you using pressure advance? If so, please do a print using 3.4.0b7 and no pressure advance, and report whether the odd noises are still produced.
@dc42 Hi, I haven't enable Pressure Advance on this firmware as seen in the attached filament config file.
I've had issue with pressure advance grinding the filament in the extruder on long bowden setup. Probably due to my pressure advance, extruder jerk/acceleration settings so it has been disabled on this machine.
I can confirm this strange behavior. I have an afterburner direct and from 3.4b6 I started to have problems with clogging in the parts where there were many retraction commands during the prints and the sound of the retraction was accentuated compared to 3.3. Same with 3.4b7. The parameters were M207 S0.5 F2100 Z0.0, I changed to M207 S0.2 F500 and for now it seems that the clogging is gone.
No pressure advance.
bberger last edited by bberger
I can also confirm that something is off with PA in the 3.4 beta release(s?). I just upgraded from 3.3 to the 3.4b7 and with PA on the printer doesn't feed enough filament anymore.
Basically similar behaviour you'd get when either turning up PA too much (I use 0.15 on a very short bowden tube on a flying extrude) or use too low retraction speeds.
When I turn off PA the issue is gone.
Argo last edited by
I had similar issues with input shaping + pressure advance in 3.4b6:
Maybe there are issues with higher PA values in general.
@argo I have not had my PA activated for this issue to happen. I believe this issue neither related to Pressure Advance nor Input Shaping.
Can any of you provide a short print (preferably only one layer) and associated config.g file that reliably demonstrates this issue? Preferably in the form of the sound being different between RRF 3.3 and 3.4beta7 when the printer settings are identical. I don't mind whether PA is needed or not.
@dc42 Hi, I will setup some print files and all the associated settings and send it to you in couple of hours.
@natthapol-vanasrivilai @danzaywer has either of you been able to produce a GCode file and associated config.g file that reliably demonstrate this problem?
@Argo if your issue only occurs when high PA and IS are together then I think it is a different issue. We already know that when input shaping is enabled, PA is affected and may need to be tuned again.
@dc42 My current configuration would not work on 3.3, I have to bypass the toolchange macros. Anyway, can I downgrade from 3.4b7 to 3.3 simply by uploading the 3.3 files?
@dc42 Hi sorry that it took too long on my part.
I've attached the zip containing the files from SD card.
config, gcode, filament and macros that are used in startup/ending sequences.
The forum doesn't allow me to upload zip file, so please rename the file extension to ".zip" afterwards
The attached gcode file is just a bunch of 5x0.2mm hollowed cylinders. The machine and gcode is setup to do firmware retraction.
Argo last edited by
Coming from 3.3 the same PA values (with input shaper enabled) result in more or less bulging corners with 3.4b7. Increasing PA (from 0.065 to almost 0.1) then to get almost as sharp corners as with 3.3 results in starving infill lines which do not connect properly to the perimeter.
I‘ve added pics in my other thread.
@dc42 I still can't downgrade but I found out what could have caused the problem: the M563 command in config.g (but also from the console) resets the retraction of the tool, so M207 must follow M563.
@dc42 I have found something interesting. Since the firmware retraction behave unexpectedly, I've switch to slicer retraction and ran some test prints. The retract/unretract or let say any commands that involve extruder movement. Sometime the extruder move at a very high speed as well (Command that involve pure extruder move e.g. G1 E5).
This show that the issue is not purely related to retractions.
I think it will be easier to debug the issue by simply setup a gcode with a bunch of G1 E** commands and observe the extruder speed.
Hope it help for further investigation.
@natthapol-vanasrivilai I've run your test file several times using both RRF 3.3 and 3.4b7, but I was unable to detect any differences in the sound. I disconnected the X and Y motors so that I could hear only the extruder motor.
However, when I enabled debug output I did see a different between RRF versions. This difference might occasionally cause the first 2, 4 or 8 microsteps of an extruder movement to be performed rapidly instead of at the correct speed. It is possible that this might explain the difference in sound you heard.
I have corrected this and put a new RRF firmware build at https://www.dropbox.com/sh/up0gytwkxcn4if2/AACO6rIrTu5kPSgMxOmjmxdZa?dl=0. Please try it.