ahoeben

Das hat sich nicht, und soweit mich bekannt gibt es kein Plugin für das.

There is another workaround, which is to disable only the explorer thumbnail created by Chitubox. This workaround is outlined here: https://support.ultimaker.com/hc/en-us/articles/4402996140946-Ultimaker-Cura-crashes-when-opening-any-file

Do you use the {speed_travel} replacement pattern in your start gcode? If so, don't. Cura inserts the number that is configured in the interface, which is specified in mm/s. Marlin expects the number to be in mm/min. So the number that gets inserted if you use {speed_travel} in your start gcode snippet is 60 times lower than the number that you would expect.

There is very little we can see in the gcode. Please post a project instead (File -> Save project...)

Part of the cool-down process can be shortened using the (unofficial, use-at-your-own-risk) UltiTuner tool:

That's sad to hear. If you do, be sure to offer it up as a "semi-working 3d printer", as I am sure someone will be able to make it work still.

Thanks for letting me know anyway. I never got confirmation in that issue that Auto Select was the culprit.

Actually, those links would have downloaded the correct versions of the files, if you would not have skipped all the manual build steps. But I am glad you got something working now. Just know that what you have working now is (apparently) >2 years old.

I stand corrected.

What resources repo exactly? The CuraEngine you are using seems to be version 4.8. You would need to use a version of fdmprinter.def.json and fdmextruder.def.json that matches this version. https://github.com/Ultimaker/Cura/blob/4.8/resources/definitions/fdmprinter.def.json https://github.com/Ultimaker/Cura/blob/4.8/resources/definitions/fdmextruder.def.json

There's an application running on the printer called mjpg-streamer which hosts the :8080 page and the camera stream for /dev/video0. You would have to configure and run a second instance of that application to host /dev/video1 on :8081. There's nothing on the printer that launches that second instance automatically AFAIK.

Some people experimented with "socks" around the nozzle in the past: Having said that, it has never really been a problem with any of my Ultimaker printers sofar, but maybe I am just lucky.

From your earlier list, I don't see an obvious problematic plugin. I have not tested with any of them (apart from Virtual Printer, which is a bundled plugin). I am very interested to know which plugin turns out to cause this issue.

It is hard to know what we are looking at without seeing the model and your print settings, but I blame your model. It may not be "manifold", which confuses Cura. https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/troubleshooting/missing_parts.md#non-manifold-meshes If you want a better diagnosis, please save a project and post a link to it here. File -> Save project...

These keywords do not exist as replacement patterns. A postprocessing plugin script could be used to find the data in the gcode and insert that MESH_CONFIG macro from it.

I am afraid that doing this by preprocessing gcode (as opposed to inside the motion planner in the firmware), it will greatly increase the size of gcode files, which will have adverse effects on especially 8 bit boards.

It would help to know if the print does start when you run OctoPrint in safe mode (which basically turns off all plugins): https://docs.octoprint.org/en/master/features/safemode.html#how-to-start-octoprint-in-safe-mode

The cheese was named after the city. It would be extremely painful. For you. (do not mess with stroopwafels)

Beyond the word "stroopwafel", @gr5 does not speak dutch.

What OS do you use? This issue was fixed in Cura 4.12.1. The latest release of Cura is 4.13.1. What version of Cura are you running (you mentioned 4.12.0)?

It is neither. It is an issue with the OctoPrint Connection plugin for Cura, which I am the creator of. This bug has been reported before, here: https://github.com/fieldOfView/Cura-OctoPrintPlugin/issues/233 What plugins do you have installed in OctoPrint?

I'll admit that I don't know much about RRF, but from a cursory look Input Shaping is done mostly in the firmware. The only change that needs to be made (after calibration of the parameters) is adding an M593 gcode command to the start gcode snippet: https://duet3d.dozuki.com/Wiki/M593

They (likely) want to get rid of the cylindrical prime tower, and the supports that extend beyond the model on the left and right side (caused by the Horizontal Support Expansion, which has a default positive value for PVA supports). When using default settings, it may not be obvious for a user why a certain value is set that way. Why is there a prime tower, and why do PVA supports print "a bit wider" than what looks like is needed. Setting values intended to improve (certain) prints may not be obvious to a user and may look unnecessary.

Sorry.

Here's an article for you: https://support.ultimaker.com/hc/en-us/articles/4402996140946-Ultimaker-Cura-crashes-when-opening-any-file