Slic3r
Slic3r copied to clipboard
slic3r
Detect arcs and generate G2/G3
Some notes by @bkubicek here: http://bernhardkubicek.soup.io/post/191097625/If-you-have-a-path-of-segments
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.
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).
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" [email protected] 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" [email protected] 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.