Firmware 3.4b7 - firmware retraction bug
-
@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?
-
@danzaywer said in Firmware 3.4b7 - firmware retraction bug:
@dc42 Anyway, can I downgrade from 3.4b7 to 3.3 simply by uploading the 3.3 files?
If you are running the Duet in standalone mode, then yes.
-
@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
repo.txtThe attached gcode file is just a bunch of 5x0.2mm hollowed cylinders. The machine and gcode is setup to do firmware retraction.
-
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.
-
@dc42 When this behavior happens to me, it lasts for the entire commanded movement of the extruder, so I don't think that anything about a few microsteps would create that sound. I'm confused why it only happens to rarely, just yesterday night it happened again during my normal filament unload macro.
-
@diamondback can you provide a test file that reproduces this behaviour?
-
@dc42 I'm afraid I can't, it happens seemingly randomly when unloading filaments via the DWC feature. The gcode that is running when it happens is posted in my first post in this thread.
For what it's worth, it's a TC design with 4 tools, it seems to happen on all of them from time to time (ie. I've seen it happen on every tool at least once, it's not restricted to a specific tool) -
@diamondback the G91 and G90 commands in that macro will have no effect. You should replace G91 in that macro by M83 and remove the G90 line. That will probably fix the issue for you.
-
@dc42 I'll test with the attached firmware and let you know how it is
-
@dc42 Unfortunately, the issue is still persist with the 3.4b7+3 firmware.
-
@dc42 I was be able to make the problem go away by changing acceleration/jerk/max. speed of the extruder. The same print file running with old config.g and new config.g show no sign of unwanted rapid extrusion.
The test ran using 3.4b7+7. This might help narrow down the issue.
The jerk was reduced from 1000 to 300mm/min (5mm/s)
Max speed was reduced from 9000 to 3600mm/min (60mm/s)
Acceleration was reduced from 10000 to 5000 mm/s2
Since the above parameter was reduced, I've reduced the extruder motor current from 800mA to 600mA as well. -
@dc42 said in Firmware 3.4b7 - firmware retraction bug:
@diamondback the G91 and G90 commands in that macro will have no effect. You should replace G91 in that macro by M83 and remove the G90 line. That will probably fix the issue for you.
Hah, my bad, yea those G90/91 are leftovers, the printer is running in relative extrusion mode all the time anyway.
I triggered the issue with some manual extrusion yesterday, simply by using the console...G1 E100 F300
Immediately sending that very same command again worked fine and as expected.
-
@diamondback Hi, do you mind sharing your jerk/acceleration/max speed for extruder here as well?
The problem seems to go away when I reduced the value of jerk/acceleration of extruder. I would like to know how your machine is setup for these values.
The problem is definitely there, I'm just setup the config to avoid this specific firmware issue.