Saving G29 Bed Level Correction Matrix to EEPROM

[Fri]

How about we start fresh? (It is hard to keep track of everything!) Can you describe the new issue from the beginning? When does it work correctly? When does it start doing bad things?

Right now it works pretty good, printing since 2 hours. But it is very iffy when starting a print or just homing the machine after connecting, if it make the correct z safe move. Sometimes it does, but sometimes it doesn't.
Once my print is done I will be reducing the speed and try again.

[Fri]

I am still not able to solve the issue on one of the machines. It's really weird. After ABL ( I save it to Eeprom) the z probe/stop triggers x&y. I am really not getting it, I have another machine with the exact same firmware that works fine.
Here is again what is happening and it only happens when the ABL is not erased, it doesn't do this after M502.
When I send G28 the machine homes all axises and rests in the front left corner, the z stop is triggered. So if I hit print, my g code sends another G28 and the machine
homes from where it is at. Meaning the machine thinks x & y are triggered when z is triggered, but they are not. M119 shows Zmin triggered, x&y min open.
When now trying to home only x, it moves away from the stop as if it were triggered, but again, it is not.

[Fri]

I am still not able to solve the issue on one of the machines. It's really weird. After ABL ( I save it to Eeprom) the z probe/stop triggers x&y. I am really not getting it, I have another machine with the exact same firmware that works fine.
Here is again what is happening and it only happens when the ABL is not erased, it doesn't do this after M502.
When I send G28 the machine homes all axises and rests in the front left corner, the z stop is triggered. So if I hit print, my g code sends another G28 and the machine
homes from where it is at. Meaning the machine thinks x & y are triggered when z is triggered, but they are not. M119 shows Zmin triggered, x&y min open.
When now trying to home only x, it moves away from the stop as if it were triggered, but again, it is not.

[Roxy]

There is a major effort going on over at GitHub to fix Marlin bugs. The bug you mentioned about the firmware thinking end stops are triggered when they are not is getting a lot of focus. It probably is at the root of some of the 'Air Printing' that people have seen.

Any way... My advice would be if you can live with it for a for a couple of weeks... Soon, there should be a much more stable version of Marlin available. I think a lot of the 'unexplained' behavior is going to just disappear.

[Fri]

There is a major effort going on over at GitHub to fix Marlin bugs. The bug you mentioned about the firmware thinking end stops are triggered when they are not is getting a lot of focus. It probably is at the root of some of the 'Air Printing' that people have seen.

Any way... My advice would be if you can live with it for a for a couple of weeks... Soon, there should be a much more stable version of Marlin available. I think a lot of the 'unexplained' behavior is going to just disappear.

I can certainly wait 2 weeks or so, and thanks again for your help. What's really driving me crazy is that fact that one machine does it but the other doesn't. There is one difference that was relatively obvious and that was that
one machine did show the measured points while doing the G29 while the other machine only shows the final matrix. But anyway, I will check back in a few weeks.

[Roxy]

That almost sounds like you have different versions of the firmware in the two printers. Is it possible one of them isn't running the code you think it is?

[Fri]

That almost sounds like you have different versions of the firmware in the two printers. Is it possible one of them isn't running the code you think it is?

I don't think so, they are both derivatives of your fw with minimal changes, I flashed the one that works good onto the other machine and it did act the same way. On bigger difference is that the machine that
acts up has a viki, but i had that turned off to without a change. I tried different boards and fw and what not and as I mentioned before, the whole thing started several month ago when I changed the z offset on the viki.
One thing that may be interesting is that sometimes depending on how I connect to the machine that works fine, it acts up to, I then do a M502 and G28/G29 and everything is good. But that same procedure doesn't help on the
the "bad" machine. It only does it when I don't let G29 erase the abl information. So let's say I home all, safe z brings the z stop sensor after touching home switch x & y to x10y10z0 now I hit print or g28, it moves to x20y20z0 without going to the home switches. If I send a M502 at this point, it will send x & y to the home switch and then back to the safe z postion and it will keep doing that until I bed level....

[Roxy]

Yeah... This sounds all too familiar with the issues being debugged over at GitHub. Some how, LCD Panels make the problems worse. But there is some weird Z Offset bug that is randomly popping up and causing trouble. The good news is everybody is focused on it and very soon I expect things to stabilize.

[adamfilip]

any news related to the ABL Matrix?

[Roxy]

any news related to the ABL Matrix?

Things are more stable over at GitHub with regard to Auto Bed Leveling and Marlin. But the latest branches are still sick. With that said, they have provided a Tag to get the v. 1.0.2 branch and that is pretty trust worthy. You can use that for the next couple of weeks or month until things get to where they need to be.