Yes. If you don't have a stable wifi connection to begin with or not enough signal strength where the pi is located. This can definitely happen.
Are you able to check if the Pi is still connected to your wireless access point/router? Or are you able to attempt to connect to the pi using Putty?
Just some networking infrastructure knowledge... The ip in the list you see on the router isn't live, it's just a record of what ip the router had handed out to the device when it first connected to the network. After the expiration of the ip lease,it will disappear (unless the device renewed it)
Thanks, I'll have to look into that.
I tried connecting with octopi, and I tried to ssh into the Pi, both just timed out.
My router has a "Connected Devices" section where it shows some details about recently connected devices, if the device is currently connected the icon by the device lights up. That is how I knew the device was being "seen" by the router.
I just experienced this as well, though it self-recovered. Sometime after the print finished I was able to access the Pi over the network again. Checking the logs suggests that the wireless network interface was flapping:
# /var/log/syslog
[...]
Dec 26 15:39:08 octopi dhcpcd[591]: wlan0: carrier lost
Dec 26 15:39:08 octopi dhcpcd[591]: wlan0: deleting address fe80::aaff:c7ef:53cd:d128
Dec 26 15:39:08 octopi avahi-daemon[405]: Withdrawing address record for fe80::aaff:c7ef:53cd:d128 on wlan0.
Dec 26 15:39:08 octopi avahi-daemon[405]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::aaff:c7ef:53cd:d128.
Dec 26 15:39:08 octopi avahi-daemon[405]: Interface wlan0.IPv6 no longer relevant for mDNS.
Dec 26 15:39:08 octopi dhcpcd[591]: wlan0: deleting default route via 172.3.3.1
Dec 26 15:39:08 octopi dhcpcd[591]: wlan0: deleting route to 172.3.3.0/24
Dec 26 15:39:08 octopi avahi-daemon[405]: Withdrawing address record for 172.3.3.252 on wlan0.
Dec 26 15:39:08 octopi avahi-daemon[405]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 172.23.32.252.
Dec 26 15:39:08 octopi avahi-daemon[405]: Interface wlan0.IPv4 no longer relevant for mDNS.
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: carrier acquired
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: IAID eb:e8:5b:4b
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: adding address fe80::aaff:c7ef:53cd:d128
Dec 26 15:39:17 octopi avahi-daemon[405]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::aaff:c7ef:53cd:d128.
Dec 26 15:39:17 octopi avahi-daemon[405]: New relevant interface wlan0.IPv6 for mDNS.
Dec 26 15:39:17 octopi avahi-daemon[405]: Registering new address record for fe80::aaff:c7ef:53cd:d128 on wlan0.*.
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: rebinding lease of 172.3.3.252
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: probing address 172.3.3.252/24
Dec 26 15:39:18 octopi dhcpcd[591]: wlan0: soliciting an IPv6 router
Dec 26 15:39:22 octopi dhcpcd[591]: wlan0: leased 172.3.3.252 for 7200 seconds
Dec 26 15:39:22 octopi avahi-daemon[405]: Joining mDNS multicast group on interface wlan0.IPv4 with address 172.3.3.252.
Dec 26 15:39:22 octopi avahi-daemon[405]: New relevant interface wlan0.IPv4 for mDNS.
Dec 26 15:39:22 octopi avahi-daemon[405]: Registering new address record for 172.3.3.252 on wlan0.IPv4.
Dec 26 15:39:22 octopi dhcpcd[591]: wlan0: adding route to 172.3.3.0/24
Dec 26 15:39:22 octopi dhcpcd[591]: wlan0: adding default route via 172.3.3.1
Dec 26 15:39:30 octopi dhcpcd[591]: wlan0: no IPv6 Routers available
Dec 26 15:40:03 octopi dhcpcd[591]: wlan0: carrier lost
[...]
No relevant logs from OctoPrint itself. This setup has been rock-solid over the past few months (maybe a year?), and I only ran into issues after upgrading to 1.5.2 today. 
env.hardware.cores : 4
env.hardware.freq : 1200
env.hardware.ram : 917016576
env.os.bits : 32
env.os.id : linux
env.os.platform : linux2
env.plugins.pi_support.model : Raspberry Pi 3 Model B Rev 1.2
env.plugins.pi_support.octopi_version : 0.16.0
env.plugins.pi_support.throttle_state : 0x0
env.python.pip : 19.0.1
env.python.version : 2.7.13
env.python.virtualenv : true
octoprint.safe_mode : false
octoprint.version : 1.5.2
printer.firmware : Marlin 2.0.5 (GitHub)
Faced the same issue. Got the same feedback about network déconnection etc.., but this a bug deep rooted in the Py3 migration., reverted back to 0.17 and 1.5.2 solved everything.
On windows by any chance? If you don't have mDNS set up, windows may not support that by default. https://stackoverflow.com/questions/23624525/standard-mdns-service-on-windows
I opted to install bonjour print services for windows, I think it is the easiest way to go. See:
https://support.apple.com/kb/DL999
Oh, a bug in something I created. Interesting. I'd like to know, if you wouldn't mind 
.
Though I am not sure how using a different python version to run OctoPrint affects your network, so it would be great if we could know the full details.
Hi @Charlie_Powell look at my previous post regarding the issue I had with octoscreen and octodash pretty similar to what is described here. However reverting back to 0.17 and still running 1.5.2, I don't have the same issue on exactly the same print... and I didn't change anything to the network. So there is something that create this problem which is in 0.18. It behaves like a memory leak but it is not as the memory stays stable during the whole run. No info in the log (I have spent some time looking at them) - I don't see this carrier lost message. The only thing that I could come accross is the printer firmware. But as the revert to old version stop this issue, I choose not to change the firmware.
The network adapters (wireless, wired) in an RPi are completely controlled by the operating system. OctoPrint and Python do not have any influence on the state of the adapters, only the drivers and utilities supplied with the operating system.
OctoPi is a repackaging of the lite version of the Raspberry Pi OS (Raspbian) with added packages like OctoPrint. I believe that since "the silent majority" of users aren't having a problem, OctoPi (both 0.17 and 0.18) contain the correct network drivers.
Of course, there could be an obscure bug that is showing itself in the cases reported here. I'd suggest checking the Raspberry Pi forums for similar reports and possible solutions.
Ok so you didn't migrate to Python 3, you just installed OctoPi. Not my problem then.
It's fully possible that the upstream RPi OS distro has this issue, but it's definitely not related to Python 3.
Sorry to necro post (not sure if 3d is necro) but if this is a common problem that you are experiencing with your Pi, and you have narrowed your search down the Pi being the issue rather than OctoPrint (which if you're on post is more than likely) then a quick fix can be to set a fixed local IP for your Pi's MAC address.
Should your Pi lose its wireless connection for whatever reason, then you don't need to worry about your home router giving it a new IP address and screwing with any cached DNS addresses. Just a quick and dirty fix, but if you're 3+ hours into a print, it at least lets you finish the print before fixing the underlying issue.
I'm supporting this resurrection! I've the same issue - Pi 4 unresponsive in middle of a 6 hour print, although print proceeding without issue. My router has also stopped showing the connection. I had already set up a static local ip for it and tried connecting via a mac as well as my usual Windows 10, without success. It is a new setup using latest updates, so I obviously can't comment on previous software but I may give @jaduret fix a try
Yes, the print still finished, but I could not control/connect to my printer
I haven't had the problem since I updated my printer firmware, so I'm not sure python had anything to do with it in my case?
Ubuntu 20.04.2 LTS
Ip was never an issue, even after running into the problem and I could not connect to Octoprint for the remainder of a print, after restarting the pi (and I then could connect) the IP was always the same.
What printer are you using? Which version of Marlin?
I know this is old, but... The way i found it was by opening CMD and doing a tracert from the IP.
tracert 192.168.1.xxx
From here it should show you what its URL is.