nallath

This might be something that @bagel-orb is interested in. He's doing a PhD on slicing now.

I'm all for sharing it. There are some pretty cool insights. Let me ask around a bit. I do need permission for this. We're already using the data to decide on what profiles we need to focus on, so you guys are already benefiting from it

@nallath, is there a way to get our hands on it to give it a try??? (guess it´s not at your github :-) ) I have a lot of situations where I would need this feature highly - e.g. on model heli fuselages... It's super unstable. A lot of models just make it crash.

We also tried optical sensors. Didn't work with PVA (as it's transparent)

That would be me. I developed a scanner for Ultimaker. Got quite far with it, but UM decided to focus on just 3D printing, so it wasn't a resource issue.

It could be that the model is not watertight. Check an online model fixer.

Is the model being printed with the second extruder?

Well, Ultimaker is always looking for more people, especially engineers. Cura is also open for paid plugins now, so i think there will be plenty of opportunities to make a living with 3D printing. I've been doing exactly that for the past 5 years!

Remeshing is of course a thing that's interesting. Cura 3.0.3 has a third party tool to help with that. As fixing & remeshing is a pretty darn hard problem, i don't think that Ultimaker is going to fix that by itself. But we definitely welcome other parties to do this (case in point, the plugin).

Team is perhaps a big word for the um2 and UM2+ firmware. Its one developer that does that on the side. The whole "machine sets the temp, retraction, etc" was a mistake that we made for the um2. We believed (wrongly!) that you could generate machine paths without knowing the material and that the machine would be able to set material specific settings. This is such a fundamental thing that we can't retroactively change that for those machines. It is something that we changed for the UM3, so it won't be an issue when we are moving forward.

Uh. Fairly little. We don't do much with the cloud or internet connection. What little data we sent is obviously done with HTTPS and can always be opted out (Cura sends settings if you save slice data, but we have no idea who sliced it or what they sliced, just how it was sliced.) Security was also a reason why we didn't have a remote acces system for the UM3; It's damn hard to properly do this. Security is one of those things you only get one shot at, so if you do something like this, do it right. Our best defence is not being connected in the first place. Well if your UM is hacked, it's because you actively made steps to open it up to the internet. Depending on how well (or poorly) you did this, there are security risks. As it's not something that we provide you with, handling the security is then also up to you. I'm not quite sure what you mean by this. We send Cura to major virus scanners to be checked before hand, but we mostly do that due to not being marked as a virus. I'm pretty sure that we will move toward more connected systems in the future, but I think we should do that slowly and carefully, regardless of the amount of pressure that costumers might put on it. People tend to want things yesterday, but it's my responsibility to give them what they want while taking care of them (and protecting them against risks they might not know about).

This is already the case :)We have a huge number of types of profiles, which are used in a stack like fashion; user, quality_changes, quality, material, variant, definition_changes and definition. If a user changes a setting, it's put in the user container. If the user decides to make a profile, it's moved into the quality_changes (so "update profile" actually moves settings from user into quality_changes). For the UM3 we have quality profiles based on the material. So if someone changes the material from PLA to ABS, we switch out to another quality, but with the same type (so if it was normal pla, we switch to normal ABS). The quality_changes profile is tied to the type, so that remains in place. It is not the case. Perhaps I didn't explain it well enough to make clear what I meant. As an example, if you change the "Material" under the tab for an extruder, as far as I can tell, it does not change settings under "Material." It does not update the printing temperature, it does not update the filament diameter, et cetera. (It is used for color, cost, et cetera, sure, but materials are more than that.) Which is why you have to re-enter all the same information for each profile that uses this material. If I have a PLA-PVA profile and a PLA-PLA (say for multi colors) profile, then I have to enter the print temps, filament diameter, et cetera for PLA three times, even though it is the same exact information. If I find I need to change the retraction by a millimeter then I have to do it in 3 places. This is very different from pushing settings from "user" to "quality_changes" when "update profile" is pressed. That is just moving/copying a block of data from one place to another. I'm speaking of how those blocks of data are fundamentally organized. The "huge number of profiles," as you say, is exactly the problem. If how profiles are handled was re-thought, you could cut down the number of profiles, or at a minimum, make them a lot easier to manage by reducing the amount of duplication. I understand the how and why it got built this way, and I do appreciate the number of settings and their relationships make this difficult to design, but this problem is only going to get worse as more material types are developed, Cura features added, new print cores are developed, et cetera. I can put together a small demonstration if you are willing to review it. By all means, as I don't understand what the difference is. What you describe is what we have as far as I can tell.

This is already the case We have a huge number of types of profiles, which are used in a stack like fashion; user, quality_changes, quality, material, variant, definition_changes and definition. If a user changes a setting, it's put in the user container. If the user decides to make a profile, it's moved into the quality_changes (so "update profile" actually moves settings from user into quality_changes). For the UM3 we have quality profiles based on the material. So if someone changes the material from PLA to ABS, we switch out to another quality, but with the same type (so if it was normal pla, we switch to normal ABS). The quality_changes profile is tied to the type, so that remains in place.

I think some form of preference / setting / machine saving to the cloud (tied to an account) would be nice. Being able to "deploy" pre-fixed settings & machines to a group of computers is also a request we've had from universities & schools. As for moving everything to the cloud, i'm not a big fan. If there is no need to move something to the cloud, you shouldn't do it. Software should be usable offline (I have a bit of a pet peeve with always online software)

I don't see Cura as a modelling tool. But it is doable to do this with plugins. I've made a sort of working cutting tool that could cut models on the build plate by dragging a plane.

If we can change layer height, it should just as easily (from a technical viewpoint that is) be possible to have other settings. How it will look / work isn't clear just yet.

Far from it! Plugins can actually do things like; Add new tools to manipulate the 3D scene, add new render types (the X-ray view is actually a plugin), add new file types, add new ways to send g-code (both octoprint & the um3 connection stuff are plugins).

FieldOfView (ahoeben) actually started out by suggesting UX changes.

https://ultimaker.com/en/community/35603-support-mesh-anti-overhang-mesh You can use them to "mark" areas so they won't be supported anymore.

This is something you could already make if you wanted to. I've written a script some time ago that puts all flattened settings into the user changes. That way it won't ever do auto magically setting calculation. But it's not for the faint of heart and there is no guarantee that it won't mess up your prints (as it probably will mess it up)

I think the visibility presets will help greatly with this. That way we can have a gradient in what settings you have visible (and we can give hints regarding what settings we view as super advanced vs intermediate)

I think a lot of them could benefit from it. You already named a few, but i've myself already used it to repair the wheelchair of my niece (an arm rest had broken off and it would have costed a few hundred euro and weeks to fix it. I could do it in one day for a few euro)

None!! Especially not on talk like a pirate day Cura has no easter eggs what so ever. Especially not on talk like a pirate day.

One is only reachable on a certain date. One requires an extra bit of hardware.

If you actually want to code, you need to understand python. If you only want to change how the UI and UX looks like, you should have a look at the .qml files that are shipped with cura (and the theme.json file). Those describe how the UI looks. But we do need more resources on how to get started with developing for Cura. I'd love to have more people outside of Ultimaker to work with. Diversity will lead to a better overall product (both for Ultimaker and for those with other printers).