[BUG] ARC moves slowing down

[THE-BOW]

Hello, i have some trouble with ARC moves on 2.0 Bugfix.

I swapped my Mainboard from my CR-10 to a SKR V1.3 and installed Marlin 2.0 Bugfix. I used the example configuration for my printer and activated ARC_Support for my attached laser.

All the configuration i made on base of my previous Marlin 1.1.9 to be sure that everything is as close as possible as before.

So when i run my GCode on the new board the speed slows extremly down on some movements. Running the GCode serveral times shows that it slows always down on the same positions. Looks like it slows down when it comes to smaller curves.

Running the gcode from the same SDcard on my 2nd printer with Marlin 1.1.9 installed with same configuration does not slow down anywhere.

Just to be sure i checked again if jerk settings are the same. I can nowhere find a significant difference...

[reloxx13]

Additional Information

• Include a ZIP file containing your Configuration.h and Configuration_adv.h files.
• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[THE-BOW]

Hello reloxx13

i added a ZIP file with the Configs and the gcode that i run on the machine.

#15295-1.zip

[cinealfa]

Im having the exact same problem with the same board...

[gloomyandy]

@cinealfa I thought from your other report you were printing via Octoprint not directly from the SD card? So do you see this issue when printing from the SD card?

[cinealfa]

yes @gloomyandy I am I thought it was octoprint related so I didn't want to suggest it was a fault with Marlin until I was sure it was octoprint. I also really was having a hard time describing what was going on due to the other errors as well. I had hoped to introduce the skr board/bmg extruder and 2208s in a more incremental way. But it wound up being quite a hairdo. I like to change one thing at a time and observe the results. Due to some hardware failures , I ended up having a bunch of stuff changed at once. As you know, its damn near impossible to troubleshoot if 11 parts are changed at once. I now have it reduced to a few goofy things: Zits, a bmg clone that takes 800 steps to move a 1mm (instead of 400 as one would expect) The stuttering on arc moves - good on linear moves (maybe causing the zits idk) and The SD card issue. Problem is really can't work very quickly and change commits until the sd issue is solved as it is PITA to get at the card with the rear facing skr/pi enclosure.

[THE-BOW]

The GCode is executed via onboard SD card.

I have now taken a photo showing clearly where the speed is decreasing.

Additionally I generated GCode with Laserweb4. This GCode contains no G2 / G3 commands. The speed is constant there. A picture and the GCode can be found in the zip file.

I also did a video. On the video I used the same picture but with a higher feed rate so you can see the difference in speed. (I disconnected the laser from the motherboard for the test.)

#15295-2.zip

[040medien]

I have the same issue with my SKR 1.3 and the latest Marlin snapshot. Disabling JUNCTION_DEVIATION helped, but now the machine pauses for several seconds every now and then.

[boelle]

i would like to test this one, but i only have a 3d printer....

could we cook up a test routine for that?

[THE-BOW]

Please try the following

Make sure your firmware is configured as follows:

Configuration.h //#define S_CURVE_ACCELERATION is commented out

Configuration_adv.h

define ARC_SUPPORT //is uncommented

//#define LIN_ADVANCE is commented out //#define BEZIER_CURVE_SUPPORT is commented out

Upload the firmware to your Printer

Home your nozzle to the font left corner

Now lift your Z-Axis about 50mm to be sure not touching the buildplate

Set all positions to zero with command -> G92 X0 Y0 Z0 Make sure the display shows all axis on zero (Blinking)

If not send command for every Axis G92 X0 G92 Y0 G92 Z0

If this also is not working - power the printer of and on to reset the position.

If your printer has a buildplate greater then X 145mm and Y 157mm run attached gcode.

The nozzle has to move now on a constant speed when part cooling fan is on. The cooling fan simulates the powered laser

If it slows down when moving an arc and cooling fan is on you have the same problem.

The laser never powers down while moving so the speed needs to be absolutly constant...

Atari_Logo.zip

[boelle]

will try that tomorrow

[boelle]

so this works without extruding plastic right?

that i can test now

but i looked at the code and what is this:

I-503.5024 J6.2373

taken from this one G2 X58.1438 Y107.0735 I-503.5024 J6.2373

[boelle]

its hard to judge the speed.... will try a few times

maybe make a video if it does not take to long

@shitcreek does the code attached work for you?

[boelle]

how far from code start will the problem show the first time? just so i know when its most important to make the video

[boelle]

but now the machine pauses for several seconds every now and then.

with the code just supplied i have that to some small degree... in that the fan stops for 1-2 sec, but then also the printer stops moving at the same time

[THE-BOW]

Hi there,

i already did a video in this post -> https://github.com/MarlinFirmware/Marlin/issues/15295#issuecomment-532993748

When you watch the video you will notice on second 43 to 44 that it slows down extremely. For the video i used the same source file with a higher feed rate to make it more visible...

[THE-BOW]

but i looked at the code and what is this:

I-503.5024 J6.2373

taken from this one G2 X58.1438 Y107.0735 I-503.5024 J6.2373

This i the x and y offset to move the center of the arc to another spot. This is not a special command its a regular opperation.

[THE-BOW]

You can run the gcode on the free available Simulator https://camotics.org/download.html where you can see how it should move.

I have updated Marlin again today. Attached you will find my updated configuration.h and configuration.adv.h

Configuration.zip

The issue is still the same just to be sure that it is not solved with another bugfix...

[boelle]

@shitcreek @thinkyhead @reloxx13 @gloomyandy

any idea's on this one?

[THE-BOW]

Is it possible that in the 32-bit version automatically take more decimal places than in the old 8-bit version?

Might be that the calculations take so much performance that the effect comes during the G2 / G3 movements?

If so, can you limit the calculations to the same amount of decimal places as in the 8-bit version?

[brizzer]

Hi

I think I have found the problem and a temporary solution, at least for me.

I had the same problem and for me it was related to MIN_ARC_SEGMENTS, when commented out the printer ran smoothly. But then it is impossible to print small arcs. I think the real problem arises in line 209 (and 229) in G2_G3.cpp

if (!planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, MM_PER_ARC_SEGMENT

it adds a segment to the planner, but if the arc is small and MIN_ARC_SEGMENTS is set, the lenght of that segment is not MM_PER_ARC_SEGMENT (1mm per default) but rather much smaller.

The temporary solution is to change MM_PER_ARC_SEGMENT to 0.0 and let the planner calculate the lenght. This works for me so far on the SKR V.1,3 board. I haven't investigated if there are a more efficient way to calculate the lenght.

The fix:

change line 209 in G2_G3.cpp to: if (!planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, 0.0

and line 229 to: planner.buffer_line(raw, scaled_fr_mm_s, active_extruder, 0.0

[THE-BOW]

@brizzer

Thank you for this. I will give it a try this week and let you know if it helps.

[THE-BOW]

@brizzer It worked for me too. Thank you

@boelle Think we are on the right way.

[boelle]

yep that looks far better

@shitcreek @thinkyhead does the fix from @brizzer look ok?

[boelle]

@brizzer you think its possible to make a more clean and permanent fix that could get baked in marlin permanently?

[boelle]

btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible

[boelle]

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.

[justinshumaker]

Confirming this fixed my issue relating to G2/G3... using Marlin to drive a NEJE Master laser engraver. Suggest setting #define MM_PER_ARC_SEGMENT to 0.0 in Configuration_adv.h instead of changing the source code.

[THE-BOW]

@boelle I have not made any further tests or firmware updates since the changes in G2_G3.cpp. for me it is also ok to change the file again with the next update ... setting the MM_PER_ARC_SEGMENT to 0 can work, but indicates that there is a bug here.

if I can help with any tests please let me know ...

[Ohmarinus]

I have been battling this same issue since May/June 2019 and just found a solution here thanks to @ellensp

See my thread here: https://github.com/MarlinFirmware/Marlin/issues/17348#issuecomment-606757799

This issue needs some attention as it seems to happen to more people.

[github-actions[bot]]

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.