nallath

Unfortunately it's not possible to do this in Cura. What you could do is manually add a brim to the model of the large cog.

Could you share the log files?

Because sketchup is very good at making rubbish 3D models. The software is intended to make 3d models that look good, which is can be quite different from a model that needs to be printed. Have a look at the model in Cura when the x-ray view is active. If there are red area's in that view, the model is broken. If thats the case, the 3D model needs to be fixed.

Unless you provide us with more information, there is little we can do to help. Did it generate log files? What is your operating system? Have you installed previous versions of Cura?

Because the AMF spec contradicts itself in certain bits and hardly anyone used it. Because of this we decided that your time was better spent on other formats / features.

It was moved offline due to a bug with support meshes, which could lead to g-codes with no Z values. Because this can wreck your machine, we decided to move the beta offline until we have a new version. We already have a fix for this, so the beta should be back on today. Sorry for the inconvenience.

It was moved ofline as we found a pretty nasty bug with support meshes. These could in some cases result in g-code with no Z values (eg; all layers printed on z0), which can do pretty massive damage to the machine. We already have a fix, so it should be up again today. Sorry about this!

Support mesh -> This mesh is to be printed as if it's support (usefull for manually adding support) Infill mesh -> Apply all the infill settings of this mesh to the intersection of this mesh and all other meshes.

We don't have that. The setting architecture is quite complex. Porting it to the engine would only increase the odds of it going wrong (as we'd be re-implementing a bunch of code in another language). As we don't even use it, i don't think it's likely that we're going to spend time on this. We have a lot more stuff that has higher priority.

The logs output them when a slice starts. You can just copy them from there.

Did you try to play around with the cubic subdivision settings? I've tried the feature myself a few times and in most cases it needed a bit of tinkering for it to work.

Note that the way this works now is not the way we envision this should work. We left it as it is now because it would take quite a bit of time to do it right and we did wanted to let people play with it a bit.

Nope. I mean that using the exact same version of Cura with the exact same settings is not guaranteed to give the same g-code. I doubt it will be noticable (or any change at all) if you do it on the same computer, but different hardware can lead to slight changes.

Uh. try to download a version that isn't 2> years old?

Even then it's not possible to guarantee the exact same results

Soon. Probably won't take more than a month. This is also the reason why I don't let the IT touch my laptop I want software as soon as it's there. Guaranteeing that something will work exactly the way it is working is always a tricky business. But I do agree with the sentiment; the feature only works nice if future version also support it. It is something that we aim for, but it might always be that certain settings trigger slightly different behaviour (aka; I can't and won't guarantee that the g-code will be the same)

Download 2.4, it has project saving & loading. As for loading g-code, Lulzbot created this for Cura 2.x, but it was just too late for the 2.4 release. I expect it to be in 2.5

Uh. No. 2.4 will have some support for it. As for the material support; The um2 handles it's own material settings. As such, you can't set them in the slicer.

Merging a model will only set their origins to be "shared" and then group them.

2.4 will have it again.

We have no official place to do it. But rest assured, i've forwarded this topic to the right people within UM.

It means that this; "bla": {"default_value":10} is allowed. "bla": {}, "default_value": 10 is not allowed. I don't see anything obviously wrong, but why don't you try to keep it as simple as possible first? Try something like "6 if machine_type == 'A'" and see what happens. If that works, increase the complexity.

Move the switch (on the head) so that it's between the two lips of the "calibration bay" in the right back corner of the machine. While doing this, ensure that the switch is aligned in such a way that the second nozzle is down.

A few things that i notice with your json; default_value can never have a python function, use value instead. Things that need to be evaluated by python (such as; 5 if machine_type == \"A\" else 3 if machine_type == \"B\" else 9) need to be enclosed by "" default_value must be a part of a setting. So if you take that into account, the json would be someting like "input_paramA": { "label": "Second JSON", "description": "Beep bop boop", "unit": "mm", "type": "float", "default_value": 5, "value": "5 if machine_type == \"A\" else 3 if machine_type == \"B\" else 9" }

For some systems you can, but it still won't fix the issue if your printer is printing from SD.