[BUG] Mesh inset settings do nothing

[Arson31]

Did you test the latest release build?

Yes, and the problem still exists.

Bug Description

Updated to MAY 2024 Rev.2 build. (Aquila_GD32_MM-ProUI-EX-05-23.bin)

I set the X maximum to 199.0 because I'm using a Satsana shroud for the Haldis Red Lizard Q1 like I have with the previous builds. After setting and saving the settings the shroud still crashes onto the LCD screen mounted vertically to the right of my Aquila.

I set the X maximum to 160 (which should be dead center) and the shroud still crashes into the screen.

Printer Model

Voxelab Aquila

Model Type

OG

Your Mainboard

Aquila GD32

Other Mainboard Type

No response

Add-ons that could be involved

Satsana shroud for the Haldis Red Lizard Q1

ProUI-EX | Extra Features?

Yes

Bed Leveling

MM - Manual Mesh Bed Leveling

Did you include your own configuration files?

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[classicrocker883]

how about the Physical Settings, under the Control menu? shouldn't this be adjusted instead of the Mesh Inset?

[Arson31]

@classicrocker883 I set the X max on physical settings to 180, stored settings, and it still crashes into the lcd screen.

[classicrocker883]

so I'm a bit confused. physical settings are one thing, and mesh inset are another. being able to set the bed dimensions, X/Y Bed Size, and X/Y Min/Max should be working normally.

if you set it to max 180, what then is the actual limit that it ends up crashing?

[Arson31]

@classicrocker883 The mesh X maximum was set to 199.0 in the Mesh Inset settings so I guess that's the limit. It never crashed into the LCD screen when I set the mesh X maximum to 199.0; I was able to create the mesh in the past.

[classicrocker883]

I had made some changes regarding mesh_inset code, how it is defined. I was able to test with probe firmware fine, so I have a suspicion of what it can be.

could you tell me which firmware release did work fine last that you know?

I will try some changes and upload a firmware file for you to try

Update:
Aquila_GD32_MM-ProUI-EX-test.zip

here you can unzip this and flash this update see if this works. please let me know if this fixes the issue. (dont worry about the file name just place into the SD card like normal)

[Arson31]

@classicrocker883 I think it was the November release of last year, I couldn't remember it's been a while since I updated the firmware.

I'm using a 3x3 mesh and I tested Aquila_GD32_MM-ProUI-EX-test.zip. The 1x3 point of the mesh (the last X point until it begins the next Y set) is at the middle of the bed. The 2x3 is maybe 1 inch or 1/2 inch away from the 1x1 which the 1x1 point is right where the X home is.

Adjusting the X maximum mesh inset to 220 (when it was 210) does not make a difference, the 1x3 point is still at the middle of the bed.

[classicrocker883]

okay, give this one a try, that should do it.

Aquila_GD32_MM-ProUI-EX-test2.zip

[Arson31]

@classicrocker883 Same. The 3rd probe point is at the middle of the bed.

[classicrocker883]

Aquila_GD32_MM-ProUI-EX-test3.zip
Aquila_GD32_MM-ProUI-EX-test4.zip

heres a couple more tests. I went back and took a look through the code from when you say it worked, I couldn't find anything that stood out, but made a couple changes I thought would work.

if you can, make a quick video and upload it, that'll help me understand whats actually happening.

[Arson31]

@classicrocker883 Neither of the two made a difference.
Here's a quick video of what I'm talking about. It doesn't probe the entire bed just half of it.

[vw72]

I don't know if this helps, In the physical settings menu, I set the max bed size to 230 for both x and y and the bed size to 220 for both of them. I then set the mesh inset to 10.0 for each. I'm using a bltouch, not manual, but maybe these settings will have the head move to the right positions for the mm.

[classicrocker883]

I'm not sure what's going on, I will have to perform some tests to figure it out. because I had updated the mesh inset code, I tried reverting to what it was originally, so i'll have to do some git bisect I think all the way back to November, so thats gonna take some time, trial and error.

looking back and comparing the code didn't give much clue. it is just odd how the mesh is appearing to be almost exactly half of what it should be.

for now I suppose either use the last build release which worked, or work with what you got. because technically with a good and level bed you should not need any active bed leveling, that is even if there is slight variation +/-0.10, that isn't really significant enough to effect the first layer. I know with mine I can turn active leveling off and there's no noticeable difference.

just hang in there i'll try and figure this out.

[Arson31]

@classicrocker883 It could've been either the November or October release, they may have the same logic so I doubt it makes a difference.

[RCP1990]

Im having a similar issue when using the June UBL PRO UI. my Aquila has an ender extender kit so my bed is 400mm x 400mm. Ive set my physical settings and mesh settings to 400mm. When I home my Z axis, it correctly goes to the center of the bed but when I try to make a mesh, it probes based on the default ~220X220 bed size instead.

[classicrocker883]

@RCP1990 have you used an October or November version? if so, did it work normally then?
also, do you experience the same kind of result how it is half of the bed, or is it a bit different?

that is interesting since it is UBL, yet works fine on default bed sizes.

[RCP1990]

I have not. ill install the November and test it out.

[classicrocker883]

what .bin file do you use? chip and version and such? because I may have found something and I can provide and updated firmware for you to test.

[classicrocker883]

GD32-MM-ProUI-EX-July-Test1.zip
@Arson31 I made another if you'd like to try to see if this works now

[RCP1990]

@classicrocker883 UBL works as expected on the November release. (im using a G32 Aquila and the UBL Pro UI 7x7 bin, for the record)

[Arson31]

@classicrocker883 Same problem with 3x3 mesh as #143

[classicrocker883]

@Arson31 @RCP1990 thanks for confirming. well I uploaded updated releases for July 2.1.3f-7 here.

I looked back and reverted the things which had to of caused what started the issue.
if you try the new build let me know if this has solved it

[Arson31]

@classicrocker883 No change with JULY 2024 2.1.3f-7.

[classicrocker883]

well I hate to say it, but it would be great it you could try like the December, January, Feb... and so on, from the working November (or is it November Rev. 1?) until you get to the one that doesn't work. that would be super helpful.

even after comparing then from now I still cannot find why it would the mesh would be like in half

for example, I have suspicion in February.

Try this:

• If January build works
• and February Rev. 1 build does not...

then that will at least narrow it down. again, above is where I would start. please let me know if you test these out.

---

Here is a list of the other releases if that helps out:

4. APRIL
   April. build

3. MARCH
   March. build

2. FEBRUARY
   February Rev 1. build
   February. build (Warning: may have an issue, so this can be skipped)

1. JANUARY
   January. build

12. DECEMBER
    December Rev 2. build
    December Rev 1. build
    December. build

11. NOVEMBER
    November Rev 1. build
    November. build

[classicrocker883]

I really appreciate the help trying to solve this. I made just one more test file which is really optional, it would be much better going month by month releases and letting me know the point it goes from working to not working.

GD32-MM-ProUI-EX-July-Test2.zip

This is a separate test which I took November and copied the current dwin.cpp (main UI display file). this should work - but if this doesn't work then it will mean its something in this file and should narrow it down.

actually it's not exactly the November release, but close enough.

again at this point there has been lots of changes since November so finding where one release works and the next doesn't is the best course of action and should really help solve the issue.

[Arson31]

@classicrocker883 The GD32-MM-ProUI-EX-July-Test2.zip had no change. The February Rev. 1 build probes the entire bed properly using the 3x3 like it had in the past.

[classicrocker883]

so youre saying Test2 works as it should, or no?

here is another test which I added the workaround for the mesh inset, which is present in November, and that I had previously removed thinking I solved the issue before.
GD32-MM-ProUI-EX-July-Test3.zip

if this works then thats gotta be it.

[Arson31]

@classicrocker883 Sorry for the wait, GD32-MM-ProUI-EX-July-Test3.zip works as it should.

[classicrocker883]

so I uploaded new releases, this should be fixed!

[Arson31]

@classicrocker883 I flashed the latest firmware today and the issue is still there. GD32-MM-ProUI-EX-July-Test3.zip and the February Rev. 1 build works.

[classicrocker883]

oh no youre kidding... at least i think i know what it is

[classicrocker883]

@Arson31 so here is a test
GD32-MM-ProUI-EX-August-Test1.zip

so for some reason the original struct doesn't register the values, and I just incorporated the workaround from February which defines the MESH_MIN/MAX_X/Y insets to the eeprom (settings.cpp) directly.

[Arson31]

@classicrocker883 same issue with 3x3 mesh with #143 (comment) using GD32-MM-ProUI-EX-August-Test1.zip

[classicrocker883]

So here are a couple more,

• Test2 has the older settings.cpp structure
• Test3 I tweaked the same/recent settings.cpp which I noticed a couple things wrong, and bumped the EEPROM version
  Hopefully either one does work, otherwise I would have to go back and try adding the old struct back and previous meshinset workaround.

GD32-MM-ProUI-EX-August-Test2.zip
GD32-MM-ProUI-EX-August-Test3.zip

[Arson31]

@classicrocker883 I'll test when I come back Wednesday.

[Arson31]

@classicrocker883
GD32-MM-ProUI-EX-August-Test2.zip did not work.
GD32-MM-ProUI-EX-August-Test3.zip works.

[classicrocker883]

Test3 working is good news. I will be posting a new release soon, working on a couple things - extra firmware compilations.

[classicrocker883]

@Arson31
got a new release:
https://github.com/classicrocker883/MRiscoCProUI/releases/tag/2.1.3f-9

if you can let me know if that is also working as it should

[Arson31]

@classicrocker883 the problem's still there using Aquila_GD32_MM-ProUI-EX-09-19.bin.

[classicrocker883]

ok, so you sure it was Test3 from earlier that worked? because that is what I went with for changes

[Arson31]

@classicrocker883 Ok, something strange is happening. When I tested the two firmwares 2 weeks ago:

GD32-MM-ProUI-EX-August-Test2.zip did not work.
GD32-MM-ProUI-EX-August-Test3.zip works.

That was true before, but now I can't get either of them to probe correctly. Here's what I did:

1. Flash the firmware
2. Remove SD card
3. Change X physical settings to 199.0
4. Save setting
5. Level
6. Mesh settings
7. Change mesh points to 3x3
8. Change X Mesh Maximum to 199.0
9. Continue Bed Mesh
10. Doesn't probe correctly
11. Save setting
12. Restart
13. Level
14. Continue Bed Mesh
15. Still doesn't probe correctly

I flashed back to GD32-MM-ProUI-EX-July-Test3.zip here's what I did with that:

1. Flash firmware
2. Change X physical settings to 199.0
3. Level
4. Mesh settings
5. Change mesh points to 3x3
6. Change X Mesh Maximum to 199.0
7. Continue Bed Mesh
8. Probes correctly
9. Save settings
10. Remove SD card
11. Restart
12. Level
13. Continue Bed Mesh
14. Probes correctly

If the order I handle these doesn't matter then I don't know how to go about this. Does reformatting the SD card before every flash make a difference? I've never done so with any of these tests but going back to GD32-MM-ProUI-EX-July-Test3.zip without reformatting the SD card fixed the probing.

Also the latest release https://github.com/classicrocker883/MRiscoCProUI/releases/tag/2.1.3f-9 had violent movements when auto homing. Never had that before.

[classicrocker883]

here is a new test file. I moved the values to a struct to follow the current head fork of MRiscoCProUI. before it was a simple workaround, this change is better so hopefully it works.
GD32-MM-ProUI-EX-Sept-Test1.zip

If the order I handle these doesn't matter then I don't know how to go about this.

it seems like your steps are correct, but it shouldn't matter changing any settings specifically after every flash. you can if you want for consistency's sake, but having to remove the card + restarting wouldn't make a difference.

Does reformatting the SD card before every flash make a difference?

The SD card itself doesn't need to be formatted every time. just once ever.

[Arson31]

@classicrocker883 I tried GD32-MM-ProUI-EX-Sept-Test1.zip and it did not probe properly. I noticed after storing settings and a restart the steppers react violently, The carriage slams the X switch when auto-homing.

[classicrocker883]

that is strange. but the previous August Test3 worked the best? no other problems? I might revert back to that, because Marlin should have fixed the issue with the motors shaking. 😔

[Mik-S-UMS]

I think some of the test code made it into the main release as someone on Reddit mentioned the motors moving too fast when homing, and issue #159 appears to be the same thing.