ahoeben

If the memory usage is growing while it is just "sitting there", it is definitely a memory leak, however small the increase is (and in this case the increase is NOT small). Note that it is not too surprising that when loading a small file the memory use grows by much more than the file size. A file in use in an application can take up much more memory than the file; the file is optimised for storage, the data when loaded into the application is much more optimised for usage, and it can be in memory multiple times, optimised for different usages (eg for display AND for slicing).

Note that the Printer Settings category is only available if you install the "Printer Settings" plugin from the toolbox. Also note that the "Toolbox" has replaced the plugins menu.

Thanks for testing. Hmm, that's a bug by an off itself. I will make a fix for that. In the mean time, we can still test the hypothesis of the camera feed leading to the memory leak. In the OctoPrint settings, on the Webcam & Timelapse tab, could you clear the Stream URL field? Then restart Cura. I know this is in no way a solution, but it is a temporary test to diagnose the issue.

Note that I am not an Ultimaker employee, I am just a guy who purchased Ultimaker printers before, who contributed a fair amount of code to Cura, and who has been fairly active in this community. My views are not the views of Ultimaker, and I am tired of this discussion so I will refrain from further participating in it.

Class names can’t have spaces or dashes; only alphanumeric characters and underscores are allowed.

I have seen a couple of mentions in passing of memory leaks in Cura 3.5 while viewing the print monitor. These mentions were in a topic that quickly ballooned and became ineffective to discuss this particular problem, so let's try to get to the bottom of this in a thread dedicated to this issue. It seems the problem may be shared between Cura Connect and OctoPrint. This would not be strange, because they use a lot of the same code. @kmanstudios mentioned it here (I can't find the original report he mentions), and afaik he does not use OctoPrint. https://community.ultimaker.com/topic/24675-new-ultimaker-cura-35/?do=findComment&comment=221744 @StefanoCAD also reported a memory leak and seems to be using Cura Connect https://community.ultimaker.com/topic/24675-new-ultimaker-cura-35/?do=findComment&comment=221232 Both @Adam324 and @nbJosh report a memory leak with OctoPrint https://community.ultimaker.com/topic/24675-new-ultimaker-cura-35/?do=findComment&comment=221686 Note that in my cursory testing I cannot (yet) reproduce the memory leak with the OctoPrint Connection plugin. But I am just a single 3rd party developer that does not have a testing team, so please bear with me. Because the memory usage increases so quickly, the camera feed is - to me - the most likely candidate for causing the leak. The code for displaying the camera feed is also shared between Cura Connect and OctoPrint. For the OctoPrint Connection plugin this hypothesis can be tested fairly quickly by turning off the camera feed. Adam324 and nbJosh, as a first step in narrowing down the problem, can you try if the memory leak still occurs after you go back to the "Connect to OctoPrint" dialog and uncheck the "Show webcam image" checkbox?

Settings Guide is a plugin, and needs to be updated seperately

But one of those plugins is provided by... Ultimaker.

Glad to see you got it working, and sorry for not reading the message box; there's a very similar message that does not mention the per-model settings, and I assumed that you got that one.

Now you're acting as if Ultimaker employees came into your house and killed your cat. Noone is telling you you have to do anything; you don't have to test beta versions and you don't have to upgrade to Cura 3.5. Cura 3.4.1 - though not perfect - still works, right? If you have removed it from your computer, you can still download it from software.ultimaker.com I am all for more testing, and not releasing a "stable" version before it is proven stable by internal and community testing - instead of releasing because it is that time of the week - but lets not make more of the issues found in Cura 3.5 than what they are.

You recall incorrectly. There never was such a distinction between two versions.

On Github they also wrote workarounds for 3.5.0

It should. Please start a separate thread about that.

The only thing that does (if it works) is opening a webbrowser to https://ultimaker.com/en/products/ultimaker-cura-software So if downloading Cura from that page is what you call "installing as a new version", there is no difference between that and "upgrading".

Normally, only bug fixes are allowed in after a beta release, but this time some exemptions seem to have been made for Cura Connect changes. The settings guide is a plugin, and simply wasn't made available during the beta phase.

That may be true, but a fair amount of code was added after the release of 3.5.0-BETA that was not community tested; both the Settings Guide plugin and part of the Cura Connect rework was added after the beta was released, and both of these "break" with the dark theme. Perhaps having a second beta and/or one or more release candidates would be a good idea.

Nobody has said that as far as I can see. Seems you said "that".

That may be how you do it, but it is not the way the Cura team envisions you doing it. Upgrading the previous configuration should just work, and if it doesn't it should be reported so it can be fixed.

It could be that your Matrox GPU is simply not capable enough. Matrox is not known for their 3d performance, and Cura needs some 3d gpu support.

I think it may be broken for some people (configurations).

@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)