ghostkeeper
-
Posts
209 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Events
3D Prints
Posts posted by ghostkeeper
-
-
It's already integrated. It's in! But we've just today found an issue with Creality project files from before the merge not working after the merge. Hopefully we can get that fixed before the 4.2 beta or at least before stable.
-
Okay, thanks! That's bad news but in a way also good news because we hadn't changed anything to fix it so I was worried that we might accidentally trigger the problem again later without knowing how to fix it...
-
Users on Github are reporting that this issue seems to be gone in Cura 4.1.
-
The machine settings for Steps per Millimetre are normally not visible (only because you installed a plug-in that makes machine settings visible).
They are not used currently by CuraEngine but only by the X3GWriter plug-in to convert to X3G properly. However in the future we might use them to improve aliasing when rounding to steps or halfsteps.
-
-
On 1/18/2019 at 12:24 AM, kreeser1 said:
1.) Is this still how the Cura software determines the order in which to print polygons on a layer-by-layer basis?
Yup, it hasn't changed. My statement wasn't quite complete though. There are multiple orderings going on, from significant to insignificant:
- It needs to print all mesh groups in order (in case of one-at-a-time mode) so that they can be printed without colliding with the print head.
- It needs to print all layers from bottom to top.
- It needs to print all extruders in such a way to introduce the fewest extruder switches.
- It needs to print all meshes for an extruder in such a way to reduce travel distances, by nearest neighbour (as described above).
- Within a mesh, if a mesh consists of multiple simple polygons at a certain layer, it needs to print all parts in such a way to reduce travel distances, by nearest neighbour (as described above).
On 1/18/2019 at 12:24 AM, kreeser1 said:but the actual printing of the loop doesn't matter because the loop starts and ends at the same point.
It prints all of the part together. Usually it doesn't print just a loop for the outer wall, but also inner walls, infill and skin. It's not common to end at the same point.
On 1/18/2019 at 12:24 AM, kreeser1 said:Does Ghostkeeper truly mean that, (a) for each layer, given some starting point, all loops are represented by the point on the loop that is closest to the initial starting point, proceeding with a simple nearest neighbor solution? Or does it mean that, (b) for a given starting point, all nodes on all untraversed polygons are checked for the smallest distance from the starting point, then representing that second polygon as a single point at the node, and so on and so forth until there are no polygons left?
Neither, to be precise. It finds the closest point on each polygon from the starting point (so you get a bunch of coordinates on the borders of polygons), then from those points chooses the closest one to go to. Then it prints that polygon completely and ends up on a new position. It again finds the closest point on each remaining polygon from the new starting point and chooses the closest one again, and so forth until there are no polygons left.
On 1/18/2019 at 12:24 AM, kreeser1 said:If (a), it seems like this solution would be highly dependent on starting node, so how is the starting node picked? Does the algorithm cycle through all potential starting nodes?
Indeed it is. The starting position is two settings: Layer Start X and Layer Start Y. It's not (necessarily) on an existing polygon and it doesn't actually travel to this starting position first. Previously we had the option to make the starting position the position where the nozzle ended in the previous layer, but that didn't work any more once we introduced multi-threaded slicing.
On 1/18/2019 at 12:24 AM, kreeser1 said:If (b), I think this would make more sense and yield a better answer, but be potentially costly in testing each "current point's" distance from every node in every other untraveled polygon.
It uses Pythagoras, but omits the square root, so we're comparing squared distances. It's not so taxing then, just two multiplications, one addition and a comparison per polygon. It scales quadratically but you'll rarely have more than 1000 polygons anyway. In fact, we're doing the same algorithm to determine the order in which to print skin lines and infill lines.
On 1/18/2019 at 12:24 AM, kreeser1 said:3.) Finally, if the bit of code isn't too large, or there is a comment directly in the code that explains it further, could someone provide that in the comments, along with what file it's located in? I am writing an academic paper for that has a small section in which I would like to cite how one or more popular tool path generation programs solve this problem for the 3D printing use-case.
There's some stuff in there for finding the proper location to put the Z-seam as well that you can ignore (unless you do want to write about that because it's specific to 3D printing). There is also an optimisation that I hadn't mentioned yet with a bin map, which finds points that are very close together faster (the grid is stored in the loc_to_line variable).
-
1
-
1
-
Changing support settings for an object will change how that object is supported. So if you change the Support X/Y/Z Distance for a custom support block, you're changing how that block would be supported but the block itself isn't supported so it has no effect. The block causes the model to be supported.
The support X/Y/Z distance can't be changed for just parts of your model. I'm sorry. You'd need to change it everywhere or nowhere, or indeed model the support yourself in CAD.
-
You need to look at the following four settings:
- Support X/Y Distance
- Support Z Distance
- Support Distance Priority (normal support only, not Tree support)
- Support Min X/Y Distance (normal support only, Z overrides X/Y only)
I would expect that reducing the X/Y Distance has a lot of effect for you, but don't reduce it to below 0.3mm or so because then your support will stay too close to your model sideways.
-
We did some things to improve that, which should be released in 4.0.
-
PETG and HIPS are not supported for the Ultimaker printers. You can download that profile, and it'll show up for some other printers, but we disabled it for the Ultimaker printers.
-
On 9/23/2018 at 11:54 PM, phantom said:
Hi Samrtavionics,
Saved it as you said how to save it, let me know if this is sufficient.
I did a performance test on that 3.5 file using Callgrind and got this result: http://dulek.net/work/3.5-beta-callgrind.out.3886
This seems to point to this change: https://github.com/Ultimaker/CuraEngine/pull/791
We'll continue discussion there.
-
31 minutes ago, drayson said:
Is a huge rework or just a minor mod required to make them work again? Just as a hint how long it might take to have them available again... ?
We expect that 1 or 2 lines of code need to change for most plug-ins. It's not much, but the developer needs to figure out the stuff that is broken, test it, package it and re-submit it which could be an hour or two of work. Also, some people have loads of plug-ins up there which could be quite a significant amount of work to do for all.
-
A more complete list of features is in the great blog post, written up by my friend Matt: https://ultimaker.com/en/blog/52715-whats-new-in-ultimaker-cura-35-beta
An even more complete list (that includes the most significant bug fixes as well) is in Cura itself. You can read that list from Cura's source code here: https://github.com/Ultimaker/Cura/blob/master/plugins/ChangeLogPlugin/ChangeLog.txt
-
1
-
-
What's that error traceback that you see in the first textbox?
-
On 9/17/2018 at 10:36 AM, bman said:
I can understand temperature and material but do I need to set things like bed temperature in both extruders?
I would be great if someone could advise what settings are shared between extruders, which extruder sets the defaults, and how to ensure that both nozzles are primed for printing.
There can only be one bed temperature. Bed temperature is a global setting, so shared between extruders. Cura indicates these sort of settings by displaying a chain link icon next to the setting.
Each extruder has its own defaults for most settings. Like the print temperature and such, these can be different for each extruder. That is a problem for Chimaera-style nozzles because Cura will try to set the temperatures for both extruders to different temperatures but on your nozzle only one of them can win. There is no real solution for that yet (and no priority from Ultimaker to make one) but you can work around it by removing some temperature commands using the Search-and-Replace post-processing script.
Some default settings that are global can still be set by the material profiles per extruder. This is kind of a complex system, but necessary for things like the bed temperature. For these, there is a resolve function that Cura defines per setting. For instance, for the heated bed temperature, Cura chooses the highest of the temperatures of all nozzles.
Make sure you check "Enable Prime Blob" or use a skirt/brim/raft for the extruders that need priming at the beginning of a print. Use a prime tower if you need them primed after each extruder switch (strongly advisable for Chimaera!)
On 9/17/2018 at 10:36 AM, bman said:I am alos looking for some help on enabling things like the ooze shiled / prime tower etc.
Don't bother with the ooze shield in my opinion. Use a prime tower for your Chimaera printer though.
-
Did you try updating your graphics drivers?
Cura indicates in the log that you support OpenGL 3.3, which is pretty old (released in 2010). They are at version 4.7 right now.
-
That is the correct log file ? Only there is nothing in the log that indicates that Cura finds something wrong on your computer.
Technical background: I suspect, also from your pictures, that it's some redrawing bug in Qt. We aren't seeing it on our computers though. I can't find that it has been reported on QtBugs anywhere either, so the chance that it'll get fixed in Qt 5.10 is small. In the next Cura release we've updated to a newer version of Cura's GUI framework, Qt. There is some chance that that fixes things but don't keep your hope up.
I looked through the Cura code that generates these comboboxes and the application menu but there is nothing to indicate that the opacity of these menus get set to 0% or anything... ?
-
That log file is from September 2017. At some point we moved the log file into the folder of the specific version you're using. Could you look into the /3.4 folder for another log file? Sorry for the confusion.
-
Cura stuff around your print and forbids you from slicing if that extra stuff would move outside the build volume (since that could damage your printer). Some of the stuff that's added around your print includes:
- Brim
- Skirt
- Raft
- Avoid Objects when Travelling
- Draft Shield
With default settings, setting the brim size to 0 and disabling Avoid Objects When Travelling will allow you to print stuff using the maximum volume of your printer.
-
We haven't seen this on our testing computers. That makes it a bit hard to fix the problem.
Maybe there is something in your Cura log? Could you post that here?
-
Looking at the log file again. I fixed a broken colour that I found because of that log, so thanks already ?
So in the log it appears to be crashing right after it initializes the shaders and right before or during initialization of the main window. The most likely culprit is these lines:
2018-07-22 05:06:55,824 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Topbar.qml:19: TypeError: Cannot read property 'stageId' of null 2018-07-22 05:06:55,826 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Topbar.qml:104: TypeError: Cannot read property 'stageId' of null 2018-07-22 05:06:55,829 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Topbar.qml:175: TypeError: Cannot read property 'stageId' of null 2018-07-22 05:06:55,831 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Cura.qml:433: TypeError: Cannot read property 'mainComponent' of null 2018-07-22 05:06:55,834 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Cura.qml:427: TypeError: Cannot read property 'mainComponent' of null 2018-07-22 05:06:55,836 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Cura.qml:465: TypeError: Cannot read property 'sidebarComponent' of null 2018-07-22 05:06:55,839 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Cura.qml:497: TypeError: Cannot read property 'sidebarComponent' of null
From this it appears that `activeStage` is null at that time which is weird to me. Also strange is this line:
2018-07-22 05:06:37,560 - INFO - [MainThread] UM.VersionUpgradeManager._getUpgradeTasks [272]: Config file [.\cura.cfg] is of version [6000000], which is different from the defined version [2000000], no upgrade task for it from type [preferences].
There it looks like someone mixed up two of the version numbers that we have in Cura.
-
To know what sort of bug this is, we would need to see a log file. See some instructions here: https://github.com/Ultimaker/Cura#logging-issues
The "Cura GUI log file" is the important one for this particular issue.
If you need to get Cura started no matter what, a surefire way to do that is to delete the configuration folder that this log file is located in. This resets Cura to factory defaults, so you'll lose all your preferences and profiles and such. But it probably resolves your issue. And it would be nice if you could copy the log file out for us so that we can see what the problem was and fix it for the next time ?
-
I don't know how it came to be, but it seems that your main configuration file got given a newer version number than what we currently use (version 6 instead of 4).
One simple solution is to delete the file: C:\Users\[you]\AppData\Roaming\cura\3.4\cura.cfg
This will reset your preferences, such as whether you have auto-slice enabled and that sort of stuff, but will not delete your profiles or the slicing settings. In the preferences window you can set your preferences back to what you prefer to use.
-
14 hours ago, bob-hepple said:
I switched to Cura 3.2 to try the Ironing but I haven't touched Cura for about 3 years now so completely lost ??? couldn't even find the ironing
If you click on "Custom" after Print Setup on the right side of the screen, and then type in the search bar "iron", then you should find some settings.
File that shows current settings ?
in UltiMaker Cura
Posted
No, not one file. That would be shadow administration, because we also need to keep the information separate per profile layer. There's a couple of ways you can get at this though.