I have never printed off of the SD card before,

@foosel That was it! The firmware thing. I forked the one they used for Bukobot, cherry picked in that commit you link to that fixes it, now it works like a charm. starts printing immediately after clicking print. Thanks!

@Deezmaker Went ahead and posted about it on the Bukobot forums and did a PR with the cherry pick in it if they want to use that. Anyone using bukobot that is curious about the fix see my PR: Cherry-picks commit to fix sd card file opperations by jonyo · Pull Request #1 · whosawhatsis/Marlin · GitHub

From what I read, the only changes are to the configuration and configuration_adv so maybe they can just re-fork a more recent stable tag or something that is after the fixed commit and re-apply the configuration changes. Or just merge in my PR.

EDIT: oh and even after the fix, the filename listed has extension of .gco so I guess my original assumption that it only shows 3 chars of the extension was correct, was not because of the bug lol…

Hah! :slight_smile:

Might also be worth to cherry pick the other fixes of mine mentioned in the FAQ. Each of them was the direct result of users reporting issues “in OctoPrint” which then turned out to be caused by the firmware.

@foosel @Diego_Porqueras_Deez These are the ones right? Pull requests · MarlinFirmware/Marlin · GitHub

In that case if might be worth it to go the route of re-applying the config changes to a more recent stable branch for Marlin (if one exists, I had trouble figuring out what was considered stable, the 1.1 tag’s readme was still showing it was for development only). That’s why I ended up cherry-picking just the fix for my own use.

Those and possibly also the fix to https://github.com/MarlinFirmware/Marlin/issues/1568.

Whether to base off a new stable version already containing those or cherry picking should decide those who have to support that fork - there’s a lot of changes and making sure everything still works as it should after basically a rebase could be “fun”. I wouldn’t hold it against anyone in the current situation with the Marlin development to steer clear of that.

@foosel I might go ahead and do cherry-picks for all of those committs as well and do another PR, I see that @Whosa_whatsis already merged the original PR (unless he beats me to the cherry picks). The printer is acting a little odd (good prints but sloooow, no matter what I use in cura settings, I’ve only managed to make it go slower not faster lol). If getting those fixes for the firmware doesn’t help the printer I might do another post with video of what it’s doing to see if anyone has ideas. Thinking either just some odd setting I’m missing somewhere in new version of cura, cura bug, or maybe something going out on printer…

Anyways thanks for the info!

Accidentally set the top speeds/acceleration too slow when reflashing?

@foosel I thought of that, I checked the max speeds and they seemed correct, I don’t know what the max accelerations should be though, here they are:

#define DEFAULT_MAX_ACCELERATION {800,800,100,10000} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.

#define DEFAULT_ACCELERATION 3000 // X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION 3000 // X, Y, Z and E max acceleration in mm/s^2 for retracts

The full config file:

The speed thing I’ve been trying to tackle since I started using my printer again in the last few weeks. The one thing that has remained consistent is I’ve been using the latest version of cura. Seems like no matter what I can’t get it to go fast on solid layers, it seems to go decent on infill though. Then I managed to slow it down even more by turning on firmware retraction in the starting g-code LOL. So I was going to apply those firmware fixes, see if I can get it to print fast on solid layers, if not post full details with a video.

Me talking out loud: Something that just came to mind, the “last time” I used the printer, I was printing with t-glase so had the speed settings turned way down… I wonder if maybe there is some setting on the older version of cura, that maybe isn’t exposed (or is buried deep in the UI or something) left over from that… Though I did a setting load profile so you would think anything like that would have gotten over-written. But maybe if it was a deprecated setting… maybe if I look at the settings profile file source I might be able to spot something… Hmm…

Update: messed with the retraction settings to speed it up and the time now matches what cura thinks it will take plus about an hour. But I think it’s grinding the filament, it started way under extruding. I’ll experiment with it some more over time but for now will stick to what works but is slower. Probably also related to filament quality, working with some older PLA.

Anyways thanks for the help! :slight_smile: