Closed theofficialgman closed 4 years ago
@theofficialgman have you tried to ask for help any of these places?
RepRap.org Marlin Forum Tom's 3D Forums Facebook Group "Marlin Firmware" Facebook Group "Marlin Firmware for 3D Printers" Marlin Configuration on YouTube Marlin Discord server. Join link: https://discord.gg/n5NJ59y
@boelle I was actually leaving this bug report open as reference for #15908 which detailed the same problem as this bug report but was posted after mine and gained more traction for some reason. Problem was solved yesterday and merged into the 2.0.x bugfix branch with commit 0fcd1f4.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
The problem I observe can be seen when doing any movement (x,y, or z) that simultaneously involves using the extruder. Whenever a G1 command is executed that includes E values, the values for acceleration set by M204 P are ignored. To me, it seems that the printer attempts to accelerate as quickly as possible. Printing is also noticeably louder when this occurs. Setting the eeprom and firmware values for acceleration low (as in 500mm/s^2) does not affect this.
Observed on an 8 bit Mega 2560 based arduino board. Marlin-Bugfix-2.0.x 227951a (the most recent as of posting)
Going back to an older (last year) 1.1.9 firmware shows no signs of problems. The last firmware which I was running also had this issue (bugfix-2.0.x built on october 30th)
Edit: By randomly choosing an older firmware, I found a more recent firmware that does not have this bug: bugfix-2.0.x f57ce2b (september 28th). I am thinking the issue could have something to do with the changes made in 438835f @InsanityAutomation and @thinkyhead but I could be wrong
Steps to Reproduce
Expected behavior: Printer slows speed change according to set accelerations
Actual behavior: Printer ignores acceleration values for movements that include an extrusion
Additional Information
Purely travel moves function correctly according to their defined acceleration values. The height in Z has no affect on this (it happens at all Z heights). Setting the jerk higher or lower does not stop the problem. I am currently using the classic jerk. I have manual_mesh_bed_leveling enabled I have an i3 style printer
configs.zip