Ultimaker / CuraEngine

Powerful, fast and robust engine for converting 3D models into g-code instructions for 3D printers. It is part of the larger open source project Cura.
https://ultimaker.com/en/products/cura-software
GNU Affero General Public License v3.0
1.68k stars 882 forks source link

G2 / G3 arch support #429

Open Patola opened 7 years ago

Patola commented 7 years ago

Just to rehash this issue from legacy Cura: https://github.com/daid/LegacyCura/issues/494

It is desirable to have arc support for a number of issues, the rounding of paths being better treated by the firmware instead of interpolation for one. An algorithm to detect arcs in a bunch of segments is not too difficult to implement and indeed is present in a number of places. For example, the slicer repsnapper has it - https://github.com/timschmidt/repsnapper There is a branch of slic3r with the arc fitting algorithm being made - https://github.com/Salandora/Slic3r/tree/arcFix There is a standalone software that can replace G1's in g-code with G2/G3 arcs: https://github.com/manticorp/GCodeArcOptimiser

Ghostkeeper commented 7 years ago

Agreed, this would be nice. We already have an issue in our internal tracker since last year (CURA-994, created in March 2016). Unfortunately, according to the planning, it ended up in the "Some Future Release" category, which tends to end up getting done when hell freezes over.

That GCodeArcOptimiser was also mentioned in the issue.

dholl commented 5 years ago

Just tossing in a vote to somehow eventually support at least second-order curves. (ideally, reimplementing ClipperLib for curves as posited in https://github.com/Ultimaker/Cura/issues/2953#issuecomment-354557269 so that input models with these higher order curves are supported throughout the whole process)

DDDirk commented 5 years ago

Note: I believe that in Marlin this is implemented with a fixed number of segments, which is not very practical. A fixed segment-length would make more sense.

dlitz commented 5 years ago

I haven't looked at the implementation, but Marlin's Configuration_adv.h file template (in the bugfix-2.0.x branch) suggests that it supports limiting the segment-length:

//
// G2/G3 Arc Support
//
//#define ARC_SUPPORT               // Disable this feature to save ~3226 bytes
#if ENABLED(ARC_SUPPORT)
  #define MM_PER_ARC_SEGMENT  1   // Length of each arc segment
  #define MIN_ARC_SEGMENTS   24   // Minimum number of segments in a complete circle
  #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
Sebazzz commented 3 years ago

Would this (partially) mitigate Cura/issues/#8321?

nallath commented 3 years ago

Would this (partially) mitigate Cura/issues/#8321?

It might, but it would depend on the implementation.

If you start off with a STL, I don't think it will matter all that much.

ghost commented 3 years ago

There is a plugin on octoprint called arc welder which is basically just a post script that converts G1 to G2/G3. A good temporary solution would then be just to apply that script as a add on plugin to cura.

nallath commented 3 years ago

I'm not so convinced that welding them back together is a good idea. It's a bit like as if you start off with a vector image, convert that into pixels and then try to convert that back into vector again.

ghost commented 3 years ago

No I totally agree. That is why I said temporary. Ideally it should directly generate the arcs. Post processing arcs would probably lead to a loss of resolution. But there is one other benefit to arcs that would make the post process method still useful. It reduces file size and this has a benefit for those printing by applications such as Octoprint or other such USB print methods because arcless circles generate so many points that the buffers of these eight bit systems get overloaded leading to stutter and other such problems. By using arcs, the buffer can be more effeciently managed and thereby possibly leading to less stutter.

cron410 commented 3 years ago

@yysh12 exactly this. I helped a friend troubleshoot blobs on his Ender3, turned out to be printing too fast for the microcontroller in the printer. Printing a tall cylindrical screwdriver handle and not able to keep up with the massive stream of points would cause a freeze for half a second randomly every 10-40 seconds and result in a blob in the skin of the print. Printed at 60% speed and the blobs were gone.

nkappler commented 3 years ago

There's an octoprint plugin for this: https://plugins.octoprint.org/plugins/arc_welder/?utm_medium=announcements&utm_source=octoprint&utm_content=1.3.12

Would be nice if there would be an experimental setting in Cura that does this, so no post processing step is needed...

ghost commented 3 years ago

https://github.com/FormerLurker/ArcWelderLib/issues/14 Attached at top of linked issue is a hotfix cura post processing script. Install post processing plugin and then add file to scripts folder and restart cura.