nallath

If I import it, the profile works. Could you also share the log files?

Could you also share the profile and the log files? You're not providing us with enough information to help you.

Yes; Upgrade your windows. Windows 7 is no longer supported by Microsoft or by us.

Please post feature requests on https://github.com/Ultimaker/Cura/issues

Try the Cura Arachne beta. It's specifically developed to solve issues like this.

Please provide log files. We can't help you without them.

The settings are calculated based on whatever the printer you selected has setup. So every printer can have a different way to calculate the ratios of these settings.

Since windows 7 isn't supported by Microsoft for quite some time, other software libraries (including the ones that we use) have also stopped supporting it. As such, we can't guarantee that Cura works on windows 7 anymore. We officially no longer support it.

The instructions already tell you to tell cmake to not use debug mode (-DCMAKE_BUILD_TYPE=Release). You need to doublecheck that that is in the command line option when building it

Uh. Theoretically, yes. If you run the machine in dev-mode, you can just ssh into the machine. The base OS running on the printer is debian, so as long as the firewall runs that you could do it. But maybe it's a good idea to get into contact with one of our application engineers about this. This is not the first time that they have had to deal with strict company IT policies, so they will be better able to suggest possible solutions.

Well, if it cna't run opengl 4.1 it automatically sets it to be in compatibility mode. The preference item just enables you to force the behavior. I've never had to do that, so i dont know of a set of instructions that would work. So i would just google something and give that to you.

Uh, you should be able to set that in your operating system. Cura will just use whatever the OS tells it to use.

Sounds like an issue with the printer.

Are you logged in with an enterprise account?

No worries; We see pretty much the same issues as you. But as you might understand, people within Ultimaker can't say anything about what the next products or steps will be outside of official communication. That is also the origin of the lawnmower joke; We can't say anything less we risk that people read too much in other things that we say.

it's been in development for almost 7 years now. It's going to be the lawnmower to end all other lawnmowers

What does clipper need in the start g-code? You might be just able to do that with replacement tags

I don't understand what you mean. If you print a tube, the walls exposed to air on the inside are considered to be outer walls. Do you have a project file + image that shows the problem?

I double checked it, we did switch. We're now building on debian buster. But that is also what your mint version is based on... It seems that you're not the only one with problems like this: https://unix.stackexchange.com/questions/653465/how-to-install-glibc-2-28-on-linux-mint-19-3-cinnamon

More reliable than the previous two releases of the Arachne engine. But since it's such a massive change, I expect that there will be issues that we haven't found yet. That's also why we release so many beta's for the rework; We need people to stress test it. I understand that people might be a bit wary of using a beta release, but it's a bit of a catch 22; It only gets to stable if we have enough people testing it. That being said, even though it does have some cases where it produces somewhat suboptimal results, in most cases it will be at least in the ballpark of what the current engine does. In quite a few cases it's better. I've heard from multiple people that they have completely switched over, even though it's still in beta.

Well, you could also try using another application to actually view the g-code. I think that it's likely that the g-code that cura produces is correct, it's just that the re-loading of the g-code has some issues with it.

Uh, well. We generally use layerheights below 0.5 mm. Even though I don't see a reason why this wouldn't (at least theoretically) work. My guess is that the g-code parser has an issue with too large layers. As you might imagine, it's not something that we test 😉

Not as far as I know. I just double checked the appimage and the 14.13.1 it works on my machine. Appimages shouldn't use anything but what is in the image itself...

You might want to try Cura Arachne. It's much better at slicing features like that.

True. If you want the most out of a printer like that, it's probably best to start off from scratch. But the results that you get from this are pretty decent, even if somewhat limited. I do think it's less work to get to something usefull out of this than it would be to write a 5-6 DOF slicer from scratch though.