Issue with running Cura while connected to the internet

[jschwar 3]

I am using Cura to slice for an Ultimaker 3. For some reason, Cura becomes unusably slow (having to wait for a minute or more between mouse clicks) when I have it connected to the internet. As soon as I disconnect my computer from the internet, it returns to the normal speed. I assume this it has something to do with Cura trying to connect to a service and getting a bad response? Either way, this issue happens on both my macbook and PC, as well as across Cura versions (I have tried 2.3, 3.0, and 3.1). 

 

Disconnecting from the internet to use Cura works in the meantime, but it means I cannot view my printer over the air, nor send prints wirelessly. It would be nice to have this functionality.

 

[msurunner 2]

This is EXACTLY what I'm seeing...  I suppose the work around could be disconnect, slice, reconnect, print, but that seems to be a lot more steps than intended...

[furdterguson 0]

4 hours ago, jschwar said:

I am using Cura to slice for an Ultimaker 3. For some reason, Cura becomes unusably slow (having to wait for a minute or more between mouse clicks) when I have it connected to the internet. As soon as I disconnect my computer from the internet, it returns to the normal speed. I assume this it has something to do with Cura trying to connect to a service and getting a bad response? Either way, this issue happens on both my macbook and PC, as well as across Cura versions (I have tried 2.3, 3.0, and 3.1). 

 

Disconnecting from the internet to use Cura works in the meantime, but it means I cannot view my printer over the air, nor send prints wirelessly. It would be nice to have this functionality.

 

 

Did you turn OFF automatic slicing? Turning that off only helped a small bit. Cura still bogs down with every mouse click, even when a model is not loaded.

Edited January 9, 2018 by furdterguson

[msurunner 2]

Yes. Even initial start up is ridiculously slow, but when disconnected from the network, it's substantially (100 times) faster...

[furdterguson 0]

Just now, msurunner said:

Yes. Even initial start up is ridiculously slow, but when disconnected from the network, it's substantially (100 times) faster...

 

I have not tried disconnecting from the internet. But yes, Cura initial startup take about 1 minute and 40 seconds for me.

[nallath 1,120]

Cura only tries to get a single network request; trying to find the latest version. But that runs in a seperate thread, so that shouldn't be an issue. Could you try to disable the "update checker" plugin?

[msurunner 2]

I tried this and there was no improvement.  Without looking at the Cura code itself, I noticed in the logs there are communication requests to the printer, which it obviously needs for the monitor aspect. Is it possible this is what is slowing it down? Could there be a way to toggle the feed/communication? Perhaps have it send a picture every .5 second versus video?

[nallath 1,120]

Cura is loading the stream if you try to monitor the printer, but should close it when you aren't looking at it. But yeah, that's not something it does over the internet but the local network (hence me asking about the update, as that's the thing that actually connects with the internet)

Edited January 10, 2018 by nallath

[msurunner 2]

With a wirelessly connected printer and a wirelessly connected computer in a school setting (large network), is it possible this is causing the issue?  I can do things on the internet/computer just fine, but whenever the wireless network adapter is active, Cura dies.  I started Cura 10 minutes ago and the processes are active in task manager, but Cura has failed to pop up yet.

[nallath 1,120]

If you didn't press the monitor tab, it shouldn't be accessing the camera. It does try to request the status of the printer every 2 seconds, but that shouldn't cause a massive load on network on CPU (we're talking about a few kb's tops)

[jschwar 3]

So I went through one by one and disabled the different plugins that may be connected to the internet. It appears the one that is most taxing on the system is the "OctoPrint connection".

 

Here is the rundown of the slicing time for one of my parts:

All plug-ins enabled: ~54 seconds 

OctoPrint disabled: ~4.5 seconds

OctoPrint + update checker disabled: ~4.5 seconds

OctopPrint + firmware update checker disabled: ~4.5 seconds

OctoPrint + update checker + firmware update checker disabled: ~3.7 seconds

Offline Speed: ~3.5 seconds

 

Although Cura is not as fast to respond as no internet connection, disabling OctoPrint speeds it up dramatically. Disabling both the update checkers seem to add a slight edge as well, making it usable once again.

Thanks for your help!

[msurunner 2]

DAMN YOU OCTOPRINT!!!! Good find jschwar!

[JTTM 0]

Sorry to post on this old thread. I was searching for this issue on Google and this is the first result, so might as well add some useful info I found. 

 

This happens for Cura on a large network (school) in our case and it was annoying to have to turn off WiFi everytime we used Cura. We found that the issue was fixed not only by turning off the OctoPrint plugin but also by turning off the UM3 Network Connection plugin. After that, Cura showed the same speeds that would happen while disconnected from the network. 

[ahoeben 1,948]

I will add an option to disable bonjour/zeroconf discovery of Octoprint instances in a future update of the plugin. I’ll see if I can get a similar option added for UM3NetworkPrinting in a future Cura version.

[ahoeben 1,948]

I would appreciate it if you could help me test this version:

http://files.fieldofview.com/cura/OctoPrintPlugin-v5.0.0-2019-01-28T16_19_16Z.curapackage

 

This new version has a checkbox in the "Connect to OctoPrint" dialog that will let you disable automatic discovery of local OctoPrint instances. If you uncheck the checkbox at the bottom of the list, the plugin should stop all bonjour/zeroconf activity.

[Marius0188 0]

Running good laptop with Windows 8.1 Pro.

When doing internet speedtest using google I get 9 - 10mbs.

Open Cura and do same speedtest a couple of times my internet speed drops to between 0.5 and 1.5 (max)

 

Cura is really becoming painful. I am worried why it is consuming my bandwith.

 

Dev's can say what they want but there is huge issue since version 4.

 

[sookoll 0]

From stderr.log:

Quote

13:58:45,859 - DEBUG - [MainThread] Toolbox.src.Toolbox._makeRequestByType [550]: Requesting updates metadata from server.
14:00:25,886 - DEBUG - [MainThread] cura.CuraApplication.run [790]: Booting Cura took 108.02174663543701 seconds

 

Deleting plugins\Toolbox helped (after that marketplace button doesn't work) . Or nicer approach:

--- Toolbox.py    2019-12-24 12:29:39.000000000 +0200
+++ a/Toolbox.py    2019-12-24 13:06:54.000000000 +0200
@@ -548,11 +548,11 @@
     # --------------------------------------------------------------------------
     def _makeRequestByType(self, request_type: str) -> None:
         Logger.log("d", "Requesting %s metadata from server.", request_type)
-        request = QNetworkRequest(self._request_urls[request_type])
-        for header_name, header_value in self._request_headers:
-            request.setRawHeader(header_name, header_value)
-        if self._network_manager:
-            self._network_manager.get(request)
+        #request = QNetworkRequest(self._request_urls[request_type])
+        #for header_name, header_value in self._request_headers:
+        #    request.setRawHeader(header_name, header_value)
+        #if self._network_manager:
+        #    self._network_manager.get(request)

     @pyqtSlot(str)
     def startDownload(self, url: str) -> None:

When examining wireshark output thare are lot of other weird requests. Like

Quote

10.0.1.100	10.0.1.3	SMB2	402	Create Request File: 4.4-exe\build\inst\lib\python3.5\site-packages\UM\Qt\QtRenderer.py
10.0.1.3	10.0.1.100	SMB2	131	Create Response, Error: STATUS_OBJECT_PATH_NOT_FOUND
...

 

where 10.0.1.100 is cura host and 10.0.1.3 is my home linux samba-dlna-web-etc server and has nothing to do with cura or printer. I Didn't investigate reason for that. At least now it's booting normally.