I have never printed off of the SD card before, does it normally take a while to “load up” before it starts the print? How long should I wait before I kill it and check the formatting on the SD card and such? (and if it is not normal to load up that long, any tips?) Here is a sample from the terminal on octoprint:
When I use Octoprint on my Simple Metal it takes a few minutes to load onto the SD. If you’re just transferring the file from your computer to the SD through an SD reader then it shouldn’t take longer than transferring a normal file. Although all this depends on the SD card, you can buy a faster one. Just make sure you don’t go too big, printers usually don’t recognize anything over 8 GBm for the SD.
Hmm, yeah I put the gcode file on the sd card with a card reader (it was going to take 30 minutes to transfer through octoprint). then put the sd card in the printer. Then mounted it through octoprint (they call it initialize), the file showed up, I clicked print on the file… Then it was loading forever. Finally canceled it after about 20 minutes, think it doesn’t like the 8gb size, I read somewhere it doesn’t work well with sd cards over 2gb.
@Jonathan_Foote That’s possible. I haven’t tried using Octoprint to initialize a file I put on the SD card from my computer but it shouldn’t take long at all since the gcode is read line by line from the SD and not sent to the printer. I’m using a standard (i.e. not one of the ultra fast Sandisk or Samsung) 2 GB micro SD since the printer didn’t like the 32 GB Samsung one from my old phone. You should be fine with 4GB on the BukoBot but just to check let’s hit up @Whosa_whatsis .
My Printrbot Simple Metal begins to print from the SD card within about 2 seconds of powering up. I guess that is the expected behavior for most 3D printers.
I had an issue with Octoprint not recognizing cards on the machines I’ve upgraded to 1.2.6 a few days ago. Prior to the upgrade they mounted and would print right away. I tried 3 cards, 2, 4 , 8 GB, all worked in the display and other machines, just not on the 1.2.6 machines.
What I did to fix it was leave the card inserted. I halted the Pi (sudo halt -n on the command line) power cycled both the Pi and the printer PSU. Brought it up as normal and the card mounts and reads. Rebooting and restarting the daemon didn’t work, I had to do a full power cycle of both the Pi and the RAMPS.
@Mark_Rehorst I agree that print quality is greatly improved when you print from an SD card. I use Octoprint to monitor my printer from my desktop and to render time-lapses. I also don’t mind the slow SD card upload from Octoprint and it saves me the effort of trying to get the micro SD out of my Simple Metal each time I want to print. My only problem is that it greatly shortens the file names of the uploaded gcode files.
@Mark_Rehorst I use Octoprint so I don’t have to mess around with SD cards and also so I have a remote control (and remote view with the camera). Its running on a Raspberry Pi on my network, so I can literally hit the power button on my printer and control the printer from any desktop/laptop/phone/tablet in or outside of my house. This means I can go out when big jobs are running and occasionally check in.
@Adam_Steinmark you shouldn’t see an improvement in print quality (not unless something is wrong with your coms and its REALLY slow) but you might experience greater reliability when printing from the SD if your setup drops out or your PC crashes or whatever.
Personally I’ve always printed directly with Octoprint and it been completely without issues except just recently I’ve had the Pi crash a couple of times on really big ABS jobs due to the temperature inside the enclosure. I need to move the Pi outside of the print enclosure.
@Daniel_Bull He’s not loading the file over serial. He mentions that in his first reply on the thread. He’s using a card reader to write the file. The issue is once he get the card and fille to the printer, it does not print.
@Daniel_Bull I noticed significant differences in layering with the SD card on thin structures. It’s not as visible on larger objects but with thin artifacts the layering is much more precise.
@Mark_Rehorst You don’t give up the reliability of printing from the card nor are you giving up the gcode to a host machine. Octoprint starts the print from the card just as you would with any printer host or from an LCD connected to the computer. I use Octoprint to control multiple printers via a single host over the network without dedicating the host to the printing task. I also poll the various machines for print status.
In the main shop I have a Pi with display running guillford’s Printerview (I’ve also ported Printerview to iOS) so I can see from in there what the status of the bots are in the print studio in the next room. The machine control panel in Octoprint (or any other printer host) I find quicker and easier to use than toggling through the lcd displays. I’ve started using guillford’s octorprint-iOS so it’s a bit more portable as we’re getting ready to split the farm into two rooms.
.
@foosel hmm interesting, I actually read that exact link in my own troubleshooting process, but silly me thought, “nah I compiled it myself just last year, that’s bound to be talking about some really old bug”…
Thinking more on it though, in octoroon’s it did list the filename without the last e in .gcode filename… At time thought it was just shortening to 3 chars…
I’ll grab the latest version and make sure it includes the changes mentioned in the commit it links to next time I’m on a computer. Sadly, the original place I pushed the firmware from I have no idea so I can’t look at the source to verify.
I started down this path because I had 2 prints fail, from what seems like the pi crashing (nothing in any logs I could find,raspberry seemed to have rebooted). Thinking I had a crummy power supply or something. Don’t have any extra money to drop on a reliable power source at the moment, stuck with what i have for now. So for long prints I wanted to still have remote control from octoprint, but printing off the SD card in case my unreliable pi crashed again, the print would carry on without there pi.
To add to the “why octoprint” discussion that cropped up in the thread… I already said part of reason. Other part, I like being able to monitor remotely and kill it from the next room if a print starts to go sideways. With an sd card plus octoprint you get higher reliability of printing from SD card plus convenience of remote monitoring and control. Plus I’m a web developer, so I like playing with this sort of setup.
@Jonathan_Foote if it isn’t any of the mentioned firmware issues that are at work there, next thing would be to try to start a print from sd again and grab the full contents of the terminal tab or serial.log for that. in order to start a print from sd, OctoPrint tells the firmware to select file x and then to start printing from the selected file. then it polls the printing status again and again, that’s the M27 you are seeing there. But since the first value (current position) isn’t increasing, something went wrong either while selecting or starting the print and to fix that we need the log from that part of the process.
@Mark_Rehorst Regarding the “why OctoPrint” discussion, it’s already been explained perfectly here - you can print from the printer’s sd, starting it from OctoPrint and get the remote control and monitoring capabilities you wouldn’t have if only relying on the printer’s LCD controller (fun fact: my printers all have an sd card, but only one has a controller, and I only bought that to be able to test stuff with M117 - I don’t need it otherwise and actually find its usage quite uncomfortable). But of course, if you don’t need or want that, that’s fine too
