Detect arcs and generate G2/G3 #23
Comments
|
There are still some glitches in detection or arc center. |
|
Also, it appears that radius is not always correct. |
|
http://www.thingiverse.com/thing:13976 Slicing this model with --gcode-arcs results in this error around 70% of the way up the model: Can't call method "distance_to" on an undefined value at /home/sparr/src/slic3r/git/Slic3r/lib/Slic3r/ExtrusionPath.pm line 168. I suspect this is because ray_intersection is failing to return a point. |
|
Please add a checkbox under the advanced tab to enable/disable arc-slicing support. |
|
I like @jgeerds suggestion. |
|
I'll be very glad too if arc support could be useable resulting in better accuracy of printed objects and avoiding some extrusion problem with very short segments of small arcs. |
|
@furynick, can you provide more details about extrusion problems with very short segments of small arcs? Even with G2 and G3 firmware will subdivide the curve in many small segments. |
|
it's not a Slic3r problem but a physical problem, I bought a all in one extruder where stepper is directly "plugged" on filament so the minimum extrusion length for 1 step (RAMPS driver configured with 1/16 microsteps) is about 0.02mm (49 steps per mm). |
|
Are arc commands supported in the GUI? I would like to output gcode with arc commands so that there is less code when I am printing cylindrical objects. |
|
I have a machine running smoothieware and I would love to test this feature to have it possibly included in a future release. |
|
@qharley, that code is not maintained and probably doesn't even work unless some work is done on it |
|
I see. I could do some work on it. It seems to be one of those features that everyone gets excited about, and then give up on... Perhaps make it gcode flavor dependent, and only support the firmware that actually support it properly. |
|
+1 on this |
|
Hi I've been working on a gcode curve detector for implementing G2 and G3 code arcs for a while, and it seems to be coming along nicely and completely stops stuttering over USB. An example of the change it can make: becomes: If you'd be interested in the code, I can upload to GitHub if you want (although it's pretty raw at the moment, it does seem to do the job). |
|
yes please share your code, I'm highly interested. |
|
Okay, here you go: https://github.com/manticorp/GCodeArcOptimiser All the main working code is in: https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php It's written in PHP (sorry!) but should be fairly easily translatable to Perl/C++. One problem I'm having is testing it - its hard to know where it's going wrong, I've never got a fully working print out of it, but a lot of the movements seem right - of course any number of tiny things can make a print fail, though... |
|
PHP isn't a bad choice :) |
|
That's okay - I'll update the README in a moment with a basic overview of how it works - I know how cryptic it can be reading someone else's hacky code... |
|
@qharley there's a Smoothieware gcode flavor now, so you can work on arcs for it if you'd like. |
|
@phord have a look on the code capsule https://codeocean.com/2018/09/07/polyline-approximation-with-arcs-and-segments/code. With very little tweaks you can modify the formatting script (inside the FitPolyline script) to write gcode instructions. I'll make it eventually but right now I'm busy with the starting course. |
Extend current fill tests to include smooth.
|
this all sounds interesting and i was looking for g2 g3 in a slicer. I also discovered that it is key to detect arcs in a polyline environment (stl) before it was confirmed in this post. i would think of a way of telling if 3 consecutive lines share a common tangential radius and have about the same length, it could be an arc? but how could this be computed? |
|
I would also suggest that paths or path segment (lines) can be selected and "tagged as arc" so the slicer has more information on where to g2/g3. |
|
@Leozolt there is a branch on @TheThirdOne GitHub fork where the work was being done to get it into Slic3r. |
|
does a file format exist that can be used by slic3r to communicate 3d with arcs? stl is lines only if i remember well. |
|
@Leozolt no, which is why the work of @PurpleSensation was prompted. If someone wants to build a replacement for TriangleMesh and the related Polygon-based code to be able to use STEP or something related. |
|
I don't have te time to code the thing into slic3r, but I know someone who might be. I'll tell him. What should I explain to him? I don't know the structure of slic3r. Would this be a post processing script? |
|
@PurpleSensation it would be an extension of https://github.com/slic3r/Slic3r/blob/master/xs/src/libslic3r/PrintGCode.cpp very likely. https://github.com/TheThirdOne/Slic3r/tree/arc-fitting is probably a good initial baseline (take a look at this files touched in that branch), and I would expect self-tests to be written according to expectations of how the arc fitter would work for a few example geometries. |
Hello, I'm very interested in your G1 to G2/G3 converter. Unfortunately I cannot run it. Is my way of running the software correct? Now i have a page which asks me to browse for a .gcode file. Now it asks me again to browse for a GCODE file. What am I doing wrong? I don't get a converted file. Cheers from Germany |
|
Any Luck so far getting proper ARC support 9 years later? I agree that it would improve a lot of prints. |
|
I think that arc support needs a proper s curve acceleration to have good results which must result in stronger chips. I know it's off topic but arc support in combination with non planar 3d printing moves must be the next level sh*t in a few years for fdm printers. |
|
Hi, I've working on the topic for several years now professionally. 3D segmentation is already a thing, we just need someone doing an implementation. Sadly I Can't take that task on myself for being too busy, but I can help with the algorithms. |
|
Reviving |
|
The question is: How would such a feature be implemented (in the main core or as external program/library/plugin/....) and what are the ingredients? One thing is, of course, the arc detection from the mathematical/algorithmic perspective. The second thing is how to connect things in Slic3r. Can someone implementing this use support from the main development team (like how to integrate in the rest of the system)? @PurpleSensation What would have to be implemented? If things are somewhat confidential, you can find a mail address in my Github profile. I would like to have a quick look into things if I might be able to help here a bit. |
|
Mmmmmm I am definitively not a software engineer, and I have little idea on how to integrate this into the main core. The ideal would be to code the methods on a low level and not as a post processing thingy, but that is a possibility. Someone getting into experimentation is all we need. I can provide the algorithms coded in python / MATLAB. The first approach would be to apply only on perimeters. |
|
I am both capable of Mathlab as well as C++. So my personal thinking is that It might be best to go this way: Reimplement the proposed algorithm as a "library" in C++. This allows testing and all fancy things. As the STL files are only polyhedrons/polytopes. So the arc information was already lost during the CAD-to-STL conversion. So it might be best to work on each layer independently to detect any arcs. For my own reference see here. |
|
I get your point. This incoming year I might have some extra time to work on this (also, I need a new printer because my self-made delta is in terrible condition). If anyone (like you) wants my direct assistance and the original code, I am more than pleased. Also, since I am working with C++ right now for my PhD, it might be possible that I build such library myself. Hope this issue is pushed forward. |
|
@christianlupus the work done by @PurpleSensation involved an algorithm to curve fit in 2d. See GCode.cpp in libslic3r. Slic3r has all of the polygons already present in each layer (and each layer is done in parallel) as read from the 3d model as ExtrusionEntities. When I looked at it last, it was more work than I was willing to put into it (especially since I want reproducible tests), and there's still some guesswork involved with the termination clause. My thoughts on the matter were to implement it into GCodeWriter (immediate use) or to detect the arcs from ExtrusionEntities embedded polygons and extend Polyline, etc to store the arc information for later rendering with GCodeWriter. The SVG output is probably a good place to start, to be honest, as it will give you a cleaner representation of how Slic3r sees it (and that code has less going on). |
|
Any tests you would write can test it in libslic3r, no need to reinvent your primitives. |
|
@FormerLurker is working on https://github.com/FormerLurker/ArcWelderPlugin, an Octoprint plugin that postprocesses uploaded files to generate arcs; the core algorithm is I think already in C, so porting the code across might be feasible? |
|
@Floppy, the console version can already be used as a post processor, fyi. |
|
@Floppy, also, you might want to look at ArcWelderLib, which contains the console app and various CMake scripts (not verified in all OSs). I've got a few commits to push that keep case and formatting consistent, which I will push in the next couple days. |
|
CSG format contains enough info. STEP format AFAIK contains too. |
|
I think a way better option would be to not generate arcs at all and leave that to the program which generates the 3d model in the first place. For instance if a file format is supported which already has arc capability, that file format can be used by the 3d model program to save the file. When reading that file is supported by the slicer, arcs won't need to be generated because they already exist. |
|
Bambula integrated OpenCascade kernel, that is half of FreeCad. Bambula use OpenCascade to tesselate STEP files into triangle models, thus the smooth arches are lost. |
|
Ok, that's very interesting. But I think, even with arcs from a step file it's probably quite a pain to calculate the infill between the curves. Well, not necessarily pain, but probably quite expensive to calculate because of all the sine and cosine functions that would be required. |
and others
No description provided.
The text was updated successfully, but these errors were encountered: