burtoogle
-
Posts
1,529 -
Joined
-
Last visited
-
Days Won
19
Content Type
Forums
Events
3D Prints
Posts posted by burtoogle
-
-
23 minutes ago, martincho said:
What would be VERY helpful is for CURA to have various view options such that you could quickly inspect z-seam points without having to manually explore a thousand layers. It would be as simple as rendering a single black dot at the z-seam, perhaps with options for transparency of the tool-path graphic. With something like this it would be a very simple matter to turn it on and look to see if any dots exist where we might not want z-seams.
Indeed, this request or similar comes up regularly. The most recent request was https://github.com/Ultimaker/Cura/issues/6072.
-
1 hour ago, martincho said:
The first question is: From what frame of reference? Inside the part or outside? And then, of course, there's the fact that the long edges are straight, which means they are not concave/convex, regardless of where we look at them from.
Not sure what you mean by frame of reference but your model is providing the outside shape of the part.
Here's the model from your project. You can see it is made up of triangles. Cura (and most slicers I should think) work with models that are defined as triangles.
When the model is sliced into layers, the vertices of the outline polygon for each layer will be located at where the layer hits the edges of the triangles at that height. On those large flat sides, you will get vertices appearing on the diagonal lines (moving to/from the corner of the model as the height varies). The slicer tries to remove collinear vertices but due to numerical precision, arithmetic errors, etc. sometimes vertices remain. There is a setting (maximum deviation) that influences the removal of vertices.
2 hours ago, martincho said:How do I know which approach will produce good parts?
Good question. I don't really have a good answer other to say that having sliced your model you should go through the layers in the layer view to check that the z-seam hasn't ended up somewhere bad.
Personally, I use the user-defined z-seam hint nearly every time but my models are, generally, amenable to doing that.
-
I have submitted a small mod to Cura (https://github.com/Ultimaker/CuraEngine/pull/1122)
that fixes the z-seam position in your example project. The problem is caused by the fact that the model has some vertices in the long edges that make the outline very slightly concave and you are using the hide seam option which looks to find the most concave corner. All the other corners are convex and so it was choosing the slightly concave corners.
-
I just realised that you are using hide seam alignment which tries to position the seam on the most concave region of the model. But your model only has convex corners. So you need to use the expose seam option and then the seam will stick to the sharpest corner.
-
This model is good because it has some nice straight edges that extend from top to bottom so it's easy to get the z-seam to follow one of them. The "trick" is to turn off the seam corner preference option. That rarely (but sometimes actually does) gives you what you want. So go for the user specified z-seam hint. I think that using the z-seam relative option makes it easier to position the seam as the location you specify is now relative to the centre of the model and it doesn't matter where the model is on the buildplate. This image shows the location of the z-seam and it doesn't vary appreciably over the whole height of the model. It also shows the settings I used. Hope this helps.
-
Hello @martincho, could you please provide the project file (File -> Save) and attach the .3mf file to this thread. thanks.
-
Hello @kulfuerst. Yes, sorry about that. I discovered the crash myself today. I have fixed the bug already along with a workaround for an upstream bug and will create a new build now. Should be available tonight from the usual place.
-
1
-
-
Hello @Exitaph, I have reworked the bridge skin processing so that it will segment skins into separate bridged and non-bridged regions. I think it will do what you are requesting. It was quite an overhaul so I wouldn't be surprised if there are some new quirks.
I have built Cura releases for Linux and Windows so if you can use one of them you can try it out and I would be grateful of any feedback you may have. You can find my releases at...
https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0
Once proven to be good, I will submit the changes to Ultimaker to be incorporated into a future release although they are so slow to process contributions that it could be a very long time before that happens.
-
1
-
-
It's because top surface skin layers is > 0.
-
Sorry, I haven't looked at this yet. I will probably get around to it over this weekend.
-
Removing the CR-10S printer could well be sufficient to clear this. Not sure. Living on the "bleeding edge" I get these messages quite often and normally just wade in and remove from the config directory the profile/extruder/printer definition file(s) it's bleating about.
-
1
-
-
Coming late to this thread. I assume you are using adequate cooling with a lot of fan for the top layers?
-
23 minutes ago, gr5 said:
Do the tower thing I talked about. Why didn't you do the tower?
But then it will not be possible to use spiralize and there will be all the normal z-seam unhappiness to contend with.
-
Hi. Please save the project file (File -> Save) and attach the .3mf file to this thread so I can investigate. Thanks.
-
-
2 hours ago, pmleite said:
In future releases they should solve this problem...
Indeed they should. Let's hope they treat it with the priority it deserves!
-
BTW, you can save yourself some time and filament by switching to gyroid infill at a much lower density than what you are currently using. It will still be stupidly strong. I also recommend enabling the optimise wall printing order setting.
-
1
-
-
Hi, it's definitely a bug in the current Cura. I have taken the liberty of creating an issue (https://github.com/Ultimaker/Cura/issues/6215).
In the meantime, a workaround that worked for me was to change the top/bottom line width slightly. i.e 3.9 or 4.1 instead of 4.0.
-
Thanks for the project file. Hmm, very weird, It looks to me that those sections are being inverted, i.e. the hole is treated as solid and gets skin and the non-hole area which should be skin is empty (if you turn off the fill gaps between walls setting).
At this time, I can't say where the bug is. Possibly in the front end but it looks more likely to be in the slicer back end.
Interestingly, when I sliced the led_panel.stl using different settings there wasn't a problem so I will continue to investigate.
-
1
-
-
Thanks for the models. I was wrong, the models are OK. However, I can slice led_panel.stl and it looks OK. It must, instead, be a problem with the settings. Please save the project file and attach to this thread. Thanks.
-
1
-
-
I expect the model has a problem. Please attach it to this thread. Thanks.
-
1
-
-
Actually, I think what is happening is that the wall overlap compensation is enabled and because the wall is thin, the resulting 2nd wall contains very little filament. To stop the pointless travel set the minimum wall flow value to something like 50 (or even higher) and it should stop that pointless travel occuring.
-
1
-
-
BTW, I just discovered that you can actually use Cura remotely on the Pi from another computer using VNC. The display performance doesn't appear to be noticeably worse than when using it locally. You can also run Cura on the Pi using a remote X display (i.e. ssh -X) but the display is very slow doing that.
I haven't tried it but I would think that it would be possible to run Cura on a headless Pi using VNC server.
-
9 hours ago, mimel said:
How can I access your build?
Builds for Linux and Windows can be found along with a README that gives you an idea of what the differences are compared to Ultimaker Cura can be found at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0
Experimental Cura build for Raspberry Pi 4 now available
in UltiMaker Cura
Posted
Hello @ccpetersen, that's great to hear, thanks for letting me know. Once I had sorted out a couple of issues, building that release is no trouble at all as I am already building Linux releases for x86_64. So I will be continuing to create armhf releases.
Functionally, the armhf releases are the same as the x86_64 releases apart from the fact that the layer view is restricted to compatibility mode because of the legacy OpenGL version provided on the Pi. I can't do anything about that. Perhaps in the future, the Pi's OpenGL support will progress and it will be able to show the more advanced layer view.