search

knutwurst / Marlin-2-0-x-Anycubic-i3-MEGA-S

Marlin 2.0.x Version for Anycubic i3 MEGA M/S/P/X/CHIRON and 4MAX with Anycubic TFT or the "new" DGUS Clone TFT - Now also with BLTouch!
GNU General Public License v3.0
781 stars 183 forks source link

[FR] Bump Marlin to at least 2.0.6.1 for better arc support (and more benefits) #184

Closed gloomytree closed 2 years ago

gloomytree commented 3 years ago

Description

Hi, I am not sure if this is a bug or not, so I file it as a feature request. I've been printing with arc welder (done in cura) using an Octopi and experienced a lot of stutter on detailed areas. Since then I've been digging and found resources recommending Marlin 2.0.6 when using arc welder. And indeed, the Marlin release page states "Fix G2/G3 Arcs segment bugs".

I think this repository uses Marlin 2.0.5.4, at least that is what version.h says. Are there any plans to bump Marlin to a newer version? I know this is a major effort, but it might be worth it for better arc support. There are additional benefits, with bugfixes for the BLTouch, TMC, power loss resume (I know this was an issue before), and even ExtUI support for the I3 Mega. There are even more Anycubic/Trigorilla & LCD related fixes in later Marlin versions.

Additional Information

Quote from here https://plugins.octoprint.org/plugins/arc_welder/ :

Marlin has supported arc commands for a long time. However, starting with version 2.0.6 arc support has been greatly enhanced. I recommend you upgrade to at least this version before using Arc Welder because your experience will be much better.

Marlin release 2.0.6: https://github.com/MarlinFirmware/Marlin/releases/tag/2.0.6

knutwurst commented 3 years ago

Hi @gloomytree ;) My current source code is based on 2.0.5.4, that's right. However, I merged various bug fixes from 2.0.7 and 2.0.8 upstream. This is actually one of the big problems: Due to my own implementation of some functions and especially the implementation of the Anycubic Display, it is extremely difficult to transfer this to another original Marlin version.

I recently built a 2.0.9.1 version for the GEEETECH A10, which worked very well and I also thought about doing this for the Anycubic printer.

However, the effort is very big and actually bears no relation to the benefit. Mainly because since 2.0.6 the path to ExtUI has been taken, which is completely incompatible with my implementation. (The special menu would be really shitty)

As a quick win, I would like to offer you to take a look at the G2/G3 implementation in the 2.0.9 version and to transfer it to my Anycubic version. This is certainly the simplest solution with the greatest added value.

Olli

Jack77777777 commented 3 years ago

It would be great to have G2/G3 for the i3 Mega S.

gloomytree commented 3 years ago

I was afraid it would be this complicated. This is a complete redesign for your codebase, isn't it? It would be nice to backport the 2.0.9 implementations!

I am wondering how this FW will continue in the next years if Marlins version can't be bumped. It would be a shame to have all this work go stale!

ashleysommer commented 3 years ago

@knutwurst Would be great if you could backport the new G2/G3 features to your project!

ashleysommer commented 3 years ago

I've started doing the backport of G2/G3 features. I just noticed, @knutwurst already has one of the ARC stuttering fixes applied already: https://github.com/knutwurst/Marlin-2-0-x-Anycubic-i3-MEGA-S/commit/c14f93323c2bc796f90b00d7b75493d6ce05c8a6

knutwurst commented 3 years ago

1.3.0-beta.1 should be available within the next hour.

gloomytree commented 3 years ago

wow that was fast.

gloomytree commented 3 years ago

I've tested this now. I wrote a small script that generates arc based stress-test gcode with increasing resolution. I basically move in 180° arcs with a 5mm radius and break the arc into more and more individual parts to increase the difficulty.

With the old fw version, the printer war OK with 3 segments and stuttering extremely with 10 segments on a single arc.

The new fw could manage 30 segments OK-ish (maybe a bit slower) and started stuttering with 50 segments. 40 segments were noticeably slower, but I think this might work without creating print artifacts, so good work on the buffer underrun protection through reduced print speed.

I'd call it a huge success! Are you interested in the testing gcode and or script? I've added it to this post. Beware, it's a VERY crude python script, I'm no programmer and this was meant to generate the file only once. It can be configured a bit, tough.

Arc Tester.zip

ashleysommer commented 3 years ago

Thanks for your testing @gloomytree. I did another test print with ARC Welder. I printed one of these bearings after processing with ARC welder. It was stuttering pretty badly. I think I need to check the welder plugin settings.

gloomytree commented 3 years ago

Based on my test, the minimal arc length should be greater than 0.5mm (5mm radius, 180° arc, 30 segments = 0.5mm arc length). Feedrate was 3000, so if you are going faster, you will need less resolution. Maybe start with 1mm? As far as I understand, Marlin converts the movements to 1mm linear moves, anyways.

knutwurst commented 3 years ago

Reopened the issue because fine-tuning of the various settings is obviously necessary. :)

Jack77777777 commented 3 years ago

Hi Guys,

What is the difference of 1.2.0 and 1.3.0b1 regarding ArcWelder Support? I can not see any quality change for my test print with default ArcWelder settings.

gloomytree commented 3 years ago

Knutwurst backported a few bugfixes regarding G2 and G3 from Marlin 2.0.9 which reduce stuttering and increase the performance. Maybe you had models that had no complicated geometric that leads to a high amount of arc commands in a short time... Try printing the gears from the comment above, that is a pretty good torture test. Or try my designated torture test gcode ;-)

Jack77777777 commented 3 years ago

Ok. I will try the test. Any recommentations for AW settings and have the settings to be changed for every print ?

ashleysommer commented 3 years ago

@gloomytree I was going to try other values for minimum arc length, like you suggested, I thought it was an arc welder plugin option, but I realize now its on the other side of things, in the Marlin configuration.

I was just reading through the documentation in the Octoprint Arcwelder Plugin, and found this section:

Some firmware is compiled with options that will prevent the arc commands from working as expected in all instances. In particular, Marlin has an option called MM_PER_ARC_SEGMENT that defaults to 1mm, which is a very conservative default value that few people have changed (G2 and G3 is not commonly used, afterall). This means any arc segments shorter than 1mm will be converted into straight lines. A 1mm curve that is printed as a straight line is very obvious. I recommend reducing this value to 0.1mm, though I will have a better recommendation once I'm able to play with it a bit more.

Do you agree with the above?

These recommendations seem to conflict. Default minimum arc length is set to 1mm, you recommend minimum length to be 0.5mm (or greater) and the plugin author recommends minimum to be 0.1mm.

There are two (currently disabled) options, to compute arc segment on the fly:

I wonder if those need to be explored further. Currently they are both disabled, so segment length is the same as MM_PER_ARC_SEGMENT always.

Note, I also noticed in the code, the segment length calculated by MM_PER_ARC_SEGMENT can become smaller if required if additional segments need to be added by the MIN_ARC_SEGMENTS calculation. So minimum segment length of 1.0 may be less than 1.0 if more segments are needed to min MIN_ARC_SEGMENTS.

gloomytree commented 3 years ago

I agree with the above. Although Ive been meaning something entirely different. You mean the conversation into linear movements, that happens in the firmware. I've been testing the amount of G2 / G3 commands per time that the board can handle without stuttering. Shorter arcs = more arcs per minute. This has nothing to do with the setting in the firmware and I don't recommend anything, because I have never tried or touched it.

I find that 0,1mm is probably overkill. Especially considering that we might face issues with computing power even now.... But that is speculation.

I am quite happy with the situation as it is and I feel that there might be other issues with greater priority?

ashleysommer commented 3 years ago

Worth noting, I did find a bug in the current implementation: https://github.com/knutwurst/Marlin-2-0-x-Anycubic-i3-MEGA-S/pull/191 That reduces the number of calculated segments, because it divides the min-full-circle-segments by the degrees-of-travel twice to get calculated segments, so for a 90deg arc, it will be using one quarter the number of segments it should be.

Will need retesting after that fix is merged. There will be more movements, but higher quality output after the fix.

knutwurst commented 3 years ago

The fix is merged :) I'll trigger a build later. We have friends over at the weekend and in general I haven't gotten around to doing anything on the firmware lately. :/

Thank you both!

Esquilo007 commented 3 years ago

Thank you all for that great feature, I will follow this thread here

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 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.