ahoeben

@Link it might be a feature of the tinker firmware, it has been a long time since I used the stock firmware.

You can write a plugin that detects the use of that head (a variant?) and then applies the gcode postprocessing if needed. The Z Offset plugin (https://github.com/fieldOfView/ZOffsetPlugin) is an example of a plugin that applies gcode postprocessing of its own, but it does not include a check for a certain variant. If you are not afraid of Python code, here's a much more complex example of a plugin that checks for certain conditions before executing filters on the gcode: https://github.com/BlackBelt3D/Cura/blob/bb-3.4/plugins/BlackBeltPlugin/BlackBeltPlugin.py#L293

That's sketchup, not sketchfab.

A memory leak, especially one that reproduces this easily, is a serious issue. Though I appreciate the thought of not being negative to developers, be vocal about issues like that. Don't think that someone else will report it or that it will be fixed in the next stable release; if it does not get reported, it may go unnoticed by the developers. I am the creator of the OctoPrint Connection plugin, and this is the first I read about this. A message in this thread may easily go unnoticed by developers. If you find something that is clearly broken and that you have not seen reported before, please log an issue on https://github.com/ultimaker/cura/issues. You may want to check there if the issue hasn't already been reported. If going to github is too much for you (I know, you just want to print), feel free to start a new topic about serious issues, instead of your issue being snowed under in a thread like this.

Thanks. This message says nothing about “per model” though; it tells you that there are errors in some setting values. These settings may be “hidden” in your sidebar, but that does not mean they don’t have an (illegal) value. Use the search in the sidebar to look for the setting, and make their values legal (eg prime tower location has yo be inside the buildplate, whether a prime tower is printed or not)

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.