Can't connect to OctoPrint

SeaGull711 commented 2 years ago

I keep getting an error when trying to use "Print to OctoPrint"... when I go into the machine settings, it says, "OctoPrint is not available:. But if I click "open in web", it open's right up. And it's automatically detected. I double checked the application API keys, and even deleted and re-added them on both sides (Cura and OctoPi). Nothing seems to work.

I am running the current version of Cura (4.12.1), the current version of the plugin (3.5.18), the current version of OctoPi (0.18), and the current version of OctoPrint (1.72).

Any advice would be appreciated.

fieldOfView commented 2 years ago

Sorry for taking my time to get back to you. To diagnose this issue, I need your logs, both from OctoPrint and Cura. The Cura logs can be found via Help -> Show configuration folder. The file you are looking for is Cura.log. OctoPrint has its own logs which can be accessed through the OctoPrint settings.

SeaGull711 commented 2 years ago

That's ok. I ended up uninstalling the plugin and reinstalling it, plus also removing the API key and recreating it. Eventually, when I went to connect it back together, I got a "verify" button (I think that was the word), to the right of the API key box in the "Connect to OctoPrint" dialog. After I clicked that, it started working again.

Now, it has given me the same error when I click "print to OctoPrint" on occassion since (maybe when Cura is open but the printer is not on - the printer, not OctoPrint... that's always on)... anyway, when this happens now, I just restart Cura and it has worked since the reinstall.

I'm happy to pull the logs and all if it will help you/someone else, but thought I'd give you an update in case it's not necessary.

fieldOfView commented 2 years ago

I'm happy to pull the logs and all if it will help you/someone else,

Yes please, after it happens again.

mnggh commented 2 years ago

Hi, I seem to experience the same issue. So I tried as SeaGull described, but there's no verify button next to the API field (see screenshot). It doesn't seem that the API key is saved / checked.

fieldOfView commented 2 years ago

There is no button labeled "verify" in the plugin.

It seems the octoprint instance is not responding (or at least, not in time). Can you post a link to your Cura.log (see Help -> Show configuration folder)?

fieldOfView commented 2 years ago

If you are willing to experiment, you could try to increase the timeout here: https://github.com/fieldOfView/Cura-OctoPrintPlugin/blob/release/DiscoverOctoPrintAction.py#L333

Go to Help -> Show configuration folder and browse to plugins/OctoPrintPlugin/OctoPrintPlugin/ Open the DiscoverOctoPrintAction.py file in a text editor (preferably not TextEdit, ironically), and in line 333 change the 20000 to - say 60000. That changes the timeout to one minute.

mnggh commented 2 years ago

There is no button labeled "verify" in the plugin.

Sorry, must have misunderstood the description.

If you are willing to experiment

That's what I like to read. :D Unfortunately it didn't help. Still timing out.

Can you post a link to your Cura.log (see Help -> Show configuration folder)?

Please find the file here: [link removed]

fieldOfView commented 2 years ago

Could you (approximately) time how long it takes in your browser to open http://10.10.70.19:80/api/settings?apikey=your_api_key ? Obviously filling in your API key.

fieldOfView commented 2 years ago

Looking at your logs, other parts of Cura also seem to have trouble accessing the network. Do you have a firewall that could be interfering?

mnggh commented 2 years ago

Could you (approximately) time how long it takes in your browser to open http://10.10.70.19:80/api/settings?apikey=your_api_key ? Obviously filling in your API key.

It takes 782 ms measured using the browser dev tools.

Looking at your logs, other parts of Cura also seem to have trouble accessing the network. Do you have a firewall that could be interfering?

Yeah, suspected the network too, after reading the logs. But my setup used to work this morning and I could print successfully. Then I decided to update everything (Cura incl. all extensions and Octoprint incl. all extension) as I haven't used my printer recently. After the updates, the connection wasn't working anymore. To provide an answer to your question. Yes, I have a firewall, but it's set to "permit all".

mnggh commented 2 years ago

I performed a packet capture and found that not one single packet destined for Octo was leaving my machine. So I installed Cura incl. all extensions on another machine and it worked instantly! Now I know which button is missing in the connection screen. It's not "Verify" as stated above but rather "Request..." - see screenshot enclosed and please compare it with the screenshot above. This made me again completely uninstall Cura and all its depending files ("Cura" folder within Application Support folder, too). And I simply restarted my laptop. Afterwards I installed everything again and voila - it's working again. Do you want to investigate this issue further and why the "Request..." button was not showing?

mnggh commented 2 years ago

This is getting more interesting. As stated, everything worked last night and I was able to print. Great! Next, I was about to print another part this morning and again: Cura with Octo plugin didn't connect to the printer anymore. This time, I just rebooted my laptop, started Cura and everything was back to normal. For one print. Now it's refusing again to connect. Simply restarting Cura doesn't help. What could be the issue?

fieldOfView commented 2 years ago

I performed a packet capture and found that not one single packet destined for Octo was leaving my machine.

The contents of that packet and any response would be valuable to see what is going on.

mnggh commented 2 years ago

Sure. I'll provide both working and non-working states.

Non-working (you'll just find the MDNS / Bonjour discovery):

Working (you'll see the MDNS as well as request and responses):

fieldOfView commented 2 years ago

The "Request..." button is only shown if the OctoPrint instance supports the appkey workflow (where you don't have to manually copy/paste a key, but just answer a prompt in OctoPrint to allow access). In order to see if the appkey workflow is supported, the plugin tries to access /plugin/appkeys/probe. If that request times out, or returns an error, then the button is not shown. The probe request is made any time the selection of OctoPrint instances changes.

Modern OctoPi instances come with appkey support out of the box. So the "Request..." button not showing up is indicative of Cura not being able to access the OctoPrint instance.

fieldOfView commented 2 years ago

Non-working (you'll just find the MDNS / Bonjour discovery):

Did you open the Connect to OctoPrint dialog at all in this case? It is strange that there is no request to the OctoPrint api at all. I would expect at least a request for the aforementioned /plugin/appkeys/probe. Making a change to the API key should result in a request for /api/settings.

mnggh commented 2 years ago

Modern OctoPi instances come with appkey support out of the box.

Right, thanks for the explanation. I'm using appkeys already. One for Cure, another one for OctoDash.

Did you open the Connect to OctoPrint dialog at all in this case?

Yes, right after opening Cura to basically force any kind of request.

BTW. After a short amount of time in a working state (and after I was able to send the print job), Cura falls back into a non-working state and refuses to connect. Until I reboot my machine. I wonder, if there's some kind of process terminating in the background or anything like that. Let me try my secondary laptop, if this issue is reproducible.

fieldOfView commented 2 years ago

Cura falls back into a non-working state and refuses to connect.

When it does, please start your sniffer and go into the Connect to OctoPrint dialog. Then press the Refresh button. And change the API key.

mnggh commented 2 years ago

Ok, when it happens, this is what I see in the sniffer.

Just above that is a bunch of stream for the webcam image. Using this knowledge I found a way in successfully reproducing this issue:

Reboot my laptop to start fresh
Open Cura and go to the "Connect OctoPrint" dialog to make sure connection is working.
Go to "Monitor" tab in Cura, to see webcam image. -> working.
Now you have to choices on how to break the connection: 4a. Go to the "Connect OctoPrint" dialog again -> connection will break. OR 4b. Laptop falls into sleep -> waking up laptop -> connection will break.
Now perform your t-shoot steps: start sniffer, go to the "Connect OctoPrint" dialog again (if not already there), press refresh, change API key.
This will give you a similar sniffer as above.

Interestingly:

Connection will not break, when you're not in the "Monitor" tab.
Connection will not break, when "show webcam image" is deactivated. Now you can safely be in the "Monitor" tab.

This leads to following assumption: Connection will break, when the webcam image is active AND you're trying to reconnect (either through the "Connect OctoPrint" dialog or after waking up).

I still have to verify on another machine though. But still hope this helps already. Not sure, if I can perform any t-shoot today anymore. Happy New Year and thanks for your help! 🎉

mnggh commented 2 years ago

I still have to verify on another machine though.

Tested on my secondary machine. Was not able to reproduce...

fieldOfView commented 2 years ago

Tested on my secondary machine. Was not able to reproduce...

Are both of them connected to the network in the same way?

Connection will break, when the webcam image is active AND you're trying to reconnect (either through the "Connect OctoPrint" dialog or after waking up).

I will see if I can detect going to sleep or reconnecting, and actively pause/stop the webcam display.

mnggh commented 2 years ago

Are both of them connected to the network in the same way?

Yes. Both using WiFi. Same SSID. Main difference: hardware. Primary: MacBook Air with M1 Secondary: MacBook Pro with Intel

I will see if I can detect going to sleep or reconnecting, and actively pause/stop the webcam display.

Thanks!

alfondehesa commented 8 months ago

If you are still having this issue:

I was facing what seemed like the same issue.

The plugin is able to discover a local instance of Octoprint, and also request the API key automatically sometimes, and yet after all that, it said "Octoprint is not available".

It used to work fine until a couple of days ago.

I have tried re-installing the plugin, to no avail.

For the "Octoprint is not available" message:

Logs kept repeating the following:

2023-10-14 19:24:41,901 - DEBUG - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice.connect [477]: Connection with instance ROCKO with url XXXXXXXX started
2023-10-14 19:24:42,018 - DEBUG - [MainThread] cura.Machines.MachineErrorChecker._rescheduleCheck [164]: New error check scheduled.
2023-10-14 19:24:42,018 - INFO - [MainThread] cura.Machines.MachineErrorChecker._setResult [221]: Error check finished, result = False, time = 0.00s
2023-10-14 19:24:42,413 - DEBUG - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction.testApiKey [349]: Trying to access OctoPrint instance at XXXXXXX with the provided API key.
2023-10-14 19:24:46,843 - DEBUG - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice.disconnect [512]: Connection with instance ROCKO with url XXXXXXX stopped
2023-10-14 19:24:46,848 - DEBUG - [MainThread] cura.PrinterOutput.NetworkedPrinterOutputDevice._createNetworkManager [323]: Creating network manager
2023-10-14 19:24:46,852 - INFO - [MainThread] UM.OutputDevice.OutputDeviceManager.addOutputDevice [214]: Output Device ROCKO already added

and also

2023-10-14 19:24:50,446 - DEBUG - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice.connect [477]: Connection with instance ROCKO with url XXXXXXX started
2023-10-14 19:24:50,553 - DEBUG - [MainThread] cura.Machines.MachineErrorChecker._rescheduleCheck [164]: New error check scheduled.
2023-10-14 19:24:50,553 - INFO - [MainThread] cura.Machines.MachineErrorChecker._setResult [221]: Error check finished, result = False, time = 0.00s
2023-10-14 19:24:50,952 - WARNING - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction._onRequestFailed [570]: Connection refused or timeout when trying to access OctoPrint at XXXXXXXXX/api/settings
2023-10-14 19:24:50,953 - DEBUG - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction.testApiKey [349]: Trying to access OctoPrint instance at XXXXXXX with the provided API key.
2023-10-14 19:24:57,816 - DEBUG - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice.disconnect [512]: Connection with instance ROCKO with url XXXXXXXX stopped
2023-10-14 19:24:57,822 - DEBUG - [MainThread] cura.PrinterOutput.NetworkedPrinterOutputDevice._createNetworkManager [323]: Creating network manager
2023-10-14 19:24:57,829 - INFO - [MainThread] UM.OutputDevice.OutputDeviceManager.addOutputDevice [214]: Output Device ROCKO already added

I couldn't pin this down to a specific update of Cura or Octoprint, as it just felt like it just randomly started happening.

As far as how it looks like on the octoprint logs, this is an instance of the "timeout or refusal" plugin error in cura, viewed through the octoprint logs:

In Cura:

2023-10-14 20:00:51,389 - DEBUG - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction.testApiKey [349]: Trying to access OctoPrint instance at XXXXXX with the provided API key.
2023-10-14 20:01:11,378 - WARNING - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction._onRequestFailed [570]: Connection refused or timeout when trying to access OctoPrint at XXXXXXX/api/settings
2023-10-14 20:01:11,379 - WARNING - [MainThread] OctoPrintPlugin.DiscoverOctoPrintAction._onRequestFailed [570]: Connection refused or timeout when trying to access OctoPrint at XXXXXXXX/api/settings

In Octoprint:

2023-10-14 20:01:16,697 - octoprint.server.util.flask - INFO - Passively logging in user XXXXX from ::XXXXXX
2023-10-14 20:01:16,698 - octoprint.access.users - INFO - Logged in user: XXXXXX
2023-10-14 20:01:17,092 - octoprint.server.util.sockjs - INFO - Client connection closed: ::XXXXXXX

so it seems from the times like the plugin gives up or the timeout is triggered before my octoprint instance is able to sign it in... To be fair, I am running something like 40+ plug-ins and my instance is pretty slow as it is.

Upping the timeout to 60000 as mentioned by @fieldOfView worked for the "Octoprint is not available" message. I was then able to set up a new Octoprint connection (which had a couple of bugs, one of them being that it would automatically default to "Octoprint is not available" when adding the API key by hand and it would not save the API key, and it would not show the request button in what seemed was random patterns that I could not pin down).

I wonder if it would make sense to submit a pull request to change this value for folks with slower setups, I don't think anything would break by having a one-minute timeout.

As far as the uploading and waiting for GCODE analysis goes, I was getting an issue where Octoprint would either think the print job was completed in the middle of the "preparing" stage, or it would upload and not start the print at all. This turned out to be due to the "autoselect" octoprint plugin, it seems that when both this cura plugin and the autoselect octoprint plugin were battling to select a file I got unexpected results. Disabling the plugin solved this issue.

I hope this helps any folks that might have the same issue!

fieldOfView / Cura-OctoPrintPlugin

Can't connect to OctoPrint #256