nallath

We have a number of posts floating out and about describing how it's done. But it pretty much boils down to; Have a look how other printers did it. It's a matter of creating a definition file (a *.def.json) file, which describes default settings & properties of a printer.

Could you remove & re-add the machine? I see some issues in the log that should be fixed by doing that. Could you also remove your logs? They are quite big now, so for the next time it's a bit easier if you only have the latest

Could you share the cura log files? You can find them by going to help->show configuration folder and then share the cura.log file.

The speed increase with the project loading is not something intentional. There have been changes there, but those were all bugfixes. I'm glad it's faster now, but i have no idea how this happened. As for print time increase; This is one of the major reasons to update Cura regulary. We constantly improve our printing profiles. Although it's something that isn't noticed a lot, it is one of the major reasons why UM machines work so well with Cura.

Actually, my Raise3D N2 is sitting next to my Ultimaker 2. I've tried to get Raise3D to contribute profiles for their hardware, but they have their own (mediocre) slicer, and aren't interested in Cura support. You could take matters into your own hand and provide us with profiles. That's the beauty of open source

As for the whole custom machine thing; Yes, this isn't tested very well. As you might imagine, we have limited resources to test things and a lot of things to test. So things that are required for Ultimaker printers get a preferred treatment. This is also why we have beta versions; So issues that don't get this treatment can still be found and fixed. So tldr; If you want a better experience, buy a machine from a company that supports Cura development (eg; Ultimaker & Lulzbot)

Aldo's fix was incorporated into the 2.7. It's such a simple fix that i feel pretty safe about it. As for "Cura wants the D" 2.0 issue, it seems like a build system issue. Should be fixable for the release (keeping fingers crossed here)

Cura can't do milling, it's purly for FDM printing i'm afraid.

This is probably going to be very hard. You will probably need to build a whole bunch of libraries by yourself to get this to work. If you don't have experience with this, I would not recommend this. We stopped supporting 32 bit as it took way to much time to support and there were only a handfull downloads.

We kinda designed it to work with PVA. That way you can print a single mold, cast something in it and then disolve the mold. That way, it doesn't matter if the mold can be split (some molds might even need more than 2 splits, so that makes the splitting a bit complicated!)

Damnit. I thought I fixed that. If you disable the WindowsRemovableDrive plugin you shouldn't have the problem anymore.

*Mumbles something about stupid python libraries* I'll go have a look at this. It might actually fix the virus scanners triggering on Cura. Still can't believe that a default python lib does stupid stuff like this. Anyways. It should be fixed now.

Apart from the fact that webbrowser is a standard library of python3, so no-one seems to have an alternative to it. I could move the importing of the module to when it's actually called, so that should atleast limit the issue somewhat.

The only thing I can come up with is that it might have something to do with file extensions, but we never tell cura to open any of those scripts. There is no need for us to do so.

De profielen voor de UM2+ zijn beter als die van de UM2, omdat bij de UM2 er wel rekening word gehouden met het materiaal wat je aan het printen bent.

We actually had a drybox system for the UM3 in the design at some point in time. But it created far more problems than it actually solved. What I understood from our material researchers is that most materials aren't that influenced by humidity.

Ik heb zelf de upgrade nooit uitgevoerd, dus of daar iets fout gegaan is kan ik je niet zeggen. Zelf heb ik wel vaker de switches wat omgebogen zodat op een ander moment de stops geraakt worden.

2.5 also has the "realistic" layer view. Did you try forcing it to be in compatibility mode? It could be that your graphics card doesn't like those new shaders and slows down a lot.

The system is open looped; We don't actually check if the machine actually reached the position where you want it to go. If it's blocked for some reason, you will miss steps, so the position is no longer correct. If you home the head, you do know what the position is. But a switch also has a tolerance, so first moving to (10,10,10), then a home and then moving to (10,10,10) again won't exactly be the same position (but pretty darn close). One of the hardware guys should be able to tell you what the tolerance is.

I wouldn't recommend directly using the USB. The SSH is probably a better option. That way you don't have to break things in order to try something. Software can always be re-setted to defaults

Uh. I'm pretty sure that Cura isn't trying to open a bunch of scripts from third party vendors. Only thing I can think of is that the installer is doing something weird, but for the life of me, i can't imagine why it would do this.

The URI didn't change, so its probably some service that failed to start.

Our first machine the UMO is quite bare bones. It doesn't have a whole lot of things preventing you from doing weird stuf. The further you go to the future (UM2, UM3) the more checks & protections you will find. UM being UM, we do provide ways to avoid them, but doing this on the UM3 is more tricky than on the UMO.

Red means that the area's are overhangs.