Cuq
-
Posts
675 -
Joined
-
Last visited
-
Days Won
18
Content Type
Forums
Events
3D Prints
Posts posted by Cuq
-
-
It's strange that the parameter I mentioned generates paths like your screenshot, should be like that :
There's something weirde about your model. But without sharing your project, it's hard to understand your problem.
-
Such pattern depends of a new parameter introduce in Cura 5.5 call small top/bottom surface. Try to change this parameter. But on my pointvof view you have also an issue with your flow. Try to reduce to 96 - 98 %
-
Open the settings Guide via the menu, and in the top right Search field give the name of the setting : Extruders Share Heater.
-
Are there any other changes in Beta 2 or just what is indicated ? :
Introduced Balanced and Solid profiles for 1C cores to UltiMaker Method X and Method XL -
1 hour ago, alfonsvh said:
I can't find this plugin
https://marketplace.ultimaker.com/app/cura/plugins/UltimakerPackages/CuraEngineTiledInfill
-
Use the Export HTML Cura Settings: https://marketplace.ultimaker.com/app/cura/plugins/5axes/HTMLCuraSettings
Export every parameters in a Html Document and print this document.
-
A rapid general comment on comparison results on calculation times (Or result) . But it may have its place here, since the problem also concerns version 5.6 Beta .
Still in my time tests if I 'm using the part NASA Fabric 12x16.stl :
What is the difference between this part and this one ?
Virtually nothing, same Software version (Beta 5.6 ), Same PC, Same printer, Same settings, Same geometry but in the end :
First Project : calculation time 15 mn 56 s printing time by Cura 21 h 42 mn.
Second Project : calculation time 1 mn 21 s and printing time by Cura 22 h 15 mn
Difference in the second case the model have been split into individual parts.
So sometimes the result can be totaly different just because the slightest difference in a value or a model feature.
-
18 minutes ago, Dadkitess said:
I am using an alternative version in 4.x, 4.23 IIRC (don't have my PC right now) and it globally never fail at slicing when 5.1 ; 5.2 and 5.3 does fail a LOT unfortunately. With the same STL. I don't remember if I actually tried 5.4 but I read the comments about it, and about the 5.5, hoping from improvement on that topic, but it did not seem OK.
I'm not saying that this isn't the case, I'm just saying that I haven't personally experienced these problems (With my printer and My own Part).
The variation in calculation times is very different depending on the shape of the parts, the parameters you use and problems can exist with one printer configuration and not with another. Even between Slicers or versions, if you run tests you'll find differences in favor of one version or another, and this is the same with all the Slicers I know.
If you share one of your parts, other users will be able to compare it with their config. If the problem is specific to your configuration (e.g. graphics card or OS), it will be very difficult for the Cura teams to find a solution.
When it comes to software, you can't assume that just because you have a problem, everyone has the same problem. In some cases, it depends on how you use it, which can be unique to your field of activity.
-
1
-
-
3 hours ago, Dadkitess said:
All the 5.X versions so far are very-very-very slow / picky when it comes to slicing, with very weird behavior or complete refusal to slice a rather normal part.
To be fair as far as I'm concerned, if we disregard version 5.5 and this Beta, versions 5.4 are generally faster than the latest version 4.13 and I don't have any particular cutting problems with my configurations. Perhaps you should open one or more issues on Github to explain your problems. They might be due to a particular hardware configuration or to particular types of parts, but I don't think this is a general problem for all users.
-
Unfortunately, there's no difference in my case. With the example : CarpetSpikesFinal
Cura 5.4 : Optimize wall printing order ON : 7 s
Cura 5.4 : Optimize wall printing order OFF : 7 s
Cura 5.5 : Optimize wall printing order ON : 2 min 20 s
Cura 5.5 : Optimize wall printing order OFF: 2 min 19 s
-
1
-
-
A few tests later ... The explosion in calculation time seems to be linked more to the number of cutting area than to the STL size. With a "simple" example Cura 5.4 : 7s Cura 5.5 : 2min 13s on my PC
-
I hadn't done the test yet, because on classical mechanical parts it wasn't very significant, but for the same project: I tested the NASA Fabric 12x16.stl model with 0.2 layer and Nozzle Size 0.4 without support on Windows 10.
Cura 5.4.0 : 27s
Cura 5.5.0 with Fluid option Off : 17mn 06s
Cura 5.5.0 with Fluid option On : 17mn 26s
EDIT
I've also tested with version 5.6 Beta 1; same as in 5.5.0 : 17mn
Given the difference in calculation time and the limited number of users who have been screaming since the release of version 5.5, this may be a problem linked to parts with a lot of slicing areas, like this model ?
-
Question seems to be quite similar to this post :
So same answer : The execution of the plugins follow I think the order of loading and the order of loading is according to the alphabetical order.
Try to dhange the names of the plugins to change the order ?
-
1
-
-
4 hours ago, displaynamenotallowed said:
The customized infill could be neat for no top/bottom layer reveals. There are two types of infill I'd like to see but they would be significantly more complicated. One would look kinda like Gyroid infill. It would utilize topological optimization/generative algorithm to lay out the pattern. The other would be less complicated but would still need its own ability to calculate and adjust distances of infill lines and convergence of them. It would be only optimizing from one axis though as opposed to all 3.
For custom Infill you should have a look to the Master Cura Release of @burtoogle : https://github.com/smartavionics/Cura/tree/mb-master
His Discrete Lines Infill options offer a lot of new possibilities. Not exactly what you are looking for but it's the closest thing we've got.
Some explanation to the option can be found here : https://github.com/5axes/CuraMasterSettings/blob/main/resources/articles/mb-master/discrete_lines_infill_definition.md
-
1 hour ago, Gero said:
Printed with Tough PLA Black.
Here I have the project file.
UMS5_BigSpoolHolder_HalterV1_TPLA_test1.3mf 316.33 kB · 2 downloads
Yes certainly something wrong , in 5.4 for the same profil the Print Speed was 45 mm/s and now in 5.5 it's 100 mm/s For sure you've almost divided the time by 2.
Cura 5.4
Cura 5.5
So the pillowing effect is certainly due to this high top/bottom Speed.
-
The prefect example to convert : snowflake just need to convert from SVG to POLYGON via : https://betravis.github.io/shape-tools/path-to-polygon/
Then Add a first dummy line :
POLYGON ((0 0, 1 0, 1 1, 0 1))
And we have :
Svg original file and wtk file
-
No issue to slice this model (In 5.5 ):
But an error on some triangles.
-
48 minutes ago, JelleSpijker said:
On a side note I'm planning on adding some rudimentary SVG support, but that will probably be a hobby weekend PR and I'm not sure when I have the time for that.
Maybe it's not so urgent after all, now that we know the WKT format is a standard format. Google becomes your friend ... https://betravis.github.io/shape-tools/path-to-polygon/
Converts my SVG file directly to WKT.
Settings :
Units : None
Precision : 0
Then a copy and past.
-
1
-
-
7 minutes ago, JelleSpijker said:
Weird that hardly nobody knows the WKT files which stands for, and I kid you not: Well Known Text representation
https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry
We only use a small subset of that format tho: https://github.com/Ultimaker/CuraEngine_plugin_infill_generate/blob/aaeebbd3c2c795184e94b404c46941c94739bb5e/include/infill/content_reader.h#L30
- LINESTRING
- MULTILINESTRING
- POLYGONNever heard of it, but interesting to know that it's in an ISO standard. :
-
Ctrl+C
Ctrl+V
Rename
EDIT... and test
That's all I can say. Or ask the author ( @JelleSpijker) of this plugin. There is no documentation on this point.
The only instruction comes from the readme file :
You can create your own infill tills by adding
*.wtkfiles in theCuraEngineTiledInfill/tiles/folder even when you already installed it in Cura...EDIT
In my case there are two lines ,
I suppose the first defines the hexagon envelope ... the second the geometry of the filling (Note according to my test the First polygon definition is mendatory and the geometry definition is not used to define the infill lines :
e.g. for the cow's head:POLYGON ((866 2000, 1732 1500, 1732 500, 866 0, 0 500, 0 1500)) POLYGON ((0 1045 ,170 1023 ,256 1020 ,335 1031 ,414 1081 ,349 1099 ....
I use Excel to represent the model (in orange the outer polygon, in blue the infill lines) and then I'll write the validated points in the POLYGON instruction (X Y coordinate pair separated by a comma).
You can also use the code : LINESTRING (866 2000, 1732 500)
or MULTILINESTRING ((1834 404, 1834 1595), (866 0, 166 404, 166 1595, 866 2000))
In this case the model is not closed.
EDIT EDIT : Pattern Name
The name of the Wtk file will used to add a new Infill Pattern. If you use the underscore as a character then the pattern name will replace this character with a space and the first letter of the following word will be capitalized. Ie head_cow.wtk -> Head Cow
EDIT EDIT EDIT
For the size of the model , I started with the Honeycomb example :
POLYGON ((866 2000, 1732 1500, 1732 500, 866 0, 0 500, 0 1500, 866 2000))
I don't know what unit is used and whether these values can be reduced or increased. As it worked, I kept this model as a starting point.
EDIT EDIT EDIT EDIT
The definition of the first polygon doesn't seem to matter . The pattern is created from the bounding box of the lines. So it's only useful if you want to define a margin around your pattern. In this case, the size will be adjusted to this first polygon. (To be confirmed)
in the second example the polygon representing the cow is the same and the first definition is a very small polygon:
POLYGON ((0 0, 0 1, 1 1, 1 0))
This must also give an answer to the unit used, the model will certainly be adjusted, so there's obviously no need to respect a starting size (still to be confirmed).
To be completed ....
-
3
-
1
-
-
Christmas Tree decoration
-
-
1
-
-
-
1
-
-
Just for fun playing with the new infill custom till plugin. Adding to new infill :
Star
and Triangle Star
-
3
-
The dancing nozzle problem
in UltiMaker Cura
Posted
Ok so yes Small Top/Bottom On Surface generates this strange paths. And 110% for the flow it's not normal even if it's standard for you. By trying to regulate under-extrusion, we end up generating over-extrusion elsewhere. Personally, I think that a 100% flow calibration should be required (you can have between 98 and 102% more means that you often have another problem ).