Refresh page as per request at the bottom of the page opens the GUI but I believe it is offline (see screenshot 2)
It says the printer is connected but hovering over the connection settings produces a 'stop sign' and clicking 'disconnect' appears to do nothing. Going into settings and making any change, e.g. change printer bed size produces a load wheel when confirmed; this eventually produces an Octoprint screen to say server is offline.
Screenshot 3 also shows Octoprint restart through GUI could not be executed in the background.
Octo has been working the past few weeks until I moved the printer last night to another table in my house (about 2m away); Since then it hasn't worked.
I should note that octoprint sits there happily thinking it is connected and doesn't tell you it is offline until i try and do something within the UI.
Not sure what log files I can produce but happy to try with a bit of instruction.
What did you already try to solve it?
Power off/on of my Raspi
Restarting router
Restarting Octoprint through GUI (it cannot be executed)
Restarting Klipper Service
Tried a different SD Card Reader
Tried connecting to Octoprint through different devices (Windows 10 PC, Android Tablet, Android Mobile and IPad)
Tried SD card reader in each USB port (disconnected it during the move)
Pinged the IP and got a reply
Started RasbPi/Octoprint with and without control board connected: same results either way
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
OctoPrint version: 1.3.10
OctoPi version: 0.16.0
printer: Homebrew- still building it but running an MKS Gen1.4 Control board alongside Raspi.
firmware: Klipper but doesn't appear to get far enough for that to seem to be an issue
Raspi 3B+ Powered by 5V, 3A PSU
Screenshot 1 is a typical response when your browser didn't load the stylesheet within, say, 60 seconds. Usually a reload/refresh of your browser will cure this.
Screenshot 2, you indicate that you believe it wasn't connected. And yet, the "Disconnect" button is being displayed in the Connection side panel widget which means that it seems to be.
Screenshot 3 is what you would see immediately after an OctoPrint restart and is to be expected. The screen then includes a blue button after this which says Reload. Pressing the button is reasonably the equivalent of pressing your browser's reload/restart button.
Your octoprint.log can be found by remoting into the Pi and running cat ~/.octoprint/logs/octoprint.log
You shouldn't discount Klipper as the cause of all this. If you're new to OctoPrint, you might want to make all this work first without Klipper, save your microSD card image at this point and then advance to the next level.
Okay that explains why the refresh does what it does then. I have just loaded it up again and this time it brought up screenshot 1 immediately and loaded within a second.
Correct, it says 'Disconnect' but until this issue arose this morning it produced the thermal graphs, from my two thermocouples, which it doesn't now. Plus all of the homing and motion control buttons are greyed out when you go into the control tab.
As you can see I haven't got Octo configured to auto-connect upon start-up so it shouldn't be trying to connect anyway. In the past, clicking disconnect would disconnect from the printer but selecting it doesn't produce any response.
See linked video:
Okay, so perhaps the restart is working, hence the window. But from there, pressing the blue button doesn't refresh the browser and shows no signs of trying to either (no loading wheel and 'refresh' isn't replaced by 'cancel'.
I assume I do that through a PuTTy terminal (sorry a bit of a software noob) and login to the Pi?
I guess i was discounting Klipper because I knew it was working before (i.e. i was testing the homing and playing with some speeds in the cfg file yesterday afternoon, prior to the move) , but then again so was Octo... I'm mostly confused because I can't think of anything that has changed other than unplugging and moving the RasPi 2m across the room.
Before unplugging it, did you shutdown the Raspi? (You'd find this in OctoPrint's system menu.)
It's possible that where you are now has poor wi-fi connectivity. If there are vertical metal bars (like you might find in an old radiator), then this could be the reason.
If you're a software noob then installing Klipper is probably living life dangerously, wouldn't you say?
Your baudrate seems high to me, are you sure it's not 115200?
That is something I did not do. I am guessing by you mentioning it that this is something that should always be done?
As a matter of fact, it is now further from a radiator and probably a more direct route to the router (in the same room).
Yes, it was perhaps a little naive of me to go straight into a Klipper-controlled system but I felt that if I was going to have to set it all up from scratch anyway, why not run Klipper rather than Marlin. I had done a bit of research and found some decent tutorials that aided installation and basic setup so thought I would see how it went (and was going swimmingly until this morning).
That was something i wasn't sure on. During klipper setup, I was expecting to have to configure baudrate but the prompt never appeared in the menu I expected it to, so decided to leave it as default. I shall perhaps reinstall Octo/Klipper tomorrow and do a little more research on baudrates and see if that works.
After a quick look at baudrates. Klipper recommends 250k and the control board can take that too although the information on the RasPi seems to be mixed but suggests it's 115200.
Any operating system which is read/write wants you to shut it down gracefully. Since it has the ability to be actively writing to your microSD, there's a chance of corruption if you just pull the plug during operation. The ext4 partition type is supposed to be robust and yet I've seen my fair share of corrupted microSD cards from one of my clients.
You could try to temporarily add an Ethernet cable to see if it behaves better. It's also possible that when you moved it the serial cable didn't get firmly re-attached. Similarly, it's possible that the power outlet on the other side of the room is internally damaged (or its wires are) and is delivering less voltage than you think.
I think I would suggest getting another microSD so that you can run a test: try the unaltered version of the OctoPi image with Marlin and your printer at 115200 until you get it to work. Having then blessed the entire rig's collection of components then advance to the Klipper level.
Yeah, I ashamedly rarely shutdown Octoprint in the past but this time i was perhaps not so lucky (i guess it's like pulling a USB stick... Chances are you won't corrupt anything but every once in a while you'll find yourself in a pickle).
I have just tried through ethernet and achieved the same result, unfortunately.
Okay, I will give it a go using Marlin first (walk before you can run and all that!) and see how that goes.
Out of curiosity then, what makes Klipper less noob-friendly? I know it is more of a development software so is it just that to get it running smoothly, some code-tinkering may be required?
I have done as mentioned above and things appear to be running (Marlin).
I noticed that on boot for Octoprint, the connection window hesitates as per my original screenshot 2 (except both dropdowns are AUTO) until it kicks into gear after a couple of seconds; giving me the option to connect to my board. Could this be a sign that on my previous version there was an issue that stopped it making it to the next step which is where printer selection/connection could occur?
If you watch the Terminal while you're connecting (with AUTO) you can see why there's a moment's hesitation. It's walking through attempts at different speeds, sending a command and waiting for a promising result. Earlier, you were manually selecting a single device and speed so it just connected.
Was this the earlier issue? Too hard to say yet.
What makes Klipper less-than-noob? It's completely different. It brings back a lot of the logistical work from the controller board and makes the Raspi do that "upstream". This is especially amazing if you have a Delta-style of printer since the mathematics is really too difficult for an 8-bit controller board.
Klipper is pretty amazing and has been known to cure problems (usually those related to the cheap 8-bit controller boards). The biggest problem it solves is the stereotypical blobbing seen when a tight circle has been sent to the printer which is comprised of MANY tiny segments. There's a point where each one of those movements is too much for the controller to do its logistics and then starts falling behind. The receive buffer then runs tight, exacerbating the problem.
In this scenario, by moving the logistics calculations upstream to the Raspi, the controller then only has to do the moves and get it done. Since the Raspi has four 32-bit cores then it can handle the logistics calculations even with a Delta.
All that said, there is probably only five people who frequent the forum here who have gone through the upgrade from Marlin to Klipper, I'd guess. I'm familiar with it but I have yet to upgrade one of mine since I'm usually too busy or I need things to be very vanilla for testing purposes since I develop software.
Usually those who are upgrading to Klipper do so to solve a problem. If you have a Delta, then yeah, go for it. If you have an 8-bit controller, likewise this is for you. If you experience blobbing on the surfaces of your prints, this might be a good path for you.
Doubling the speed from 115200 to 250000 has been known to smooth blobbing as suggested by at least one person. Once logistics have been upstreamed, I see no reason why you wouldn't want to do that as long as you have a good-quality serial cable.
This is actually pre-connection instagation but will pay attention to the terminal later to see what you mean.
No, i actually meant what makes it more difficult to get it to work as an inexperienced softy? Klipper was actually suggested to me from someone on another forum when i was first deciding on 8-bit vs 32-bit. As you mention, it overcomes many of the drawbacks of 8-bit without having to spend the £££ for a 32-bit controller, as well as being able to amend the cfg file without having to reconnect to a laptop and flash the board again. After looking through a bit of on github, it seemed as though it was quite well developed (enough for me to follow a tutorial to get it installed at least).
Are issues mainly surrounding it not printing properly/not at all? Or is it getting it talking to start with?
If you're building a printer then that external-config-file approach (Smoothieware, Klipper) is the way to go. It's a pain to recompile/re-flash a board and for some, they're simply terrified of the process as seen in the typical Marlin approach. I will note that the Marlin approach results in the smallest/fastest executable, though.
Klipper is a great idea, the entire concept. It's not well-known yet in the 3D printing space from an experience standpoint. If you get into trouble you're going to get lots of shrugs from others.
Like I said, the average person installing Klipper is attempting to fix a problem. And this is the typical problem they're facing, a printer which momentarily halts while it's printing the exterior edge.
At the point where you're seeing this, as a hobbyist you have to be pulling your hair out. This just isn't good enough (part on the right).
So obviously, the printer gets going, connects and all that. It just then stutters while printing. Given that the hotend throat is filled with molten filament under back-pressure from the feed gear, this results in the blobbing you see here when your printer hesitates.
Yeah, having now had a little bit of exposure to both, Klipper is more convenient but at the end of the day you still have to do the same thing, the only difference is not having to power everything down in order to modify cfg files.
So that I don't do something stupid again... to modify the Marlin cfg, it is just the matter of shutting down the pi, powering everything down, connecting control board to pc, open in Arduino, modify, verify, upload?
Hmmm, I see. I guess I had only considered the fact that if it installed then it would work as desired but I'll perhaps reinstall it all to my other SD card and once I've got my printer up and running with Marlin could see how it compares.
I think you've got the process down. The Arduino IDE comes with avrdude as one of the executables. So when you select the right board, set the speed and the right programming interface it's down to just pushing a button to compile and flash. I'd recommend visiting the Board Manager screen and do the update to see if you've got the latest.
Even if you don't intend to keep Marlin for good, it's a good learning experience. You end up understanding a lot of what's going on. Once you've done that successfully then look at the FirmwareUpdater plugin.
