Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gapfill problem with thin walls #2960

Closed
teppix opened this issue Jun 29, 2015 · 155 comments

Comments

Projects
None yet
@teppix
Copy link

commented Jun 29, 2015

I think that the gapfill feature may be producing too wide extrusions, and needs to be configurable.

These tests were done in 1.2.9.

This model shows the problem really well.
https://dl.dropboxusercontent.com/u/448992/github/idler.stl
Slic3r profiles are linked below the images.

Note that the inner walls of the object is slanted in some places, which causes the gap fill to vary along the height.

Here is the result when using automatic width for perimeters:
idler_a
Slic3r profile: https://dl.dropboxusercontent.com/u/448992/github/slicer_gapfill_issue/idler_a.ini

The measurements are pretty accurate, apart from the obvious bulge on the middle of the part. This bulge coincides with the layers where the gap-fill is made. The g-code shows perfect sides, but I believe that the problem is caused by the gap fill pushing the perimeters apart.

I can work around the problem by manually tweaking extrusion width for perimeters, but that seems to introduce other inaccuracies in the model like the perimeters becoming inaccurate. i have calibrated the extrusion multiplier, so I don't think that's the problem.

This is the result with manually set 0.5 mm perimeters.
idler_b
Slic3r profile: https://dl.dropboxusercontent.com/u/448992/github/slicer_gapfill_issue/idler_b.ini

You can clearly see that the thickness of the rim is affected (guess this is another issue though).

I'll add more information if needed, but I think this is enough to be able to reproduce the problem.

@a4jp-com

This comment has been minimized.

Copy link

commented Jun 30, 2015

My models were thick at the bottom too and I just thought it was a printer problem. Glad to hear it might be software related.

@teppix

This comment has been minimized.

Copy link
Author

commented Jun 30, 2015

That's interresting a4jp-com. I'd like to know if someone else is seeing the same issue, and also if you could check the g-code preview if there are any gap fills near the area where the problem occurs.

Just adding a clarifying illustration

gapfill-illustration

Have also tried printing the part again with same settings as in the first image, except with 0% infill. The bulge is gone, so this proves that the gap fill is what's causing the problem.

Also, note that I'm using a 0.5mm nozzle, so maybe you won't see the same problems that I do at this scale if you have a smaller nozzle.

Perhaps the nozzle size is what triggers the problem?

@hakimio

This comment has been minimized.

Copy link

commented Jun 30, 2015

I see the same problem with 0.4 nozzle. I don't think it has anything to do with nozzle diameter. Some things to note:

I have 0.4mm nozzle and I have set external and internal perimeter extrusion width to 0.45mm which gets rid of the issue.

@teppix

This comment has been minimized.

Copy link
Author

commented Jun 30, 2015

hakimio, thanks for the comment. I will check the links more in detail. I did make some effort of finding the issue before, but apparently i may have failed :)

Regarding the extrusion width in relation to the nozzle diameter: You may be right regarding the 1.05 factor, but that's not really relevant to the issue.

1st print used automatic extrusion widths for everything.

2nd print used manual extrusion widths for perimeters (internal and external), but automatic for everything else. The width were tweaked so that the gap fill wouldn't be so significant.

So the problem I'm focusing on here is only present when in the 1st print, where I'm using automatic setting for extrusion widths. The only point I'm trying to make is that I can eliminate the problem by either manually setting extrusion width, or by setting infill to 0%.

EDIT: I realized that you wrote that you don't think it has anything to do with nozzle diameter, and I agree. Wer'e talking about a possible miscalculation somewhere of course. I agree that in theory it should be totally unrelated.

But automatic extrusion width is directly related to nozzle size (I assume), and there seems to be some correlation with automatic width and the actual problem described in the first comment, so nozzle size may not be completely unrelated to the problem, even if it's far fetched.

That said, I have barely touched Slic3r's source, so I may of course be way off in my assumptions :)

@teppix

This comment has been minimized.

Copy link
Author

commented Jul 1, 2015

Here's almost definitely proof of the problem:
infill_onoff

I have been taking a peek at the code, and if I understand it correctly, it has two different widths of gap fill.
https://github.com/alexrj/Slic3r/blob/master/lib/Slic3r/Layer/PerimeterGenerator.pm#L286-287

For small gaps it always uses 100% of perimeter width for the gap fill, even down to gaps which is 0.1 times the perimeter width.

I'm not sure if I'm reading it correctly, but I think the picture speaks for itself in any case. the infill is pretty wide if you compare to the gap it's supposed to fill.

Will try to experiment a bit with the code to see if I can make it work better.

@teppix

This comment has been minimized.

Copy link
Author

commented Jul 2, 2015

teppix@0a41715
This update makes this issue disappear for me. The values are pretty arbitrary, and could probably be refined even more, but so far I'm getting pretty good results.

I'm not sure what $pspacing is referring to though, so it would be very welcome if someone with a bit more knowledge about this code could comment on this,

Also note that this issue doesn't seem to appear as much when using larger layer heights, but it becomes very apparent at 0.2mm layers. Also, like I mentioned, I'm using 0.5mm nozzle, and I'm not really sure what happens if I use a different width.

Also not sure how much this commit affects slicing performance. I haven't noticed any significant difference anyhow.

I'll be making more test prints to compare, but I'd be happy if more people could try this out and comment!

@hakimio

This comment has been minimized.

Copy link

commented Jul 2, 2015

@teppix you should make a push request to get some feedback from @alexrj .

@teppix

This comment has been minimized.

Copy link
Author

commented Jul 2, 2015

@hakimio ok, thanks, I'll do that!

@alranel

This comment has been minimized.

Copy link
Member

commented Jul 3, 2015

Thank you @teppix. I decided to put the error on the abundance side, since people usually complain about gaps more than they complain for overextrusion. But I agree that needs to be improved.
The more correct and more efficient solution will be to have the medial_axis() logic return the actual gap width; then we can assign it to the extrusion instead of trying fixed tiers. That way there would be no error at all, and variable-width gaps would be handled nicely.

Working on Slic3r I've learned one thing. Whenever tuning some hard-coded fudge-factor seems to fix some issue, it means that a better and more robust logic is needed. :)

@teppix

This comment has been minimized.

Copy link
Author

commented Jul 5, 2015

@alexrj it's nice to hear that this is an actual issue and not just my imagination :)

I have been tweaking the values a bit more, but I realize of course that this is not the most elegant solution. Would love to see a fix that does a correct calculation. Solving it the "right" way is beyond me at the moment but if you want my "hack" as a temporary solution, the current values which seems to work fine mostly, are available in this branch: https://github.com/teppix/Slic3r/tree/gapfix

I have seen some comments about 1.2.9 producing inferior results to earlier versions, I think this issue is one of the main reasons. Another one is the default settings, which I don't agree with 100%, but I suppose that's also in part a personal preference. This is a bit off topic here, but if tweaking the default settings is up for discussion I'd love to chime in, since I believe that a lot can be done to ease the transition for new users (migrating from previous versions or other competing slicers).

@joecarpita

This comment has been minimized.

Copy link

commented Jul 7, 2015

@teppix @alexrj

I just wanted to chime in and add my experience to the discussion. I think I'm experiencing the same problem? Over the weekend I updated from 1.1.7 to 1.2.9 and using the same settings I'm now getting some odd smudging as a result.

slic3r_thin_wall

• a was sliced using 1.1.7. The settings worked great, everything was nice and smooth.
• b was sliced using 1.2.9 using the exact same config file as I had used in 1.1.7. Nothing changed on the printer, or in the settings.
• c was sliced using 1.2.9 with detect thin walls turned off -- I thought it might have something to do with the adjustment to thin wall logic made that is mentioned on the changelog for Slic3r 1.2.9, so I turned off "detect thin walls."

This is a print of this part: http://www.thingiverse.com/thing:903411
Here is the slic3r profile I used: https://dl.dropboxusercontent.com/u/972227/pg_self_watering_planter.ini

@teppix

This comment has been minimized.

Copy link
Author

commented Jul 8, 2015

@joecarpita

i think it's very likely that the problem in picture B is the same.

In picture C you get other errors, simply becaulse slic3r doesn't check for perimeter collisions, so you may get too much extrusions there also, but that's expected. The assymetry is probably caused by pressure buildup in the extruder along the extrusion path. Part of the pressure problem might go away by increasing temperature and/or decreasing speed (assuming you are printing at lower temperatures now, i.e. 190-200 C).

@a4jp-com

This comment has been minimized.

Copy link

commented Jul 8, 2015

It looks like the program is slowing the feed down too early and then when it starts up again maybe that amount is missing from the feed calculation. I could be wrong though. I have a slightly similar problem when the first blob of PLA is always a bit too thick on the start of the skirt but as it is the skirt it doesn't really matter. This problem would probably be really bad if you're trying to print a house with windows though. Do you have any other models that have the same type of problem?

@joecarpita

This comment has been minimized.

Copy link

commented Jul 10, 2015

@teppix I'm printing at 210 deg. in PLA, 30mm/s in all those photos. To make sure is was something in Slic3r 1.2.9, I downloaded the part from Thingiverse again, and downloaded Slic3r 1.1.7 again, sliced, printed, came out perfect (like in photo A).

@a4jp-com I haven't experienced this with any other models, yet. I just updated to slic3r 1.2.9 this weekend and have been trying to troubleshoot this particular print. I'll try another thin wall part and report back.

@Hexman64

This comment has been minimized.

Copy link

commented Jul 14, 2015

I had too-much-material issues with gaps, too.

To investigate, I created a simple wall with 2.12mm width and set the extrusion width to 0.7mm:
simplewall

This should give one perimeter and a gap fill which is 0.72mm wide. So the extrusion speed of the gap should only be slightly higher than for the perimeters.
I got:
; generated by Slic3r 1.2.9 on 2015-07-14 at 20:27:00
; external perimeters extrusion width = 0.70mm
; perimeters extrusion width = 0.70mm
...
G1 Z2.010 F15000.000 ;(somewhere in the middle)
G1 E1.60000 F1620.00000 ;(retraction)
G1 X80.350 Y120.710 E2.78121 F747.168
G1 X80.350 Y119.290 E2.81524
G1 X129.650 Y119.290 E3.99645
G1 X129.650 Y120.635 E4.02868
G1 X129.217 Y120.460 F15000.000
G1 X129.325 Y120.000 F15000.000
G1 X80.675 Y120.000 E6.44835 F600.000 ;(gap fill with high E value)
G1 E4.84835 F1620.00000

while Slic3r 1.1.7 gives:
(Edit: also 1.2.7 has similar values, but starting with 1.2.8 I get E6.44)

G1 Z2.010 F15000.000
G1 E1.60000 F1620.000
G1 X75.350 Y100.710 E2.79290 F747.126
G1 X75.350 Y99.290 E2.82726
G1 X124.650 Y99.290 E4.02016
G1 X124.650 Y100.635 E4.05271
G1 X124.217 Y100.460 F15000.000
G1 X124.321 Y100.000 F15000.000
G1 X75.679 Y100.000 E5.84512 F600.000 ;( <-- the difference)
G1 F1620.000 E4.24512

(Edit: I misunderstood what E-values mean, but the above difference still means a bug)

@teppix

This comment has been minimized.

Copy link
Author

commented Jul 14, 2015

This looks like the same problem: https://www.youtube.com/watch?v=ZUgwaFuD5Us

@oysteinkrog

This comment has been minimized.

Copy link

commented Jul 17, 2015

This bug is IMO a showstopper for having 1.2.9 as stable.

@teppix

This comment has been minimized.

Copy link
Author

commented Jul 17, 2015

@oysteinkrog I agree completely. I think this problem creates a bad reputation for Slic3r.

On another note, Travis (author of the video in my previous comment) confirmed via IRC that changing from 0.2mm to 0.4 mm layer height fixes the problem, just like I described in an earlier comment. I think the video reflects the frustration many are feeling when trying to make their prints work with 1.2.9. I ceartainly had pretty much the same reaction myself before I realized what was causing the bad prints.

@alexrj what's your opinion on this? Do you think that there is a fix in sight? Otherwise think marking 1.2.9 as experimental is the best option, like @oysteinkrog mentioned, or you'll likely see a lot of people migrating to other slicers (especially first time users).

@Hexman64

This comment has been minimized.

Copy link

commented Jul 17, 2015

I repeat myself 'cause it might be helpful for both, users and alexrj:
1.2.7 gives good (or at least much better) prints and has layer-preview built in,
1.2.8 and 1.2.9 have too much extrusion on gap-fills.
1.2.8 introduced autospeed, which may have led to the problem.
As a windows user, from the changelogs I read that 1.2.7 might actually be a good choice, as long as you check the preview and get around the use of broken models or non-ascii-characters.

@NoNaym

This comment has been minimized.

Copy link

commented Jul 19, 2015

I pretty much immediately stopped using 1.2.9 and reverted to 1.2.7 shortly after 1.2.9 was released (because 1.2.7 beta was already working pretty damn well for me). Below is a comparison of the results from 1.2.7 and 1.2.9 side by side after printing a custom 40mm fan shroud I slapped together (sorry it isn't the sharpest image, but you can definitely see the difference). The settings for these prints were exactly the same between the two versions, only difference was 1.2.7 beta vs. 1.2.9 "stable". This print and ongoing issue is the reason I refuse to use 1.2.9 for now :-/

20150624_195824 large

@oysteinkrog

This comment has been minimized.

Copy link

commented Jul 19, 2015

Does anyone know if there is a way to mitigate this issue?

@Hexman64

This comment has been minimized.

Copy link

commented Jul 19, 2015

teppix said the issue doesn't appear as much when using higher layer heights, but from a calculation point of view it looks like the problem is the same.
Look at the gcode I get when I calculate the above wall (0.7mm perimeter and a 0.72mm gap fill):

0.2mm layer height
G1 E1.60000 F1620.00000 ;(after retraction)
G1 X80.350 Y120.710 E2.63731 F747.126 ;(50x0.7mm perimeter, E increases by ~1)
G1 X80.350 Y119.290 E2.66718
G1 X129.650 Y119.290 E3.70449 ;(another 50mm line, again about E+1)
G1 X129.650 Y120.635 E3.73279
G1 X129.217 Y120.460 F15000.000
G1 X129.321 Y120.000 F15000.000
G1 X80.679 Y120.000 E5.84660 F600.000 ;(50x0.72mm gap fill line, but E increased by 2!)

0.4mm layer height
G1 E1.60000 F1620.00000 ;(after retraction)
G1 X80.350 Y120.710 E3.53910 F747.402 ;(here the E value grew by 2)
G1 X80.350 Y119.290 E3.59495
G1 X129.650 Y119.290 E5.53405 ;(again E increased by 2)
G1 X129.650 Y120.635 E5.58695
G1 X129.217 Y120.460 F15000.000
G1 X129.343 Y120.000 F15000.000
G1 X80.657 Y120.000 E9.68448 F600.000 ;(when gap filling, E grows by 4)
G1 E8.08448 F1620.00000

So the layer height does not seem to have an influence.
But now I see that 16days ago alexrj has already become aware of the problem, so I'm afraid complaining about it isn't necessary any more^^

PS: When Slic3r 1.2.7 gives E+1 for a line, it gives E+1.5 for the gap. Ok, printed lines are not ooo, but oxo, so I guess factor ~1.5 is the result of a highly complicated calculation and therefore correct.

@teppix

This comment has been minimized.

Copy link
Author

commented Jul 19, 2015

@Hexman64
You are right that the problem doesn't go away. The with calculation is still done in the same way - it's just a very rough estimation really, but it makes the problems less apparent at least.

Larger layer heights results in wider extrusion widths, if set to automatic (0). So the walls gets thicker, and at least for very thin walls there will be less or none gap fill. Perhaps this just makes the problem appear in different places, but from my experience after doing a lot of test prints, I prefer the result from 0.4 layers over 0.2 layers.

Note that setting gap fill speed to 0 (not very obvious) will disable gap fill, and do ordinary infill instead, and will simply leave an empty space in small gaps. I guess this will work like in earlier versions. I haven't really tried this much.

@teppix

This comment has been minimized.

Copy link
Author

commented Jul 19, 2015

I think the actual problem is well defined (read the comment from @alexrj), so it's mostly a matter of implementing a fix. I have kept posting just to bring some attention to it, since i think it's a very important issue.

I'll try to take a shot at it myself, but I'm not very familiar with the code, so don't hold your breath. At least I know where to start digging, if I can only find the time for it...

@luisonoff

This comment has been minimized.

Copy link

commented Jul 22, 2015

@teppix [OFFTOPIC] You said you wanted to change default settings, I would like to know what would you change, or what you think are proper default settings, maybe this is not the place, but you could post them somewhere or start a new issue. Thank you

@simonkuehling

This comment has been minimized.

Copy link

commented Jul 24, 2015

@alexrj I'd like to vote for priorizing this bug, as it is quite hard to debug for the average user and not quite easy to predict as well. For thin walled parts (think hollow boxes, example below), the issue is not just a cosmetic one, but can also reliably result in failures mid-print - due to gap-fill excess material piling up and sealing the nozzle during the next layer (nozzle backpressure getting too high).

While the workaround to disable gap-fill by setting Gap fill speed to 0 serves as an option, the speed improvement of gap fill (and the general functionality where it is working correctly) is quite substantial for many complex models. I really appreciate that!

My example for reference:
box.stl
box.gcode
config.ini

Preview:
screenshot

While this box looks alright, the extrusion width of of the gap fill is way to wide - the gap that needs to be filled is actually smaller than one perimeter width.

@luisonoff

This comment has been minimized.

Copy link

commented Jul 26, 2015

+1 on this request, gap filling is broken on this version. Also would love to see it compatible with autospeed. #2976

lordofhyphens added a commit to lordofhyphens/Slic3r that referenced this issue Jun 6, 2016

Adaptive slicing (#4)
* Releasing 1.2.8

* More fixes for Unicode path handling (thanks @josefprusa for Czech test VM)

* Bump version number

* Limit bridge over sparse infill to areas that can absorb such extrudate. slic3r#2899

* Minor adjustment of infill_overlap math

* Raise the thickness threshold used for generating thin walls. TODO: don't enforce this at the segment level but consider the average thickness of an entire polyline and compare it to the total length. slic3r#2910

* Typo

* Fixed regression casusing some rare STL files not to parsed correctly because of lack of the solid name. slic3r#2914

* Fix minor rendering glitch in 2D toolpaths preview

* Releasing 1.2.9

* Bugfix: binary ASCII files were not written with the correct fopen() mode. slic3r#2928

* Disable testing of modules that have known broken tests

* Add perl 5.22 to Travis CI

* Revert "Add perl 5.22 to Travis CI"

This reverts commit 3b7cb67.

* Ported PlaceholderParser::apply_env_variables() to XS

* Ported Config::setenv() to XS

* Finished porting PlaceholderParser to XS

* Ported Slic3r::GCode::AvoidCrossingPerimeters to XS

* Removed setenv() test as we can't test environment variables in Perl since they are now set in XS

* Ported Slic3r::GCode::Wipe storage to XS

* Ported Slic3r::GCode::OozePrevention storage to XS

* Updated test

* Ported Slic3r::GCode storage to XS

* Ported more Slic3r::GCode methods to XS

* Ported Slic3r::GCode::needs_retraction() to XS

* Make tests happy

* Macro for readability

* Use macro in PrintConfig.hpp

* Ported GCode::set_extruder() and OozePrevention

* Ported GCode::travel_to() to XS

* Ported GCode::extrude_path() to XS (speed boost!)

* Use GCodeWriter for path segments (refactoring)

* Ported GCode::set_extruders() and GCode::change_layer() to XS

* Finished porting Slic3r::GCode to XS (speed boost!)

* Initial work for porting PerimeterGenerator to XS

* Bugfix: bridge anchors were shortened under rare circumstances

* Bugfix: changing range-based layer heigths didn't trigger background processing. slic3r#2958

* Bugfix: zooming in empty layers preview (because of disabled background processing) crashed

* More work for porting PerimeterGenerator to XS

* Fix compilation on Windows due to lack of setenvt(). slic3r#2973

* Finished porting PerimeterGenerator to C++

* Ported make_perimeters() to C++

* Fixed potential hang in PerimeterGenerator.cpp

* Update GCode.cpp

Bugfix slic3r#3038

* Fix for slic3r#3069

* Finished porting LayerRegion to C++

* Bump version number

* Added a new grid infill pattern

* Several improvements to the print job queue

* Test button for serial connection

* Fixed memory leak

* Fixed memory leak

* More memory leaks fixed

* Removed debugging statement

* More memory leaks fixed

Conflicts:

	lib/Slic3r/GUI/Plater.pm

* Keep print job order

* Manual control

* Implemented connection timeout in C++

* Fixed manual control buttons

* Smarter logic for displaying printer panels

* Try to fix broken wx scrolling

* Display a warning when no USB/serial printers were configured

* Bugfix: wrong error handling in GCodeSender

* Fix incorrect comments to temperature-setting gcode

* Fix G-code checksum

* Bugfix: wrong default in extruder_offset tooltip. slic3r#3051

* Fixed regression causing empty prints to hang. slic3r#3107

* When background processing fails because of an error, display it in an explicit dialog

* Fixed one more memory leak

* Include the option category for first_layer_extrusion_width. slic3r#3061

* Prompt user when setting wipe + use_firmware_retraction. slic3r#3056

* Bugfix: error when setting per-region percent perimeter_extrusion_width. slic3r#2983

Conflicts:

	lib/Slic3r/Layer.pm

* Refactoring: prefix inc/dec operators for iterators

* Style fix: const for some functions

* Fix: Initializer list, right initialisation order

* std::list::empty faster than std::list::size (for C++03)

* Fix: memory leak in ExPolygon::triangulate_p2t

* Function arguments passed by reference

* Function arguments passed by reference

* Config: pass value as a reference

* Fix for -Wmaybe-uninitialized warninig

* Removed unused variables

* Addtional check for TPPLPoly::operator=

* Fix signed-unsigned compare

* Fixed compilation warnings and a potential bug in MotionPlanner, as reported in slic3r#3054

* Replace the flip word with mirror. slic3r#3060

* Added more search paths for Boost on Win32

* Fix compilation on Windows

* Improve Boost path detection

* Remove Boost from distribution and fix some more things for Windows compilation

* More compilation changes for Win32

* Fix serial port detection on Windows

* More fixes for serial port detection on Windows

* Prevent double connection check

* Two fixes for --debug

* Two fixes for --debug

* Smoother manual control movements

* Fix rendering on Windows

* Some fixes and improvements to controller

* Projector for DLP

* Re-enable serial connection for DLP projector

* More customizable options for DLP projector

* Slice objects even if background processing is disabled

* Don't crash when no serial ports are available on Windows

* Several fixes to GCodeSender, including compilation on older OS X and DTR reset

* Changed default settings for DLP projector and changed time options from integer to decimal

* Added libboost-* packages for Travis CI build

* Further improvements for compilation (Ubuntu)

* Further improvements for compilation (Ubuntu)

Conflicts:

	.travis.yml

* One more fix for Travis CI

* More small fixes for compilation on Linux

* One more fix for Travis CI

* More small fixes for compilation on Linux

* Add manual control to DLP projector too

* Added manual projection control

* Let user configure travel speed in manual control dialog

* Prevent absolute movement if user hasn't homed both X and Y

* Limit slider to number of layers

* Fix projection of slices with holes because wxDC is not honoring the fill rule

* Project grid

* New option for inverting the Y axis in projection

* Removed debugging comment

* Bugfix: an error in porting caused bad perimeter ordering. Includes regression test and more unit tests for PerimeterGenerator

* Bugfix: prevent crash when setting a Choice field to a non-indexed value

* Change order in DLP projection

* Ported _arrange() and arrange_object() to XS

* Ported mode Model methods to XS

* Ported a couple more methods to XS

* Ported Layer::maker_perimeters() to XS

* Make test happy

* Try to fix compilation on older Perls

* Improvements to DLP projector: disable all options while printing; apply config changes to the printer preset so that user can save them; show total and remaining print time

* Disable screensaver while projecting (untested on Windows)

* Fix a compilation error on Win32

* Upgrade Travis CI conf

* Fixed Travis CI conf

* Add color icons to menu items about axes. slic3r#3121

* New "Scale to size" command(s). slic3r#2711

* Fix a minor glitch with scrollbars in OverrideSettingsPanel

* Preserve the current layer when refreshing the 3D preview

* Fix compilation on Windows

* Fix comment stripping in sender

* Bump version number

* Separate libslic3r code from slic3r application code

* Import config bundle automatically if found in application directory

* Large refactoring of the Config classes

* Remove any Perl related code from libslic3r

* Fix typo slic3r#3152

* Fix compilation

* One more fix for compilation

* Updates to GUI projector: fix buttons not updating when print finished; ring a bell at that time; disable screensaver not just when printing but until the DLP projector window gets closed

* Move the position_screen method to the Screen class

* Bugfix: missing include assert.h slic3r#3155

* Live preview in the cut dialog

* Fix one regression in arrange

* Prevent flickering

* Refactored the Config XS bindings

* More refactoring on Config XS bindings

* More efficient syntax for the PrintConfigDef constructor

* Removed debugging statements

* Don't show any dialog if 0 configs were imported

* Some changes to DLP projector

* Fix compilation with GCC

* Typo

* New --retract-lift-above and --retract-lift-below options. slic3r#763 slic3r#3057

* Implement resizable left column in preset editor. slic3r#3151

* One more fix for compilation with older compilers

* Fix regression in lift, includes regression test

* Use bridge flow and speed for solid_infill_every_layers

* Fixed error in porting causing wrong moves with avoid_crossing_perimeters

* Fix false positive in lift unit test

* Fixed ported code of PerimeterGenerator

* Very minor code improvements

* Bugfix: external details were simplified too much when using default settings at low layer height, because the internal flow was erroneously taken into account. slic3r#2807

* Fix Slic3r crash when opening About dialog

* Minor code cleanup here and there

* Editable text control for specifying the cut Z in cut dialog

* Ignore cut result if user didn't click the cut button

* Refactor cutting logic, don't slice in 3DScene

* Fixes and improvements to MotionPlanner, much smarter now

* Force the 'nearest' strategy for starting skirt loops

* Revert "Implement resizable left column in preset editor. slic3r#3151"

This reverts commit 4b30d67.

* Dump serial messages to file in order to debug communication issues

* @farhaven: There's one more wxCLOSE in lib/Slic3r/GUI/Projector.pm, that one should probably be changed as well.

* Implement serial port baudrate selection for OpenBSD

Signed-off-by: Gregor Best <gbe@unobtanium.de>

* Don't toggle support_material_enforce_layers field

support_material_enforce_layers works independently of the support_material ||
raft options, so we should not disable the field when support material
generation is disabled.

Fixes: slic3r#3046

* New icon for Infill (credits: Carlo Mariella)

* Fixed regression in the C++ port of PerimeterGenerator causing gaps to be filled twice

* Refactoring: new Layer::make_fill() method

* Don't use equality comparisons for floats

This fixes an issue where F0 moves arise from 0-width (or 0 layer
height?) support material segments when using autospeed.

Fixes: slic3r#3261

* fix a segment fault by admesh

* Fixed float comparison in combine_infill

* Fixed return value for deserialize() implementations. slic3r#3250

* Make GCodeSender more robust (keep more than one sent line) and fix a memory access problem in the asio write buffer

* Bugfix: memory corruption in BridgeDetector (thanks @JakeQZ for the patch). slic3r#3267

* Support incompatible change in Boost 1.60. slic3r#3117

* Raise allowed temperatures to 500°C. slic3r#3114

* Fix issue with undefined BOOST_VERSION

if BOOST_VERSION < 106000 always succeeds because BOOST_VERSION is
undefined.  In order to avoid the code for new boost, we need
<boost/version.hpp>

* Bugfix: crash when input to bed shape options was '-'. slic3r#3254

* Fixed regression in bridging caused by error in porting. Includes regression test. slic3r#3175

* Variable-width gap fill. Yay! slic3r#2960

* Variable-width thin walls. Yay!

* When loading an AMF file having multiple objects that look like multiple parts of a single object, prompt user and ask how to consider it. slic3r#2970

Conflicts:

	lib/Slic3r/Model.pm

* Fixed dragging in 3D plater having some glitches with multipart objects

* Missing #include

* Update ISSUE_TEMPLATE.md

* Rewritten the medial axis algorithm, now more robust (don't just prune MAT from endpoints, but validate all single edges)

* Moved CONTRIBUTING.md to .github/

* Fixed type error

* Actually add CONNTRIBUTING.md, not included in f5a5eb3

* Filter gap fill using length relative to the actual width. slic3r#2781

* Tune gap fill and thin walls to less extreme values

* Refactored calls to Wx::Bitmap->new

* One more year

* Fix layer time slowdown

The recent GCode writer changes which put the speed changes on a line of
their own have caused the layer time slowdown to be ignored by the regex
in CoolingBuffer.pm.

Fixes: slic3r#3134

* Update tests for new GCode style and markers

* Fixed compilation on OS X

* Support static linking of the Boost libs

* Account for travel moves in elapsed_time

* Use float for elapsed_time

When accumulating elapsed_time from many moves that take less than 1
second, elapsed_time does not get incremented because (unsigned int)0.9
= 0.

* Fix cooling not working if !gcode_comments

The cooling markers were being passed into GCodeWriter::set_speed() as a
comment which were being ignored if gcode_comments was false.

Fixes: slic3r#3325

* The "controller" tab and the settings of the USB/serial connection was
made configurable. Now one may hide the "controller" tab and the USB/serial
connection configuration from the preferences. This is useful for someone,
who never connects his printer to the computer by a cable.

* More refactoring to medial axis and gap fill, more robust

* Added a short OpenSCAD description to aid in the creation of simple modifier meshes that describe a change every N layers

* Bugfix: homing was not correctly saved

* Add XYZ homing button to printer manual control

* Update solid_layers.scad

Oops, left a hardcoded 0.3 in. Fixed.

* Feature: try to match horizontal surfaces with adaptive slicing
@PotatoFi

This comment has been minimized.

Copy link

commented Dec 30, 2016

1.2.9 is still the current release, and this bug is still present (1 year after this bug was reported). Could a new unstable build of the next version be posted for ordinary users to have access to without having to build from source?

Of course, going back to 1.2.7 is an option as well.

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Dec 30, 2016

@nicksears

This comment has been minimized.

Copy link

commented Dec 30, 2016

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Dec 30, 2016

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Dec 30, 2016

@Tinchus2009

This comment has been minimized.

Copy link

commented Dec 30, 2016

@PotatoFi

This comment has been minimized.

Copy link

commented Dec 30, 2016

To the developers, thank you very much for all of your hard work on this project. It's an amazing tool that I've used for years.

To the users who are aware of the bug but don't have the skills/time to build from source, I recommend switching back to 1.2.7. On macOS, it is very stable, seems to be fully compatible with 1.2.9 profiles, and does not seem to be affected by the thin walls bug. I've been slicing with 1.2.7 all day and it was been performing beautifully.

Again, thank you to the developers for all of your hard work on this tool. It is MUCH appreciated.

@nicksears

This comment has been minimized.

Copy link

commented Dec 30, 2016

Thanks @lordofhyphens, ill have to give that a try

I've tried the Prusa builds as well, I just cant believe there's not a new version with all the changes that have been going on.

Thanks for the reminder, I and so many others appreciate contributions SO much. I literally just got my PhD and could NOT have done it without this software (and furthermore, without the improvements made to this software in the last 2 years!)

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Dec 30, 2016

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Dec 31, 2016

@nicksears https://bintray.com/lordofhyphens/Slic3r/download_file?file_path=slic3r-1.3.0-dev.2016.12.31.2be6e1a.zip is a package I made on my laptop using my bundling script. AFAIK it works.

If you're an OSX user and the build instructions don't work for you at all, there's basically nothing I can do for you as I don't have any OSX systems.

@Tinchus2009

This comment has been minimized.

Copy link

commented Dec 31, 2016

@TrueFawkes

This comment has been minimized.

Copy link

commented Jan 5, 2017

Hello everyone, i just made this account to comment on this thread,
i've been looking at this for quite some time now and i'd really like to thank all that are working on fixing these issue's (the gap filling is a huge issue)
I just ran the slic3r-1.3.0-dev.2016.12.31.2be6e1a.zip file, and i-am currently printing.
I'll post an update when it finishes printing

@TrueFawkes

This comment has been minimized.

Copy link

commented Jan 5, 2017

Back again, and i-am AMAZED! just look at these results!
I think you can tell which one is 1.2.9 and which is the 1.3.0-dev version!
I used the exact same settings in both of them,
(both, manually set Perimeter and ext,perimeter width, Gap fill ON, Detect thin walls ON.)
20170105_214615
20170105_214737
20170105_214653
20170105_214728

However one odd thing did happen, the bottom is a little better but the top infill is "much" worse.
both have 4 top layers.
20170105_214931
STL-FILE

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Jan 5, 2017

@TrueFawkes

This comment has been minimized.

Copy link

commented Jan 5, 2017

Yes i could, however i-am not sure if it's a problem in my settings or a problem in the slicer so i won't make an issue (yet?)

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Jan 5, 2017

@TrueFawkes

This comment has been minimized.

Copy link

commented Jan 5, 2017

ah alright i understand.
But nice job! i actually enjoy printing once again!
(Off topic, how do i quote or reply to someone here?)

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Jan 5, 2017

@Tinchus2009

This comment has been minimized.

Copy link

commented Jan 5, 2017

@nicksears

This comment has been minimized.

Copy link

commented Jan 10, 2017

@lordofhyphens Just wanted to follow up, thanks for the input, the key seems to be to select the bat file in repetier. One of your bintray links is down, but the other worked and it seemed very much like what I had compiled before myself. I had no idea how to correctly call slic3r with a bat file, but I see already there. However, even with this, I can't get those versions to work.

I can open slic3r directly (perl is correctly installed) but I get an error when I try and slice in repetier. Maybe because I have a newer version? I'm installing 5.22 (vs 5.24) now.

I did however get everything to work with prusa's precompiled "slic3rPE" (Prusa Edition) since it's an exe. Days it's version 1.31 or something, but it had the gap fill fix, so works for me.

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Jan 10, 2017

@bubnikv

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2017

The exe wrapper on Windows may be built from the following slic3r.c file:
slic3r.zip

@grigorig

This comment has been minimized.

Copy link

commented Jan 18, 2017

I had some issues while printing a small box that fits a PCB. Even though I added 0.5 mm tolerance the inside ended up too small! Will try the master branch next.

But seriously, this needs a bugfix release. There's a 1.2.x stable branch that is actually being updated and it seems to contain a fix for this. Is there any reason why no releases at all have been cut?

@lordofhyphens

This comment has been minimized.

Copy link
Member

commented Jan 18, 2017

@Tinchus2009

This comment has been minimized.

Copy link

commented Jan 18, 2017

@grigorig

This comment has been minimized.

Copy link

commented Jan 18, 2017

Could be. I'm going to reprint with gcode generated by a fixed Slic3r version, but the worst issue I can see off hand is that the walls of the box are a bit too thick, and that is possibly the reason for the non-fit. Anyway, this is quite off topic...

@bubnikv

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.