ahoeben

On many printers (eg UM2(+)), you can effectively change this setting in the firmware, hence my not needing it in the slicer. I'll look in to the gcode.

Could you add a screenshot of the message? Slicing should not require per model settings, and I can't think of anywhere in the code where such a message is created.

The plugin could very well be broken; it is one of those things that I made because it was so often requested, but that I don't actually use (or need) myself. So keeping it in a working state depends on feedback from users like you. Could you save a gcode file with the zoffset set to a non-0 value, and check if it contains the string "ZOFFSETPROCESSED"? If so, keep searching, for ";adjusted by z offset". This would mean that the plugin is doing something, but possibly at the wrong location.

The plugin is available in the Toolbox as "Mesh Tools".

I would say that printing laptop keys is very ambitious. The required details, flexibility and strength will be very hard to achieve with FFF printers. If this is a first project with 3d printing, I would highly suggest starting out with something simpler.

Ik geloof dat de Ultimaker Original een thermocouple gebruikt, en de UMO+ en UM2(+) een thermistor. Die moet je verschillend "uitlezen".

Sorry, wrong again. The legacy Cura would do the same thing especially if you set it to automatically detect the serial port (instead of manually setting the port). The difference is that in the legacy Cura, it was possible to manually specify the serial port to use, and it was possible to upload firmware to a serial port that was not recognisable as a printer. Something that also changed is that the legacy Cura did not try opening the serial port until printing was started, so it would not reset connected printers by merely starting the application.

Wut? I see no such change in the code in Cura. Cura still opens every serial port it can find, and the mere fact of opening a port resets the printer. There is no way of communicating with the printer over the USB cable without resetting it.

Also tell us if dropping the file into the Cura window, instead of using the File -> Open menu, opens the file without a crash.

You don't. The idea is that Cura takes the configuration from the last version and upgrades it on the first launch of a new version. Is that not what's happening for you?

Cura 3.5 has made it easier to change a single extruder definition to a multi-extruder definition, by requiring an extruder definition for the single extruder. * Make a copy of the single extrusion definition (creality_cr10.def.json -> creality_cr10_dual.def.json) * In creality_cr10_dual.def.json, change the name metadata and "machine_extruder_trains" metadata: { "0": "creality_cr10_dual_extruder_0" "1": "creality_cr10_dual_extruder_1" } * Now you need to create those two extruder files: * Copy extruders/creality_cr10_extruder_0.def.json -> extruders/creality_cr10_dual_extruder_0.def.json and extruders/creality_cr10_dual_extruder_1.def.json * In extruders/creality_cr10_dual_extruder_0.def.json and extruders/creality_cr10_dual_extruder_1.def.json, change the id, and under metadata change the machine and position (position should be "1" for the second extruder).

Note that as far as I know, this change is unintended. IE: this is a bug (with a workaround). The 210 value that is being used now is from the "global" stack, instead of coming from the "extruder" stack. As you can imagine, printing temperatures differ per material, and because different extruders can have different materials, and different extruder print at different times, the extruder temperatures need to be defined "per extruder". However, the bed can only have one temperatures, and that is stored in a "global" setting (which is evetually calculated from the values specified per material, so per extruder). It seems that in 3.5 the material_print_temperature is taken from that global set of settings, instead of taking it from the extruder set of settings. With the {... , 0} syntax (which was introduced in... 3.1 I think), you force the value being taken from the first extruder.

There are many more ways to screw up a print from the start gcode (you could also set the units to inches, for example). Cura does not parse the start gcode (with the exception of {replacement patterns}, it just passes it along to the printer. You should know what you are doing when editing the start gcode.

You can specify the extruder number in the replacement pattern like so: M104 S{material_print_temperature, 0} T0 M104 S{material_print_temperature, 1} T1

You can run them side-by-side. If 3.5 is not working out for you, you can switch back to 3.4. Cura 3.5 does not change your Cura 3.4 configuration, it just makes a copy of it (and upgrades that copy).

From a cursory look, I can see that there was a postprocessing script active: "Post stretch script". I'll have to check later if that could cause big delays.

? Sorry if I came across grumpy.

It would have been more helpful if you had backed up those files in AppData/Roaming. Now we'll never know what went wrong, untill someone else runs into the same problem.

No, this needs to be fixed in inventor too. When exporting, your perfectly round cylindrical walls get converted into polygons. Polygons (triangles) have no curves; polygons can only approximate a curve. By the time the model is loaded into Cura, there are no curves, only polygons. The more polygons are created, the more precise the approximation of the curve. Somewhere in inventor, there has to be a setting for the precision of exported models.

And what I am saying is that your understanding is wrong, and I would suggest (again) that these texts are checked by engineers who pick out the crap. The original line, as it is in the Changelog is: " A 3MF extension is now used for project files. The ‘.curaproject’ extension is no longer used. ". The "better compatibility with 3d software applications" is just incorrect embellishment. There was an issue on OSX where Cura would create confusing filenames. That was fixed.

It is the former. The ender seems to be treated as a machine compatible with 2.85mm materials, so those are listed.

Do you perhaps have (m)any postprocessing scripts active? Does this also happen if you save the gcode to another drive (eg to your desktop)?

Note that though it is best to learn to create proper models, you can get Cura to slice this particular model the way you probably intended it. Find the setting "Union Overlapping Volumes" in Mesh Fixes (you can use the Search on top of the settings) and uncheck it.

You did not model it with inverted faces, but probably with too many walls. This happens when boolean operations go wrong, or there was no boolean. I don't know enough about your specific model or inventor to be sure.