That looks pretty good.
It worked?!
Yes it did, but still, no joy trying to Auto Z-align or even Bed Level.
Problem solved!!!
Replace the board and everything is working!
I can’t beliave it, that board was brand new, it was just seating in the shelf unopened for about 3 months.
1 Like
Oh boy. That is strange.
Right, the board has no noticeable damage, nothing burnt that I can see…
1 Like
An m48 worked, but neither M29 or 34 did. I can’t believe that is somehow board related, what the heck?!
1 Like
I decided to replace the board after reading on Reprap forum where a guys had the same problem with the Octopus Board
If the firmware can see TRIGGERED, then I have no idea how this could be hardware related. That’s what bugs me.
1 Like
Exactly.
I haven’t gone back through the whole thread, but was the eeprom cleared out and reset at any point? Following a Marlin upgrade (years ago) I had some issues I thought were firmware related, but turns out the “layout” of values stored in the eeprom changed, so nonsense values stored previously were causing aberrant behavior.
2 Likes
Hey Tom, yes it was several times, before and after I loaded the firmware.
2 Likes
I guess while we are on that subject can you take a quick look at your accel values. A bunch of mone were at 50k instead of ~3k. I know I cleared my eeprom as well so it might be a firmware setting gone bad.
I checked and they are all 3K, no changes here.
I will play with the printer a little more when I get home, hope to get the first print out tonight. I only have couple of days before a week long work trip.
1 Like
I have a weird one for you.
That new repeat I have been having issues with, odd accels, beat up grub screws, poor prints, every time the second layer was shifted even though I rebooted, new gcode…I removed the microSD and it is perfect now. Reinitialized the eeprom and the accels are perfect.
I had issues on my MPCNC as well. For some reason I pulled the card to flash it and it fixed it there as well. I do not remember what that issue was but it was a few months back.
I am wondering if the micro SD is the cause of your problems as well. I see it is in, in all the pictures.
1 Like
That is a great point. I will try the “busted” board again without the SD card.
I agree with all of you, make no sense the board been the problem, everything point to “Firmware/human error” issue.
I just paused the printer to show this.
The nasty one in front is with the card in. The one behind is currently printing. Only difference is no card in the board.
Sooooo weird.
Any chance there’s a file on the board being treated as autostart gcode that’s messing with settings? See Marlin Documentation
I hope not. The SKR does rename the firmware file so it should not read it. I am thinking it is some sort of shared pin situation…but that is pure speculation.
I would not be surprised if having an SD card in the slot was causing pausing, while it handled sd card interrupts, or reading the card contents for some reason. I would be surprised if that ended up changing settings like acceleration. But stranger things have happened.
1 Like