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

[Bug] Supports generated beyond bed edges (X<0 and X>250) and where none are needed. #902

Closed
3Delights opened this issue May 18, 2018 · 10 comments
Labels

Comments

@3Delights
Copy link

3Delights commented May 18, 2018

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

  • 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:
    image3

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

image1

image2

Is this a new feature request?
No.

STL/Config/gcode (.ZIP)
STL, config, gcode.zip

@3Delights 3Delights changed the title Unexpected support errors. Supports where there should be none... May 22, 2018
@3Delights 3Delights changed the title Supports where there should be none... Supports where there should be none... (Updated) May 24, 2018
@3Delights
Copy link
Author

3Delights commented May 27, 2018

After a lot of fiddling this is the best that I can get Slic3r PR to do:
nearly there

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:
NewestConfig.zip

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:

G1 X-2.062 Y80.269 E0.21069 ; support material
G1 X-1.286 Y80.268 E0.01876 ; support material
G1 X-1.286 Y71.733 E0.20643 ; support material
G1 X-0.511 Y71.733 E0.01876 ; support material
G1 X-0.511 Y80.267 E0.20640 ; support material
G1 X-0.073 Y80.266 E0.01059 ; support material
G1 X-0.063 Y73.650 E0.16000 ; support material

G1 X249.756 Y81.440 E0.19895
G1 X250.532 Y81.440 E0.01876
G1 X250.532 Y73.214 E0.19895
G1 X251.308 Y73.214 E0.01876
G1 X251.308 Y81.440 E0.19895
G1 X252.083 Y81.440 E0.01876
G1 X252.083 Y73.214 E0.19895
G1 X252.859 Y73.214 E0.01876
G1 X252.859 Y81.440 E0.19895
G1 X253.634 Y81.440 E0.01876
G1 X253.634 Y73.214 E0.19895
G1 X254.410 Y73.214 E0.01876
G1 X254.410 Y81.615 E0.20317

image1

Is there an ETA on when the fix for supports generated beyond the bed will be done?

@3Delights 3Delights changed the title Supports where there should be none... (Updated) [Bug] Supports generated beyond bed edges (X>250) May 28, 2018
@3Delights 3Delights changed the title [Bug] Supports generated beyond bed edges (X>250) [Bug] Supports generated beyond bed edges (X<0 and X>250) May 28, 2018
@3Delights
Copy link
Author

3Delights commented Jun 2, 2018

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:

X greater than 250
image1

X less than 0
image2

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.

Config, stl, and gcodes.zip

@3Delights 3Delights changed the title [Bug] Supports generated beyond bed edges (X<0 and X>250) [Bug] Supports generated beyond bed edges (X<0 and X>250) and where none are needed. Jun 2, 2018
@3Delights
Copy link
Author

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!

@bubnikv
Copy link
Collaborator

bubnikv commented Aug 20, 2018

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.

@3Delights
Copy link
Author

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!

@vojtechkral
Copy link
Contributor

@3Delights

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.

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.

@3Delights
Copy link
Author

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??!!

40881344-f4b87df0-66bb-11e8-953a-b2e60b71805a
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?

@bubnikv
Copy link
Collaborator

bubnikv commented Aug 22, 2018 via email

@3Delights
Copy link
Author

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!

bubnikv added a commit that referenced this issue Mar 23, 2021
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
@bubnikv
Copy link
Collaborator

bubnikv commented Mar 23, 2021

Fixed with af9c7c9

Implementing a new switch for the shape of support towers:
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants