nallath

This is one of those bugs that has proven to be a nightmare to squash. Could you guys send me logs (both from the printer & Cura) and information about your OS & network?

I've had pretty decent results with a big cardboard box. It doesn't look that fancy, but it works like a charm.

It is possible to turn of the automatic leveling, by doing a manual level. But why would you still want to measure but not actually use the data that you get from it? In that case it would be better to skip the measuring all together. If you do manual bed leveling, you also manually calibrate the nozzle offset. If you don't move around your printer often or switch cores, you should not need to calibrate all that often.

To play the devil's advocate here; If you want nothing to change, don't update. In this case we could have prevented this change, but there are always behavioural changes, even when no settings are changed. I understand you are annoyed that it's something that directly impacted you, but stating that nothing should change is simply unrealistic. I do agree that in this case it should have been put in the profiles and not in the default behavior. Then again, we would have most likely put it in every profile with pretty much the same result. Adding the temperature isn't all that silly as you think it is. If you read the github issue about this (https://github.com/Ultimaker/Cura/issues/1315) the reasons for this are explained.

Why are you using cura 15.04 for this? If you want really awesome octoprint support (eg; Directly stream from Cura to octoprint) you should use cura 2.x and download the octoprint plugin (https://github.com/fieldofview/octoprintplugin)

Arrow keys are another way to rotate the view. Pressing space + mouse drag also does something like this.

USB printing is supported for the UMO, but that is pretty much the full extent that USB is supported. All others might / might not work. As far as I know, most marlin based printers should work fine with Cura 2 (The UMO is marlin based after all).

I'm guessing that their g-code is created with 15.04 cura (aka Legacy Cura) and that you are using Cura 2.x (Aka "New Cura"). The differences between these two versions are too big to be able to convert. I fear you either need to use the old Cura (and accept the fact that you won't get software updates) or manually convert the values.

Usually if the stream isn't there, it's a hardware issue.

With a bit of post processing magic you could. (add the display message g-code every few lines)

Download the appimage of Cura. Because of compatibility issues we had to use python 3.4, but for some reason some linux distro's decided to remove 3.4 and give no easy option to run both 3.4 and 3.5 side by side.

Sorry, Cura can't do that. You could also display the layer nr on the display if you really wanted to.

Just download the appimage. The PPA is not officialy maintained by Ultimaker (it was created by someone that works for UM though).

You're not the first. This is something we're looking into. Our current focus is improving the speed & improving automated testing.

First off, the settings are definitely not the same. The left print takes 6 hours to complete, the right print takes ~5 hours to complete. Why are you creating a custom machine in the first place? The people from Lulzbot just released a Beta of the new Cura with their machines in it.

I'm not aware of any specific silent installation, but windows isn't my main operating system. We are on the windows store, which if I recall correctly, should allow for an admin to add applications to a machine.

The UM3 uses volumetric extrusion. Most other printers use filament length.

You can change the location of the rendered bed by adjusting the "platform_offset" variable in the .def.json file.

There is no such thing as "the same settings" between multiple slicers. The name of the settings might be the same, but how they behave will have slight (but notable) differences. Especially when you think about the 300+ settings that cura has. A lot of small differences can add up to a very big difference.

Use the CPE profile. It should be pretty much the same in behavior.

The math of the back function lives in the engine, which doesn't have a plugin structure. The beta has a Z-seam-aligment option, which enables you to select a "user specified" location.

Support mesh pretty much means; "Print this object as it it's support". You use it in the per object settings, as you need to mark an object as being the support object.

Zet in de json de has_heated_bed (zo even uit mn blote hoofd, dus niet zeker of het exact die naam is) waarde op true.

There is a pretty extensive API on the printer, but this would require the remote server to poll the printers. You could also make a small service that runs on the printer itself that sends the data to the cloud. All systems on the machine are connected through DBUS, but those API's aren't stable just yet, so the second option will probably require more work / upkeep.

As you guys might have noticed, Lulzbot is also working on Cura 2.x these days. They have already made a pull request that was a bit too late for 2.4 that adds a G-Code reader to Cura. They've also mentioned that they are going to work on better USB controls. FieldOfView also made some mockups for how the jogging / remote control should look in Cura.