nallath

I've forwarded this topic to our designers. They should have a look at it soon.

You can also group objects. Objects that are in the same group are never pushed apart. So; 1. Select the two objects 2. Right click; group objects (or ctrl+g) 3. Use ctrl click to select a single object inside the group and move it to the position you want.

It will be in the next release; in that release you can disable unused extruders. So as long as you don't use both extruders, you can print one at a time.

Not at the moment, but we're working on that.

I can't put more likes to this post! This is super nice!

It was always intented to work how Ahoeben implemented it, but we just never got to it. We decided to add the functionality in the way it was so it would at least be available for the die-hards that don't mind experimenting. That being said, i'm really happy its now (ab)usable for everyone!

I think the only way to do that would be to add an extra pass (eg; DepthPass) that returns a depth image.

There isn't a mailing list, but we do read the forums. So if you have any questions, feel free to ask them.

See the metadata of the fdmprinter.def.json. It as ""preferred_material": "generic_pla"," So your new machine should already do this.

For the UM3 it needs to be a USB stick, as it doesn't even have a card reader.

It's not about performance, its about it being possible at all. In order to get the simulated g-code view, we need some features of a certain version of open GL.

In this case it's kinda like the flight controls that we don't use anymore. But there are people working on it, so it might be fixed. As far as staying in print mode, that's probably also because we really don't put time into fixing the USB printing (or even testing / looking into it). So it's a bug, but don't expect it to get fixed by us (eg; Ultimaker).

Well, in this case we just put most (eg; 95-99%) of our time into optimising Cura to work with Ultimaker machines. As printing over USB is a fickle beast at best, our latest generations of machines don't really support it (only the UMO really supports it, and even there i'd recommend getting the ulticontroller). So as a result, we just don't put any time into building features like that, as none of "our" users will benefit from it (okay, maybe a few, but you get the point. We've got other stuff to fix too) But not all is lost; Cura is open source. There are people working on getting a few of your issues (manual control extruder temp) up and running. But the stuff that people do in their own time won't be as fast as having >5 full-time software engineers churning out features. So if you want changes, pull requests are always welcome. As for the travel paths; We've looked at optimising those. Turns out that in almost all cases it costs you tons and tons of extra slicing time at a marginal improvement of the actual printing. Optimising these is only worth it if you expect to print the same g-code multiple times, which isn't a fairly common usecase. Your example of the airbus does fall a bit short, as in this case the engineers are also frequently flying the plane (granted; we do "fly" Ultimaker machines, so other machines might not get the same experience). But it's not really weird that you get a different experience if you use Airbus control software on a Cessna plane. It's just impossible to make something that's perfect (or even okay-ish) for everyone.

I'm not a 100% sure about the behaviour, but it could also be that it was a thing that you could only override when the machine is in developer mode. Right now, connect can't override it (We could make it, but it's not something that I think we should, as it's pretty easy to wreck your machine if you do it)

The Connect issue is because the printer has a much less advanced detection system to check if something can be printed. The printer only gets a min x,y,z and a max x,y,z. Cura takes way more into account, which in this case leads to the very small area where Cura does accept it, but the cluster software doesn't. We explicitly added the feature to have both applications check for size, as you can also manually send files to the cluster. You always want it in Cura, because it's just easier and faster for users to see it right away (Doing it on the cluster is just another safety check)

I'm not sure when we fixed this bug, but we did fix some issues that look similar to this. I expect that it will be fixed with the next firmware release.

You need to manually create the *.def.json file. Examples of this can be found on https://github.com/Ultimaker/Cura/tree/master/resources/definitions

Well, rotation is not in there because rotation is just insane hard to do. Especially when you go into shearing and all kinds of weird transformations that you can do. Have a look at quaternions if you want to know a bit more. But don't tell i didn't warn you that dragons live there (and other imaginary stuff / numbers). So yes. Putting in rotation is hard. If you don't believe my answer, why ask in the first place? I want to fix it, but there really isn't an easy way to do it. As for a "disconnect", this is just using very large terms to say; "I found a bug". Because that's what you did. So the cluster seems to refuse to do something even though it was sliced. Okay, that should be fixed. But that isn't a UX issue, its a bug. Not doing hard things is just common sense. Or well, not doing hard things if there is only a few people using it. Every bit of work we do is always a balancing act between how hard it is and how much "value" we think we can get out on it (emphasis on think, as we can and will be wrong in some cases). We don't do this because we *want* to. We do it because we have to. I don't quite agree with the statement from Chris that we have a ton of legacy. There is legacy, but in quite a few cases it's just simply because of how something is set up. Some choices make option A easy and option B hard. This is always a balancing act and some choices that we made in the past can cause things that should not have been that hard to become harder.

And don't forget more testing, as these changes are pretty "deep" into the code. So those changes could impact a large number of other features. To be sure it didn't accidentally break some stuff, you need to re-test a whole load of features. So pretty much what Aldo said; Don't assume malice if we didn't build a feature exactly how it should be. We know that it's not perfect. We don't like it either, but there is only so much things that we can do, so it's a constant balancing act. Constantly having the feeling that we need to defend ourselves isn't really helping

At the very least you need to add the .def.json file. If you also have a build plate model, you should also upload that. It could be that your machine has variants (eg; switchable nozzles). In that case all variant files also need to be uploaded. Same is when the machine has quality types per material.

Could you share log files?

This is because auto-arranging is a pretty damn hard problem for a computer. Humans are pretty good at it, which is why most people seem to think that it's easy. Getting the automatic system to the same level as a human would probably take months (if not years) of development. Cura right now uses a rather naive aproach; It tries to put the largest object in the middle first and then add the other objects. In case of a number of objects that share almost the same size, this is a pretty horrible way of doing it. But if you have a number of models with different sizes, it gets a whole lot better. The current implementation isn't the best, but it's already quite a lot better than the "old" way of doing it, which was just adding the model to the right of the existing model.

You don't need to just change the printer; you'd need to change every profile in the printer. The Ultimaker 3 has a quality profile per quality type (Normal, Fine, etc), Per material (ABS, PLA, PVA, etc) and per variant (AA 0.4, BB 0.4, etc). The difference in temperature behaviour will require different settings for certain qualities. It's not as simple as just changing a few temperatures and calling it a day. It would effectively double the profiles that are already there. Copying those isn't hard, but ensuring that all of them are good is.

They load just fine in Cura 3.2 with me.

Is it? I personally see it more are the manufacturer of the printer providing you the settings in the first place.