nallath

That's the best way to do it under most operating systems. The UFP package is (in it's current implementation) a wrapper for a .gcode file and a preview image. In the future, we might put more payloads in there.

Because certain settings are set per extruder. If you have two extruders, you need to set it twice. Yep, should be the same. This has to do with the first question again (at least the -e<extruder_nr> does). If you give a setting without telling the engine on what extruder it needs to be applied, it will use it as a global setting (Layer height is a setting that should only be set globally, since both extruders must use the same value). If you want to change a setting for a certain extruder, you can use -e0 -s setting_to_change="foo" to do this. One at a time printing is even more complicated. When printing multiple objects, it's possible for certain objects to have a subset of settings changed.

How does the model look in x-ray view? I'm guessing that the model has some issues with it. If possible, share a .curaproject file with us, then we can have a look at what you did (and thus, what might be wrong).

The version is actually an API version. Sometimes we make internal (breaking) changes. We try to avoid them, but sometimes we're forced to do it (because previous assumptions of us have been proven wrong, or keeping the API the same would just result in unmaintainable or hard to implement code). Also; Plugins are completely different from scripts. The scripts are what is used by the post-processing plugin (and are run against the entire g-code). Plugins can do much, much more than scripts. With a plugin, it's possible to change what slicer is actually being used, change rendering on the screen, add new tools, add new filetypes that can be written/read or even change workflows. This makes them much more powerful, but also harder to actually work with.

You need to set the setting "support_extruder_nr" to 1 (instead of 0, which is the default) If I recall correctly, this can be done by adding; -s support_extruder_nr="1"

Share Cura & machine logs. Without it, we can't debug.

Uh? Where did you get that information? Next firmware release will be for both machines. I very much doubt that a similar issue exists in the released state of S5 and UM3, since pretty drastic changes have been made on the side of Cura Connect. Could be that it's in a part that wasn't touched, but chances of that are pretty low.

So my guess is that those are probably what's causing the issue.

True, but that doesn't allow you to specify it. The algorithm makes those decisions for you.

So yeah. I work for Ultimaker ?

Did you also set it to use the same acceleration & jerk? The speed is actually setting the max speed, which is quite different from actual speed (which is the result of max speed, acceleration and jerk)

You did nothing wrong, but sometimes people go on holidays. Cura sends an auth request if your printer has old firmware. If you upgrade it, you will get to use cura connect (which also provides cool features like queueing on the printer).

Nope.

Without logs (both from Cura & the machine itself) we can't do anything to fix it. We're not experiencing the issue.

It is possible, but you have to change the *.def.json file of your machine. We assume that those files are provided by the person / company that sold you the machine.

I don't see anything weird in the logs at first glance. Could you also share a project file of your setup?

https://github.com/ultimaker/cura#logging-issues

Could you share logs? This seems to be a bug, as it should save values that you entered as a user.

Could you share the cura logs?

@Msuurmond is our product owner, so he can give a definitive answer. I can answer the developer license thing; you don't need one. I think you can also use the icon, but I'm not a 100% sure about that one.

The flow sensor of the S5 won't fit in the casing of the UM3 feeder (at least, that's what the hardware engineers told me). But i guess it should be possible to backport it if you don't mind getting your hands dirty. You probably will need to drill some extra holes in your back panel though.

I think the thing here is perceived and actual need. It doesn't really matter what a company actually needs, it matters what they think they need. So even though you might be able to solve the static IP thing in another way (which may or may not be better), it does not mean that they don't need the feature (because they expect it to be there and convincing them otherwise is harder than building the thing in the first place).

We try to put easter egg games in all machines. The UM3 also has one, but that's a bit harder to find (and much harder to beat!)

Derp. Well, It's on the public repo. I forgot that I run Cura from source.

Inside cura; Top bar > toolbox > materials