search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.17k stars 19.21k forks source link

[BUG] Short diagonal moves (and part of 1 move after) are too fast after using G29 bilinear leveling #21531

Closed foxalabs closed 2 years ago

foxalabs commented 3 years ago

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

When performing small diagonal moves (less than 3mm usually) and using G29 bilinear leveling the toolhead moves much faster than the requested 80mm/min. I would put the speed at 500mm/min but is hard to be exact, the rapid movement seems to continue for part of one additional move after that.

Bug Timeline

New (April 03 2021)

Expected behavior

The toolhead move at the requested speed.

Actual behavior

The toolhead moved at an accelerated speed.

Steps to Reproduce

G29 bilinear level an imperfect bed. Request small diagonal moves followed by small vertical/horizontal moves as would be typical when routing out PCB traces.

Version of Marlin Firmware

FIRMWARE_NAME:Marlin 2.0.7.2 (Apr 3 2021 13:52:25)

Printer model

Ender 3

Electronics

SKR 1.3 X/Y TMC2208 Duel Z DRV8825 E DRV8825

Add-ons

No response

Your Slicer

Other (explain below)

Host Software

Pronterface

No slicer used, gcode generated by FlatCAM https://youtu.be/Rb2G-8a1FHg Video of fast moves Marlin-cfgs + short log.zip mill1-MOSFET.gcode.zip

XDA-Bam commented 3 years ago

First suspect would be 45c1432. Did you by any chance also try a version of bugfix-2.0.x shortly before that commit's date (April 2nd)? If no, please try something from end of March or April 1st and see, if the bug is also present in those.

foxalabs commented 3 years ago

First suspect would be 45c1432. Did you by any chance also try a version of bugfix-2.0.x shortly before that commit's date (April 2nd)? If no, please try something from end of March or April 1st and see, if the bug is also present in those.

Yes I have a build from January that also had the same issue

XDA-Bam commented 3 years ago

OK. I'm not really an expert for bed leveling code. But it seems useful to run the GCode again after uncommenting #define DEBUG_LEVELING_FEATURE and log the serial output.

thisiskeithb commented 3 years ago

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

foxalabs commented 3 years ago

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:

  • Download Marlin bugfix-2.0.x to test with the latest code.
  • Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
  • Connect to your printer from host software such as Cura, Printrun or Repetier Host.
  • Send M502 and M500 to ensure your Configurations are applied.
  • Issue the command M111 S247 to enable maximum logging.
  • Perform a G28 to do your standard homing procedure.
  • Do a G29 to probe the bed. This will also enable bed leveling.
  • Do some of the moves that revealed problems before. Take notes.
  • Copy the log output into a .TXT file and attach it to your next reply.

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

marlin-log.txt

foxalabs commented 3 years ago

I have done a little more investigation and determined that the jerky movement can occur when transitioning from a single axis movement to a duel axis movement and the other way around, so it is not limited to diagonal moves being the cause, simply some change in direction. I have tried changing the size of #define LEVELED_SEGMENT_LENGTH 5.0 to be 1 and 5 with no apparent difference.

foxalabs commented 3 years ago

I have found a simple sequence to recreate the issue. The following gcode draws a small circle at what should be a feed rate of 80mm/min but is actually closer to 200 


G01 X4.8078 Y4.9803 F80
G01 X4.8205 Y4.9813 F80
G01 X4.8394 Y4.9838 F80
G01 X4.8582 Y4.9878 F80
G01 X4.8766 Y4.9931 F80
G01 X4.8945 Y4.9998 F80
G01 X4.9119 Y5.0078 F80
G01 X4.9287 Y5.0170 F80
G01 X4.9394 Y5.0238 F80
G01 X4.9550 Y5.0350 F80
G01 X4.9648 Y5.0431 F80
G01 X4.9743 Y5.0517 F80
G01 X4.9876 Y5.0654 F80
G01 X4.9960 Y5.0751 F80
G01 X5.0038 Y5.0851 F80
G01 X5.0112 Y5.0956 F80
G01 X5.0180 Y5.1063 F80
G01 X5.0243 Y5.1174 F80
G01 X5.0300 Y5.1288 F80
G01 X5.0352 Y5.1405 F80
G01 X5.0398 Y5.1524 F80
G01 X5.0456 Y5.1707 F80
G01 X5.0487 Y5.1830 F80
G01 X5.0522 Y5.2019 F80
G01 X5.0543 Y5.2209 F80
G01 X5.0549 Y5.2336 F80
G01 X5.0550 Y5.6398 F80
G01 X5.1048 Y5.6398 F80
G01 X5.1048 Y4.6600 F80
G01 X5.1068 Y4.6129 F80
G01 X5.1085 Y4.5939 F80
G01 X5.1154 Y4.5472 F80
G01 X5.1193 Y4.5285 F80
G01 X5.1293 Y4.4890 F80
G01 X5.1351 Y4.4708 F80
G01 X5.1513 Y4.4265 F80
G01 X5.1564 Y4.4148 F80
G01 X5.1739 Y4.3780 F80
G01 X5.1800 Y4.3668 F80
G01 X5.2008 Y4.3318 F80
G01 X5.2077 Y4.3210 F80
G01 X5.2150 Y4.3106 F80
G01 X5.2433 Y4.2729 F80
G01 X5.2517 Y4.2632 F80
G01 X5.2791 Y4.2331 F80
G01 X5.8185 Y3.6935 F80
G01 X5.8532 Y3.6617 F80
G01 X5.8679 Y3.6493 F80
G01 X5.9006 Y3.6250 F80
G01 X5.9110 Y3.6177 F80
G01 X5.9218 Y3.6108 F80
G01 X5.9568 Y3.5900 F80
G01 X5.9738 Y3.5811 F80
G01 X6.0165 Y3.5613 F80
G01 X6.0284 Y3.5567 F80
G01 X6.0668 Y3.5430 F80
G01 X6.0790 Y3.5393 F80
G01 X6.1185 Y3.5293 F80
G01 X6.1372 Y3.5254 F80
G01 X6.1775 Y3.5193 F80
G01 X6.1902 Y3.5178 F80
G01 X6.2029 Y3.5168 F80
G01 X6.2500 Y3.5148 F80
foxalabs commented 3 years ago

Given my understanding of how G29 is implemented this error must be as a result of the move being split into sections or rather attempting to split it into sections and then each section is adjusted for Z to follow the bilinear path set by the probing data. If anyone can point me in the right direction as to what file name that section of code is held in I'll have a go at fixing it. Cheers.

thinkyhead commented 3 years ago

First suspect would be 45c1432.

I think we can rule that out. No changes to motion code were made in that commit.

thinkyhead commented 3 years ago

There are a lot of layers to the timing of moves, so we'll need to run some tests to actually locate this issue. Especially if it is something that has been lingering undetected all this time in the release.

foxalabs commented 3 years ago

Extra Info: I tried changing back to #define CLASSIC_JERK which had no effect, I also tried disabling //#define LIN_ADVANCE and that also had no effect.

foxalabs commented 3 years ago

I have found an acceptable solution, changing #define MIN_STEPS_PER_SEGMENT 6 to #define MIN_STEPS_PER_SEGMENT 1 eliminates the issue. Not sure if that is important in other things but for me it works for both 3D printing and PCB milling. Let me know if you need any additional information regarding this.

Cheers.

foxalabs commented 3 years ago

Although #define MIN_STEPS_PER_SEGMENT 1 reduces the issue there are still circumstances where the speed increases at the start of new move when the planner has moves to complete

thinkyhead commented 2 years ago

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

github-actions[bot] commented 2 years ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

github-actions[bot] commented 2 years ago

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.