What is the problem? When I tell a gcode to copy to the SD card, nothing seems to happen. Also, can't seem to browse files on the SD card, though there are working print files on there.
Copying up a 13mb gcode sliced in cura (which will work if I copy it to the SD card via Windows) took about 10/15 minutes and failed with Upload failed Could not upload the file. Make sure that it is a valid file with one of these extensions: .g, .gco, .gcode, .stl - 504 Gateway Time-out
The server didn't respond in time.
What did you already try to solve it?
Not a lot yet if I am honest, as I have no idea what I could do. I understand it copies the gcode line by line so will be slower, but I have tried a few times and nothing seems to work.
Additional information about your setup (
OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
Lots of entries in the terminal log that look like below (this is the end, no reported failure)
Send: M105
Recv: ok T:16.6 /0.0 B:16.3 /0.0 T0:16.6 /0.0 @:0 B@:0
Send: M105
Recv: ok T:16.7 /0.0 B:16.1 /0.0 T0:16.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:16.7 /0.0 B:16.4 /0.0 T0:16.7 /0.0 @:0 B@:0
Actually, it looks like it has all hung up... this sadly seems to be a common theme for me.
The Pi seems to lose connection to the printer a lot, to the point where I had to give up using the Pi before I ever really got in to it and this is my attempt to get it working and falling at the first hurdle.
The printer currently says its active... but temp is not adjusting and graph not moving... yet it still looks normal on the web page.
We need the octoprint.log. If it is locking up when you copy to SD and the previous log doesn't show what happens on the hang, ssh (putty) to the Pi and run this:
Is it locked up or just busy. With a serial bit rate of 115200 (stock CR-10S) it will take over 15 minutes just to transfer a 13 MB file assuming that the serial link can be run at full blast and that writes to the SD card occur instantaneously without error. The serial link can not run at full blast and it takes time to write to an SD card.
I'd expect it to take a long time for a Pi to transfer a 13 MB file to the printer SD card. It's the reason I never use the SD card on the printer.
Nothing showing in the log after a Long time, so either it cut out near the end of the transfer or at the end of the transfer.
Doing some more tests I realised it is having issues even listing the files on the sd card, so I expect there is a file on there it doesn't like and crashes so just going to format the card and try again.
15 mins to transfer 13mb is correct and is fine by me, still quicker and easier than going upstairs to get the card while wrestling the dog out of my print room, coming back down to transfer, going back upstairs and wrestling the dog once more.
I think that was it, files on there it didn't like. As I deleted everything (didn't format) save for a few gcode files.
I then put the SD card in and booted the printer.
Booted the Pi.
Came downstairs and connected in to the Pi and straight away I could see it was connected to the printer and had a list of all the files on the SD card which was a good sign. I then kicked off the 13MB transfer again and this time it looks completely different.
This is the first time I have seen it actually do the transfer, as in, you can see the progress in the status area:
Still going, but it looks a lot better.
Now, the SD card has been fine with the files on it for the printer as a stand alone. I was able to print the gcode files off the SD card via the printer without any issue whatsoever. I guess this is because files on an SD card do nothing until you try and open them. With the Octoprint connection however, I expect that was sending a command to read or check all the files on the SD card. It was probably hitting a file that either had a name it didn't like or actually contents of the file, depending on what it does.
Does anyone know what actually happens here?
I wouldn't expect a dodgy file (probably non-gcode) to crash the printer and Octoprint. Surely if it was a file type issue, it would just be skipped? Only read files that are .gcode if that is all it is looking for and ignore everything else?
Ah... I may have spoke too soon.... looks like it might have fallen over again...
24,000,000 bits transferred in 1,800 seconds = 13,333 bits / second... even though it says connected at 115,200 bits/s... so running 8.6 times slower than expected.
Does this seem right?
On the up side, it does now look like everything is working as it should be, no hanging, no kills, great progress.
But if the print is initiated from the SD card and Octoprint was to crash, hang, update, reboot, etc. then the print would keep going right?
Whereas, if the print comes from Octoprint itself then any issues and it would fail.
From the few guides I have seen on YouTube that actually led me to Octoprint, they all said always print from SD because of this.
Given the complete lack of stability I have experienced when starting out with Octoprint, I don't yet have the confidence in it as a platform to hand a long print to it. The problems I have been having might well have stemmed from dodgy files on the SD card, in which case I will get some confidence in the platform (my setup) now and so maybe that will be something I can do.
Today seems to be the record for having had it all alive with the 30 minutes of transfer, before, we were looking at a max of about 2 to 3 minutes between crashes and kills and hangs and lockups... so while Octoprint as a platform may be stable, my experience with it thus far has been anything but.
Just saying: My OctoPrint installations never crashed or hang.
And OctoPrint updates and reboots only on user demand.
This way, you are using OctoPrint to only a fraction of it's capabilities.
What stability issues you are talking about?
What Raspberry Pi are you running?
What's about the power supply?
Sorry but just because a few or the majority of people don't have issues, doesn't mean issues don't exist. You can have bad hardware, a defective pi, faulty SD card, dirty power, low quality usb cables, At the most extreme end, you've got printers that cost $100 now, you honestly think they're using top quality components on those controller boards? Hell no, they're using the most absolute bargain basement power connectors, the cheapest usb plugs, the crappiest usb-serial chips, lord help anyone using a fake ftdi chip (google ftdi gate).
Personally I've been plagued by connection issues on first connect due to one of my control boards, I had to disable the reset line on that board so the controller didn't reset on serial activity. Nothing to do with octoprint, but is an example of printer hardware being the cause of issues.
Many of the people on youtube saying to print from SD may do so because the SD card is attached directly to the printer so there's no risk of the usb connection crapping out, there's no extra steps to go wrong, it's just the sd card and the printer.
@DivideByZero If you want to print from SD, I would suggest taking it out of the printer and putting it in your machine that is slicing. It's far faster and far more reliable than letting the printer act as an sd card reader. It's also far more annoying having to transfer the card from printer to computer, but that's the tradeoff.
As per previous posts here in other threads and mentioned in this one, I would crash or lockup every few minutes, to the point where this was not useable. So far, it is looking to be that the Pi was reading files on the SD it didn't like and messing with the printer. But time will tell, no more print stuff today.
Raspberry Pi 3 B+ with the official RP 2.5A Plug... so it's not that.
I installed RetroPie on the same RP (different SD card) and that was stable as you like off the bat and I would expect that will be putting the RP through it's paces a lot more than OctoPrint ever would.
Sorry, it was not my intension to step on someone's toes. My apologies for this.
What I tried to express, that it is possible to have smooth running OctoPrint.
For myself, I'm struggling to get my MMU2 to work properly.
I could say, I leave it and use only the MK2.5, but I want to have it run.
Seeking the forums for valuable hints, but I don't give up.
So my questions to @DivideByZero to find out what makes his system in stable.
Thanks dude, it certainly does seem to be the way to go... which is a shame but there you go.
At least this has actually led to me getting my platform slightly more stable now.
And you are right in what you say, just because the majority of people don't have issues doesn't mean something is perfect and after all, I am posting here in the get help section. "Well it works for me" is not really any use to someone needing help as it is obviously not working for them.
Thanks, I know it's possible to run smooth as many 3D print people use this and sing its praises.
It's very frustrating when you want to be getting on printing however and a system that should be quick and simple to setup actually introduces a lot of new issues instead of making things easier.
Anyhoo. It seems SD upload is hella slow and so I can sack that off as a bad idea. Shame, but whatever, we move on.
On the plus side, looking in to this might have actually found and fixed my stability issues which seem to be files on the SD card in the printer that it did not like... so maybe I will now be able to enjoy some OctoPrint goodness.
Thanks all - will post back in a few days or so to confirm my findings.
I would bet that it was actually files on the card rather than the card itself.
I expect that Octoprint was doing some kind of operation with all the files on the SD card and causing the issue.
When you use the printer interface, it probably doesn't even scan though the folders unless you manually open that folder and it wont inspect a file unless you tell it to print that.
Octoprint can't even interact with the files on your printer's SD card, at least not in the way I'm guessing you think it does.
Your printer doesn't act like a card reader, octoprint asks your printer for a list of what's on the sd card, which it then reports back. When transferring files, octoprint asks your printer to please start saving this stream of bits to a file on the sd card. It's then up to your printer's firmware to read those bits over the serial connection, and then your printer's firmware saves them to its internal sd card.
Octoprint is only responsible for files you save onto the sd card of the raspberry pi it's running on (or otherwise the storage medium of the server since that might be a spinning hard drive or ssd or anything).
