GD32_UBL_ProUI.bin May 2023 not producing the correct mesh

[vw72]

Describe the bug When creating a mesh with the UBL version, the right most column is not probed. For instance a 4x4 mesh only probes 12 spots instead of 16

To Reproduce Steps to reproduce the behavior:

1. Run mesh wizard
2. Wizard starts normally
3. Wizard shuts down before probing all of the bed
4. Mesh viewer shows the right most column of points as the same as the column just before it.

Expected behavior Wizard should build a complete mesh.

Screenshots If applicable, add screenshots to help explain your problem.

Version (please complete the following information): GD32_UBL_ProoUI version and release date May 2023

Additional context I thought this might be a problem with using a BL Touch with the UBL firmware, so I installed the BLT version. I should have tried to issue a G29 code in my gcode file to see if it was a problem with just the wizard or with creating the mesh in general.

[classicrocker883]

I know what this is about. So basically it won't probe past an area it cannot reach. For example, lets say your probe X offset is -50. and the max X you can go is 230, so basically the probe can reach a max 180 (because max 230 minus probe offset 50 = 180) so whatever mesh is past the 180 mark it cannot reach, so it wont be probed.

there is a G29 command that automatically computes what the last row or any unprobed points will be, and with good accuracy. I think this is G29 P3. if i recall, previously the auto probe bed was set to G29 P1, which is what you described of doing 12/16 points and leaving the rest blank.

I uploaded a new "pre-release" you can try here, or in the newest default (2023-June) branch.

you can also test this yourself with sending the gcode commands yourself. so the difference between G29 P1 and G29 P3 is (P1) doesnt probe or calulate points it cannot reach, and (P3) calculates non-probed points (with good accuracy).

you do have the option to manually probe these areas like Manual Mesh for a more accurate value. You can match up what you come up with vs what it has calculated if you feel it needs change.

ill throw this out there: if you want to be able to probe the whole bed (and not rely on automatically calculated points) you can set your Mesh Inset to be smaller. This was a previous issue when changing the Mesh Inset wouldn't save. it used to calculate the probe offset in advance to figure out what the mesh inset should be so it could reach all points. but this is not necessary since G29 P3 now calculates those unprobed areas.

one other way to probe the whole bed, and ill throw this out there too cause why not: is moving your auto bed level probe to the center. so the probe X offset is basically or close to 0.00. this would make it in line with the nozzle so you can reach (at least) the whole X of the bed. then you just have to worry about the Y offset.

with the update it should be changed from 'P1' to 'P3'

[vw72]

I downloaded GD32_UBL-ProUI.bin and it would not create the mesh at all. After homeing all three exis, it would just stop and return to the screen as if it completed. Looking at the mesh, it displayed zeros for all the spots. I tried this with various mesh sizes, but none of them actually probed the bed.

Joe

On Wed, Jun 7, 2023 at 8:26 PM Andrew @.***> wrote:

I know what this is about. So basically it won't probe past an area it cannot reach. For example, lets say your probe X offset is -50. and the max X you can go is 230, so basically the probe can reach a max 180 (because max 230 minus probe offset 50 = 180) so whatever mesh is past the 180 mark it cannot reach, so it wont be probed.

there is a G29 command that automatically computes what the last row or any unprobed points will be, and with good accuracy. I think this is G29 P3. if i recall, previously the auto probe bed was set to G29 P1, which is what you described of doing 12/16 points and leaving the rest blank.

I uploaded a new "pre-release" https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3c-test2 you can try here, or in the newest default (2023-June) branch.

you can also test this yourself with sending the gcode commands yourself. so the difference between G29 P1 and G29 P3 is (P1) doesnt probe or calulate points it cannot reach, and (P3) calculates non-probed points (with good accuracy).

you do have the option to manually probe these areas like Manual Mesh for a more accurate value. You can match up what you come up with vs what it has calculated if you feel it needs change.

ill throw this out there: if you want to be able to probe the whole bed (and not rely on automatically calculated points) you can set your Mesh Inset to be smaller. This was a previous issue when changing the Mesh Inset wouldn't save. it used to calculate the probe offset in advance to figure out what the mesh inset should be so it could reach all points. but this is not necessary since G29 P3 now calculates those unprobed areas.

one other way to probe the whole bed, and ill throw this out there too cause why not: is moving your auto bed level probe to the center. so the probe X offset is basically or close to 0.00. this would make it in line with the nozzle so you can reach (at least) the whole X of the bed. then you just have to worry about the Y offset. with the update it should be changed from 'P1' to 'P3'

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1581751461, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRHUSBLBDUX5BWKZ6Z3XKES23ANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[classicrocker883]

I think with the update something was changed so it would automatically Home the axes without having to have it in the code, so basically what I think was happening was it was calling for it to home more than once so it exited.

   * Enqueue command(s) to run from PROGMEM. Drained by process_injected_command_P().
   * Don't inject comments or use leading spaces!
   * Aborts the current PROGMEM queue so only use for one or two commands.

the code was "G28ZL\nG29P3" I changed it so when you click to Build Mesh, a pop up asks if you want to continue, and it should go ahead and do the G29 code, with UBL the code was "G28ZL\nG29P3"

now it uses just "G29P3", and will automatically Home Z within the G29 code.

so ill upload a new version with this fix by the time u see this it should be up.

[classicrocker883]

uploaded some new files with the fixes let me know how it goes

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3c-test3

edit: as of uploading this new compilation, I may have forgot to enable Home Z before G29

[vw72]

This seems to be working. And it does home Z before building a mesh. Should I be using M420 S1 in my starting gcode to enable the mesh or something else? Also, will there be an UBL version with the proui features?

Thanks!

Joe

On Fri, Jun 9, 2023 at 2:07 PM Andrew @.***> wrote:

uploaded some new files with the fixes let me know how it goes

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3c-test3

edit: as of uploading this new compilation, I may have forgot to enable Home Z before G29

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1585020672, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRDFYOZB625GJXN4IDDXKNX6ZANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[classicrocker883]

yes, oh I thought the ProUI UBL version was uploaded. my mistake, ill have that posted right away.

yes use M420 S1 in the start gcode to enable. put it after G28 - G28 / Home disables any mesh as if putting M420 S0.

for a specific mesh, you can also add L0 for slot 0, L1 slot 1... and Z10 for a fade height of 10mm.

[vw72]

Awesome, thanks!

On Fri, Jun 9, 2023 at 10:22 PM Andrew @.***> wrote:

yes, oh I thought the ProUI UBL version was uploaded. my mistake, ill have that posted right away.

yes use M420 S1 in the start gcode to enable. put it after G28 - G28 / Home disables any mesh as if putting M420 S0.

for a specific mesh, you can also add L0 for slot 0, L1 slot 1... and Z10 for a fade height of 10mm.

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1585444268, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRFSHLOJBRA4KPZTBYLXKPR6VANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[classicrocker883]

hey I posted a new update if you wanted to see. if you can let me know everything is all good I'd appreciate it. thanks.

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d

[vw72]

Installing now (UB version). I'll report back.

Joe

On Wed, Jun 14, 2023 at 6:21 PM Andrew @.***> wrote:

hey I posted a new update if you wanted to see. if you can let me know everything is all good I'd appreciate it. thanks.

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1592116778, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRFBLDOFZA7YG3ZSAR3XLJBOFANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[vw72]

June 2023 ProUI UBL 2.1.3d Observations:

When PID tuning hotend, temp line on graph not shown. Works fine for bed temp.

Tramming Wizard didn't seem to be working correctly. All four corners showed 0.0 but told me to lower front left. After restarting printer worked as expected. Tramming Wizard when turning off the Calculate Average and then going into the wizard, the screen doesn't clear properly and text is displayed over itself. Actuall tramming works as expected.

Built 4x4 mesh. Worked as expected Interesting that the tramming wizard shows the bed level, but the mesh shows it slopes downward from left to right. After buidling the mesh, I used the save mesh option and then restarted the printer. The mesh that was just built could be displayed!

Only other thing is that the encoder knob is pretty flaky. It tends to jump alot when trying to dial values in. You might be turning it counter-clockwise to decrease a setting and all of a sudden it jumps up the opposite way, increasing the setting by a large amount. The same is true going the other way, sometimes increasing the setting causes it to show a large decrease instead. I don't know if this is in the firmware or my encoder may be going bad. I just thought I would mention it.

2.1.3d looks like a keeper!

Joe

On Wed, Jun 14, 2023 at 6:21 PM Andrew @.***> wrote:

hey I posted a new update if you wanted to see. if you can let me know everything is all good I'd appreciate it. thanks.

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1592116778, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRFBLDOFZA7YG3ZSAR3XLJBOFANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[vw72]

Couple of minor issues. First, while the mesh loads at power on, I'm not sure it is using it during a print, at least with the straight G29 command. Previously when using a mesh you could see the z axis value changing as the print commenced. That isn't happening. So, I don't know if I need to use G29 A or the screen simply isn't updating.

Second, I've enabled the speed display which alternates back and forth with 100% and the speed. However, the 1 in 100% doesn't clear when it shows the speed so instead of the speed being 55, it shows as 155.

Finally, the time remaining stays at zero. If I recall it used to just work, but now it doesn't.

Joe

On Wed, Jun 14, 2023 at 6:21 PM Andrew @.***> wrote:

hey I posted a new update if you wanted to see. if you can let me know everything is all good I'd appreciate it. thanks.

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1592116778, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRFBLDOFZA7YG3ZSAR3XLJBOFANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[vw72]

Still problems with the mesh. Building the mesh from the Aquila screen works the first time, but after that, it locks up if you try to build it again. Also, under the probe settings, if you turn of the HS setting, the M48 test fails. Adding the G29 A definitely turns on the stored mesh, but then issuing a G29 command after it fails to build a mesh. Also, after issuing the G29 A command, I've had all sorts of problems with the mesh settings. For instance, from the control pad, I was able to successfully build a 4x4 mesh, but after having a G29 A command, it now leaves off the back row and the right column as if the mesh points are out of bounds. It doesn't matter if I reboot the printer or not.

I'm going to install the BLT version and see how it goes. I'll report back.

Joe

On Wed, Jun 14, 2023 at 6:21 PM Andrew @.***> wrote:

hey I posted a new update if you wanted to see. if you can let me know everything is all good I'd appreciate it. thanks.

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1592116778, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRFBLDOFZA7YG3ZSAR3XLJBOFANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[vw72]

Preliminary results with the BLT version.

When building the mesh, it propes all 16 points of the 4x4 grid! If you try building a second mesh, it locks up the printer when you hit the confirm button.

Issuing the G29 command in the startup code builds a mesh and then while printing the z-axis indicator fluctuates as it moves across the bed as expected. So it is using the mesh it created.

Encoder knobs still can jump around quite a lot.

So far the BLT version with the exception of locking up when trying to build the mesh multiple times seems to be function better than the UBL version.

I'll let you know if I find other problems. Also, if I get some time in the next few days, I'll try one of the UBL non-ProUI versions to see if it works better.

Thanks for all your hard work on this.

Joe

On Wed, Jun 14, 2023 at 6:21 PM Andrew @.***> wrote:

hey I posted a new update if you wanted to see. if you can let me know everything is all good I'd appreciate it. thanks.

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1592116778, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRFBLDOFZA7YG3ZSAR3XLJBOFANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[classicrocker883]

this is all great information i appreciate you taking the time to let me know.

for the encoder speed, i'm not sure what it was but in the recent mriscoc update this was changed. i suppose he "fixed" whatever because before the stock values were simply too slow. I had to increase the values 10 times in the firmware. now the values are about what they should be, but i haven't figured out what they ought to be, I only noticed the speed values for the code changed - it all seems fine on my end but I was able to enable a way to change the encoder values right on the LCD screen. so i can just make another firmware file and post it, youll be able to manually change the encoder rates in the advanced settings. i'll be glad to know what works better.

the PID temp line on the plot graph can be an easy fix, again he changed the code in a recent update which is able to allow two or more hotends i suppose, so it should be a quick fix otherwise ill just revert back to the single hot end code. same with the Speed Indicator that flashes between % and mm/s, moving the rectangle that covers the numbers over.

and that was what I mean with the Tramming Wizard - it only gave 0.00 for the corners. like the Z values weren't updating. so dont trust whatever it says, because its not right to be all zeroes. i mean there shouldn't be all zeroes before you know its not leveled, you might get a difference of +- 0.01 or 0.02 no matter what.

I mean I looked through the Tramming Wizard code itself and doesn't look like anything was changed. but now that I think about it there was one value or two which was changed and at the time viewing the code it seemed fine - maybe its that one in particular which replaces the decimal place.

I was thinking that this can also be the same reason why the Z axis values wouldn't fluctuate while printing when bed mesh is enabled, giving a constant 0.00 difference value like the Tramming Wizard but you said the BLT version didn't have that problem. so that may offer a helpful clue.

after having a G29 A command, it now leaves off the back row and the right column as if the mesh points are out of bounds.

can you explain this to me? does this mean the mesh doesnt cover the bed when printing? or as it is being probed, it doesnt probe the back row and right column?

also, what are your probe X and Y offsets? and what are your Mesh Insets (Min/Max for X+Y)?

[vw72]

With regards to the tramming wizard only showing 0.0 the problem was intermittent. It would work normally and then after trying it again, it wouldn't. Same thing with the mesh creation locking up when pressing confirm (although the tramming wizard didn't lock the entire machine). Rebooting the printer would allow the tramming wizard to work as expected.

"after having a G29 A command, it now leaves off the back row and the right column as if the mesh points are out of bounds."

What I meant by this was that prior to issuing this command in my gcode, when building the mesh it hit all 16 points for a 4x4 mesh. After issuing this command in the gcode, even after restarting the printer, with no other changes, building a 4x4 mesh did not probe the back row or the right most column.

Before the G29 A the mesh probing was xxxx xxxx xxxx xxxx

After the G29 A the mesh probing was oooo xxxo xxxo xxxo (where x = spot probed and o = spot not probed)

My probe offsets are -41.5 and -5.7. I use the minimus shroud found on cults3d and as part of it, it gives the offsets, so that's what I use. I think it is definitely something in the way the UBL version builds the mesh as the BLT version probes all of the points using the same offsets and bed size settings. (I'm at work so I'm not sure, but I think i set the max x and y to 225 and the x and y size to 235. I can check when I get home if you think that might help)

I looked at the marlin repository itself and it seems with 2.1.x bugfix, there are others having issues with the UBL version not compensating for the mesh which is the problem I had which led to me trying G29 A. I should note that the BLT version handles the mesh wonderfully - both in probing all the points and compensating for the mesh with a G29 command (I have to check to see if I build it through the menu and activate with the M420 S1 command if it still does).

I noticed on the marlin site, it was mentioned that there was a config setting called RESTORE_LEVELING_AFTER_G28. They said the problem was starting gcode and it fixed something with PrusaSlicer. It's at the end of this thread: https://github.com/MarlinFirmware/Marlin/issues/25244

I'm wondering if the ProUI is bumping up against a memory limit and something is either being overwritten or otherwise corrupted. If the UBL code is the same for the ProUI and NonProUI I can try installing the NonProUI version and see how it behaves. I have to finish a couple of long print jobs first, though.

Joe

On Thu, Jun 15, 2023 at 2:50 AM Andrew @.***> wrote:

this is all great information i appreciate you taking the time to let me know.

for the encoder speed, i'm not sure what it was but in the recent mriscoc update this was changed. i suppose he "fixed" whatever because before the stock values were simply too slow. I had to increase the values 10 times in the firmware. now the values are about what they should be, but i haven't figured out what they ought to be, I only noticed the speed values for the code changed - it all seems fine on my end but I was able to enable a way to change the encoder values right on the LCD screen. so i can just make another firmware file and post it, youll be able to manually change the encoder rates in the advanced settings. i'll be glad to know what works better.

the PID temp line on the plot graph can be an easy fix, again he changed the code in a recent update which is able to allow two or more hotends i suppose, so it should be a quick fix otherwise ill just revert back to the single hot end code. same with the Speed Indicator that flashes between % and mm/s, moving the rectangle that covers the numbers over.

and that was what I mean with the Tramming Wizard - it only gave 0.00 for the corners. like the Z values weren't updating. so dont trust whatever it says, because its not right to be all zeroes. i mean there shouldn't be all zeroes before you know its not leveled, you might get a difference of +- 0.01 or 0.02 no matter what.

I mean I looked through the Tramming Wizard code itself and doesn't look like anything was changed. but now that I think about it there was one value or two which was changed and at the time viewing the code it seemed fine - maybe its that one in particular which replaces the decimal place.

I was thinking that this can also be the same reason why the Z axis values wouldn't fluctuate while printing when bed mesh is enabled, giving a constant 0.00 difference value like the Tramming Wizard but you said the BLT version didn't have that problem. so that may offer a helpful clue.

after having a G29 A command, it now leaves off the back row and the right column as if the mesh points are out of bounds.

can you explain this to me? does this mean the mesh doesnt cover the bed when printing? or as it is being probed, it doesnt probe the back row and right column?

also, what are your probe X and Y offsets? and what are your Mesh Insets (Min/Max for X+Y)?

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1592539810, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTREPTREHJGBMAQKAVD3XLK5DNANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[classicrocker883]

So for the trammingwizard giving 0.00 it appears I did not have the custom gcode enabled since the last update the definition to enable was changed. I think I have fixed that issue.

as for why it probes all but then it doesn't probe all has to come down to the Mesh Inset. G29 A is the code for Bilinear bed leveling (BLT version), and I believe I mentioned this somewhere that the firmware would automatically fill in any points its unable to reach. but the way Mriscoc set the mesh Inset was so all the points can be reached within.

so if you pay close attention to where your probe is relative to the bed, when it probes all points it doesn't actually cover the bed. but then you look at where it doesn't probe a row or column, you'll see it's about the same area where it doesn't probe. sure u get all the points probed, but you're still missing part of the bed. if you adjusted your probe offsets to 0,0 and pretend the nozzle is the probe you'll see it probe all the points - but if you add enough offset it will be able to probe less and less of the bed, unless you add more rightward possible position (Max X size).

for the max X Bed Size you can set it to 235, but if it's anything like my printer - 235 is too much. for me 230 is as max it goes, like if I go 230.1 it would not move further. so basically u can set this to 250 or 300 for example, what you want to do for getting max is then go Almost as far it goes, then Live - baby step until it just can't go anymore. record that value (X or Y axis) and that should be your Max X - Y bed size.

you mentioned RESTORE_LEVELING_AFTER_G28. the issue is if you enable M420 S1 or G29A or whatever sets the auto bed level active, then issue G28 to home - it will disable /inactivate leveling. this firmware has RESTORE_LEVELING_AFTER_G28 enabled, it says it restores prior leveling state. which I think means disable, because the other option is ENABLE_LEVELING_AFTER_G28 (which is not enabled) to always enable leveling.

so could this be why you don't see the Z axis changing while printing to indicate leveling is working?

"If the UBL code is the same for the ProUI and NonProUI "

to answer that, yes and no. UBL does have the same code for both pro or NoPro. but also. some functions aren't exactly the same. Mriscoc will have UBL functions redefined in his libproui library. of the top of my head I'm not sure which ones. but basically with NoPro (no PROUI_EX) all the code is 99% Marlin - besides the ProUI LCD screen code. with ProUI (PROUI_EX enabled) it's maybe 80% Marlin and you get all those extra features like variable bed size and grid and mesh, some of the Marlin original code is disabled (commented out) and redefined or referenced through the library. which is code I cannot see or edit or anything.

its an encrypted file so no one pretty much steals his code.

usually I don't have an issue but sometimes it would help to know what that hidden code is to fix an issue.

anyway I'm working on the issues. just to reiterate what we got going on to fix let me know if I'm missing anything or add something else. I might post the updated versions later. I'll shout out when I do.

• Tram wizard giving false all zeroes (should be fixed now)
• Tram wizard not clearing screen after Calc avg. off (have to test to see if fixed)
• speed indicator not covering "100" all the way (should be fixed now - will test to see)
• encoder knob speed rate needs fixing (I may change the values, but I'll enable in a Manu option which can adjust this on the fly)
• Confirm build mesh on start locks up (this only when first doing the auto build? or when saving mesh or both?)
• locks up when attempt to build 2nd mesh (only with BLT version, correct?)
• HS mode causes issue with M48 test. (I think this was mentioned somewhere else, I'll look into that)

[vw72]

I appreciate him wanted to protect his work, but Marlin is released under the GPL 2 so I don't think it allows keeping the code encrypted, but I appreciate his work, so I'm not going comment further on that except to say that these issues aren't just from your build of the code, people are having similar issues with his and if the coder wasn't encrypted then the issues might get resolved more quickly.

From your list of of items, I think adding an option for setting the encoder speed rate is an excellent idea, regardless of what values you settle on. Again, this could also be hardware dependent based on the wear and tear the physical encoder has experienced. It's hard to say without more data points.

With regards to the confirm build mesh locking up, there are two different scenarios. The first was after issuing the G29 A command on the UBL version. After that, hitting the confirm button would consistently lock up, even if I rebooted the printer. I'm wondering if that wrote something to memory that wasn't expected on overwrote something. Reflashing the firmware fixed it (until running the G29 A command again). If G29 A is a problem for the UBL version, then maybe intercepting it in the gcode and not processing it or converting it just to G29 might be a good thing for the UBL version. I don't know what is involved or if that would break something else. I'm just thinking out loud, so to speak.

The other time it would lock up would happen after building and saving a mesh and then going back in to build it again. Basically, after building a mesh and hitting save and then going back in and building again, the moment you hit confirm, the printer is locked up. Is the save option after building the mesh the same as the save mesh option in the menus? Also, I think I had problems with locking up if I hit the continue button instead of save, but it was late and I didn't take detailed notes.

While Marlin is putting more work into the UBL version, I think the BLT version is more stable. I'd probably recommend it over the UBL until the issues get sorted out. It be a lot easier if you could look inside the encrypted code.

All in all, except for these few issues, things are working really well!

Joe

On Thu, Jun 15, 2023 at 6:39 PM Andrew @.***> wrote:

So for the trammingwizard giving 0.00 it appears I did not have the custom gcode enabled since the last update the definition to enable was changed. I think I have fixed that issue.

as for why it probes all but then it doesn't probe all has to come down to the Mesh Inset. G29 A is the code for Bilinear bed leveling (BLT version), and I believe I mentioned this somewhere that the firmware would automatically fill in any points its unable to reach. but the way Mriscoc set the mesh Inset was so all the points can be reached within.

so if you pay close attention to where your probe is relative to the bed, when it probes all points it doesn't actually cover the bed. but then you look at where it doesn't probe a row or column, you'll see it's about the same area where it doesn't probe. sure u get all the points probed, but you're still missing part of the bed. if you adjusted your probe offsets to 0,0 and pretend the nozzle is the probe you'll see it probe all the points

• but if you add enough offset it will be able to probe less and less of the bed, unless you add more rightward possible position (Max X size).

for the max X Bed Size you can set it to 235, but if it's anything like my printer - 235 is too much. for me 230 is as max it goes, like if I go 230.1 it would not move further. so basically u can set this to 250 or 300 for example, what you want to do for getting max is then go Almost as far it goes, then Live - baby step until it just can't go anymore. record that value (X or Y axis) and that should be your Max X - Y bed size.

you mentioned RESTORE_LEVELING_AFTER_G28. the issue is if you enable M420 S1 or G29A or whatever sets the auto bed level active, then issue G28 to home - it will disable /inactivate leveling. this firmware has RESTORE_LEVELING_AFTER_G28 enabled, it says it restores prior leveling state. which I think means disable, because the other option is ENABLE_LEVELING_AFTER_G28 (which is not enabled) to always enable leveling.

so could this be why you don't see the Z axis changing while printing to indicate leveling is working?

"If the UBL code is the same for the ProUI and NonProUI "

to answer that, yes and no. UBL does have the same code for both pro or NoPro. but also. some functions aren't exactly the same. Mriscoc will have UBL functions redefined in his libproui library. of the top of my head I'm not sure which ones. but basically with NoPro (no PROUI_EX) all the code is 99% Marlin - besides the ProUI LCD screen code. with ProUI (PROUI_EX enabled) it's maybe 80% Marlin and you get all those extra features like variable bed size and grid and mesh, some of the Marlin original code is disabled (commented out) and redefined or referenced through the library. which is code I cannot see or edit or anything.

its an encrypted file so no one pretty much steals his code.

usually I don't have an issue but sometimes it would help to know what that hidden code is to fix an issue.

anyway I'm working on the issues. just to reiterate what we got going on to fix let me know if I'm missing anything or add something else. I might post the updated versions later. I'll shout out when I do.

• Tram wizard giving false all zeroes (should be fixed now)
• Tram wizard not clearing screen after Calc avg. off (have to test to see if fixed)
• speed indicator not covering "100" all the way (should be fixed now
• will test to see)
• encoder knob speed rate needs fixing (I may change the values, but I'll enable in a Manu option which can adjust this on the fly)
• Confirm build mesh on start locks up (this only when first doing the auto build? or when saving mesh or both?)
• locks up when attempt to build 2nd mesh (only with BLT version, correct?)
• HS mode causes issue with M48 test. (I think this was mentioned somewhere else, I'll look into that)

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1593848853, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRFNF6TMRWLX6VCLGVDXLOMKXANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[vw72]

I installed the GD32_UBL-3x3-NoPro and the UBL still acted up by not completing the full grid. The tram wizard seemed to work better than the ProUI version, but I'm not sure. At least it didn't have all zeros for the corner. Also trying to build the mesh twice without rebooting or trying to build the mesh directly after the tramming wizard caused the printer to lock up when hitting the confirm button. This makes me think that the issue is really in the marlin code or in something the Microsec changed in the marlin code to make ProUI work.

I then installed the GD32_BLT_4x4-NoPro and it pretty much worked as expected. In my gcode I issued a G29 after the G28 and it probed the full bed and began printing. The z-axis indicated it was compensating for the bed although at one spot, it was definitely too close to the bed (I could see through my first layer at that particular spot), but otherwise worked well.

I think for most people, the BLT version will work fine. It would be even better if one could preview file before printing and if it had an option to change the bed size.

Joe

On Thu, Jun 15, 2023 at 6:39 PM Andrew @.***> wrote:

So for the trammingwizard giving 0.00 it appears I did not have the custom gcode enabled since the last update the definition to enable was changed. I think I have fixed that issue.

as for why it probes all but then it doesn't probe all has to come down to the Mesh Inset. G29 A is the code for Bilinear bed leveling (BLT version), and I believe I mentioned this somewhere that the firmware would automatically fill in any points its unable to reach. but the way Mriscoc set the mesh Inset was so all the points can be reached within.

so if you pay close attention to where your probe is relative to the bed, when it probes all points it doesn't actually cover the bed. but then you look at where it doesn't probe a row or column, you'll see it's about the same area where it doesn't probe. sure u get all the points probed, but you're still missing part of the bed. if you adjusted your probe offsets to 0,0 and pretend the nozzle is the probe you'll see it probe all the points

• but if you add enough offset it will be able to probe less and less of the bed, unless you add more rightward possible position (Max X size).

for the max X Bed Size you can set it to 235, but if it's anything like my printer - 235 is too much. for me 230 is as max it goes, like if I go 230.1 it would not move further. so basically u can set this to 250 or 300 for example, what you want to do for getting max is then go Almost as far it goes, then Live - baby step until it just can't go anymore. record that value (X or Y axis) and that should be your Max X - Y bed size.

you mentioned RESTORE_LEVELING_AFTER_G28. the issue is if you enable M420 S1 or G29A or whatever sets the auto bed level active, then issue G28 to home - it will disable /inactivate leveling. this firmware has RESTORE_LEVELING_AFTER_G28 enabled, it says it restores prior leveling state. which I think means disable, because the other option is ENABLE_LEVELING_AFTER_G28 (which is not enabled) to always enable leveling.

so could this be why you don't see the Z axis changing while printing to indicate leveling is working?

"If the UBL code is the same for the ProUI and NonProUI "

to answer that, yes and no. UBL does have the same code for both pro or NoPro. but also. some functions aren't exactly the same. Mriscoc will have UBL functions redefined in his libproui library. of the top of my head I'm not sure which ones. but basically with NoPro (no PROUI_EX) all the code is 99% Marlin - besides the ProUI LCD screen code. with ProUI (PROUI_EX enabled) it's maybe 80% Marlin and you get all those extra features like variable bed size and grid and mesh, some of the Marlin original code is disabled (commented out) and redefined or referenced through the library. which is code I cannot see or edit or anything.

its an encrypted file so no one pretty much steals his code.

usually I don't have an issue but sometimes it would help to know what that hidden code is to fix an issue.

anyway I'm working on the issues. just to reiterate what we got going on to fix let me know if I'm missing anything or add something else. I might post the updated versions later. I'll shout out when I do.

• Tram wizard giving false all zeroes (should be fixed now)
• Tram wizard not clearing screen after Calc avg. off (have to test to see if fixed)
• speed indicator not covering "100" all the way (should be fixed now
• will test to see)
• encoder knob speed rate needs fixing (I may change the values, but I'll enable in a Manu option which can adjust this on the fly)
• Confirm build mesh on start locks up (this only when first doing the auto build? or when saving mesh or both?)
• locks up when attempt to build 2nd mesh (only with BLT version, correct?)
• HS mode causes issue with M48 test. (I think this was mentioned somewhere else, I'll look into that)

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1593848853, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRFNF6TMRWLX6VCLGVDXLOMKXANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[classicrocker883]

well im not exactly sure if that the code is encrypted or whatever, but after I tried to extract the file it didn't exactly work for me. I tried looking up ways to farthest I got was turning the ". a" ext to ".cpp.o"

not sure where to go from there, the ways I tried got my something but mostly garbled.

what I can always try is use his previous library - basically roll back to the pre updated current one. it should be more or less compatible and if any errors I just roll back related files.

I'd rather go back with a rollback than wait for an update. who knows if or when they will be. I'll keep you in the know if anything pops up.

the lockup after hitting confirm can be from me adding popup option to continue or cancel. or taking away one of the calls to start automatically. same with saving. both of those things can be effected by the unseen library just mentioned before. or it can be like you said the base code from the repos upstream. it may be calling to do two things at once which would cause it to lock up. like telling it to save twice at once.

I can post both Mriscoc and Marlin original (vanilla) to work with the aquila and u can try/test them out individually if u like. I'm about to do just that.

the thing right now I'm trying to figure out is why the heck the PID plot graph doesn't want to show. you said only the BED PID one works? that is you can see the yellow line change, the red line is the "target" temp. also in the Tune menu (during a print) there is the option to view the same graph. is that the same like PID auto tune or different?

[classicrocker883]

P. s. also, with G29 A, for UBL it enables the active mesh leveling. that should not cause any issues, it's used the same as M420 S1.

i use M420 S1 and it the active leveling seems to be working - the Z axis varies slightly during a print. I haven't tried G29 A in start gcode.

[vw72]

I just wanted to update you with I went back and installed the January 2023 GD32 GD32-UBL_ProUI_BLT.bin and everything seems to work except being able to swap SD cards. I believe it is a slightly earlier Marlin version, so it might be worth while to see what, if anything has changed in the UBL code.

Joe

On Fri, Jun 16, 2023 at 5:03 PM Andrew @.***> wrote:

P. s. also, with G29 A, for UBL it enables the active mesh leveling. that should not cause any issues, it's used the same as M420 S1.

i use M420 S1 and it the active leveling seems to be working - the Z axis varies slightly during a print. I haven't tried G29 A in start gcode.

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1595367030, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRCQHGW2EMK4FGGLRATXLTJ3ZANCNFSM6AAAAAAY2GUACI . You are receiving this because you authored the thread.Message ID: @.***>

[classicrocker883]

ah OK I'll check that out. thanks for that. the branch you used for January is the Mriscoc-2023 correct?

[classicrocker883]

@vw72 hey Joe I've got some good news and some not so bad news. good news I've fixed several things, as far as I've tested it doesn't crash saving mesh or rebuilding a mesh.

trammingwizard works as intended.

M48 probe test works and HS bl touch mode works, however the issue is Extra Probing (or multiple_probing). apparently the code was changed "behind the scenes" so when it's at 2, it's like adding 2 extra probes so you have a total of 3. but the issue is now it doesnt seem to work as intended with a value of 1. I suppose 0 works as it should, but I'm not sure how to get it to probe twice if you want it to do that. and high speed mode (HS) just complicates it a bit. so not sure what to do with this, or just do away with the option.

I'll probably put in an issue over at Mriscoc and see what can be done. otherwise I'll double check everything on my end and post an updated version you can go ahead and try out yourself to let me know how it is.

[vw72]

While it takes longer to prove, I’d gladly accept that if the mesh actually works right! Let me know when it’s ready and I’ll test it. JoeSent from my iPhoneOn Jun 22, 2023, at 5:45 PM, Andrew @.***> wrote: @vw72 hey Joe I've got some good news and some not so bad news. good news I've fixed several things, as far as I've tested it doesn't crash saving mesh or rebuilding a mesh. trammingwizard works as intended. M48 probe test works and HS bl touch mode works, however the issue is Extra Probing (or multiple_probing). apparently the code was changed "behind the scenes" so the issue is when it's at 2, it's like adding 2 extra probes so you have a total of 3. but now it doesnt seem to work as intended with a value of 1. I suppose 0 works as it should, but I'm not sure how to get it to probe twice if you want it to do that. and high speed mode (HS) just complicates it a bit. so not sure what to do with this, or just do away with the option. I'll probably put in an issue over at Mriscoc and see what can be done. otherwise I'll double check everything on my end and post an updated version you can go ahead and try out yourself to let me know how it is.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[classicrocker883]

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d-test1a

OK I uploaded a recent build at the link.

edit:

use this release instead 2.1.3d-test1b

[vw72]

I did not get a chance to test this before you pulled it and put the fixed version out. However, I did install the GD32_UBL-ProUI.bin that you put out earlier today (6/24) and I must say it is working flawlessly. Great Job! Thanks!

Joe

On Fri, Jun 23, 2023 at 12:38 PM Andrew @.***> wrote:

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d-test1a

OK I uploaded a recent build at the link.

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1604610557, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRAX3CCIRJXQKCFJMOLXMXIANANCNFSM6AAAAAAY2GUACI . You are receiving this because you were mentioned.Message ID: @.***>

[vw72]

I take that back. It is working flawlessly except for the SD card. When enabling the feature to read the SD card when it is swapped out, after printing a job and then going back to print another file, it reboots the printer after you select the file. Swapping out the card gives an error that the card failed to initialize. However, popping it out a second time, it will initialize it properly, but after printing, when going back to select another file, it reboots. However, if after printing a file and before going back to print a second file, if you pop out the card and then re-insert it twice (first time gives the initialization error, second time reads the card), then the printer does not reboot and you can select another file.

This is definitely not a show stopper, but probably needs looked at before the next release. I'm in the middle of a print job, so it is possible that this is related to the specific sd card in the printer. When it is finished, I'll try a different card, but I don't think it will make a difference.

On Fri, Jun 23, 2023 at 12:38 PM Andrew @.***> wrote:

https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d-test1a

OK I uploaded a recent build at the link.

— Reply to this email directly, view it on GitHub https://github.com/classicrocker883/MriscocProUI/issues/43#issuecomment-1604610557, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAKGTRAX3CCIRJXQKCFJMOLXMXIANANCNFSM6AAAAAAY2GUACI . You are receiving this because you were mentioned.Message ID: @.***>

[vw72]

It appears the sd card problem is specific to this one card. Other cards work fine. It’s 64gb. Do you know is there a max size for sd cards?JoeSent from my iPhoneOn Jun 24, 2023, at 12:57 PM, Joseph Braddock @.> wrote:I take that back. It is working flawlessly except for the SD card.  When enabling the feature to read the SD card when it is swapped out, after printing a job and then going back to print another file, it reboots the printer after you select the file.  Swapping out the card gives an error that the card failed to initialize. However, popping it out a second time, it will initialize it properly, but after printing, when going back to select another file, it reboots.  However, if after printing a file and before going back to print a second file, if you pop out the card and then re-insert it twice (first time gives the initialization error, second time reads the card), then the printer does not reboot and you can select another file.This is definitely not a show stopper, but probably needs looked at before the next release. I'm in the middle of a print job, so it is possible that this is related to the specific sd card in the printer. When it is finished, I'll try a different card, but I don't think it will make a difference.On Fri, Jun 23, 2023 at 12:38 PM Andrew @.> wrote: https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d-test1a OK I uploaded a recent build at the link.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[classicrocker883]

I did make another release if you havent noticed already https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3d-1/*-98+6

there isn't much difference just a minor change or two, nothing to make note of. but for the SD, I think someone had brought that up under Mriscoc issues. I have heard larger SD capacities aren't always reliable. I myself haven't tried anything besides the 8gb one they supplied with the machine and its never let me down. I might have a 64 laying around i could try and test on, but even posts on reddit said larger SD cards cause issues.

I could take a look in the code maybe its a simple fix like increasing the read or buffer size, or some variable. and lets not forget where Marlin is coming from, 8-bit processors and limited memory and what not. I've noticed some values have remained the same as if we're still using older tech, so either the code itself is limited or bottlenecked, or it just could get updated some.

there is one option you can try if you haven't already. in the advanced settings menu under the Control, look for SD Card Auto Mount - this is typically for SD card extenders. or you can try unchecking Sort SD Card which alphabetizes the file order. maybe with a bigger card its using too much the program memory which isn't allocated for the larger card. anyway if you have success with smaller SD cards I would stick with those for now.

but if there is anything else, anything I could change in the firmware, how it looks, the order its in, whatever it is let me know, in the mean time happy printing and thanks for input, and patience 👍

[github-actions[bot]]

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.