Slic3r: Detect arcs and generate G2/G3

There are still some glitches in detection or arc center.

Some notes by @bkubicek here: http://bernhardkubicek.soup.io/post/191097625/If-you-have-a-path-of-segments

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'd love to see Arcs working on Slic3r.

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).
The gcode of the raft for example contains after each infill line a very small extrusion of 0.0031mm for ex (I use a 0.2mm nozzle). Arcs contains also small segments needing less than 0.02mm of filament and I believe they should be correctly extruded with G2/G3 commands (I need to make some tests to verify this hypothesis).
In all cases I plan to print precision mechanical parts and almost all parts may have rounded faces which will be better printed with G2/G3 commands.
I'm planning to add a Worm as a reductor to multiply needed amount of steps to forward 1mm of filament and avoid this problem as the minimum steps/mm value should not be less than 1000 in my mind.

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.
It seems to be disabled - How do I go about enabling it again?

@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:

G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.84105
G1 X117.874 Y63.038 E5.94500
G1 X118.846 Y63.205 E6.05141
G1 X119.789 Y63.405 E6.15536
G1 X120.745 Y63.645 E6.26177
G1 X121.670 Y63.915 E6.36572
G1 X122.606 Y64.226 E6.47213
G1 X123.508 Y64.565 E6.57608
G1 X124.417 Y64.947 E6.68248
G1 X125.290 Y65.353 E6.78644
G1 X126.168 Y65.803 E6.89284
G1 X127.009 Y66.274 E6.99679
G1 X127.850 Y66.788 E7.10320
G1 X128.652 Y67.322 E7.20716
G1 X129.452 Y67.898 E7.31356
G1 X130.212 Y68.491 E7.41751
G1 X130.966 Y69.126 E7.52392
G1 X131.679 Y69.775 E7.62787
G1 X132.383 Y70.465 E7.73428
G1 X133.044 Y71.166 E7.83823
G1 X133.507 Y71.694 E7.91402
G1 X134.301 Y72.656 E8.04857
G1 X134.892 Y73.445 E8.15498
G1 X135.441 Y74.237 E8.25893
G1 X135.971 Y75.068 E8.36534
G1 X136.458 Y75.900 E8.46929
G1 X136.924 Y76.769 E8.57570
G1 X137.347 Y77.635 E8.67964
G1 X137.746 Y78.537 E8.78605
G1 X138.102 Y79.432 E8.89001
G1 X138.431 Y80.361 E8.99641
G1 X138.718 Y81.281 E9.10036
G1 X138.977 Y82.233 E9.20677
G1 X139.194 Y83.171 E9.31072
G1 X139.379 Y84.140 E9.41713
G1 X139.524 Y85.092 E9.52108
G1 X139.636 Y86.072 E9.62749
G1 X139.709 Y87.033 E9.73144
G1 X139.746 Y88.018 E9.83784
G1 X139.746 Y88.982 E9.94180
G1 X139.709 Y89.967 E10.04821
G1 X139.636 Y90.928 E10.15215
G1 X139.524 Y91.908 E10.25856
G1 X139.379 Y92.860 E10.36252
G1 X139.194 Y93.829 E10.46892
G1 X138.977 Y94.767 E10.57287
G1 X138.718 Y95.719 E10.67928
G1 X138.431 Y96.639 E10.78323
G1 X138.102 Y97.568 E10.88964
G1 X137.746 Y98.463 E10.99359
G1 X137.347 Y99.365 E11.10000
G1 X136.924 Y100.231 E11.20395
G1 X136.458 Y101.100 E11.31036
G1 X135.971 Y101.932 E11.41431
G1 X135.441 Y102.763 E11.52072
G1 X134.892 Y103.555 E11.62466
G1 X134.301 Y104.344 E11.73107
G1 X133.694 Y105.092 E11.83503
G1 X133.044 Y105.834 E11.94143
G1 X132.383 Y106.535 E12.04538
G1 X131.679 Y107.225 E12.15179
G1 X130.966 Y107.874 E12.25574
G1 X130.212 Y108.509 E12.36215
G1 X129.452 Y109.102 E12.46610
G1 X128.652 Y109.678 E12.57250
G1 X127.850 Y110.212 E12.67646
G1 X127.009 Y110.726 E12.78287
G1 X126.168 Y111.197 E12.88682
G1 X125.290 Y111.647 E12.99322
G1 X124.417 Y112.053 E13.09718
G1 X123.508 Y112.435 E13.20358
G1 X122.606 Y112.774 E13.30754
G1 X121.670 Y113.085 E13.41394
G1 X120.745 Y113.355 E13.51789
G1 X119.789 Y113.595 E13.62430
G1 X118.846 Y113.795 E13.72825
G1 X117.874 Y113.962 E13.83466
G1 X116.919 Y114.089 E13.93861
G1 X115.938 Y114.182 E14.04502
G1 X114.976 Y114.237 E14.14897
G1 X113.990 Y114.255 E14.25538
G1 X113.026 Y114.237 E14.35933
G1 X112.042 Y114.181 E14.46573
G1 X111.083 Y114.090 E14.56969
G1 X110.105 Y113.960 E14.67609
G1 X109.156 Y113.797 E14.78004
G1 X108.191 Y113.593 E14.88645
G1 X107.256 Y113.358 E14.99040
G1 X106.310 Y113.082 E15.09681
G1 X105.396 Y112.777 E15.20076
G1 X104.738 Y112.530 E15.27655
G1 X103.584 Y112.057 E15.41110
G1 X102.690 Y111.642 E15.51751
G1 X101.832 Y111.203 E15.62146
G1 X100.972 Y110.720 E15.72787
G1 X100.150 Y110.218 E15.83182
G1 X99.329 Y109.672 E15.93822
G1 X98.547 Y109.108 E16.04218
G1 X97.770 Y108.502 E16.14859
G1 X97.033 Y107.881 E16.25254
G1 X96.304 Y107.218 E16.35895
G1 X95.616 Y106.543 E16.46289
G1 X95.134 Y106.032 E16.53868
G1 X94.304 Y105.101 E16.67324
G1 X93.683 Y104.335 E16.77964
G1 X93.105 Y103.564 E16.88359
G1 X92.543 Y102.754 E16.99000
G1 X92.025 Y101.941 E17.09395
G1 X91.670 Y101.335 E17.16974
G1 X91.072 Y100.241 E17.30430
G1 X90.639 Y99.355 E17.41070
G1 X90.249 Y98.474 E17.51465
G1 X89.885 Y97.558 E17.62106
G1 X89.563 Y96.649 E17.72501
G1 X89.269 Y95.708 E17.83142
G1 X89.017 Y94.778 E17.93537
G1 X88.795 Y93.818 E18.04178
G1 X88.614 Y92.871 E18.14573
G1 X88.465 Y91.896 E18.25214
G1 X88.356 Y90.939 E18.35609
G1 X88.281 Y89.956 E18.46250
G1 X88.245 Y88.993 E18.56645
G1 X88.245 Y88.007 E18.67285
G1 X88.281 Y87.044 E18.77680
G1 X88.356 Y86.061 E18.88322
G1 X88.465 Y85.104 E18.98716
G1 X88.571 Y84.409 E19.06295
G1 X88.795 Y83.183 E19.19750
G1 X89.017 Y82.222 E19.30392
G1 X89.269 Y81.292 E19.40786
G1 X89.563 Y80.351 E19.51427
G1 X89.885 Y79.442 E19.61822
G1 X90.249 Y78.526 E19.72463
G1 X90.639 Y77.645 E19.82858
G1 X91.072 Y76.759 E19.93499
G1 X91.527 Y75.910 E20.03894
G1 X92.025 Y75.059 E20.14535
G1 X92.543 Y74.246 E20.24930
G1 X93.105 Y73.436 E20.35570
G1 X93.651 Y72.707 E20.45399
G1 E17.45399 F12000.00000

becomes:

G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.841
G3 X93.651 Y72.707 I-2.924 J25.589 E20.454
G1 E17.45399 F12000.00000

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 :)
I'll get an eye on it and give it a try, thanks for your work.

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.

I'd be happier if this lived in slic3r proper and not as a gcode post-processor :)

I also would like to see this inside slic3r, which is why I'm working on getting the already implemented algorithm back to work.

Link to the branch: https://github.com/Salandora/Slic3r/tree/arcFix
Progress so far:

• Arcs get's detected
• Arc center points gets properly calculated
• Gcode gets replaced with G2, G3
• still some small bugs like:
  
  
  
  • radius on top layer a tiny little bit too big. (Visually checked through Repetier Host)
  
  
  • a strange looking line on the first object (Tried it with 3 times the same object, which basically is a Hexagon with a small and a big hole)
  
  

@Salandora any news about your branch? I noticed your repository seems to have no new updates since 3 months ago. Do you think it would be ready to merge to regular slic3r?

No it's not ready, I wanted to port this to C++ but Iahad no idea where to start.
Actually I fixed a few bugs in the postprocessing script that was already included but Still have bugs open, like wrong E value calculation with I think it was relative E movement.

And actually I have almost no time to take a look into this again.
Not even sure if the arcFix branch was actual or if I removed the latest changed before pushing them :-/

I'm about to start the implementation of a mathematical model for this. Any support from the developer? Because it's going to suppose lot of work and simulation xD. I have a mathematically demonstrated convergence, so it is a safe arc detection.

Ask questions, people who can help and want to will jump in. I can't
guarantee anything specific in terms of support though, I have a lot of
things going on.

On Dec 5, 2017 10:12 AM, "PurpleSensation" notifications@github.com wrote:

I'm about to start the implementation of a mathematical model for this.
Any support from the developer? Because it's going to suppose lot of work
and simulation xD. I have a mathematically demonstrated convergence, so it
is a safe arc detection.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-349353693, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB8CsVQiOxmu_4hQbcmUS1RsZr6p5dNks5s9WtogaJpZM4CPczH
.

Okay, it's done. Now I have to check if the algorithm is solid but I'm plenty sure it is. I'm probably going to publish a paper with this, but I absoluty dont know how to implement this on GitHub, I did it on MatLab.

It would need to be implemented in C++ to be useful to the Slic3r project.

On Dec 9, 2017 9:12 AM, "PurpleSensation" notifications@github.com wrote:

Okay, it's done. Now I have to check if the algorithm is solid but I'm
plenty sure it is. I'm probably going to publish a paper with this, but I
absoluty dont know how to implement this on GitHub, I did it on MatLab.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-350477368, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB8CilKXqig1mWQQ4k9y66IUGp-vUImks5s-qNUgaJpZM4CPczH
.

Very interested by this project and I would like to help, I have some knowledge in C++ but almost no skill with matlab.

Im waiting to register the idea for a scientific paper ( I need some curriculum for a master program) and then I'll share. Also I have to check methods to ensure softness of the curve on the points between arcs and lines and etc... But the code is perfecly solid right now and always converge and returns to you a poly line/arc with a given colinear error.

The green lines are arcs, the nodes are the original polyline nodes and the red line are straight lines. You can send me closed polylines (given in format of an array of ordered x y positions) to test the algorithm.

I fully understand wanting to write it up and publish (I was once a grad
student myself). What's the time/space complexity look like?

On Dec 10, 2017 10:53 AM, "PurpleSensation" notifications@github.com
wrote:

Im waiting to register the idea for a scientific paper ( I need some
curriculum for a master program) and then I'll share. Also I have to check
methods to ensure softness of the curve on the points between arcs and
lines and etc... But the code is perfecly solid right now and always
converge and returns to you a poly line/arc with a given colinear error.

[image: imagen]
https://user-images.githubusercontent.com/23365990/33807172-d194e86c-ddd2-11e7-9bd5-9f8c5cc5fa46.png
The green lines are arcs, the nodes are the original polyline nodes and
the red line are straight lines. You can send me closed polylines (given in
format of an array of ordered x y positions) to test the algorithm.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-350561807, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB8Ch6ym1LE2VxV4hYYlpIGg-W2qSRNks5s_AyMgaJpZM4CPczH
.

Slic3r can generate a set of slices in SVG already. You could then check it
against a lot of interesting models (which would likely be useful for
benchmarks for your paper).

On Dec 10, 2017 11:45 AM, "Joe Lenox" lordofhyphens@gmail.com wrote:

I fully understand wanting to write it up and publish (I was once a grad
student myself). What's the time/space complexity look like?

On Dec 10, 2017 10:53 AM, "PurpleSensation" notifications@github.com
wrote:

Im waiting to register the idea for a scientific paper ( I need some
curriculum for a master program) and then I'll share. Also I have to check
methods to ensure softness of the curve on the points between arcs and
lines and etc... But the code is perfecly solid right now and always
converge and returns to you a poly line/arc with a given colinear error.

[image: imagen]
https://user-images.githubusercontent.com/23365990/33807172-d194e86c-ddd2-11e7-9bd5-9f8c5cc5fa46.png
The green lines are arcs, the nodes are the original polyline nodes and
the red line are straight lines. You can send me closed polylines (given in
format of an array of ordered x y positions) to test the algorithm.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-350561807, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB8Ch6ym1LE2VxV4hYYlpIGg-W2qSRNks5s_AyMgaJpZM4CPczH
.

The space complexity may be linearly proportional to the number of nodes you introduce in, but it depends on you. You can actually use more memory to optimize time complexity.
Time complexity may scale exponentially with the number of nodes (more or less, I'm not a student of computer engineering, I'm just a multidisciplinary physics/industrial student). But that only happens with noisy curves, if you input a high precision mechanical draw, the parametrization gets solved instantly because arcs are detected immediately after first analysis.

@PurpleSensation as a fyi work by @platsch was also submitted to a paper.

Thankyou, I am asking for some help to professors, and I have generaliced the algorithm for unclosed paths, here some results:

It seems a little strange to start with STL which is linear interpolated and then try to work back to circles. Is there a compelling benefit to doing this?

For any two connected line segments, it's pretty easy to find the centre of the circle that includes their endpoints (provided they're not degenerate). - Something like 10 multiplications, 14 additions, and 2 divisions.

So, for any extrusion path, you could just generate a series of centres, and then group segments if consecutive centers are close enough to each other, and the segments are short enough relative to the radius. I suppose there's also a check to make sure that it's not winding more than a full circle, and that the chirality is consistent.

This is the problem of STL : you can't have a circle.
Modern printers supports G2/G3, arcs no more suffers of any default (linearized arcs) and may be quicker to do. gcode is also lighter (only 1 line to do an arc, not dozens).

For NateTG:

The thing of doing an alorithm for this is pretty harder than doing what you say. It is not much harder but you must be able to mathematically demonstrate that the algorithm finds ALWAYS a solution, that it is optimal or semioptimal and manage well with colindant arcs or multiple radious arcs (wich is not trivial, but actually solved). Also you should probe that a certain colinear error is matched.

The thing of finding arcs and use a parametric trayectory instead of a polylinear one is an advantage because you need less memory movements on the processor and you are able to maintain better precission and sincronization of the motors. On delta printers it is usual to finde little bubbles on the prints because of microstopping of the extrusor. The printing speed is also limited by the number of operations per second. (the faster you move, the less polyline density your trajectory has).

Just going to leave this here:

https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php

It's a script written in php that:

1. continually loops through gcode commands, pushing them onto a buffer
2. checks to see if the points in the buffer look like a circle within a tolerance
3. if the points no longer look like a circle, empty the buffer and transform [buffer - 1] into a gcode arc
4. go to step 1

It does this by:

1. finding the circle that describes the points in the buffer using least squares (see https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php#L311)
2. calculating the total error distance between each line and the circle (see https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php#L359)
3. If the error is less than a predefined amount, create a gcode arc of the circle, summing up the extrusions along the line lengths.

I don't know if this will help anyone else hoping to write an algorithm to do this, but there you go! It worked pretty well and I got some successful prints out of it - it was just a bit slow in php!

... it was just a bit slow in php!

It looks like a lot of that "slow" has to do with an inefficient implementation. You're making something that should be O(N) into O(N^2) (or O(N^4) for the algorithm you're not using) by duplicating effort.

Those implementations work well on well behaved polylines. But I ensure you (im researching this for a paper) that noisy polylines introduce a lot of weird situations like finding little arcs wich are acctually part of bigger ones if you search for another parametric combination. I you use just a look ahead algorithm you will lose optimal solutions on noisy lattices

Well, if there's a better way to tell a circle from a series of straight lines than a fitting algorithm I'd love to hear it.

I couldn't think of a better way than stepping through the data and comparing to fitting circles. It has limits built in which make it a lot faster, for example the buffer gets full at 100 points because a 1/100 saving on instructions is enough for most uses.

It deals fine with noisy lines, as it uses a least squares fitting to fine the circle and as long as it keeps finding circles that fit the buffer within a tolerance, it will approximate those points to a circle.

If they're not within a tolerance to a circle then they should be replaced with a G code arc.

Well, if there's a better way to tell a circle from a series of straight lines than a fitting algorithm I'd love to hear it.

The way it's implemented in the script, if there's an arc with N segments, it runs getCircleCenterLeastSquares on a buffer of 1 and then a buffer of 2 ... until it's a buffer of N+1, so it iterates over roughly N^2/2 segments.

This is even worse with the getCircleCenter function because that runs about N^3/6 steps, so an N segment arc takes about N^4/24 iterations.

If, instead, the algorithm incrementally adds segments to an arc without recalculating everything for each new segment, that can happen in N steps. I'm not sure that there's an easy way to do that with the 'least squares' approach you're using.

Even so, as long as the arcs tend to come in bunches of segments, a binary search approach is faster than the incremental one. Checking buffers of 1, 2, 4, 8, 16, 32, 64, 127, 96, 112, 104, 100, 102, and 101 runs through the loop in getCircleCenterLeastSquares about 869 times, while stepping though of 1,2,3...100 goes through that loop 5050 times.

You actually search por G0 parametric interpolation papers and find other ways of doing this. The thing is: you can first assing an index to each point describing how long is the arc wich is included in and then start the assingment from the maximun index, or try to do both ad the same time. The question is, do you lose opimal solutions if you make the assignement before having all the information?

The binary search idea is a good one, as curves generally have many points as generated by modelling software.

If a buffer of 4 or 5 is found then it could skip straight to higher numbers.

This is bearing in mind a lot of models don't have a lot of arcs. A cube, for example, would go through the current algorithm pretty quick, as the buffer will never get past 3 points.

I guess it comes down to the time vs tide savings you want. You could have a max buffer of 20 and still reduce G code lines by 20 times in the best case.

My motivation was to allow my 3d printer to run via octoprint with smooth arcs, as the baud rate from the raspberry pi meant my printer would stutter a lot on arcs - if I spent a minute running the G code through th8s algorithm it was better than a print failing after 10 hrs

Update: work in progress. The algorithm is fast and soild, I'm about to start writing the paper to be publish. The process is made by several methods including incremental one (the fastest but the one with the worst solutions).

Figure a) -> 0.1mm colinear error, 20% of original weight.
Figure b) -> 0.05mm colinear error, 26% of original weight.
Figure c) -> 0.01mm colinear error, 40% of original weight.
Figure d) -> 0.005mm colinear error, 51% of original weight.

The figure a) aproximates to the incremental solution in several ways (as you can see, overlaping arcs aren't solved maintaing simetry).

300 of those take about 25 second to be processed. This number can become smaller with implementation of parallelism, gpu, etc...

Update: the method is perfectly implementable right now:

A full piece of 500 layers like the last shown is processed in about 10 seconds without any heuristic and running on MATLAB.

@PurpleSensation so when should I set aside time to review a pull request ;)

No idea bro xD. This is already implememtable but probably I should wait until submission of the paper. Also I have no idea about c++ implementation, this is fully implemented in MatLab and i'm sure I wouldn't be a good software engineer. Ill try to obtain a modular plug and play c++ compilation.

One option would be to have someone look at it under an NDA or similar to see how much work it would be to convert from Matlab into C++.... Are you relying heavily on the Matlab libraries for convenience or speed? Or is it all base math in normal code?

AFAIK Matlab has at least a compiler to convert it to standalone-C-code (I only read that as I have never used Matlab). I have no idea though if that is to be purchased separately or if it is contained in the default license. This would at least be a lot closer to C++ already.

If you are talking about the solution I am familiar with, it won't work as that approach will embed the script in a library which contains (part of) the Matlab engine, plus a C stub which can be used to link against the library. It will be big, not portable and afaik not distributable.

I only have second-hand-information but at least wanted to have it documented here - even only for being rejected. :-)

@purplesensation if you wanted, you could privately send me an advance copy of the paper and the basic script and I can sketch out the algorithm in C++.

I am very familiar with the academic publishing process. :)

Obviously how comfortable you are with that is a factor.

This software looks really good at making arcs and I want to try it ASAP!!

Is it possible to create an executable from the MATLAB file that can take a
GCODE generated by Slicer, and process the GCODE to change the lines into
arcs? That would be separate software, but at least it would let more
people test it and try it.

If you compile as an executable, you don't need to worry about the code
being copied/stolen and others can try it in the meantime....

On Thu, Jun 14, 2018 at 8:06 AM, Manuel notifications@github.com wrote:

I only have second-hand-information but at least wanted to have it
documented here - even only for being rejected. :-)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/slic3r/Slic3r/issues/23#issuecomment-397288841, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJ2tvqINaxvNnhhnfj0e4bK0XPDTzwwYks5t8l_IgaJpZM4CPczH
.

As long as the algorithm is not published I would not package it using Matlab, I'm fairly sure a lot can be extracted from the C library. Which does not mean I would not like to see it end up in a tool like Slic3r soon, but just as a fair warning :)

@lordofhyphens Okay, check your email.

@PurpleSensation Is it permissible for me to share this paper with a GSoC student (with the understanding that it would not be shared beyond that).

Yes, just give me a few hours. Right now I'm applying some important corrections that make it much more understable (the english and the math). I'll resend to your email.

@PurpleSensation Thank you.

@TheThirdOne is implementing the heuristic from the article written by @PurpleSensation in the last few weeks of GSoC 2018.

@manticorp I would appreciate your availability to print-test it once it's merged in ;)

@lordofhyphens sure no worries!

@lordofhyphens Do not hesitate to contact me for any direct conversation about the thing.

@manticorp Point out that the printer firmware should have implemented G3 arcs command.

@PurpleSensation I have said as much to @TheThirdOne.

@PurpleSensation I think mine does - did so in my tests, hard part was getting the extrusion amounts exactly right after matching the curve

Some parts of the method may take a lot of time to be implemented. They can be substituted by simplistic (and perfectly functional) approximations. e.g. the post processing of the arc can be performed just by a three point arc fitting.
Probably the best idea is to start just applying the method to perimeters because their usual organic shape. It should work perfectly being applied on every trajectory, but idk.

I've made some good progress towards getting this implemented as guided by @PurpleSensation's paper. Currently detecting possible intervals where lines could be replaced with an arc is working. I have a temporary greedy algorithm to choose which of intervals to choose. I am currently working on making the output continuous and actually outputting arcs.

@TheThirdOne I am about to submit a definitive version of the paper, it has changed a lot and now it is much more understandable. if you want I can send to you, I just need an email direction. Also, if you need some chatting to clarify paper stuff I would have no problem.

@PurpleSensation Let us know when it becomes public, and how we can buy/get it.

@PurpleSensation more importantly I will add the citation to the comments when it is published.

You can send it to me and I can forward it to @thethirdone as well.

@mamoit scholar.google.com would show the paper's title and where it is published.

I don't believe there is any financial support to @PurpleSensation by buying a copy of the journal issue or article that it arrives in.

It also probably will be months before it is published.

@purplesensation one thing that would help, I think, is checking the tests written by @thethirdone for correctness (that is, given A, B is output)

I am going to submit to ArXiv so if it is accepted it shouldn't take long. My only problem right now is my lack of affiliation with any Institution (which is commonly asked). ArXiv provides a temporary version of the paper so it should be accessible in a few days. @lordofhyphens there's no problem about the cheking, I even expect to share the MATLAB code on mathworks

@TheThirdOne fyi https://en.wikipedia.org/wiki/G-code#I when you get to gcode generation.

The center when using I/J/K is a relative offset from the current position.

I took a stab at implementing the GCode generation for this as a filter. The perl implementation gives a pretty good idea about what it should look like, but it applies to everything in a layer. It seems that arc fitting probably doesn't make sense with support, and only makes sense with specifically designed infill.

I was going to ask if there was a good way to detect if a line was infill or perimeter, but I realized as writing this that I can just filter earlier per perimeter.

I also did some looking into not parsing and regenerating gcode. As expected it requires touching a bunch of different classes to add arc support. It doesn't look like a clean solution particularly with the realization above.

Here is the paper: Polyline defined NC trajectories parametrization. A compact analysis and solution focused on 3D Printing

I'm about to upload the code implementation on MatLab, it should help.
@TheThirdOne The infill could be somewhat filtered using the control parammeters of the method. Forcing each pair of consecutive dots inside any arc to have a maximum distance between them may avoid the generation of arcs on line infills and stuff. Probably 0.5 mm is a good requisite.

Isn't there any stage at the slicing process where you have a raw node description of the printing process? Starting from that could be easier than deconstructing the GCode.

@purplesensation best we have is the Polylines that make up the surfaces in PrintGcode.cpp.

@thethirdone push your updates up to your fork and I can take a closer look.

@PurpleSensation, I have a question about the paper. How is 4a garenteed? 3.1 appears to only ensure no interval is a subset of another.

@TheThirdOne You are right. The condition of not working with intervals included in the union of two other intervals is taken in account while looking for intersections. I'll try to explain better:
Look at Listing 2 on 3.3. When you analyze an interval (call it A) in order to find intersections on its right you basically look for other intervals starting from the inside of A and keep the one reaching further distance at its end (call to this selected interval B). With this behavior you are discarding all the intervals contained in the union of A and B.

That is a tricky point to describe. I was waiting for the question.

Here is the code
Polyline approximation with arcs and segments.

I have a full implementation besides configuration and only having a simple greedy intersection handler. It possible there are some major issues with the GCode interface as that hasn't really been tested yet.

@TheThirdOne figures? Want to send me a polyline for comparison?

Here u have a published code capsule. With an account you can run, edit and overview the code. There's an interface for parameter tuning.

https://codeocean.com/2018/09/07/polyline-approximation-with-arcs-and-segments/code

I'm working on an efficient true arc-plotter in my 3d-printer firmware. This is good timing. :+1:

@phord That's very cool, I keep the working on the recognition. Want some samples to try your work? I could provide 1 layer gcodes for trying. @TheThirdOne How is it going?

@PurpleSensation Sure. Can you send me arc and non-arc versions of the same file? That way I can compare to ensure we're interpreting things the same way.

On that, do you emit arcs with I,J center or with R radius? I'm planning to support both, but I wonder how useful R is, really.

@phord I would have to start working on a primitive gcode generation script, it is easy work. I can implement both, easy work. Are you going to use a pen for the monolayer print or want me to add extrussion? I don't know the maths about extrussion inertia and stuff.

No need for extrusion; I'll start by simulating it. I thought you were working on some conversion from existing g-code to add arcs, right? So I thought you would have both in your tests. Do you want me to send you some linear g-code with lots of arcs to convert instead? I have some. :-D

https://gist.githubusercontent.com/phord/02c87e5c60c744f3998c7ee3cde0a419/raw/6611c6e7eaef8f803467f82e744bf1c1373babd7/Pure2-lego.gcode

This g-code has lots of arcs but they're cut with small facets. Others might use fewer facets and could be good test cases, also.

Oh, I see. It was @TheThirdOne who is working on the g-code conversions. Sorry about confusing you two.

@PurpleSensation, I have been busy with other things for a while. I have wanted to make some time to pick this back up.

@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.

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.

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:
G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.84105
G1 X117.874 Y63.038 E5.94500
G1 X118.846 Y63.205 E6.05141
G1 X119.789 Y63.405 E6.15536
G1 X120.745 Y63.645 E6.26177
G1 X121.670 Y63.915 E6.36572
G1 X122.606 Y64.226 E6.47213
G1 X123.508 Y64.565 E6.57608
G1 X124.417 Y64.947 E6.68248
G1 X125.290 Y65.353 E6.78644
G1 X126.168 Y65.803 E6.89284
G1 X127.009 Y66.274 E6.99679
G1 X127.850 Y66.788 E7.10320
G1 X128.652 Y67.322 E7.20716
G1 X129.452 Y67.898 E7.31356
G1 X130.212 Y68.491 E7.41751
G1 X130.966 Y69.126 E7.52392
G1 X131.679 Y69.775 E7.62787
G1 X132.383 Y70.465 E7.73428
G1 X133.044 Y71.166 E7.83823
G1 X133.507 Y71.694 E7.91402
G1 X134.301 Y72.656 E8.04857
G1 X134.892 Y73.445 E8.15498
G1 X135.441 Y74.237 E8.25893
G1 X135.971 Y75.068 E8.36534
G1 X136.458 Y75.900 E8.46929
G1 X136.924 Y76.769 E8.57570
G1 X137.347 Y77.635 E8.67964
G1 X137.746 Y78.537 E8.78605
G1 X138.102 Y79.432 E8.89001
G1 X138.431 Y80.361 E8.99641
G1 X138.718 Y81.281 E9.10036
G1 X138.977 Y82.233 E9.20677
G1 X139.194 Y83.171 E9.31072
G1 X139.379 Y84.140 E9.41713
G1 X139.524 Y85.092 E9.52108
G1 X139.636 Y86.072 E9.62749
G1 X139.709 Y87.033 E9.73144
G1 X139.746 Y88.018 E9.83784
G1 X139.746 Y88.982 E9.94180
G1 X139.709 Y89.967 E10.04821
G1 X139.636 Y90.928 E10.15215
G1 X139.524 Y91.908 E10.25856
G1 X139.379 Y92.860 E10.36252
G1 X139.194 Y93.829 E10.46892
G1 X138.977 Y94.767 E10.57287
G1 X138.718 Y95.719 E10.67928
G1 X138.431 Y96.639 E10.78323
G1 X138.102 Y97.568 E10.88964
G1 X137.746 Y98.463 E10.99359
G1 X137.347 Y99.365 E11.10000
G1 X136.924 Y100.231 E11.20395
G1 X136.458 Y101.100 E11.31036
G1 X135.971 Y101.932 E11.41431
G1 X135.441 Y102.763 E11.52072
G1 X134.892 Y103.555 E11.62466
G1 X134.301 Y104.344 E11.73107
G1 X133.694 Y105.092 E11.83503
G1 X133.044 Y105.834 E11.94143
G1 X132.383 Y106.535 E12.04538
G1 X131.679 Y107.225 E12.15179
G1 X130.966 Y107.874 E12.25574
G1 X130.212 Y108.509 E12.36215
G1 X129.452 Y109.102 E12.46610
G1 X128.652 Y109.678 E12.57250
G1 X127.850 Y110.212 E12.67646
G1 X127.009 Y110.726 E12.78287
G1 X126.168 Y111.197 E12.88682
G1 X125.290 Y111.647 E12.99322
G1 X124.417 Y112.053 E13.09718
G1 X123.508 Y112.435 E13.20358
G1 X122.606 Y112.774 E13.30754
G1 X121.670 Y113.085 E13.41394
G1 X120.745 Y113.355 E13.51789
G1 X119.789 Y113.595 E13.62430
G1 X118.846 Y113.795 E13.72825
G1 X117.874 Y113.962 E13.83466
G1 X116.919 Y114.089 E13.93861
G1 X115.938 Y114.182 E14.04502
G1 X114.976 Y114.237 E14.14897
G1 X113.990 Y114.255 E14.25538
G1 X113.026 Y114.237 E14.35933
G1 X112.042 Y114.181 E14.46573
G1 X111.083 Y114.090 E14.56969
G1 X110.105 Y113.960 E14.67609
G1 X109.156 Y113.797 E14.78004
G1 X108.191 Y113.593 E14.88645
G1 X107.256 Y113.358 E14.99040
G1 X106.310 Y113.082 E15.09681
G1 X105.396 Y112.777 E15.20076
G1 X104.738 Y112.530 E15.27655
G1 X103.584 Y112.057 E15.41110
G1 X102.690 Y111.642 E15.51751
G1 X101.832 Y111.203 E15.62146
G1 X100.972 Y110.720 E15.72787
G1 X100.150 Y110.218 E15.83182
G1 X99.329 Y109.672 E15.93822
G1 X98.547 Y109.108 E16.04218
G1 X97.770 Y108.502 E16.14859
G1 X97.033 Y107.881 E16.25254
G1 X96.304 Y107.218 E16.35895
G1 X95.616 Y106.543 E16.46289
G1 X95.134 Y106.032 E16.53868
G1 X94.304 Y105.101 E16.67324
G1 X93.683 Y104.335 E16.77964
G1 X93.105 Y103.564 E16.88359
G1 X92.543 Y102.754 E16.99000
G1 X92.025 Y101.941 E17.09395
G1 X91.670 Y101.335 E17.16974
G1 X91.072 Y100.241 E17.30430
G1 X90.639 Y99.355 E17.41070
G1 X90.249 Y98.474 E17.51465
G1 X89.885 Y97.558 E17.62106
G1 X89.563 Y96.649 E17.72501
G1 X89.269 Y95.708 E17.83142
G1 X89.017 Y94.778 E17.93537
G1 X88.795 Y93.818 E18.04178
G1 X88.614 Y92.871 E18.14573
G1 X88.465 Y91.896 E18.25214
G1 X88.356 Y90.939 E18.35609
G1 X88.281 Y89.956 E18.46250
G1 X88.245 Y88.993 E18.56645
G1 X88.245 Y88.007 E18.67285
G1 X88.281 Y87.044 E18.77680
G1 X88.356 Y86.061 E18.88322
G1 X88.465 Y85.104 E18.98716
G1 X88.571 Y84.409 E19.06295
G1 X88.795 Y83.183 E19.19750
G1 X89.017 Y82.222 E19.30392
G1 X89.269 Y81.292 E19.40786
G1 X89.563 Y80.351 E19.51427
G1 X89.885 Y79.442 E19.61822
G1 X90.249 Y78.526 E19.72463
G1 X90.639 Y77.645 E19.82858
G1 X91.072 Y76.759 E19.93499
G1 X91.527 Y75.910 E20.03894
G1 X92.025 Y75.059 E20.14535
G1 X92.543 Y74.246 E20.24930
G1 X93.105 Y73.436 E20.35570
G1 X93.651 Y72.707 E20.45399
G1 E17.45399 F12000.00000

becomes:
G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.841
G3 X93.651 Y72.707 I-2.924 J25.589 E20.454
G1 E17.45399 F12000.00000

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).

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?
I take the index.php and drag&drop it into Firefox.

Now i have a page which asks me to browse for a .gcode file.
I select my GCODE from the HDD and click Submit.

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.
I would like to have some more thoughts to this, lets start a discussion.
Nevertheless which engine of an existing slicer would be the best basis to start such an implemention? There is a topic in the cura project where one of the developers said they would have to redesign the whole engine; it's designed to work layer by layer.

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.
A second step would be to implement this into the GUI and make the functionality be used by Slic3r.

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.