ghostkeeper

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. The "user" profile contains all of the changes that you've made but not stored in a profile. The "user changes" profile contains your custom profiles. Those two combined normally add up to all your changes. If you've made custom materials those will show up in the "materials" folder and if you've edited the machine settings those will show up in the "machine_changes" folder. This is Cura's main profile administration, which is, unfortunately, split up. Saving a project file puts all of the relevant profiles in one file. It's a zip file so you could open it up with 7-zip or something. However inside the archive they will be separated in the individual profile layers again. In the log file of Cura it lists the commands that were used to start the slice. This command contains all settings that were used, hundreds of settings. Keep in mind that it also keeps all of those settings again for every extruder, so some settings will be in there multiple times (if they are settable per extruder).

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.

Yes, here: https://github.com/Ultimaker/Cura/issues/5265

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). 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. 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. 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. 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. https://github.com/Ultimaker/CuraEngine/blob/a03d9291c6d9a37e8b4f23df60d76c249c045172/src/pathOrderOptimizer.cpp#L16 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).

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.

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.

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

What's that error traceback that you see in the first textbox?

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!) 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.

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.