nallath

The current-gcode viewer is rendered in a shader that uses vertex displacement, this makes it damn annoying to get that data and save it as STL.

I know our material / processing team and I'm not surprised to hear about the stringent tests. We have super high quality demands.

Don't pin me down on it (not a mechanical engineer), but from what i understood it won't be retro-fitted. Not because we don't want to (because we really, really want to! We originally wanted to put it in the UM3 on launch, but had to scrap it weeks before the launch), but because we couldn't get it to fit in the mounting holes that were already there. Making a retro kit would mean a new backplate and that's a pain in the behind to get right (it will cost a ton of time to replace it and shipping will also be a nightmare)

The problem is that with the UM3 and with the UM3E we only know what we try to extrude. Not what we were actually able to extrude. As most of you probably have encountered at some point in time; These two are not the same. That's where the magic of the flow sensor plays a role; then we have a much better idea of what is going on. As far as I know, the S5 won't do it from launch (because there is always to much to do for a launch ;)). But i don't think it will take long for it to be added.

Ooh! I know that one. Cura can talk to the printer / Connect cluster. It will handle the magic of ensuring that the printer knows about it. We might add a way for a printer (by means of connect interface perhaps?) to download material packages by itself / by user instruction at some point in the future. Right now, we notice that quite a few companies have their UM's on a strict "No internet for you" diet, so we let desktop Cura be in charge for a bit (As we usually do have internet access there). For the s5 there is a pretty good reason to have more NFC spools, as we can actually track material usage and write it back to the spool. That means that even if you switch out a spool to another s5, the second machine still knows how much material is left.

Uh. It's in the same spot as it always was. It's still there for me.

Yup. Onder the hood UFP files are zip files with a preview image in it. So you can just open them and look at the preview image. Don't worry. Working for a company like Ultimaker and talking to people outside of it means you got to have a thick skin. I didn't experience your posts as negative; you simply argue a point. Arguments are something we can work with, quotes like "OMG Too expensive, RIP ultimaker, greedy bastards" is something we can't do anything with

We didn't get a real launch this time :( Sigh... Multiple things really. First off, the bed is way bigger. That does little for the price, but it does mean that we needed a way better power supply (+-200 watt to 500+ ish). As the brick we shipped with the UM2/3 was already the biggest we could find, and we were pushing that one to its limit. So the only way to solve that was to integrate the power supply, which in turn means a ton of extra development (Making the supply, getting it approved for CE & FCC, you name it). We also needed to really beef up the rods / bearings that we use for the carriage system. There is also a bit more actual casing material (but I doubt that will do that much). The flow sensors, screen, and improved stepper drivers also add to the price. So all in all, it's not that weird of a price increase. It's not like we just made it bigger and started asking a way higher margin. Nope. It uses (max) 40 points to level. It does take longer (duh), but it also grealy improves first layer adhesion.

I might have some DBUS commands that you can use when SSHing into the machine lying around somewhere. It's a bit of a hacked together interface and it comes with absolutely 0 warranty, but it should at least enable you to send raw g-code.

I don't think you should see the S5 as a UM3 "killer". Quite a few people see it as a replacement printer, but I don't think it should be seen as such. It's an extension of the portfolio of machines that we provide. Both the UM3 and the S5 still have the same firmware architecture, so we can continue to develop for both of them at the same time.

My work for the s5 was actually quite... boring. I'm on the Cura Connect team (amongst other things I do, but that's the primary project I'm on). But we didn't need all that many changes to get the S5 to work. I did work on getting the notifications to work and the preview images on the touchscreen and the queue. That's also why there is a new surprise file format in the spec sheet of the S5; UFP. It's basically a 3MF light with a preview & gcode in it. But the preview isn't just a S5 only feature; it's also going to be in the next firmware release. But yeah, these features are really cool from a user perspective, but not super challenging on a technical level.

It's just a bit of grandeur from us Dutchies; The Netherlands is global!

Don't pin me down on this, i'm not that deep into Cura anymore, but it adds a temp set container stacks to do the switch. So it's not really adding a new machine, it just provides you with one to use for a bit (this is so you don't clutter your local setup / or force us to track what machine is linked to where)

Also, I don't think alot of you noticed it, but the new firmware / app will also bring notifications to the table (also for the UM3), even outside of the local network.

Yeah. We changed that. So let me explain a bit more. Everything you slice for an UM3 can always be printed on a UM3E. Things that you slice for UM3E can sometimes be printed on UM3 (if you don't use the height). S5 and UM3 can't mix g-codes (or well, you could, but it will just give you poor results). In order to make it easier, Cura will allow you to connect with a cluster regardless of the local Cura machine. You will have a spiffy new sync button that shows all configurations. So if you added the cluster by means of a (local) UM3 and you select a configuration on the S5, cura will switch the local buildplate / profiles to S5 ones. I have to admit i was a bit sceptical about this at first, but having used it for some time now, i have to say it works pretty neat.

RIght now? You slice it for either UM3 familiy or for the S5. The profiles (due to head weight / size) are different, so mixing them will get you poor quality results. We did improve the whole flow for Cura & mixed connect setups. So if you have a mixed cluster, you can switch between the printers pretty fast from Cura. It also detects what configurations are on what machines. As to how I would personally want it; I'd love it for connect to be able to re-slice models. That way you can just throw a curaproject file to the queue and depending on what's available, the models can be resliced (while trying to remain as close as possible to the original intents you put in there). But yeah, future dreaming!

I can only say a bit about Cura Connect (as that's my project / team at the moment), but we don't expect to ship different software for UM3 / s5. It would add quite a burden on development if we would and the magic of connect is in the fact that you can mix & match a bunch of Ultimakers so they can print from the same queue.

My headcanon is that the S stands for sexy. So its the Ultimaker Sexy 5.

And the machine makes waay less noise.

Don't pin me down on it, but the 4 was skipped due to bad associations with the number 4 in China / Japan. The S stands for studio.

Share the logs please.

I've looked a bit regarding getting timelapses integrated with Cura Connect. Can't say when we will get it in, but its reasonably high on the todo list.

Theoretically it could be possible to have layer height available if you're printing multiple models in one at a time, but we also have some legacy issues, which make some things harder to build than they actually should be. As we always have more features than we have people to build them, the stuff that isn't used that much tends to not get picked up. Compounding the g-code is theoretically possible, but it does create quite a few issues with avoidance paths.

Cura has had per model settings for quite some time (since 2.1), but we've never supported multiple layer heights. This is an intentional "omission". Having multiple layer heights makes the slicing process orders of magnitude harder. It's doable if you only use magnitudes of a layer (eg; one object with 0.1 and the other with 0.2), but even that would require large parts of our architecture to be re-written and a load of extra features to be added.

Well, it does make the outside world influence your prints less. If your printer is sitting in a drafty area, you will notice the difference.