nallath

Wait, you're printing with the second extruder? I think we never actually tried to see what happens if you do that with one at a time printing...

Not by means of the interface, sorry.

Well, the slicing preview looks fine. The one reason we could come up with how this happens is that you head couldn't move that far and it just squished the lines there, but that would mean you'd see a fair bit of over extrusion.

You could try enabling ironing. That should improve the quality of the top surface.

Yes, don't put an override value in your profiles. Then it will use the default, which in this case is a dynamic value.

No. It will only reset data regarding Cura connect (print history according to connect, queued prints, prints in cluster, etc)

Correct. The front-end loads the models and puts them in memory. The data that is in memory is sent to the engine. Yes There is a bit more than just that going on, but that's the gist of it yeah. There are a few settings that are only used when slicing from the comand line interface (you set them the same way as you set the other ones). You can find them in the fdmprinter.def.json file in the "command_line_settings" category

I was still on an older version of the Engine. I'm also getting the same initial situation as you now.

On the printer: System -> maintenance -> Cura connect reset

No. The failed importing was because of a bug. Which is why we do betas 😉 It should be fixed for the 4.2 release. As for the profiles being worse, I wouldn't know. We got the pull request and a lot of people agreed that they were better (and no-one disagreed). We simply can't test any other printers than our own (and even if we could, it would be insanely expensive for us to do so).

I'm not quite sure what you mean by sparse structure. Could you show some pictures of it? I've sliced both your projects with the latest Cura and i seem to get a pretty good first layer. Other than that, I'd recommend using build plate adhesion. That should ensure that your flow is up and running before the actual print starts. UM3: S5:

Those should not have an effect on the welcome screen.

Did you check if your models are manifold / watertight?

Well, the frontend and the engine have different model loading code. The backend one isn't used that often, so I'm not that suprised that it works less well. As for the scaling, it's possible to provide a homogenous transformation matrix with the model which allows for scaling.

The frontend does re-position the model so that all of it is above the build plate. Anything below the buildplate is cut off by Cura. That would explain why it does work for some models (eg; those models had no vertices below the buildplate).

If you check the logs, a complete list of all settings as sent to the engine are printed there.

Yeah, I know how they work. But this doesn't guarantee that the exact same dependencies are used as we tested (which is why we can't really provide support for it). It's already tricky enough to provide support for what we have right now.

I don't think he's using the appimage. We've been getting a lot of bug reports from arch linux users (yay for posting them though, you guys do make really good bug reports), but in all cases they didn't use the appimage.

If you use the settings as printed in the logs to start the engine than those results should be the same. Could you provide us with a project file of one of those models where the estimates are different?

Your model is probably thinner than the line width.

It should work, depending on how "weird" your printer is. The better it adheres to the standards, the easier it is to get it to work. Most printers that accept marlin g-code should work without any issues (at least no issues on the slicing side). A lot of printer definitions (To have some sane defaults, profiles, build plate sizes, build plate models, etc) have been added by the community already. We don't guarantee that those will work, but they should at the very least provide a good starting point.

This is super cool!

At the moment it is user specific. Sharing it with others is something we are looking into, but I can't say if (or when) it will be done.

In order to keep better track of all the feature requests we get, I'd like to ask you to re-do your feature reqeuest on or issue tracker on github (https://github.com/Ultimaker/Cura/issues/new/choose)

I absolutely don't think that PyQt (or Qt) is the problem at all. Hell, I don't even think that Python is the issue. The main issue is simply cross platform issues and using OpenGL at all (which is something we kinda have to do, regardless of the choice that we made). The native 3D graphics also means that we double the amount of configurations that we need to support. Now we just have to support 3 operating systems (which is a PITA enough as it is) but then we also need to do it for multiple operating systems and multiple browsers. There is a case for it, sure. But the ugly truth is that we're already short staffed as it is. Essentially re-writing the GUI (which is 75-80% of the codebase) is simply not feasible (In general, in the current state it's just flat out impossible). All that being said; Feel free so do some experimentation. Don't believe me on my word for things. I'd love to be proven wrong in this case.