ubl mesh not saving

[darco415]

Running latest self compiled....jus re-flash with newer build. Ran the create new mesh....finished, confirm to eeprom. Viewed mesh., ok,,....Restart printer, no mesh available?
4.2.7 UBL 10x10
thxs

[darco415]

it may be a wiring issue on the bltouch as I was getting probing failures as well..I had spliced some wires to the z endstop....ran a manual mesh with a g29 s1 which seem to stick,,,,running print now after checking wiring and re-splicing wiring..ordered a new bltouch wire harness

[embraceentropy]

I was having this issue. My save slot was set to "-1". I set the save slot to "1" and it was retained after a power cycle. It is in the leveling settings on the LCD.

[xantrk]

I believe G29 L loads the latest mesh it founds, but lets wait for Jyers' answer

This may be due to the slot number being a new EEPROM location which if blank would read as FF (-1 in 2’s complement) It is advisable to reset EEPROM after a firmware upgrade for this reason.
@Jyers if this is a possible scenario could a check on load set the value to zero if out of range?
Just checked & mine was fine (0) so it could be quite a random issue.

[gothcha]

This may be true, but the problem @darco415 had was the mesh was not storing in the first place.

[darco415]

I just cold fired up my ender and didnt even check if mesh is present, printing fine. I think the manual entry of g29 s1 worked for me. Later I will create new mesh thru the fw and see then if it stores it correctly

[Jyers]

@gothcha You have a point about the empty location. I figured when defining the bit fields that on a fresh flash it would initialize them to zero. I'll see if I can recreate the issue.

[gothcha]

Jacob, the slot number is defined as a signed int in UBL.cpp so FF would indeed be -1 when loaded from a blank EEPROM

int8_t unified_bed_leveling::storage_slot;

I guess the gcode.process_subcommands_now_P(PSTR("G29 S")); does not check for a 0 or 1 slot number.
You could read the slot number first and force it to zero if it is not 0 or 1?

I am surprised that the EEPROM load G code does not perform this check.