Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

GD32_UBL_ProUI.bin May 2023 not producing the correct mesh #43

Closed
vw72 opened this issue Jun 4, 2023 · 30 comments
Closed

GD32_UBL_ProUI.bin May 2023 not producing the correct mesh #43

vw72 opened this issue Jun 4, 2023 · 30 comments
Labels
bug Something isn't working work-in-progress Currently focused on this issue

Comments

@vw72
Copy link

vw72 commented Jun 4, 2023

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 classicrocker883 added will not fix This will not be worked on already fixed Issue has been addressed labels Jun 8, 2023
@classicrocker883
Copy link
Owner

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
Copy link
Author

vw72 commented Jun 9, 2023 via email

@classicrocker883
Copy link
Owner

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
Copy link
Owner

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
Copy link
Author

vw72 commented Jun 10, 2023 via email

@classicrocker883
Copy link
Owner

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
Copy link
Author

vw72 commented Jun 10, 2023 via email

@classicrocker883
Copy link
Owner

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
Copy link
Author

vw72 commented Jun 15, 2023 via email

@vw72
Copy link
Author

vw72 commented Jun 15, 2023 via email

@vw72
Copy link
Author

vw72 commented Jun 15, 2023 via email

@vw72
Copy link
Author

vw72 commented Jun 15, 2023 via email

@vw72
Copy link
Author

vw72 commented Jun 15, 2023 via email

@classicrocker883
Copy link
Owner

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
Copy link
Author

vw72 commented Jun 15, 2023 via email

@classicrocker883 classicrocker883 added bug Something isn't working work-in-progress Currently focused on this issue and removed already fixed Issue has been addressed will not fix This will not be worked on labels Jun 15, 2023
@classicrocker883
Copy link
Owner

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
Copy link
Author

vw72 commented Jun 16, 2023 via email

@vw72
Copy link
Author

vw72 commented Jun 16, 2023 via email

@classicrocker883
Copy link
Owner

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
Copy link
Owner

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
Copy link
Author

vw72 commented Jun 20, 2023 via email

@classicrocker883
Copy link
Owner

classicrocker883 commented Jun 21, 2023 •
edited
Loading

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

@classicrocker883
Copy link
Owner

classicrocker883 commented Jun 22, 2023 •
edited
Loading

@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
Copy link
Author

vw72 commented Jun 23, 2023 via email

@classicrocker883
Copy link
Owner

classicrocker883 commented Jun 23, 2023 •
edited
Loading

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
Copy link
Author

vw72 commented Jun 24, 2023 via email

@vw72
Copy link
Author

vw72 commented Jun 24, 2023 via email

@vw72
Copy link
Author

vw72 commented Jun 25, 2023 via email

@classicrocker883
Copy link
Owner

classicrocker883 commented Jun 26, 2023 •
edited
Loading

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
Copy link

github-actions bot commented Sep 1, 2023

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.

@github-actions github-actions bot locked and limited conversation to collaborators Sep 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug Something isn't working work-in-progress Currently focused on this issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@classicrocker883 @vw72