ghostkeeper

That pull request is indeed the one, 24c. Keep track of that link Giving Search and Replace scripts a custom name and a sort of summary like in Simplify3D would be nice, I agree, but it doesn't jive well with the other post-processing scripts in there. If you don't use Search and Replace, that summary basically just repeats the list of scripts above it.

I think you're right there, Gr5. Though I don't know how it would arrive at this result then. The slicing algorithm in Cura (that creates the actual model outlines for each layer) stitches lines together if they're closer than 0.01mm, so that small horizontal gaps are closed. I'd expect it to take the closest available line to stitch towards if there are multiple within this range, but I didn't find that code immediately so I'm unsure about that. Also, due to rounding errors when interpolating vertex coordinates between layer heights, the endpoints of a line could be 1 or 2 micrometres off. This all could result in a bit of a mess when connecting these lines. Normally the rest of the code then expects simple polygons: No crossing polygon borders allowed. Maybe this case results in a mess at the micron level in this corner and that violates those assumptions. I don't expect it to go outside of the normal polygon border though. And apparently it's far enough outside to even be printable (more than one line width thick). So that seems weird to me.

I think the reason is that it's something new we'd need to implement in 3MF.

It shouldn't collide. It should extrude some material and then tap the nozzle off on the bed (without hitting the blob itself). That really sounds like a bug to me so I've added a ticket for the firmware team to see if they get this too, with a reference to this topic. Because Simplify3D outputs its own priming anyway then I'd think they want to reconsider the prime line for Cura. Maybe they looked at some other slicers? I don't know.

It's not currently possible, or at least not easily. We expose all settings through the bracket syntax in the start and end g-code, but nothing other than those settings except the current date and time. Those are the only thing you can use when typing start/end g-code in the interface with the Machine Settings menu. See here for the source code that handles the bracket syntax: https://github.com/Ultimaker/Cura/blob/6a053a9f46c56a94cfaf611cb55376b4d0ad09d1/plugins/CuraEngineBackend/StartSliceJob.py#L270-L285 When you're writing a definition file (.def.json) a few more things will be possible if you specify the "value" property instead of "default_value". The "value" property can be any arbitrary Python expression, so you could make calculations like "G29 P" + str(int(machine_width / 25)) or something, and all the setting names have already been filled in as variables. There are other (hidden) functions available then as well, for instance extruderValues(setting_name) which gets a list of all values for a setting for each extruder. But there is nothing there either that can get the size of the print. Warning: I'm getting gradually more technical here... There is a vulnerability of sorts that allows you to devise a setting value that escapes the sandboxed environment in which the setting expressions are evaluated, and you can obtain data from the internals of Cura this way, including the dimensions and positions of the models. I won't disclose it here. But doing this will have problems with updating the setting value if the build volume changes, so it's not going to work reliably. Also for the purpose of bed levelling you'd probably want to know the size of the final print rather than the size of the input models. The actual print can be quite different due to brims, rafts and horizontal expansion (of model and/or support). Most of these can be predicted beforehand (you know the desired brim width and such). Some of them can't though, for instance if you have conical support enabled. In those cases it is really impossible to get the dimensions of the print before slicing has completed. I'll shoot in a feature request ticket to add the size of the input models as a key replacement for the bracket syntax. No promises, of course. Our backlog is long. https://github.com/Ultimaker/Cura/blob/6a053a9f46c56a94cfaf611cb55376b4d0ad09d1/plugins/CuraEngineBackend/StartSliceJob.py#L275

Noted. It's been requested before and attempted before, but we didn't manage to get it right.

It means that the feature was rejected. I believe it was rejected because other slicers than Cura might still need a turd. Brim is the default in most of the UM3 profiles, I think. Skirt is still an option though.

The EM-1161 ticket is marked as "Won't fix" so I think that is outdated.

Cura has the ability to prime or not prime with the setting "Enable Prime Blob" under platform adhesion. It's enabled by default. Cura always writes a command "G280" to the output g-code to indicate that it should prime, but when the prime blob is disabled, this command becomes "G280 S1", which is a signal that the printer should not prime. I don't know why this strange structure was chosen but that's how it works now. The G280 command is implemented by the firmware such that it extrudes a lot of material while slowly moving the build plate down, then tapping the nozzle off on the build plate a few millimetres further. This distance is not encoded in the g-code so Cura can't tweak how many millimetres away from the prime blob the tap happens. It can only enable or disable the prime blob entirely.

I was asked by @SandervG to give a tutorial about Cura on February the 24th. Maybe that's something else though. As far as I know the 23rd is just a normal working day. So I'll be in the office, and would be glad to meet you.

According to this, 0xc00007b means INVALID_IMAGE_FORMAT, which usually comes down to some system files missing or getting corrupted. They say it is a common bug in NVidia drivers. Perhaps you could try updating your graphical drivers? Looking around with a search engine, it seems that a lot of 3D graphics applications (lots of games) have this problem.

Cura's implementation actually also uses a -0.01mm (10 micron) z-offset, which is hardcoded into the engine right now. I intended to test that with -0.02mm but never got around to it.

Maybe the hot chamber of the 0.25mm core is too large? I don't know how they compare, really, because another factor is that our standards for print quality have gone up considerably since the 0.06mm profiles for the UM2+ were made.

Nothing is missing from your configuration. There is indeed only the 0.1mm profile. When developing a 0.06mm profile we ran into some oozing problems. The reason is that the flow rate for 0.06mm layer height with a 0.25mm core is so extremely low that the material stays inside the nozzle too long and becomes too fluid. It was all right if printing large swaths of material in between but if you retract a lot, such as for thin pillars, then it was a big mess of strings. The Materials & Processing researchers are still working on their profiles for 0.25mm on 0.06mm layer height. It's not clear whether there will be a profile any time soon. As for higher layer heights, you'll quickly hit the flow limits. I'd think that 0.15mm would still be possible, but I don't think that is the focus for the 0.25mm cores.

A few things to clarify that you weren't sure about: Yes, this works and some people at Ultimaker HQ have also done this to their installations. On Windows, you can delete these files from C:\Program Files\Cura 3.0\resources. On Linux it's a little bit harder, but the AppImage file is effectively an ISO image so you could open them with an application that edits those and re-package the image. The extruders won't influence the loading time very much. The bulk of the loading time is the synergy between definitions and materials (they multiply with each other). You can delete the Cartesio extruders as well if you don't use the Cartesio printer. It doesn't belong to Custom. Removing the firmware, translations or meshes won't influence loading time. They aren't used at start-up (except the currently active translation, but you need at least one). You could also delete some quality profiles and variants. Similar to the extruders it won't influence the loading time much, only slightly. For version 3.2 I'm preventing the other printers from influencing the start-up time. It effectively only loads the metadata, which it needs to show the printer list at the start. Most importantly, it removes the multiplication of profiles caused by the definitions and materials. These are the feature_local_container_server branches on the Cura and Uranium repositories: here and here. Right now it takes about 1 second to go through the "Loading machines" stage of the start-up on my computer, down from 15.

What are your favourite past-times while Cura is launching?

No, you can still run this alongside previous releases. The first time you start the new release it will port over all your settings, but not in subsequent runs. If you then change something in 2.7 it won't be ported over to the 3.0 release (and from 3.0 to 2.7 it will never port changes in the settings) As far as we know, the version upgrade of this version is complete, as in, you won't lose any of your configuration. Profiles are inherited too. It should look exactly the same. Be sure to delete the 2.7 configuration folder then (you won't even need to uninstall Cura 2.7). You can find that in Cura by going to help -> Show configuration folder...

If you put your definition files in Cura's configuration folder they will get copied along to the next version. You can see your configuration folder by going in Cura, then Help -> Show configuration folder... Unless you're on Linux because then that shows only 1 of the 3 configuration folders. Then you need to put it in ~/.local/share/cura/3.0/definitions. For post-processing scripts this doesn't hold though. Those are only loaded from the plug-in folder itself which gets updated from every installation. You'll have to manually transfer them to the next installation.

At Msuurmond's behest I've uploaded the Siemens NX plug-in to the directory for the plug-in browser, and published the source code repository: https://github.com/Ultimaker/cura-siemensnx-plugin

And it's merged. Thanks for the debugging, guys.

Indeed, we disabled the One-At-a-Time mode for printers with more than one extruders, because we couldn't guarantee that the print head wouldn't collide with previously printed objects when going to the switching bay or the wipe location. Or at least, not without lowering the build plate at every switch. It's also a problem for the prime tower. The original plan was to fix this one day and bring the feature back for dual-extrusion as well. It's not in our short-term planning though.

Here you go: https://github.com/Ultimaker/Cura/commit/2fbcfe65ea7e29a591e3e3b247cbd182864c6913

It's a good point, actually. We just put the entire configuration file there, and that could contain the most recent load path, save path, recently opened files and the location of the engine, which are all paths on the user's file system and could be sensitive. I'll see if I can remove them for the next release.

You were misinformed about the log file. Since 2.6 the log is located in %APPDATA%\Roaming\cura\cura.log, not in local.