{"action":"created","issue":{"url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/3750","repository_url":"https://api.github.com/repos/MarlinFirmware/Marlin","labels_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/3750/labels{/name}","comments_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/3750/comments","events_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/3750/events","html_url":"https://github.com/MarlinFirmware/Marlin/issues/3750","id":154741957,"number":3750,"title":"Random loss of MESH settings","user":{"login":"WheresWaldo","id":651136,"avatar_url":"https://avatars.githubusercontent.com/u/651136?v=3","gravatar_id":"","url":"https://api.github.com/users/WheresWaldo","html_url":"https://github.com/WheresWaldo","followers_url":"https://api.github.com/users/WheresWaldo/followers","following_url":"https://api.github.com/users/WheresWaldo/following{/other_user}","gists_url":"https://api.github.com/users/WheresWaldo/gists{/gist_id}","starred_url":"https://api.github.com/users/WheresWaldo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/WheresWaldo/subscriptions","organizations_url":"https://api.github.com/users/WheresWaldo/orgs","repos_url":"https://api.github.com/users/WheresWaldo/repos","events_url":"https://api.github.com/users/WheresWaldo/events{/privacy}","received_events_url":"https://api.github.com/users/WheresWaldo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2016-05-13T15:42:27Z","updated_at":"2016-05-13T23:14:16Z","closed_at":null,"body":"There are a bunch of us using RC6 on the Robo3D forums and they have all gradually been moving to MESH bed leveling. All of us have seen strange behaviour that we cannot duplicate on a consistent basis. We do not even know how to make it happen. The issue is:\r\n\r\nAfter performing the MESH routine, either on LCD screens or in terminal mode and then saving memory locations to EEPROM, we can all get a handful of prints that work perfectly. After a period of time a subsequent print will not print properly and upon investigation it is discovered that MESH is no longer enabled.\r\n\r\nIt can usually be restored by adding M501 to the start up gcode. Typical start up code will contain G28 followed by G29 (very useful to see if MESH is enabled). Most of us have made an adjustment to add M501 between the G28 and G29 commands. It does not appear to be 100% reliable. This is spread across several users, some with printers that stay on 24/7 (like mine) and others that are completely shut off between printing sessions.\r\n\r\nWe are at a loss to figure out why MESH leveling exhibits this behaviour and thought opening a ticket, despite having little details as to the circumstances might be the best approach to resolving this issue.\r\n"},"comment":{"url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/comments/219181147","html_url":"https://github.com/MarlinFirmware/Marlin/issues/3750#issuecomment-219181147","issue_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/3750","id":219181147,"user":{"login":"epatel","id":81102,"avatar_url":"https://avatars.githubusercontent.com/u/81102?v=3","gravatar_id":"","url":"https://api.github.com/users/epatel","html_url":"https://github.com/epatel","followers_url":"https://api.github.com/users/epatel/followers","following_url":"https://api.github.com/users/epatel/following{/other_user}","gists_url":"https://api.github.com/users/epatel/gists{/gist_id}","starred_url":"https://api.github.com/users/epatel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/epatel/subscriptions","organizations_url":"https://api.github.com/users/epatel/orgs","repos_url":"https://api.github.com/users/epatel/repos","events_url":"https://api.github.com/users/epatel/events{/privacy}","received_events_url":"https://api.github.com/users/epatel/received_events","type":"User","site_admin":false},"created_at":"2016-05-13T23:14:16Z","updated_at":"2016-05-13T23:14:16Z","body":"Hmmm. Sounds really weird. Not sure I'd contribute that to MBL, as it is just an offset that is added to the position the printer think it is at. Doing a `G29 S0` before and after things get weird should show an identical setup, I'd guess, because it should always be reading from the mesh values (nothing is changing values in the mesh). If it is not the same values before and after something is rotten in denmark (that meaning a severe bug exists that overwrite memory this memory somehow). The actually inject point for MBL is an expression as\r\n\r\n> print.z = model.z + mbl.z(model.xy)\r\n\r\nBut a sidenote, 2 yrs ago I was testing \"raise when travel\" or similar feature in Slic3r. Doing this on an old Sells Mendel w/o MBL (not implemented back then). When enabled raised Z/the Nozzle and then lowered it again. This had a weird effect I did not expect because it drifted, so I stopped using that. What My reasoning or expectation back then was that the floating point number calculations in the Z axis wasn't good, and probably really bad for relative movements. I always do a `G28` with all axis as part of starting a print. This should sync the left part of the above formula. There is really two coordinate systems in play here, the 3D model/gcode and the printer hardware which is the integer counters in the steppers routine. I expect doing many relative movements is hard to keep track of absolut position, i.e. moving X axis 10 times +0.1 and then going back a single -1.0 (see https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html). So this was what I expected happening when I enabled those extra lift. Some numbers being worse than others, i.e 0.1 is really bad compared to 0.125. I haven't investigated the full path how the numbers go from gcode coordinates to stepper counters but that path is very important, and absolut positioning is definitely preferred I believe."}}