Caching print job (prevent job failure due to network outage)


#1

First forgive me if this has already been asked and answered.

I've been having some network issues of late. And as a result, unfortunately, I'm learning how easy it is to interrupt a job controlled by Octoprint.

Here are the ways I've experienced this week:

  1. Internet outage
  2. LAN outage
  3. Octoprint Service crash (these are very rare)

#3 I get, Octoprint is sending the code to the printer over USB so it makes sense that the print would stop if the service failed.

The other two don't make sense to me though. I would think that once a job is sent to Octoprint that the job would be able to continue even if the network cable was removed from the pi. The job should all be onboard the pi and the pi communicates to the printer using USB not Ethernet.

Is there something I'm missing?

I guess the main question I have is why does a network issue kill a print that is in progress?

Thank you,

Tony


#2

Nope. It should happily continue to stream as long as it has power, network connectivity doesn't play into it at all.

We will never know unless you share some logs :wink:


#3

Thanks for the response. Now that I know this is an anomaly I'll monitor things and get logs for you.

Tony


#4

During the OctoPrint Setup Wizard it asks whether or not you'd like to monitor the network's availability. I always assume that saying "no" to that will be more forgiving of a network outage.


#5

If that's the cause, is there a way short of re-running the set up to change that to NO after the fact?


#6

Not true. Good theory though.

Yeah, config->octoprint->server. Here's why it has such a ping:

If the connectivity check is enabled, OctoPrint will regularly check if it's connected to the internet. This is useful to prevent resource intensive operations (such as checking for updates) if it's already clear that they won't succeed anyhow.

My upcoming proof vid has this enabled, fwiw.


#7

Thanks for the clarification on that. :slight_smile:


#8

Here ya go, I tested with two printers/pis:


#9

Awesome job with the video.

OK so it's not the disconnect that caused my issues... Hmmmm I'm assuming that when my connection came back up with my chrome browser still open to the page that it didn't try to reconnect. I notice that my printer reboots whenever a reconnect command is sent to octoprint. To be clear, I did not click connect at any time. So the question is more, could chrome or my set up have caused an attempted re-connect?

Thank you for being patient with me. I just want to fully understand this product as I love using it.

Regards,
Tony


#10

It shouldn't. But run some quick tests, if you manage to get it to die, share the logs.


#11

Yep I have a big project that I need to finish, but as soon as it completes I'll do some testing and report back.

Thank you,
Tony


#12

...unless this is combined with a plugin which is trying to "touch the cloud", so-to-speak.


#13

OK I can absolutely confirm that my print jobs fail the second my PI loosed network connectivity. I've been able to reproduce it every time. Based on the above it seems like it might be a plugin. Just wasted an entire role of filament and burned up a print nozzle last night.

I have logs this time. Octoprint Logs.zip (87.5 KB)


#14

Try disabling that.


#15

OK once my job completes I will remove it. Never ended up using anyways. I hope this solves the issue as I want to keep using Octoprint if at all possible.

Thank you!


#16

Did it solve the issue?

If so that would probably be something for @Kenneth_Jiang to take a closer look at.

If not we'll have to dig deeper. I'd start with enabling serial.log, connecting to the printer, taking the Pi offline, back online and then checking if there's anything in the serial.log. If not, repeat with a small print job. Also see if you can reproduce the behaviour in safe mode (couldn't find in this topic whether you'd already tested that).

Based on your octoprint.log I don't see it switching away from state Printing once the plugin messages start to flood in (which is a I guess when connectivity is lost?).


#17

Sorry I swore I followed up. Yes, removing that plugin did solve the issue. I think that plug-in should warn you that once installed your prints will fail if you loose your network connection.

Thanks for checking up on me.

Tony


#18

Go over to his repository and let him know that it's behaving badly upon network loss. It's something that he can test (pull the Ethernet cable) during a print job. I'm assuming that Python has try/catch/finally behavior.


#19

What @OutsourcedGuru said. Best open a ticket in the plugin's issue tracker. I'm fairly sure that this is probably not the intended behaviour, so @Kenneth_Jiang will probably want to know about it and be able to look into it.


#20

@ibgeek Assuming the problem you reported was specific to ethernet connection (wifi connections drops all the time), I did very thorough testing by disabling my Pi's Wifi, and randomly plugging/unplugging my ethernet cable. My print never crashed. Not even a slight pause.
Assuming this is a bug in my plugin (since after you removed the plugin you no longer had crashes), I'll appreciate it if you can work with me to figure this out since you seem to be the only one who can reliably reproduce it. Can you go back tothe issue you opened and filled in a bit more details based on the questions I asked there? Thanks!