Cura running super slow on a really good computer

[GAD 10]

Also just a note - not being able to resize the Marketplace window is infuriating. 🙂

[ahoeben 1,948]

5 hours ago, GAD said:

the Marketplace window is infuriating

It is. It is being replaced entirely by a new implementation that I hope will perform better too. For now it seems to be resizable.

[GAD 10]

Just got back into Cura after three days with only the UM3 Network Printing plugin disabled and it's still quick and responsive, so I do think the UM3 Network Printing plugin is the culprit. I will re-enable and report back, but I'm now convinced that's it. 

[GAD 10]

Cura has slowed to the point of uselessness twice more since my last post, so I definately agree that it's the UM3 Networking plugin that's at fault. 

[ahoeben 1,948]

Now that we've established the UM3 Networking plugin as the likely culprit, if you need that plugin we need to dig a little deeper.

 

If you would like to experiment, open plugins/UM3NetworkPrinting/src/Network/LocalClusterOutputDeviceManager.py in a text editor and change line 62 from
 

    self._zero_conf_client.start()

to

    #self._zero_conf_client.start()

Put the # directly in front of self._zero_conf_client.start(), not at the beginning of the line. The number of spaces before #self._zero_conf... should stay the same.

 

This should disable the zeroconf discovery of printers. Effectively this means that you have to manually add your local printer by its IP address.

[GAD 10]

Assuming plugins is /Applications/Ultimaker Cura.app/Contents/Resources/plugins, I have done this:

 

 61 
 62         #self._zero_conf_client.stop()
 63         for instance_name in list(self._discovered_devices):
 64             self._onDiscoveredDeviceRemoved(instance_name)
 65 

 

I will restart Cura and let you know how it goes. 

 

FWIW my favorite text editor is vi and I've been programming since '1981 and using Linux since Redhat v 0.9. 🙂

 

 

 

[ahoeben 1,948]

3 hours ago, GAD said:

I have done this:

I'm very sorry, I got the linenumber incorrect. I meant line 55, like this:

53:    def start(self) -> None:
54:        """Start the network discovery."""
55:        #self._zero_conf_client.start()
56:        for address in self._getStoredManualAddresses():
57:            self.addManualDevice(address)
58:
59:    def stop(self) -> None:
60:        """Stop network discovery and clean up discovered devices."""
61:
62:        self._zero_conf_client.stop()
63:        for instance_name in list(self._discovered_devices):
64:            self._onDiscoveredDeviceRemoved(instance_name)

 

[GAD 10]

Came back to report that the problem is still there, but I guess that isn't important now. 🙂

 

Changed to this: 

 

53     def start(self) -> None:

54         """Start the network discovery."""

55         #self._zero_conf_client.start()

56         for address in self._getStoredManualAddresses():

57             self.addManualDevice(address)

58

59     def stop(self) -> None:

60         """Stop network discovery and clean up discovered devices."""

61

62         self._zero_conf_client.stop()

63         for instance_name in list(self._discovered_devices):

64             self._onDiscoveredDeviceRemoved(instance_name)

 

Will restart and report back tomorrow. 

 

[GAD 10]

 

 

 

Huh - I didn't even known "Print via Cloud" was a thing. Neat! 🙂

 

 

Edited November 29, 2021 by GAD

[ahoeben 1,948]

You see "Print via cloud" now, because your printer is no longer found by Cura on the local network.

[GAD 10]

15 hours ago, ahoeben said:

You see "Print via cloud" now, because your printer is no longer found by Cura on the local network.

 

I get that. 🙂 I  just thought it was neat that it worked that way. 

 

BTW. Cura's been running for eight hours with no perceivable problem, so so-far so good. Will update tomorrow. 

[ahoeben 1,948]

Good. That further narrows the issue down to the ZeroConf discovery of local printers. This is a third-party module, which has caused issues for some people before.

[GAD 10]

A good 24 hours now with no issues, so I think that's the problem. 

[GAD 10]

On 12/1/2021 at 12:59 PM, GAD said:

A good 24 hours now with no issues, so I think that's the problem. 

 

It's been days now without the need to restart Cura. 

 

So now that we've proven where the problem lies, is there any chance/hope of a cure? 

 

BTW thanks for your help! It's rare to be able to actually help and see where the problem lies. In fact I'd say the last time I was able to do that was with Secure CRT for the Mac back in 2010 or so. It is much appreciated and really helps cement Ultimaker as a good brand IMO. 

Edited December 4, 2021 by GAD

[ahoeben 1,948]

14 hours ago, GAD said:

is there any chance/hope of a cure?

What we could try is updating that 3rd party component to a newer version.

 

First that would require you to undo the change you made (ie: remove the # again).

Next, download and unzip this copy of the zeroconf library: https://github.com/jstasiak/python-zeroconf/archive/refs/tags/0.37.0.zip

Inside that zip, there's a folder named "zeroconf", which contains among other files "asyncio.py"

Replace the /Applications/Ultimaker Cura.app/Contents/Resources/lib/zeroconf with that entire folder. Make sure there are no old files mixed in.

 

NB: I have not tested this myself. If it ends up not working, put back the original zeroconf folder or just redownload and extract the original .dmg file.

 

 

14 hours ago, GAD said:

It is much appreciated and really helps cement Ultimaker as a good brand IMO. 

Just in case I end up disappointing you at some point, please know that I am not affiliated with Ultimaker. I am just a community member, like you. Just one that happens to know a lot about Cura because 5 years ago I worked on Cura 2.3 a bit, and I have written one or two plugins.

[nallath 1,120]

22 hours ago, ahoeben said:

Just in case I end up disappointing you at some point, please know that I am not affiliated with Ultimaker. I am just a community member, like you. Just one that happens to know a lot about Cura because 5 years ago I worked on Cura 2.3 a bit, and I have written one or two plugins.

He's so humble 😉

Anyhow, we ship it with Zeroconf 0.31, so upgrading it to 0.37 might solve the issue. If it does, I'd love to know so we can also fix it in our releases!

[GAD 10]

On 12/5/2021 at 5:04 AM, ahoeben said:

What we could try is updating that 3rd party component to a newer version.

 

First that would require you to undo the change you made (ie: remove the # again).

Next, download and unzip this copy of the zeroconf library: https://github.com/jstasiak/python-zeroconf/archive/refs/tags/0.37.0.zip

Inside that zip, there's a folder named "zeroconf", which contains among other files "asyncio.py"

Replace the /Applications/Ultimaker Cura.app/Contents/Resources/lib/zeroconf with that entire folder. Make sure there are no old files mixed in.

 

NB: I have not tested this myself. If it ends up not working, put back the original zeroconf folder or just redownload and extract the original .dmg file.

 

 

Just in case I end up disappointing you at some point, please know that I am not affiliated with Ultimaker. I am just a community member, like you. Just one that happens to know a lot about Cura because 5 years ago I worked on Cura 2.3 a bit, and I have written one or two plugins.

 

Steps taken: 

 

gad@Mac-Pro lib % pwd   
/Applications/Ultimaker Cura.app/Contents/Resources/lib

gad@Mac-Pro lib % ls -al | grep zero 
drwxr-xr-x@   7 gad  admin      224 Nov 18 07:46 zeroconf

gad@Mac-Pro lib % mv zeroconf/ /Users/gad/Cura-Temp 

gad@Mac-Pro lib % cp -rf /Users/gad/Downloads/python-zeroconf-0.37.0/zeroconf . 

gad@Mac-Pro lib % ls -al | grep zeroconf 
drwxr-xr-x@  17 gad  admin      544 Dec  8 01:39 zeroconf

 

Uncommented the code in LocalClusterOutputDeviceManager.py:

 

 53     def start(self) -> None:
 54         """Start the network discovery."""
 55         self._zero_conf_client.start()
 56         for address in self._getStoredManualAddresses():
 57             self.addManualDevice(address)

 

I have then killed and restarted Cura. 

 

Also, it's too late. I now have expectations and you need to meet them. 🙂

 

On 12/6/2021 at 3:54 AM, nallath said:

He's so humble 😉

Anyhow, we ship it with Zeroconf 0.31, so upgrading it to 0.37 might solve the issue. If it does, I'd love to know so we can also fix it in our releases!

 

Thanks - I'll definitely update over the next couple of days. 

[GAD 10]

Hmm, now Cura won't start: 

 

Dec  8 01:51:56 Mac-Pro com.apple.xpc.launchd[1]: Coalition Cache Hit: app<application.nl.ultimaker.cura.61889478.61889485(501)> [220067]
Dec  8 01:51:56 Mac-Pro com.apple.xpc.launchd[1] (application.nl.ultimaker.cura.61889478.61889485[34555]): Service exited with abnormal code: 1

 

Gonna reinstall and start over. 

[GAD 10]

OK - reinstalled (I love Macs!) and zeroconf updated: 

 

gad@unifi zeroconf % pwd
/Applications/Ultimaker Cura.app/Contents/Resources/lib/zeroconf
gad@unifi zeroconf % grep __version  __init__.py 
__version__ = '0.37.0'
    "__version__",

 

Cura is started and all is well for now. 

 

I'm going to bed. It's 2am. 🙂

 

Edited December 8, 2021 by GAD

[GAD 10]

Not looking good. Printed this last night and let Cura sit for probably 14 hours until today. This is how it's behaving this morning: 

 

 

[GAD 10]

Wondering if a workable solution might be having a switchable option for "Print via Local Network" and "Print via Cloud" because Printing via the cloud works flawless for me,  And that from a guy that hates "the cloud" almost universally! 🙂

[hobby_grade 2]

I'm on Windows and running into the same issue with Cura becoming unusable after it has been running for a while. It seems that if I reboot my computer, Cura will be snappy again, but the longer I go without rebooting, the slower Cura gets, regardless of whether of not it was open the whole time. I have tried disabling the same suggested plugins, but it does not seem to help. I also did a reinstall today, and after restoring my backup, Cura became slow again, so I am wondering if there is something about my config files causing thins. 

[ahoeben 1,948]

@hobby_grade, not all slowdowns are necessarily the same slowdowns. Do you have any other plugins installed? Like for example the OctoPrint plugin or the Sidebar GUI plugin?

Edited December 10, 2021 by ahoeben

[hobby_grade 2]

35 minutes ago, ahoeben said:

@hobby_grade, not all slowdowns are necessarily the same slowdowns. Do you have any other plugins installed? Like for example the OctoPrint plugin or the Sidebar GUI plugin?

I do use your beautiful Sidebar GUI plugin, but I do not use Octoprint, and for the sake of troubleshooting, I have removed any and all other plugins that I had enabled. 

[treii28 0]

I see comments in another thread to be wary of mapping network (or other) drives that may be unavailable/inaccessible on the 'X:' drive letter. Apparently some version have a build artifact that will search for files on X: as the original sources were compiled from there. From what I'm reading on that thread, it's only an issue if X: is mapped to something that is inaccessible (e.g. a share that isn't currently connected or on a machine that isn't currently on, or not currently reachable via the network)