G29 cannot load mesh from eeprom on LPC1769

[alexxy]

Hi!

Seems like i found an issue with G29 and UBL. Mesh cannot be loaded from eeprom

ttyACM1 64°> G29 P1
SENDING:G29 P1
Default storage slot 0 selected.
Mesh invalidated. Probing mesh.
ttyACM1 64°> G29 T
SENDING:G29 T
Bed Topography Report:
    ( 20,360)                                      (360,360)
        0       1       2       3       4       5       6
 6 | -2.696  -2.281  -2.066  -1.794  -1.532  -1.458  -1.422
   |           
 5 | -2.484  -2.165  -1.947  -1.739  -1.528  -1.416  -1.377
   |           
 4 | -2.598 2.342  -2.242 [-2.059] -1.917  -1.877  -1.828
   |           
 2 | -2.740  -2.449  -2.386  -2.259  -2.100  -1.997  -1.966
   |           
 1 | -2.952  -2.814  -2.688  -2.610  -2.409  -2.296  -2.144
   |           
 0 |   .       .       .       .       .       .       .
        0       1       2       3       4       5       6
    ( 20, 20)                                      (360, 20)
ttyACM1 55°> G29 P3
SENDING:G29 P3
ttyACM1 55°> G29 T 
SENDING:G29 T
Bed Topography Report:
    ( 20,360)                                      (360,360)
        0       1       2       3       4       5       6
 6 | -2.696  -2.281  -2.066  -1.794  -1.532  -1.458  -1.422
   |           
 5 | -2.484  -2.165  -1.947  -1.739  -1.528  -1.416  -1.377
   |           
 4 | -2.598  -2.252  -2.130  -1.913  -1.760  -1.656  -1.589
   |           
 3 | -2.710  -2.342  -2.242 [-2.059] -1.917  -1.877  -1.828
   |           
 2 | -2.740  -2.449  -2.386  -2.259  -2.100  -1.997  -1.966
   |           
 1 | -2.952  -2.814  -2.688  -2.610  -2.409  -2.296  -2.144
   |           
 0 | -2.952  -2.814  -2.688  -2.610  -2.409  -2.296  -2.144
        0       1       2       3       4
    ( 20, 20)                                      (360, 20)
ttyACM1 55°> G29 S1
SENDING:G29 S1
Mesh saved in slot 1
Done.          
ttyACM1 55°> G29 A
SENDING:G29 A
Unified Bed Leveling System v1.01 active.
ttyACM1 54°> m500
SENDING:M500
Settings Stored (613 bytes; crc 9040)
Mesh saved in slot 1
ttyACM1 54°> m500
SENDING:M500
Settings Stored (613 bytes; crc 9040)
Mesh saved in slot 1
ttyACM1 54°> G29 T 
SENDING:G29 T
Bed Topography Report:
    ( 20,360)                                      (360,360)
        0       1       2       3       4       5       6
 6 | -2.696  -2.281  -2.066  -1.794  -1.532  -1.458  -1.422
   |           
 5 | -2.484  -2.165  -1.947  -1.739  -1.528  -1.416  -1.377
   |           
 4 | -2.598  -2.252  -2.130  -1.913  -1.760  -1.656  -1.589
   |           
 3 | -2.710  -2.342  -2.242 [-2.059] -1.917  -1.877  -1.828
   |           
 2 | -2.740  -2.449  -2.386  -2.259  -2.100  -1.997  -1.966
   |           
 1 | -2.952  -2.814  -2.688  -2.610  -2.409  -2.296  -2.144
   |           
 0 | -2.952  -2.814  -2.688  -2.610  -2.409  -2.296  -2.144
        0       1       2       3       4       5       6
    ( 20, 20)                                      (360, 20)
ttyACM1 54°> G1 Z10
SENDING:G1 Z10
ttyACM1 54°> G1 Z10
SENDING:G1 Z10
ttyACM1 54°> G1 Z15
SENDING:G1 Z15
ttyACM1 54°> G1 Z0
SENDING:G1 Z0
ttyACM1 54°> G1 X100 Y100
SENDING:G1 X100 Y100
ttyACM1 54°> G1 X300 Y300
SENDING:G1 X300 Y300
ttyACM1 54°> 
ttyACM1 54°> 
ttyACM1 54°> 
ttyACM1 53°> 
ttyACM1 53°> 
ttyACM1 53°> G29 L1
SENDING:G29 L1
Mesh loaded from slot 1
Done.          
ttyACM1 53°> G29 T
SENDING:G29 T
Bed Topography Report:
    ( 20,360)                                      (360,360)
        0       1       2       3       4       5       6
 6 |   .       .       .       .       .       .       .
   |           
 5 |   .       .       .       .       .    [  .   ]   .
   |           
 4 |   .      .       .       .       .       .
   |           
 2 |   .       .       .       .       .       .       .
   |           
 1 |   .       .       .       .       .       .       .
   |           
 0 |   .       .       .       .       .       .
    ( 20, 20)                                      (360, 20)

[alexxy]

Another addition. I cannot reproduce this on mega2560. So seems like this bug is platform-dependent

[gloomyandy]

Works fine for me with LPC1768. What happens if you simply create a mesh, store it, clear it and then reload it (rather than all of those other steps)...

G29 P1
G29 T
G29 S1
G29 P0
G29 T
G29 L1
G29 T

We also need to know where you are storing your eeprom settings (there is no actual eeprom on an LPC176X). How recent is your build? Do you have FLASH_EEPROM defined in the file:
Marlin/src/HAL/HAL_LPC1768/persistent_store_api.h
As always full config files and details of the control board, any changes to the pins settings or other Marlin config will help.

[alexxy]

My build is current bugfix-2.0.x (from today)
FLASH_EEPROM is defined

Aren't my workflows equivalent?

It's basically

G29 P1
G29 T
G29 S1
G29 T
G29 L1
G29 T

configs.zip

[gloomyandy]

Did you actually try the simplified workflow? Did you still see the problem?

[gloomyandy]

to clarify, no the workflows are not the same. You original post contains several m500 commands which also store things into the eeprom. It could be that this is causing a problem, I'd like to get a very simple test case.

[alexxy]

to clarify, no the workflows are not the same. You original post contains several m500 commands which also store things into the eeprom. It could be that this is causing a problem, I'd like to get a very simple test case.

Yes. But anyway both should work. Right?

[gloomyandy]

So have you actually tried the simple test I posted above? What output did you get?

[gloomyandy]

Also do your other settings load correctly from the eeprom? Can you try changing something saving it and then reloading it?

[alexxy]

So have you actually tried the simple test I posted above? What output did you get?

I cannot test it now. Printer is at my work.

Also do your other settings load correctly from the eeprom? Can you try changing something saving it and then reloading it?

Changing parameters and reloading works as expected. Seems like only problem is mesh

[Roxy-3D]

I suggest the following: Do a M502 and M500 just to get your EEPROM 'correct' with what ever version of the firmware you are using. Then build a mesh. Save the mesh to a known location. For example G29 S1
The mesh should be in EEPROM at this point.

But lets get it to auto load. Activate UBL. G29 A followed by M500 When you restart the printer, you should be able to do a G29 W T and see that UBL is active, and the mesh in slot 1 was loaded. And it should print the mesh.

[alexxy]

I suggest the following: Do a M502 and M500 just to get your EEPROM 'correct' with what ever version of the firmware you are using. Then build a mesh. Save the mesh to a known location. For example G29 S1
The mesh should be in EEPROM at this point.

I did exactly that when i notice that i cannot load mesh with G29 L1.

But lets get it to auto load. Activate UBL. G29 A followed by M500 When you restart the printer, you should be able to do a G29 W T and see that UBL is active, and the mesh in slot 1 was loaded. And it should print the mesh.

It didnt happened for me. I get empty mesh

[Roxy-3D]

What does G29 W say when you power up (or reset) the printer? Does it say which slot is the default mesh slot? Does it say UBL is active or inactive?

[gloomyandy]

I think to get anything useful out of G29 W you will need to have UBL_DEVEL_DEBUGGING defined, it is off by default.

I've just rebuilt using the current (as of 10 minutes ago bugfix-2.0.x) and I can happily store and load a mesh from eeprom (which is being emulated using flash). I don't think there is any difference between the LPC1769 and LPC1768 (which I have) in this area. Given that both the normal configuration and mesh storage use the same system to load and store and that the storage is spread throughout a larger sector of flash, I'm stumped.

Did this ever work for you? Any idea how long ago? Was it using FLASH_EEPROM if/when it worked before?

You could try turning FLASH_EEPROM off (which should then use a file on the sd card for eeprom storage). If that worked then it would point towards a problem with the flash eeprom emulation.

@p3p any thoughts any idea if anything is different between the two devices that might be causing this?

[p3p]

any thoughts any idea if anything is different between the two devices that might be causing this?

There are no differences, LPC1769 is just a binned higher quality LPC1768 that can be clocked higher.

[thinkyhead]

Is there some possibility that the E2END value is incorrect (too large) for the specific EEPROM method in use?

[p3p]

E2END shouldn't be an issue we avoid using that constant now in Marlin core and the PersistentStore implementations that it doesn't apply to.

[alexxy]

Ok Any ideas what to do? Or may be i can rebuild it with LPC1768

[gloomyandy]

Can you try editing the file persistent_store_flash.cpp in the HAL_LPC1768 directory and comment out all calls to PrepareSector and then rebuild and try it again. I can't reproduce your problem at all and I've been trying pretty hard!

[gloomyandy]

Oh and take a look at this issue... #12442
If it is easy/possible for you to grab a copy of the old persistent_store_flash.cpp (the one with extra debug in it) then it would be interesting to see what output you get.

[alexxy]

This was fixed

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.