Miscalculation of Tramming Position (right/center) in new Tramming function

[DasSmeagle]

Description

Hi,

I love the new Tramming function!!!

But there seems to be a problem:

Top Left and Bottom Left are fine. Not exactly, the BLTouch is getting very close to the screws. Off by 2mm to the right of screw. No big deal, good enough.

BUT

Center, Top Right and Bottom Right are way to much to the right! About 3cm to the right of the screw, nearly off the bed. I know, the normal Ender-3 cannot go there, but as I modified my Ender-3 it CAN go there, so I notice it ;) my guess is, the ender used for testing it was limited by it's construction from going there?

I guess there is some miscalcualtion with margins and BLTouch Offsets? Maybe you go 3cm to the left from the X_MAX_POS instead of the X_BED_SIZE?

I modified my Ender-3 V2 a little to be able to get the BL Touch everywere on the bed. I modified configs with my exact margins and sizes and offsets:

(configuration.h)

// The size of the printable area

define X_BED_SIZE 230

define Y_BED_SIZE 230

// Travel limits (mm) after homing, corresponding to endstop positions.

define X_MAX_POS 273.0

define Y_MAX_POS 232.0

and:

define NOZZLE_TO_PROBE_OFFSET { -44.7, -4.5, 0 }

I tried to set tramming positions in configuration_adv.h:

// // Add the G35 command to read bed corners to help adjust screws. Requires a bed probe. // //#define ASSISTED_TRAMMING

if ENABLED(ASSISTED_TRAMMING)

// Define positions for probe points.

define TRAMMING_POINT_XY { { 30, 30 }, { 200, 30 }, { 200, 200 }, { 30, 200 } }

But it's obvious, you don't use this part, as #define ASSISTED_TRAMMING is commented out.

I added my config files in case it's something else I did in the config...

Thanks for the great work!

• Oliver

Steps to Reproduce

1. Prepare -> Manual Leveling -> enable "[X] Use probe"

-> Printe does a "4 point mesh". Top Left and Bottom Left are fine, very close to screw. Top Right and Bottom right are ~3cm right of the screws

2. Select "Top Right" or "Bottom Right"

-> Printer goes 3cm right of the screw for tramming

Expected behavior: All Tramming Points should be on (or very close to) the screws.

Actual behavior: Left points are fine, right points ar to far on the right Config.zip

Additional Information

• Include a ZIP file containing your Configuration.h and Configuration_adv.h files.
• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[DasSmeagle]

Hmmm....

Update: Ich meanwhile changed my Leveling to UBL and worked a little on that and now the positions for Tramming changed!? Not sure what did this. Left positions are now more to the left of the screw, right positions still too far right.

Would be nice to get tramming positions exactly at screws at all time.

And while we are at this I have some wishes:

a) After inital probing of 4 corners please SHOW values of all 4 corners. So we know if it is OK already and which points to change first! b) when switching to a new corner start first probing right away ( c) if possible always show all 4 corners ) not sure if this is a good idea, as changing one tends to invalid the others. d) quick "reprobe" function (feels wrong to disable/reenable probe to do this)

Thanks!

[DasSmeagle]

To be more clear:

My experience, changing one screw will always change other points to, because 4 screws is "too much" so when all 4 screws are not perfectly aligned there will be "play" in one axxis. So I always want to the all 4 values, push edge, see 4 values again to see if there is play. As soon as the play is eliminated, I still want to see all 4 values and when changing screws I always want to adjust 2 screws at a time - two on one side of bed same direction or diagonal screw in opposite direction.

So my prefered way for assisted bed leveling would be: a) probe all 4 corners, show all 4 values. b) if needed, adjust screws as the values suggest, goto a) again

[smooreace]

This is intended to be done one corner at a time... probe-adjust-probe adjust Once that corner is as close to 0 as possible move to the next corner Rinse and repeat till all corners are still close to 0

That means keep going in circles till you are happy. Displaying the other corners' measurements is absolutely pointless. If you did it right... its

0. Why do you need reminded? And as DesSmeagle mentioned... adjusting any screw makes changes to the entire bed. Do a little math and you will understand why.

On Thu, Jul 8, 2021 at 4:10 AM DasSmeagle @.***> wrote:

To be more clear:

My experience, changing one screw will always change other points to, because 4 screws is "too much" so when all 4 screws are not perfectly aligned there will be "play" in one axxis. So I always want to the all 4 values, push edge, see 5 values again to see if there is play. As soon as the play is eliminated, I still want to see all 4 values and when changing screws I always want to adjust 2 screws at a time - two on one side of bed same direction or diagonal screw in opposite direction.

So my prefered way for assisted bed leveling would be: a) probe all 4 edges, show all 4 values. b) if needed, adjust screws as the values suggest, goto a) again

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Jyers/Marlin/issues/1125#issuecomment-876271334, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPE4QYIOPOHNMK2WDNXUYLTWVTPVANCNFSM477MOJPQ .

[Jyers]

@smooreace Did you just quote him... to himself? Nevermind

@DasSmeagle I can definitely see your reasoning for some of those features and I'll definitely consider them. The screw positions are set based on the maximum positions the printhead can go. I think I need to look at it again to see if there is a way to not account for extra distance added from probing.

[smooreace]

Ha.. kinda. I usually respond via email. So I don't have any idea who starts a thread or have a lot of control over where the new comment goes. Leads to some interesting placement at times.

But... the many of us running non-stock bed sizes would benefit greatly in having more control of where this probing is happening. Mine probed about 30mm in from the edges.. a LONG way from the actual screws. Makes the entire process take forever and a half

[Jyers]

That's actually already configurable on the latest source. In the advanced menu there is a screw inset item you can set ;)

[Jyers]

@DasSmeagle I'm assuming you're compiling your own version, so give the newest source a try. I think I've fixed the issue.

[DasSmeagle]

@DasSmeagle I'm assuming you're compiling your own version, so give the newest source a try. I think I've fixed the issue.

Thanks, I will try as soon as possible, but will be Monday I guess.

[DasSmeagle]

Some more explanation, why my view on this changed somewhat: First I was very happy to set screw-by-screw isolated. Easy to get all to "0" by this way. BUT: as soon as you push down one edge even a little, the setting is bad again!

I know this is normal with the soft springs, I already use hard silicon on the screws.

After experimenting I found the reason: Because there a 4 screws - on more than really needed - it is very difficult to set them so there is no play on one diagonal axis. Its hardly noticable, but if you push one corner down the diagonal oposing corner will got up. ~0,1..0,2mm, so very noticeable.

It's very difficult to get this play away when probeing one corner aftere the other! You have to probe all 4 corners, push one corner, probe all corners again to see if it is tilted.

But I found a good way to do this: I use UBL Leveling now. And after building the initial mesh you can do this 3-point-autotilt and view the mesh, using this function I can get what I want: setup the 4 screws so there is no play when pushing down corners!

As soon as this is set, you should always change 2 screws at a time. 2 on one edge in the same direction or 2 diagonal in oposing directions.

So after I learned that, I think adjusting all 4 corners separate is not the best way to do it, instead now I think it would be better to probe all 4 corners and show them all. Then you can decide which screws to turn and probe again. Yes, probing takes longer, but you get a better understanding how your bed is moving. Would like to see them just like in mesh viewer, with colors and relative +/- numbers to the avarage.

I hope, I made myself clear ;) Difficult to explain this in English for me...

I can work with it using a combination of Tramming and UBL Auto-Tilting, just wanted to be sure you undertand my view on this.

[smooreace]

Thats exactly why I dropped back to a 3x3 mesh. Once the bed is perfect and I know what the bed SHOULD look like numbers-wise I can run a 3x3 once a week or so and see if anything needs to be adjusted. Then its always 2 screws at a time to reach a close representation of what my original perfect was. I also have my back left screw bolted solid. So attain that initial zero(ish) start I brought the other 3 down to make the center of the bed level with the back left

On Sat, Jul 10, 2021 at 2:00 AM DasSmeagle @.***> wrote:

Some more explanation, why my view on this changed somewhat: First I was very happy to set screw-by-screw isolated. Easy to get all to "0" by this way. BUT: as soon as you push down one edge even a little, the setting is bad again!

I know this is normal with the soft springs, I already use hard silicon on the screws.

After experimenting I found the reason: Because there a 4 screws - on more than really needed - it is very difficult to set them so there is no play on one diagonal axis. Its hardly noticable, but if you push one corner down the diagonal oposing corner will got up. ~0,1..0,2mm, so very noticeable.

It's very difficult to get this play away when probeing one corner aftere the other! You have to probe all 4 corners, push one corner, probe all corners again to see if it is tilted.

But I found a good way to do this: I use UBL Leveling now. And after building the initial mesh you can do this 3-point-autotilt and view the mesh, using this function I can get what I want: setup the 4 screws so there is no play when pushing down corners!

As soon as this is set, you should always change 2 screws at a time. 2 on one edge in the same direction or 2 diagonal in oposing directions.

So after I learned that, I think adjusting all 4 corners separate is not the best way to do it, instead now I think it would be better to probe all 4 corners and show them all. Then you can decide which screws to turn and probe again. Yes, probing takes longer, but you get a better understanding how your bed is moving. Would like to see them just like in mesh viewer, with colors and relative +/- numbers to the avarage.

I hope, I made myself clear ;) Difficult to explain this in English for me...

I can work with it using a combination of Tramming and UBL Auto-Tilting, just wanted to be sure you undertand my view on this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Jyers/Marlin/issues/1125#issuecomment-877583212, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPE4Q5XC4KVYA7BTNSEPG3TW7VXZANCNFSM477MOJPQ .

[Jyers]

@DasSmeagle Did the new system end up working out well for you?

[DasSmeagle]

@Jyers I just tried it. Sorry, it doesn't work.

After enableing: Manual Leveling -> [x] Use Probe

The 4 corners are probed (Screw Inset position works great now!).

After probing the 4 corners the BLTouch stays at the Bottom right, last position probed.

Selecting a position will NOT move the head to different position. Confirm will start probing always BR. After probing it show "Corner is mm high". No number.

I used the new config files just downloaded (I saw ther is a lot of change in them) and just updated my changes for bed size, max position, UBL leveling etc. like I had them before. I double checked, I see no error on my part

I include my config if you want to have a look.

While testing I had the head crash into the right side several times when homing. Could not reproduce, after trying the same again it always worked. I cannot say exactly what I did. It happened on first Home after first Power on (flashing the new firmware). It happened after enableing "[ ] use probe" for the first time 1x. It happened after I tried to probe several points, disabled and reenabled "[ ] use probe" 1x. But I always tried to do the same steps again and it did not happen again!?

Not very happy about the result... :(

Hope that helps?

Ah, I just remember, There was one update in Visual Studio Code: PIO Home -> Platforms -> ST STM32 was updated to 14.0.1, could that be the problem?

Marlin_config.zip

[Jyers]

I may have made a mistake somewhere in the merge madness. I'll take a look at it when I get home.

[darco415]

yup same here

[DasSmeagle]

No worries, nothing to print right now ;)

[DasSmeagle]

@Jyers Did you "catch up" to the 2.0.x branch from Marlin Project? Beware, before I switched to your branch few weeks ago I tried to get "normal" Marlin running, 2.0.x_bugfix branch, and that one was so buggy it was unusable... Even the latest release branch had severe bugs like adjustment of Z_Offset not working while printing. Bugs were related to the Display of Ender 3 V2.

[Jyers]

Don't worry, pulling from the main bugfix branch doesn't effect the display code in any way as my code is a rewrite. So there's nothing left of the original to get merged to.

[adam3654]

I'm having the exact same outcome as @DasSmeagle it stays in the bottom right corner, and doesn't report the value of the distance to move the bed. I took a video, but the written description is what would be seen on the video anyways.

[Jyers]

Good to know it's repeatable. I should be able to take a look at this later today.

[DasSmeagle]

@adam3654 did you have those random "head crashes", too? That's what worries me most. I had three of those, but couldn't reproduce them by trying the same again.

@Jyers To explain the 2nd part a little better: Instead of going to the left/front to the switches for homing X/Y first, the head ran straight and full speed to the right, over the end of it's way, crashing into the boundary and make very bad noises. It was so fast, I am not sure if the Y-Axis behaved wrong, too or only X-Axis, turned off as fast as possible. At least it did not overshot on the Y-Axis, so I guess it either went in right direction and stopped at switch or Y Axis did not move at all.

[Jyers]

@DasSmeagle The fact of the crashed and the fact that they couldn't be reproduced is a pretty good sign they were a one off deal. There are a lot of little things that can cause the machine to mis-behave. For instance I've seen axis completely stop working simply because someone forgot to reset eeprom after flashing. It's unfortunate, but it happens.

[adam3654]

I haven't experienced a head crash in a long time luckily. I ran a print after flashing the latest commit (third try on getting all the config settings worked out after cloning to a new workspace) and it seemed to work with no issues.

[DasSmeagle]

@Jyers OK, thanks, that may be part of the problem, I never reset my EEPROM, I just looked through all settings and saved to eeprom.

Next Time I will reset, first. I expected the eeprom to be "clear and ready" after flashing.

[smooreace]

I finally had this strange manual leveling with probe issue last night. I had to try it multiple times.. eventually I managed to get a proper test to go through, only to fail printing afterward. Started the print and it did everything right... except actually print. It homed everything, did its preheats, busted out the start beep... and sat there for 5 minutes as the progress meter zoomed across the screen. 14 hour print "completed" in about 5 minutes. Resulted in the expected "Print Complete" message

Whats really odd is that I havent changed my firmware in over a week

On Tue, Jul 13, 2021 at 7:27 AM DasSmeagle @.***> wrote:

@Jyers https://github.com/Jyers OK, thanks, that may be part of the problem, I never reset my EEPROM, I just look through als settings and Saved to eeprom.

Next Time I will reset, first. I expected the eeprom to be "clear and ready" after flashing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Jyers/Marlin/issues/1125#issuecomment-879044068, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPE4Q7VW66MSAUFNKWVAULTXQWLBANCNFSM477MOJPQ .

[Jyers]

Just recreated the issue, Looks like an issue with the normal movement... very strange, will investigate

[Jyers]

Looks like something in the last pull from upstream has broken using sprintf() with floats... which is too say the least... very unfortunate. I'll see if I can bang out a fix tonight

Update: Think I actually found the solution, we'll see 🤞

[Jyers]

Seems to be fixed now, thanks for the patience everyone. That was a weird one 😅

[DasSmeagle]

Great, just tested. Works fine. This time I reset eeprom, set everthing up and stored again. And got no "head crashes" or other issues. THANKS!!!

[DasSmeagle]

Ups. I was to quick. Autotilting the bed (UBL) is broken now. But I make a new issue ticket.