ctbeke

The formula is layer_height / tan(steepest_slope_in_layer) <= threshold. So the threshold value is compared to the potential layer height divided by the tangens of the steepest slope in the potential layer. In this case an angle of 0 is a horizontal flat surface and 90 is a vertical surface (i.e. the steepest possible slope). The 90 degree offset is there to make sure the algorithm works in the right direction for the threshold comparison. Code details: https://github.com/Ultimaker/CuraEngine/blob/master/src/settings/AdaptiveLayerHeights.cpp#L158.

You shouldn't be able to click "save" or "print" though when it's not sliced.

On the printer overview page you can set a printer to "Set to unavailable". It'll finish the current print but not take any new jobs after that, allowing you to do your maintenance until your release it again.

Cool Yeah, this is why I left the somehow hard to explain threshold parameter in there, the results are very different per geometry.

I think it's due in about 3 to 4 weeks. Don't pin me down on it though, I'm in a different team.

Omg you're totally right, it's the other way around. My bad, brainfart. So it tries to access the G-code before it's generated (or correctly stored in the Scene). I'm not sure why though...

Just started a PR to add this functionality (https://github.com/Ultimaker/Cura/pull/3187). It's in my spare time, so I don't know how long it'll take to finish yet.

How to help us solve it: 1) Share logs 2) Share project files 3) Try the latest beta (3.2) and report any changes to us. Anything else (e.g. just commenting that it's slow) won't help us and everyone move forward towards a solution. Thanks!

G-code list is new in Cura 3.2. Are you using a plugin in 3.1 that's intended for 3.2? (for example the OctoPrint version that was moved to the plugin browser?).

Yup, that's because it's very hard to implement. This is just a start to see how to move forward from here. With multiple models it's almost impossible as the layer heights are different per model then, which could cause a collision with the print head. In short, this was the most I could do in ~4 weeks without having to rewrite the entire CuraEngine

Correct. You just need to sync once after unboxing. Connecting it to your phone's WiFi hotspot could be a quick way of doing that. Edit: over time it might be offset slightly (since time-keeping is hard), but then just re-sync and you're set.

Not on the roadmap I think. Is there a reason your UM3 is not allowed to connect to the internet (even just once) to sync the date and time with a timeserver?

Next version of Cura Connect will allow printing without override if the material type is the same (so no brand-checking). Until then, use the override feature in the Cura Connect web UI, or select a different material in Cura that matches the one the printer thinks it has (generic PLA?).

The community event is 23, 24 and 25 February indeed. Both @ghostkeeper and I will be doing a Cura session on the 24th (one about post-processing scripts and one about writing Python plugins). So I guess I'll see all of you there as well

It seems the model is not entirely flat on the bottom. Try sinking it into the build plate a tiny bit and see if the skirt starts generating correctly.

Those are print quality settings, not printER (machine) settings. I don't know which settings are in the quality profile export by head, but it could be that start/end G-code is not one of them. Anyways, this feature didn't change between Cura 2.x and 3.x.

I think the Cura Connect team is aware of this issue, if not I'll alert them. Just a remark: it would be better to file this issue on https://community.ultimaker.com/forum/109-firmware/, as that's where the bug actually is, not in Cura or any plugins. Not all teams check all community sections.

I'm not aware of such a feature in Cura 2.x or 3.x releases. Are you referring to Legacy Cura (15.x and earlier)?

There was a bug in Cura 3.0.4 and 3.1 when using post processing in combination with the network printing (for UM3). These are fixed in 3.2 (Beta due in 1 week). This should solve your issue. In the mean time you can try exporting the G-code to USB and print over USB (as a test). If that also doesn't work there's another bug that we don't know about yet. For reference: https://github.com/Ultimaker/Cura/issues/2855

Great to hear it's solved!

Cura already has this, it's called support interface in the settings.

Nope, plugins are now full Python code plugins. More details: https://github.com/Ultimaker/Cura/wiki/Plugin-Directory.

I'm not sure if colouring/dual extrusion is in the STL specification (I don't think so, that's why multiple STL's are used to solve this in most softwares). A better solution would be to use the 3MF container format, which supports this in it's specification, and also Cura supports it.

This is an issue in the way that Fusion360 calls Cura. Cura has a --single-instance flag that can be used to solve this. Best would be to contact the Fusion360 developers. For reference, a similar GitHub issue: https://github.com/Ultimaker/Cura/issues/3116 that contains a workaround.

Thanks for suggesting this! As it's not really a core feature I don't think the Cura team will implement it anytime soon. You could however make a pull request on GitHub to add the functionality yourself. Have a look at the image importing plugin to start: https://github.com/Ultimaker/Cura/tree/master/plugins/ImageReader.