I'll give that a shot tomorrow. I truly wonder what is going on. The firmware is the stock from Dacbs release, minus the changes we've made here, and my printer itself is pretty stock, so ī wonder if others are experiencing this too....
Printable View
I'll give that a shot tomorrow. I truly wonder what is going on. The firmware is the stock from Dacbs release, minus the changes we've made here, and my printer itself is pretty stock, so ī wonder if others are experiencing this too....
Why not give the EricZalm Marlin a try? It is the "true stock", the one Dacb's is forked from.
https://github.com/ErikZalm/Marlin#
That may not be a bad idea. I'm trying to get moved over to Dacb's fork, but I haven't had time to do the port. The other thing that may make sense is to upload the entire source tree for your Marlin and do a diff of every file. Something small is wrong, but who knows where it is? Moving to the original Eric Zalm branch of the tree would tell us where the problem is. But we still do need to find the root cause of this.
The more I think about it... I think it makes sense to .ZIP up your entire Marlin source tree. I've got the tools to quickly go through looking at every change. If some line of code got accidentally deleted (or changed for no reason), I'll be able to find it pretty quickly. (But go ahead and add those delay's() that is going to be interesting either way)
Thanks guys, I will do that. I was just in the process of downloading EricZalm's Marlin. Obviously I will have to edit my config.h to suite our Prusa's, but I will give that a shot and see how it goes. Anything else to look out for?
Here's my last Marlin, with the delay code. I'm finally getting around to switching back to Visual Studio with Visual Micro, the Arduino IDE is giving me a headache haha!
Attachment 3379
You and I are running almost identical code bases. I have the M600 filament change patched to work without an LCD Panel. And I have the M499 EEPROM Invalidate command. But other than that... We have identical code bases. I checked every source file for differences. There is nothing that would explain this strange behavior. I hate to say this... But I doubt switching to Erik Zalm's code base is going to rectify anything. It is still worth trying... But if I had to bet, I think you will see the same thing.
Well, I don't see anything too different from my Marlin. At least nothing I wouldn't expect to be different, except for one place. Marlin_main.cpp, line 1219, you have the if (axis==Z_AXIS) retract_z_probe(); commented out. Why?
From what I see here comparing our firmware, it looks like it's a hardware issue. Maybe some switches are plugged into the wrong pins.
Hmmm, well that's what I can't believe to begin with, aside from the changes Roxy has suggested, I haven't modified the firmware in any way, aside from the obvious to enable auto levelling etc. I'm curious thought about the (axis==Z_AXIS) retract_z_probe(); being commented out, as I don't think I ever came across that or would comment that out.
Roxy, you mentioned my end stops were inverted? How so?
Ever since the Auto Bed Leveling came out... Different people have had trouble with their Z-Probes banging into the bed during retraction. Also, there was problems with the probe staying down and rubbing as the nozzle is positioned somewhere else on the bed. So there have been various attempts to 'fix' the problem. And there is some baggage in the code because of that. I wouldn't be too concerned about that unless you are having troubles with your Z-Probe staying down when you don't want it down. And the Enhanced G29 is pretty hard core about making sure the Z-Probe is in a good state. So if you care, you might want to move over to the Enhanced G29 code.
I didn't look at it carefully enough. It turns out it is a "don't care" because I don't think you have Max End Stops wired up. You don't home towards Max. But here is what I was referring to:
Attachment 3414
My endstops are set up the same way, Roxy. I wouldn't worry about it.