ArcWelderPlugin
ArcWelderPlugin copied to clipboard
FormerLurker
Altered GCode Prints slower
Hello FormerLurker,
first of all, thank you for your effort!
I tried the Plugin and with a modell (Prusa Face Shield) that I'm currently printing a lot. The normal gcode prints in around 03:07 hours and the altered gcode prints in 03:39. Filesize of the altered gcode is significantly smaller (3005kbytes instead 9725kbytes) as the originial one. I'm not really expecting that it's faster because it still has to lay down the same amount of filament but it shouldn't be that much longer?! Maybe the model I'm printing isn't the best fit for the ArcWelder right now but I guess your goal is that it fits every model it gets thrown at someday. I'll test it printing from SD-Card soon.
Printed with OctoPrint 1.4.0 on a RaspBerry Pi 4 via sending directly to the MK3S (FW: 3.8.1). Used Prusa Slicer to slice the STL.
Kind regards,
Sebastian
gcode.zip plugin_pluginmanager_console.log
Lower: ArcWelder Upper: Original
What firmware are you using? I'd like to see the arc configuration (configuration_adv.h). Perhaps mm_per_arc_segment is too low (should be 1mm)? I'm working on a patch for the prusa firmware right now, as a matter of fact. You can download my firmware modification if you want to try that:
https://github.com/FormerLurker/Prusa-Firmware
You will have to compile it for now. I could send you a binary, but I'm fully occupied for today unfortunately trying to get Octolapse rc2 out and fix some issues with the arcwelder plugin.
I haven't gotten a chance to look at your gcode, but I will soon. I can't believe how many messages I've gotten today about Arc welder and Octolapse! It's a bit overwhelming, lol!
Thanks for filing your issue. I will definitely get to this in a more thorough way soon.
Hey, thank you for the fast reply! =) I'm using the stock firmware (3.8.1-2869 as my printer shows me on the display). I'll have a look into the modified Prusa FW. No problem :) Take your time!
Besides the Issue: Looking forward to see RC2 of Octolapse. I still need to get the camera directly hooked up on the RPi4 so there is no bandwidth limitation caused by the hardware anymore.. It's still connected via the RPi Zero W sitting on the Einsy Board.
I tried your modified Prusa firmware (3.9.0-RC1-3272). Apart from having to change the filament, printing took just as long. I used the same gcode that ArcWelder initially generated. It's better now, but there seems to be a problem with the transitions from the arches. At first I thought the G2 / G3 Gcode would need its own feedrate, but they use the one specified by the G1 Gcode. I did some tests in the terminal in OctoPrint to see it with my own eyes. But if the G2 / G3 runs as fast as the G1, why is it so slow?!
From the bottom up First Attempt Originial GCode Second Attempt
But if the G2 / G3 runs as fast as the G1, why is it so slow?!
Answer: It is definitely firmware related. Can you try turning linear advance off by changing this:
to this:
I'm guessing the MK3 has more features enabled than my MK2S, so maybe this will alleviate some of the extra calculations (I've been leaving linear advance enabled, but it's caused issues for me before).
You could also try editing these lines configuration_adv.h within the firmware here:
// Arc interpretation settings:
#define MM_PER_ARC_SEGMENT 1.0f // The maximum length of an arc segment if a full circle of the same radius has more than MIN_ARC_SEGMENTS (if defined)
#define N_ARC_CORRECTION 25 // The number of interpolated segments that will be generated without a floating point correction
// 20200417 - FormerLurker - Add Additional Arc Config Values
#define MIN_ARC_SEGMENTS 32 // The minimum segments in a full circle. If not defined, MM_PER_ARC_SEMGMENT is enforced always
#define MIN_MM_PER_ARC_SEGMENT 0.25f // the minimum length of an interpolated segment
//#define ARC_EXTRUSION_CORRECTION // If defined, we should apply correction to the extrusion length based on the
// difference in true arc length. The correctly is extremely small, and may not be worth the cpu cycles
Try setting MIN_ARC_SEGMENTS 16
AND
MIN_MM_PER_ARC_SEGMENT 0.5f
I plan to do more firmware testing when I have a chance.
Alright, I'll try first without linear advance and afterwards I'll try with those firmware settings.
Thank you so far for your help. 👍
It took a little longer.. sorry for that. In addition I ported your changes in the FW to the most recent FW (3,9.0-RC3-3401). I copied your changed lines 1:1. I've created a repository because I didn't know how to "interact" with your repository. I tried a pull request but I'm not able to select your fork. I guess it's because of the older version of your fork? And I'm not sure if this would be the right solution? https://github.com/blacksurgeon/Prusa-Firmware
Here are the Results: From the bottom up (all printed running the modified firmware)
- Original
- ArcWelder
- ArcWelder with LinAdv Off
- ArcWelder with MIN_ARC_SEGMENTS 16 and MIN_MM_PER_ARC_SEGMENT 0.5f
Used Gcode: gcode_test_series_2.zip Print times and file stats (size/lines)
I would say turning Lin Adv off turns out to be the best solution. Still there are some spots which need some tweaking but they are not as coarse as the other results. Also the print time doesn't differ to much from the original one.
Maybe I soon can print a Benchy to be more comparable with others. Right now there is still a huge demand for face shields.
Awesome report, thanks!!! I have added some new features to my fork, and I will see if I can pull the n your changes. I have been doing some investigating regarding the slow downs, and I am pretty sure it is some bug I haven't discovered yet. Running the same points the g2/g3 create in marlin (using my inverse processor found in the ArcWelderLib repo to create the inverse gcode) I don't get any slowdowns. That should not be the case. There is less overhead within the segment interpolation (much less serial traffic, far fewer gcodes to parse), so if anything the g1 based code should stutter and not the g2/g3 code.
Hi there, I'm also experimenting with arc and experiencing slowing and have some observation: For me it looks like only G2 is slowing down, while G3 is printing normal-fast speed. I was observing terminal why it was happening. Strange, isn't it...
I have checked with manual commands on terminal and confirmed it's not firmware issue G3 X40 Y40 I20 J20 and G2 X40 Y40 I20 J20 both behaved the same way and speed
I'll try to pick up relevant gcode fragment from both files so will attach later.
@marekorok, do you have a link to your marlin source? If it's 2.0, I saw a recent issue discussing this exact problem, along with a commit to fix it. Let me know and I will take a look.
@marekorok, do you have a link to your marlin source? If it's 2.0, I saw a recent issue discussing this exact problem, along with a commit to fix it. Let me know and I will take a look.
Marlin is the bugfix-2.0.x, most recent
possible this one? https://github.com/MarlinFirmware/Marlin/issues/15295
Solution mentioned there either change source code or:
Suggest setting #define MM_PER_ARC_SEGMENT to 0.0 in Configuration_adv.h instead of changing the source code.
Interesting, seems the patch haven't been applied yet, let me try. Thanks @FormerLurker for the tip!
Here is the exact issue: https://github.com/MarlinFirmware/Marlin/issues/17348
I believe the solution was to edit G2_G3.cpp and change the call to planner.buffer_line on line 239 from this:
planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, seg_length
to this
planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, 0
See this commit.
ok, did few tests.
Changing MM_PER_ARC_SEGMENT only to 0 was a disaster, SKR board become overloaded, unresponsive and slowed down completely, but still moving, verrrry slowly. Also changed to 2, but still lot of slownesses in different places. Reverted back to value 1 (default in the file).
Then checked G2_G3.cpp, seems something changed in file cause line numbers not quite matching but not too far:
this is line 216 now:
if (!planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, seg_length
and this 233:
planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, 0
so looks like the second was already modified, meaning it still does not work or not for this case.
But modifying line 216 from:
if (!planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, seg_length
to:
if (!planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, 0
helped, now it works as expected: moving fast, smooth and quiet, at least few minutes print that was failing previously.
Will be watching.
btw, I'm also printing for medics, but adapter for snorkeling mask for filters, lot of arcs. File is down from 10.6 to 2.5Mb.
Thank you @FormerLurker for the tool and your help! Appreciated.
O is not a good setting for mm per arc segment. It may cause an infinite number of segments to be used, or would fall back to 0.001 mm (would need to verify).
You mat want to adjust min_arc_segments too. Not sure what your current value us. Something between 16 and 32 should create good looking small arcs. Im using 20 in my modified firmware and it works well.
Regarding the arc g2_g3 issue, would you post your findings in that Marlin thread (or create a new issue)? I guarantee they want to know about the second change ASAP. Feel free to link back to this issue. I probably run more arcs on my printer than anyone else since it is difficult at the moment to create gcode that includes these commands. Perhaps they will be interested in using my tools to help improve segment interpolation performance. They have massively boosted performance in 2.0 already, so it can only get better!
You mat want to adjust min_arc_segments too. Not sure what your current value us. Something between 16 and 32 should create good looking small arcs. Im using 20 in my modified firmware and it works well.
I left default as per configuration file for my board (SKR E3 Mini 1.2) and printer (Ender 3), so it is 24 Configuration file link Few other options are yet disabled: ARC_SEGMENTS_PER_R, ARC_SEGMENTS_PER_SEC, ARC_P_CIRCLES
Regarding the arc g2_g3 issue, would you post your findings in that Marlin thread (or create a new issue)? I guarantee they want to know about the second change ASAP. Sure, I'll try...
I added a comment to that issue as well. If it doesn't get noticed, I'll open a new issue. Thank you for contributing there!
Regarding the other settings, if you are getting good results it's probably best not to mess with them. However, I find the new ARC_SEGMENTS_PER_SEC setting quite interesting. I've done some testing with it, and while it's a bit harder to configure, it should provide excellent results at all print speeds if configured correctly. I have implemented that setting in my firmware fork. I've also been playing around with a new gcode command I implemented (M214) for adjusting the arc settings on the fly. If I can get it working well enough (so far so good) I'll see if I can work it into Marlin 2.0. It sure makes determining the correct arc settings much faster!
I'm sorry about this, but could someone please spoon feed me what to do? I've read through this thread and the Marlin thread and can't figure out what I need to change in which file before compiling. Could you please just tell me which lines I need to edit?
@simpat1zq, I will post one file you will need to replace, and some decent arc settings in the AM, and i will leave a link here.
@simpat1zq, here is a gist I created that contains one file and one partial file. The first, G2_G3.cpp can be found at Marlin/src/gcode/motion/G2_G3.cpp. Just replace the file there with the G2_G3.cpp file in the gist. The other section is basically the default arc configuration. It should work fine, but if you still experience stuttering in tight curves, drop MIN_ARC_SEGMENTS to 16, which should be plenty for tight curves.
I'm not sure how compatible that code is with versions of marlin 2.0 in general, but if you are using the most recent release, it should work fine. I'm going to work on fixing the seg_length calculation at some point as soon as I can figure out how to run Marlin 2 on my printer (Mk2.5 W mmu 2.0) if it is even possible.
Ive installed the plugin and run a file through it .. printer is now slower on the print and quality isnt as high as before .. I will update with min_arc_segments 16 after this print .. and test on a smaller print than the one Im testing on right now.
@hamselvdk, definitely check out G2_G3.cpp and check file lines 216 and 233. Make sure seg_length is replaced with 0 (zero). See the gist I posted in my previous comment.
@hamselvdk, definitely check out G2_G3.cpp and check file lines 216 and 233. Make sure seg_length is replaced with 0 (zero). See the gist I posted in my previous comment.
@FormerLurker So I did and it didnt change the behaviour of the printer - it still stutters just really really slowly - as with a gcode not processed by the plugin stutters fast in the exact same locations.
@hamselvdk, what do you have in your configuration_adv.h file for your arc interpolation settings? Also, you might try disabling linear advance (M900 K0) if it is enabled (or remove support in configuration_adv.h) to see if that helps.
These are my settings in configuration_adv.h
//
// G2/G3 Arc Support
//
#define ARC_SUPPORT // Disable this feature to save ~3226 bytes
#if ENABLED(ARC_SUPPORT)
#define MM_PER_ARC_SEGMENT 1 // (mm) Length (or minimum length) of each arc segment
//#define ARC_SEGMENTS_PER_R 1 // Max segment length, MM_PER = Min
#define MIN_ARC_SEGMENTS 16 // Minimum number of segments in a complete circle
//#define ARC_SEGMENTS_PER_SEC 50 // Use feedrate to choose segment length (with MM_PER_ARC_SEGMENT as the minimum)
#define N_ARC_CORRECTION 25 // Number of interpolated segments between corrections
//#define ARC_P_CIRCLES // Enable the 'P' parameter to specify complete circles
//#define CNC_WORKSPACE_PLANES // Allow G2/G3 to operate in XY, ZX, or YZ planes
#endif
Linear advance is already disabled. .
Hey, you might want to check out the newest version of Marlin. Lots of arc fixes for both speed and accuracy! Let me know if that helps and sorry about the huge delay in responding!