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
[Bug] Supports generated beyond bed edges (X<0 and X>250) and where none are needed. #902
Comments
After a lot of fiddling this is the best that I can get Slic3r PR to do: There are only supports inside the slot, but at just one end the supports go down to the bed, and are off the edge of the bed. I had to reduce the overhang angle setting from 45° to just 6° and no skirt. This is really frustrating as my project can't continue until this is sorted! Here is the config.ini that got it almost there: Here is a close up of the GCODE preview showing the support structure. Slic3r is generating values for X that are less than 0 and greater than 2050 (X < 0 and X > 250). Maybe a simple check needs to added to prevent it trying below 0 and beyond 250? Here is a snippet of the GCODE showing moves to X>250:
Is there an ETA on when the fix for supports generated beyond the bed will be done? |
I've managed to tweak the settings in Slic3r to the best I think is possible to try to get ride of the build plate supports and this is what I am left with: As you can see there is just a small grid of support material put down on the build plate, and off of it - for no valid reason. I have then hand removed the gcode from the file and will do a test print tomorrow to see if it works. [UPDATE: Didn't work] I would, humbly, suggest that once 1.40 is released a feature freeze is implemented until the serious bugs like this are worked out of the version 1.40. |
Any news on a bug fix for this? Been waiting to print some parts for a project for 3 months now! It's very frustrating seeing new features added to slic3r when there are still some nasty bugs like this that never seem to get fixed! |
The current beta will show you a warning overlay and it will change the background color of the path preview window to red if any extrusion lies outside the print volume. It is not a full solution (ideally the software would not store the G-code in this case, or it would trim the extrusions), but it is at least something. |
I'm sorry to say I'm a bit disappointed in this. It was already possible to simply look at the preview and see the problem (hence the screen shots I provided). This is a pretty bad bug for a slic3r as it means that anyone who wants to print a big object simply can't, this means that the maximum print size is less than the bed! Unless all you want to do is print a big cube or similar. There is more than one bug here as well - Firstly, Slic3r is generating supports and brims that go off the print bed (negative numbers and over the max). Secondly, it is generating unneeded supports (IE the zigzag one's on the bed in the screenshots above). This needs fixing ASAP. For us users it's very frustrating (annoying) to see more and more new features added to Slic3r while the one feature it is supposed to do perfectly above all else is bugged and makes it unusable for some of us. Imagine if someone had bought the printer to do a specific project, only to find that it can't do it because of a bug in the slicer, they would be getting pretty angry! |
It's a matter of expertise. Supports are hard to get right and few people know how to go about it. For example, I'd gladly help if I could, but right now as far as I can see it would do no good and only interfere with @bubnikv 's work who is pretty much the only person who can do it. And so it makes sense for other team members to instead work on other parts of the program. There's an incredible amount of work to do in various degrees of necessity. |
While I fully understand the issues you raise with regard to allotting work to various people, it raises a flaw in within PRUSA... never have only one person who can do a certain task! What if @bubnikv is sick or leaves the company? You should always have more than one person who is an expect at any given job. Secondly, as I see it, supports are one of the 3 main functions of a slicer! The first is obviously slicing the model up, the second is creating the needed supports, the 3rd being to generate the correct gcode. Now all the printers are sold as being able to print up to a certain volume and without the correct slicing and supports then that full volume can't be utilized. When I bought my MK1(1.75mm) and then upgraded to the MK2 it was with the intention all along to print a specific set of models (action figure dioramas). It has taken all this time for me to learn to 3D model and print well enough to finally begin printing them and now I find I can't because of this rather simple (basic?) bug/error! So forgive me if I seem overly annoyed by this! I have not coded in many years and so can't analyse the slicing/supports code myself, but surely there is a simple way of limiting 'where' supports get generated and when? The one's on the bed in my example below should not be there... first because they go off the bed, but also because they aren't needed at all as they don't support anything! The off the bed problem, I'm guessing, isn't going to be solved by a simple if x<0 line of code, and the supports where not needed will take a bit of code juggling, but surely this sort of thing should be a priority to fix. I can't believe I'm the only one who is affected by this??!! Surely before working on the fine nuances of Slic3rs functions it should be made to do it's 3 prime functions as near to perfect as possible! I'm perfectly willing to act as a beta tested for a development version (pre compiled for Windows) if it will help? |
While I fully understand the issues you raise with regard to allotting
work to various people, it raises a flaw in within PRUSA...
I find this discussion rather amusing. Until December 2017, I was the only
person developing Slic3r PE, and time to time I was helping with the
firmware as well. Before joining Prusa3D, I worked more than a decade in
the field of custom CAD systems and computational geometry, so I had quite
a good know how of the algorithms used in Slic3r. Now we have 6 programmers
including me plus one tester working on Slic3r full time. While we certainly
have smart people on board, it takes time to get fluent with an unfamiliar
larger scale project and to extend owns knowledge in the fields of discrete
math and programming. So it makes sense for the newcomers to the project to
start with something simpler.
never have only one person who can do a certain task! What if @bubnikv
<https://github.com/bubnikv> is sick or leaves the company? You should
always have more than one person who is an expect at any given job.
We are certainly aware of it, thank you. We are doing the best to improve,
as you can see from our hiring effort.
…On Wed, Aug 22, 2018 at 6:43 PM, 3Delight ***@***.***> wrote:
While I fully understand the issues you raise with regard to allotting
work to various people, it raises a flaw in within PRUSA... never have only
one person who can do a certain task! What if @bubnikv
<https://github.com/bubnikv> is sick or leaves the company? You should
always have more than one person who is an expect at any given job.
Secondly, as I see it, supports are one of the 3 main functions of a
slicer! The first is obviously slicing the model up, the second is creating
the needed supports, the 3rd being to generate the correct gcode. Now all
the printers are sold as being able to print up to a certain volume and
without the correct slicing and supports then that full volume can't be
utilized. When I bought my MK1(1.75mm) and then upgraded to the MK2 it was
with the intention all along to print a specific set of models (action
figure dioramas). It has taken all this time for me to learn to 3D model
and print well enough to finally begin printing them and now I find I can't
because of this rather simple (basic?) bug/error! So forgive me if I seem
overly annoyed by this!
I have not coded in many years and so can't analyse the slicing/supports
code myself, but surely there is a simple way of limiting 'where' supports
get generated and when? The one's on the bed in my example below should not
be there... first because they go off the bed, but also because they aren't
needed at all as they don't support anything! The off the bed problem, I'm
guessing, isn't going to be solved by a simple if x<0 line of code, and the
supports where not needed will take a bit of code juggling, but surely this
sort of thing should be a priority to fix. I can't believe I'm the only one
who is affected by this??!!
[image: 40881344-f4b87df0-66bb-11e8-953a-b2e60b71805a]
<https://user-images.githubusercontent.com/39102974/44477183-d7dd1a00-a631-11e8-9ffd-65be3ad8fee5.jpg>
Config.stl.and.gcodes.zip
<https://github.com/prusa3d/Slic3r/files/2311236/Config.stl.and.gcodes.zip>
Surely before working on the fine nuances of Slic3rs functions it should
be made to do it's 3 prime functions as near to perfect as possible! I'm
perfectly willing to act as a beta tested for a development version (pre
compiled for Windows) if it will help?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#902 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I6G_ccK0lhNzYbSSiz1jf0sfU-7Kks5uTYobgaJpZM4UFEhf>
.
|
Glad we're helping to keep your spirits up @bubnikv ! LOL! I remember when there were only... what? About 5 of you there at PRUSA? It must be weird in a way to actually have a team of you now! I remember when I first started working as a programmer back in the 1980's... we were seen as some kind of 'High Priests' of the mysteries and wondrous 'com-pu-ter', and back then we did all we could to hoard our knowledge! LOL! Now even all the little kids know more than I did back then! Just seeing words like computational geometry gives me a headache!! Maybe we need to go back to those "Good Old Days"... would it help if I made a sacrificial offering to you oh great and powerful one?! LOL! I'm sure you're well aware of the issues, I just felt a need to to air them as I'm so frustrated at not being able to print what I want. To be honest I am amazed at how much you and your team have achieved over the last couple of years or so (is that really all it's been? WOW) and I'm sure that you will have this and other problems fixed very soon... You're victims of your own success though! We expect miracles from you now! |
expanded to a grid (the old way) vs. snug (like the upstream Slic3r, Cura or Ideamaker). Snug supports suffered from the degeneracies when merging overhang islands over a large number of layers when projecting the support towers down. We borrowed the idea & a bit of code from Cura by simplifying the support polygons by closing the concave cracks, see the smooth_outward() function and the MutablePolygon class. Fixes Support problems with models with hole in the walls. #555 Fixes Support in the Air #740 Fixes [Bug] Supports generated beyond bed edges (X<0 and X>250) and where none are needed. #902 Fixes Unable to remove support material/can't change support "inflation distance" #2708 Fixes FR: support inflation and support conform to boundary #4783 Fixes Support blocker not working on this model #1346 Fixes Unnecessary support material #1993 Fixes support blocker enforcer issue #6240
Fixed with af9c7c9
|
Version
1.40.0-alpha1+win64
Operating system type + version
Windows 10 Pro 1803 (17134.48) x64
Behavior
Describe the problem
Unusual and unnecessary supports are generated. For the attached model there should be no supports generated on the build plate. (Also note that supports and the skirt are generated off the build plate!
Steps needed to reproduce the problem
Load model, rotate so flat on bed (broadest side down), arrange and tick Generate Support Material.
The model was made by creating a SVGs of the outlines in Serif DrawPlus X8, checking and double checking the nodes in Inkscape (all the nodes are aligned!). Then loading the SVGs into Fusion 360, extruding them, tweaking and combining them, and exporting it as a STL. This is the outline of the main block:
Expected Results
I expect supports to be generated only inside the slots down either side of the model as the only overhangs are over the lower part/side of the model/slot. Also for both ends to have the same support structure! The build plate supports are totally unnecessary and don't actually support anything. Simulation:
Actual Results
Supports are added that stick out of one end of the slot and on the build plate. I't would help if the option to only add supports for the first x layers worked as the struts along the sides don't actually need supports.
Is this a new feature request?
No.
STL/Config/gcode (.ZIP)
STL, config, gcode.zip
The text was updated successfully, but these errors were encountered: