nallath

The default is that certain things (such as adhesion) are printed with the first extruder, so only switching the one object you're printing to be printed with the second extruder is indeed not enough. The fastest way to print with only the second extruder is indeed to disable the first one.

I know that https://www.leolane.com/ is working on this, but i doubt that it will actually work. It's quite simple to bypass these kinds of security measures and still get a copy without the protections in it.

If you put the machine in dev mode, ssh to it, you need to edit the settings in the following file /var/lib/griffin/printer_preferences.json

As far as I can see, there is no real point in that field even being there, so you can probably just ignore that.

Just upgrading the version number of that plugin should do the trick. I've tried to see if I could find some documentation that I can provide that provides a bit more imidate gratification. A fair bit can be found on https://github.com/Ultimaker/Cura/wiki/Definition-Files-Explained From there you can see that machines can define a number of things it actually supports. As there is quite a bit of things a given machine can say it supports, it's a bit tricky to give a single answer. The settings itself are organised within stacks; You have 1 stack for each extruder, which is always "above" a global extruder. Each stack has a set of containers inside them (profiles). The profiles are currently in the following order; User, User Changes, quality, material, variant, definition_changes and definition. So if a machine doesn't have specific profiles for material and you change the material, the quality will remain the same (and only the material container is actually changed). In the case of the UM3, if you change the material, it will also change the quality (it will still be the same type (eg; "fine", "normal", etc)), but it will go form fine_pla_0.4aa to fine_abs_04aa

There is no simple explanation because the simple is far from simple. Depending on what the printer states, profiles can either be generic or for a specific printer. If you want to look under the hood of what Cura actually does with all the settings, I recommend looking at the godmode plugin made by sedwards2009 (you can find it on github)

The PID controller doesn't like extremely frequent temperature changes. It could be that that is causing some issues? Other than that, you could also just tune your PID to be less aggressive.

Well, for prime tower it will be in the 4.1 release. As for support, the issue is on our backlog, but as usual there is too much to do with too little time.

For an Ultimaker? There is just enough power to do so, but due to tolerances, it can happen that there is not enough power available (thus causing a shutdown). There is of course also the issue of oozing, but this can be fixed with a prime pruge.

You should contact your reseller. They should have access to SD cards that you can use to re-flash the firmware. Alternatively, you could also try to see if the slowness is gone if you don't connect the printer to the network (which is probably best done by temporarily blocking it in the router) There isn't much other advice I can give you, as the factory reset is only accessible by the menu.

A single object has a poly limit that is in the ballpark of millions if it's an STL (because the implementation that we use to load STLs has that). Without actually seeing the object, it's hard to say what is causing these issues. Could you share an example?

I've seen this bug before. Unfortunately, the only way to fix it (apart from diving in deep and removing the faulty data in the history that caused it) is to reset Cura Connect.

Well, we've had no such reports for any of the dual Ultimaker printers, so I'm guessing it's a profile/configuration issue. Since we don't actually maintain the profiles of third party printers (we only check if they don't break anything in Cura, not if they actually produce decent prints), there is not much I can help you with.

The point with quality profiles is that there can only be one given the quality type, variant, material, and machine. As we already provided quality for fast (For PLA, for AA04, for S5), you essentially override it if you put something in your quality folder. I'd recommend installing the god-mode plugin https://github.com/sedwards2009/cura-god-mode-plugin if you want to mess around with settings a bit more, as it provides a pretty good insight into what Cura is actually doing (and what makes Cura give the values that it gives)

Well, release branches tend to be much more stable so it should be pretty doable to release those.

We have nightly builds, but those are meant for internal release. I will discuss this a bit with the rest of the team, because i do think there is value in providing nightly builds (Although these do come with absolutely 0 guarantees with regards to stability, as they haven't been tested). You're not the first to think of this. I'm a big, big fan of this feature. I've tried to re-implement the algoritm as proposed by https://gfx.cs.princeton.edu/pubs/Luo_2012_CPM/ during a research sprint, but two weeks turned out to be not nearly enough to get to any functional state. I'm trying to get a (computer science) student to do a master thesis on this, so if anyone knows someone who is interested, feel free to send a resume.

Yeah, that's why I contacted a few people within Ultimaker, but we don't have any admin accounts, so it's not like we can remove it. I'm not quite sure when it was sold off, but it was some time ago.

Well, it's not Ultimakers problem, but it's still nasty that it's out there. I'm also not that sure it's illegal to have in the Netherlands though (youtube, for instance, is filled with videos on how to make guns in a home shop).

I've asked around to find out what to do with this.

You need to remove the disallowed areas from the .def.json file, but I wouldn't recommend doing that. This greatly increases the chances of destroying the nozzle.

For what it's worth I talked to my lead (although it was a bit awkward to talk to myself like that...)

To be honest, I still don't understand what you mean or how this would solve any of the aforementioned issues. But feel free to have a look at the codebase and suggest how it can be changed. I think that will have more actual results than popping generic advice that may or may not be applicable to the situation.

The one way I can come up with that would to do that is to use the register function as a factory (eg; Check API version, return different object depending on the version). But that's far from ideal.

You are aware that entry/exit logging is for crashes (and thus, does absolutely nothing when the software hangs), right?

I know. But I kinda like the new design. Mostly because I know most of the settings by heart, so I just use the search function. So he's essentially making the same "mistake" we had in the first design; assume that everyone uses (or likes to do atleast) software in exactly the same way.