ahoeben

Just to be sure it is not model-specific, can you post a link to a 123D Design model that exhibits the crash? Please go to Help -> Show configuration folder and locate cura.log. Now let Cura crash (by loading the model), and post the cura.log somewhere we can download it.

What version of Cura do you use? On what OS?

Cura only adds that heating sequence before the start gcode if it sees that you don’t have heating commands in the start gcode snippet. If you put M109 S{material_print_temperature} in your start gcode snippet, Cura will not have to add extruder heating by itself. Same with M190 S{material_bed_temperature} fir the bed. You could also use a postprocessing script to modify the gcode.

Without looking too much into the rest of the code, you are looking up the stacks in the __init__ method. That method gets called when the PostProcessing script discovers the available scripts, which might be before Cura has finished loading the printers from your configuration. Even if it worked, the information would also be incorrect once you changed to another printer in Cura. Don't do postprocessing things in __init__, but do them in execute.

Check cura.log in Help -> Show configuration folder. Search for the id (filename without .py) of your script, and it should give you a hint about why it is not loading. If not, I'm going to have to see the entire script.

A cause for a memory leak in both OctoPrint Connection plugin and Cura Connect has been identified. I have created a workaround for OctoPrintPlugin. If my workaround works without (too many) sideeffects, it can also be applied to Cura Connect (with some more development work). A testing version of OctoPrintPlugin with the workaround can be downloaded here: http://files.fieldofview.com/cura/OctoPrintPlugin-v5-2018-10-25T13_58_45Z.curapackage After downloading, drop the file into a running Cura application and restart Cura. It would be nice to hear if this fixes the memory leak for you when using the OctoPrint Connection plugin. If it does, I will release this version via the Toolbox. NB: the fixed OctoPrintPlugin will not change stability or memory issues with Cura Connect or any other part of Cura, except the OctoPrint integration.

I use Arduino 1.8.2 on Windows, and have no such errors.

Next time, feel free to use the "Code" formatting to format your post, or better yet: omit such long pastes, and use something like pastebin.com and post a link here.

Unless you want to do lots of development on Marlin, there's no need to install sdl, mingw or codeblocks. You can just install Arduino and load Marlin.ino (from the Marlin folder). Select the board that best resembles your controller board (Atmega 2560 is fairly common) and go to Sketch -> Export compiled binary. Two new hex files will be created in the same folder as Marlin.ino.

Have you tried using an IMG tag instead of a VIDEO tag? <img src="http://yourprinteraddress:8080/?action=stream" />

This thread has lost its use to me. Bye.

NO

If you want this to become another thread about different issues with Cura 3.5, that's fine with me, but then it looses its function to get to the bottom of the particular issue of the memory leak in Cura Connect and OctoPrint. Cura creates one icon in the system tray when it is started. When it is stopped cleanly, it removes the icon. If it crashes, the icon stays there, until you either log out of windows or you happen to mouse over the icon. There is no way that one instance of Cura creates more than one of these icons at a time. The 12 icons in your screenshot mean that Cura closed before cleaning up the icon 11 times since you last logged in to windows. It may not have been a very visible crash, it may have been a fairly silent crash while Cura was closing down. But it was not a clean closing of Cura. Yes, something is amiss, but no, this has nothing to do with the memory leak I am trying to investigate. Thanks for reporting it though.

That is not related to the memory leak. This happens when Cura is not closed down correctly; If Cura crashes, the icon does not get removed. When Cura is then restarted, a new icon is added. It is very untidy (of both Cura and Windows), but not the issue at hand here. PS: sorry to see you had Cura crash on you 11 times.

Ja, de UMO+ heeft dezelfde z-stage als de UM2(+), en daar wordt een andere leadscrew gebruikt.

Ultimaker only publishes the appimage on software.ultimaker.com. It is up to other repositories to pick it up. Some choose to repackage Cura, some choose to distribute the appimage.

It would be good to know if the CuraConnect memory leak also relies on having opened the Preferences dialog.

Today I can reproduce the issue with the camera feed display for OctoPrint. Some pretty weird stuff is going on; for me the memory leak stops when I open the Preferences. Not only does the leaking stop, but I get all my memory back, in a couple of steps. As in: the memory used by the Cura process goes back down. It looks like memory is being released but garbage collection does not kick in until the preferences are opened. I tried opening other windows too, but so far I have not been able to find another window that also releases my memory. Weirder still, I am finding out the memory leak only happens on a freshly started Cura after opening the Preferences window in the first place. It doesn't matter what page either. prerequisites: * have Cura, OctoPrint and camera feed configured and working steps to reproduce * start Cura fresh * go to monitor tab and observe camera * check memory usage (in my experience it stays stable) * open and close the preferences dialog * check memory usage again (in my experience it has now starts ballooning) * wait a couple of minutes and see memory use go up * open the preferences dialog again (in my experience the memory usage drops down, in a couple of steps)

@drayson please clarify. Same as what?

Why are you asking “us”? Ask Elementary OS!

Unless the memory use is steadily climbing without apparent reason, let’s not make this thread a “my Cura is using N amount of memory” bidding war. Loading objects, slicing them and showing layerview are expexted to be very memory intensive When responding in this thread, please mention if you use OctoPrint or CuraConnect.

Note that if you use OctoPrint, you don’t have to keep Cura open for days.

The problem with small circles like this is is that the extruder changes direction quite abruptly at the en of the circle. Unless the buildplate adhesion is very good, the nozzle yanks the last bit of extruded material along with it, resulting in a non-complete circle like this.

That is usefull info, and might mean there are multiple leaks/mechanisms; the OctoPrint leak seems to happen on the Monitor tab only (if it happens)

Was it open on the Prepare tab or on the Monitor tab?