nallath

Uh. Those are just cached / compiled files. We could disable that, but then Cura would run a whole lot slower. Also, there is quite a bit of logging in Cura already, but although logging helps, it isn't some magic tool that miraculously enables us to fix all issues. If only that were the case.

Some materials are a bit strange when you extrude them. If you ask for 100 (whatever the unit is, doesn't matter), some materials only extrude 96 (or something like that). This is mostly an issue for machines that have flow measurement (Such as the S5). There are basicly 2 things that you can do to fix this. If you don't have a flow sensor, you "simply" pre compensate for this factor. So instead of asking for a 100 if you want 100, you ask for 105 in order to get a 100. The problem with that is that if you have a flow sensor, it will give a warning (Because you asked for 105 and got 100, which should be seen as underextrusion). Those two settings are meant to be used to solve this problem.

Well, none of the devs can reproduce this stupid bug. If we can't reproduce it, it's almost impossible for us to debug it (and also know if we actually fixed it). Getting angry or typing in caps, although I guess it's probably nice to get it off your chest, isn't going to change any of those things, unfortunately.

Yeah, this was a stupid oversight on our end. I'm now changing the way Cura loads plugins so it's possible to have a single package / plugin be able to support multiple Cura versions (thus not forcing plugin devs to select a single Cura version that they publish their plugin for). Sorry for the confusion / issues about this.

You mean like we're already doing? Uh, okay. No need to block anything for that.

I'm totally in favor of this not being a plugin though. It makes sense for this to live in the "mainline" Cura code. So if you're up for it, make a pull request.

Theoretically? Yes. In practice? Probably not. The whole story is a bit complicated I'm afraid.

Youmagine isn't being run by Ultimaker anymore. Just sayin.

I totally understand that stuff gets talked over with the community. That's fine. But to be honest, I don't have the time to get engaged with those discussions, mostly because linux is already such a small part of our user base (and i also realise that there is no way in hell that you can get everyone happy). In the past, Ubuntu suddenly dropped support for python 3.4 in favor of python 3.5. Unfortunately at that point we really really depended on it. Which caused a bunch of extra work that we basically never have to do for the appimages. As far as the plugins not working, it might have been a bug once, but it's working just fine now.

I've also shared this with our UX designer. So it could be that we're going to borrow some elements from this.

We don't have any way to do FEA and as far as I know, solid works doesn't have the know-how to do it even if we were able to provide the internal geometry. You would also have to take the speed of the printing (since this also affects the adhesion between layers) into account, which isn't something that's done right now.

I don't expect us to port Cura so that it can be run on a Raspberry Pi any time soon.

I'm running it from source, which has a number of changes not yet in the released beta.

We stopped with the .deb file packages because they were causing too many issues for us (we switched to .appimags). There is a PPA out there for Cura, but I don't know how well that is updated.

I've just tried to reproduce this with the latest 4.0 code, and it seems to have already been fixed.

Nope. We've done some experiments with this, but it caused quite a few issues with a lot of models, so it was abandoned at some point (mostly because the actual advantage wasn't that great, to begin with)

There is a plugin that handles this. It's called something like z offset.

The errors have nothing to do with the USB printer not getting connected.

The weight of the heads is different, as is the internal geometry of the hotends / nozzles. This means that in order to get the same level of quality, settings need to be different. Usually this means that we have to tweak the acceleration / jerk settings, which will in turn influence the print time.

Marking them as a favorite is already possible.

We used to be on deb packages, but it was a complete nightmare. Mostly due to Ubuntu, which has a dreadful history of suddenly no longer supporting dependencies. Why would you need to hack anything to get plugins to work? You can install them via the marketplace or just place them in the ~/.local/share/cura/4.0/plugins/ folder. As for the corruption thing, could you share your logs / local configuration?

As far as I can see, no-one contributed a profile, so it won't be in the next beta.

Nope, that's not possible.

They are cfg files as created by the configparser of python. I don't have a regex for it, but parsing it with the configparser is pretty simple.

The beta2 for 4.0.0 isn't out yet. The beta is indeed intended for those that want "bleeding edge".