UBL levels X perfectly +-0.150m but not the Y axis? Deviates +-0.500mm on the Y

[Flight77]

I really like everything about the UBL system but unfortunately I can not get it to work properly to automatically build the mesh. Have been trying for a long time. I can successfully build a UBL mesh manually and it is awesome rendering a deviation of no more then +-0.150mm on X and Y. But when try to built it automatically the X is great but the Y axis renders deviations of +-0.500mm (Y does much better with the UBL off) Here is what I got: -- I am on Marlin 1.1.8 (Tried 1.1.9 and 1.1.9bugfix where UBL activates successfully but does not move my Z at all, Z compensation is dead, not working at all no matter what I do) -- I have the MKS Gen V1.4 -- I have a very precise analog micrometer (0.01mm resolution) attached to the printer head so I can see in real time the deviation as the head moves across the bed. -- Using BLtouch which is doing very well; repeatability test shows an average deviation of 0.007 -- I have a big bed 600 x 600mm but I have it pretty level for its size as you can see below. -- Bed Topography Report: (I have an inset of 60 that's why it goes from 60 to 540)

(0,4)                           (4,4)
(60,540)                        (540,540)
  0.034    0.052    0.052    0.110    0.099
  0.054    0.077    0.041    0.118    0.148
  0.056    0.039   -0.007    0.077    0.146
 -0.012   -0.056   -0.112   -0.042    0.102
[-0.162]  -0.277   -0.302   -0.221   -0.037
(60,60)                            (540,60)

-- Mechanics of the printer, board and firmware all working well and makes great prints.

Since my BLT probe is very accurate and I have verified that the Topography is correct with my micrometer attached to the printer head, why is the UBL system failing to do the correct algorithms for the Y axis when build with the auto mesh generation via BLTouch? It does it correctly for X but not Y?

Maybe someone can help me fix the Y axis problem on 1.1.8 or Maybe 1.1.9 has no issues with UBL Y axis so someone can help me make 1.1.9 UBL work?

I really appreciate if anyone can help, thanks

Perhaps Roxy-3D can help me?

@Roxy-3D

[gloomyandy]

Obvious questions first are you sure you have you probe offsets set correctly (your config files and perhaps a picture of your printer would help). How are you determining that there is a levelling error? Is your micrometer positioned at the same locations as the print head? If not it will be measuring the wrong part of the bed.

I doubt if anyone will want to fix anything in 1.1.8, most devs have now moved on to bugfix-2.0.x have you tried using that?

[Flight77]

Yes, the probe offsets are correct.

Yes, the micrometer is positioned relatively close to the head, close enough for such a big bed to show dependable results and determine the deviations on a particular position on the bed.

No, I have not tried the new Marlin bugfix-2.0.x I am kind of reluctant since it is so new.

I have determined there is an error, which is huge about 1mm total deviation by watching the micrometer going across X and then going across Y. The difference is easily seen. (With that kind of deviation I almost don't need the micrometer, I can visually see the increased distance fluctuation between the actual head and bed)

It shows an acceptable deviation on X +-0.150mm but deviates a total of an entire mm in the Y. I could question my offsets, the micrometer location and other variables if it was going crazy on both X and Y but it shows a very nice acceptable deviation on X and an unacceptable 4 times higher on the Y And I tried so many times to generate the mesh. Always same issue. I also base my reliance on the micrometer by confirmation of the data on the topography report. On the X going across the report on the second line, for example, from left to right (0.054 to 0.148) the micrometer confirms that by also showing a deviation of about 0.050 to 0.0150 when moving from left to right (with UBL off) acroos the bed. I also checked the micrometer against the Topography report on the Y (with UBL off) and it also conquers with the exact reading of the micrometer. My micrometer is accurate and installed solid next to the head working very well. The BLTouch probing is accurate, Marlin probes and records the mesh points accurately, it is just an issue with UBL interpreting the mesh points on Y incorrectly when actually moving the Z axis to make the correct level compensations. Again, it does it perfectly in the X just not the Y.

[Flight77]

I meant ...confirms that by also showing a deviation of about 0.050 to 0.150 ............ not 0.0150

[gloomyandy]

There have been a lot of changes since 1.1.8, I would really recommend that you try 2.0.x as it will make it much easier for people to help you. It would also really help (especially in getting any problems you have with a newer version) for you to post your configuration files. I use UBL all of the time (though only on a 220x300 bed) and have not seen any issues, I'm running 2.0.x

Oh and a useful test to run is to perform a G28 load your mesh and then run a G29 J3 V4 this will probe the bed in 9 locations and you will be able to see the difference between the actual probed Z value and the calculated one. But really the first step is to get to a more current version.

[Flight77]

Ok, I will try the new 2.0.x I understand it is backwards-compatible with my 8bit MKS board chip. How can I upload my configuration.h file here? I tried to attach it but .h is not acceptable. Tried to save it o a doc file but then it scrambles the spacing and it is hard to read. What is the best way to upload it here? Also what probe do you have?

[gloomyandy]

Best way to upload is to zip it and upload the zip file. You will need to migrate your configuration to a 2.0.x config file. Probably the best way to do that is to pick the example file that best matches your board and printer and then use a file comparison program to compare the two and move the changes over that make sense to move over. Others may have better advice on how to do it. I'd keep things as simple as possible to begin with, add the fancy stuff once you have basic movement etc. working.

[Flight77]

Ok, I understand. I'll zip it, that is if I need to. Maybe 2.0 will solve everything.

I actually move my configurations manually, one by one. It takes me about an hour but works better for me as I can recheck every change I made and place my custom name "tags" to go back to my changes in an organized way.

Yes, I agree. I will only move the basics that I know have worked for me and play with the new features once everything is running smooth.

Thanks for your help, I will load it up, see how UBL works and report.

[Flight77]

Andy, I just finished migrating to 2.0. When I went to compile I got an error that I have never seen before; File name long? What is that all about? Below is the error code:

Archiving built core (caching) in: C:\Users\ACERLA~1\AppData\Local\Temp\arduino_cache_972458\core\core_arduino_avr_mega_cpu_atmega2560_0c812875ac70eb4a9b385d8fb077f54c.a
fork/exec C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-gcc.exe: The filename or extension is too long.
Error compiling for board Arduino/Genuino Mega or Mega 2560.

[Flight77]

Never mind regarding the compiling error. It is the way the new Marlin 2.0 is build and how this new build affects Arduino on windows.

I downloaded the Arduino 1.9 Beta and it compiles the new Marlin 2.0 successfully.

Will be doing the UBL leveling right now to see if the UBL Y axis problem is solved.

[Roxy-3D]

I actually move my configurations manually, one by one. It takes me about an hour but works better for me as I can recheck every change I made and place my custom name "tags" to go back to my changes in an organized way.

Use a visual diff program. I use ExamDiff Pro. I believe they have a trial version. Or... you can use NotePad++ and enable the visual diff extension.

That lets you see what has changed and make a value by value comparison. It lets you see important stuff and ignore stuff that doesn't matter to your machine's configuration.

[Flight77]

Yes, I do use NotePad++ but did not know about the visual diff extension. I will check it out thanks.

I just tried the UBL with the new Marlin 2.0 which was successfully installed and everything seems to work as per my configurations, except UBL

It is just not working, same as in 1.1.9 and 1.1.9bugfix it only works in 1.1.8

It completed the mesh, I stored it, confirmed the Topography with G29 T the numbers look good and I activated the UBL system but no movement at all of the z axis when I move around X or Y I don't understand why it is dead.

[Flight77]

Attached are my configuration.h and configuration_adv.h files for Marlin 2.0 Thanks for the help

Configuration Files.zip

[Flight77]

All my changes in the configuration files are tagged and can be found using the Ctrl F and type the keyword: Stratus

[gloomyandy]

Are you sure you have actually turned UBL on with a G29 A or M420 S1. You will need to do this after a G28 command as by default that disables UBL.

[Roxy-3D]

He does have:

#define RESTORE_LEVELING_AFTER_G28

turned on... So if he does a G29 A before the G28.... UBL should still be turned on after the G28.

@Flight77 The reason I haven't jumped into the discussion is I don't understand what you mean about Y 'being handled correctly' and X isn't. The way all of the bed leveling systems work is they look at the (X,Y) coordinate and calculate a Z correction depending upon where that coordinate is on the bed. Is Y 'frozen' and not changing? (Personally, I doubt it...) Is Y not entering into the calculation of the Z correction? (Personally... I don't see how that can be because it is passed into the Z_offset calculation functions...)

I don't understand what the difference is between the X-Axis and the Y-Axis on you printer and what you are seeing....

[Flight77]

100% sure it is turned on. I can turn it on and off at will. Tried it both from the LCD and my computer. After I turn it on and see it is active I still confirm it again by sending a M503 to see again that it's on. It says UBL is active on the screen right in front of me, but there is no Z compensation whatsoever. And when I go back and install 1.1.8 then it works. I thought I had a problem with my UBL on the Y axis. In comparison that was nothing, now I really have a problem, I am stuck on 1.1.8 I tried 1.1.9 , 1.1.9bugfix and 2.0 but UBL does not work when active. There has to be a logical explanation for this. I checked and rechecked and triple checked my configurations, they are the same as on 1.1.8 Every other function on my printer works well with any of the three new versions, just UBL will not budge.

On Nov 3, 2018 11:40 PM, "Andy Shaw" notifications@github.com wrote:

Are you sure you have actually turned UBL on with a G29 A or M420 S1. You will need to do this after a G28 command as by default that disables UBL.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/12318#issuecomment-435639489, or mute the thread https://github.com/notifications/unsubscribe-auth/AGbX8GAxSk7G_jVjVZm9liDChu87ZuTjks5urmGfgaJpZM4YM6b4 .

[Flight77]

Thanks, Roxy for stepping in. No Z compensation when moving Y is not frozen. It is simply causing high numbered erroneus compensations that I don't know where it's getting it from. Anyway assuming maybe there's something wrong with my 1.1.8. Perhaps this will not be an issue with any of the new versions but as you can see from my last few posts I cannot get UBL to work at all on any of the latest three versions. Could you look at my configuration files I uploaded which are for 2.0 and perhaps spot something wrong?

On Sun, Nov 4, 2018, 12:57 AM Roxy-3D notifications@github.com wrote:

He does have:

define RESTORE_LEVELING_AFTER_G28

turned on... So if he does a G29 A before the G28.... UBL should still be turned on after the G28.

@Flight77 https://github.com/Flight77 The reason I haven't jumped into the discussion is I don't understand what you mean about Y 'being handled correctly' and X isn't. The way all of the bed leveling systems work is they look at the (X,Y) coordinate and calculate a Z correction depending upon where that coordinate is on the bed. Is Y 'frozen' and not changing? (Personally, I doubt it...) Is Y not entering into the calculation of the Z correction? (Personally... I don't see how that can be because it is passed into the Z_offset calculation functions...)

I don't understand what the difference is between the X-Axis and the Y-Axis on you printer and what you are seeing....

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/12318#issuecomment-435642326, or mute the thread https://github.com/notifications/unsubscribe-auth/AGbX8L3NOjKSYAfj8dSH2wcSnsWmjYgnks5urnOpgaJpZM4YM6b4 .

[gloomyandy]

Hmm I see you multiple extruders defined (with both an X and Y offset), @Roxy-3D I wonder if that is causing any issues?

@Flight77 can you provide some more information about your printer, that might help with working out what is going on here.

Is it possible to operate your printer as just a single extruder system? If so can you try just defining a single one and see if you get and Z compensation?

[Flight77]

Sure I can do that. I will change to single extruder and try it. If that doesn't work I will go to the next step. I was thinking last night about something similar. I will eliminate all my fancy settings. I have a few customized pin assigments for my fans and other preferences which I will leave at default. I will start again with a fresh clean Marlin 2.0 and change only the bare minimum configurations necessary to make the printer run correctly. (single extruder) I will leave everything else the way it comes untouched at default values. If UBL works fine then I will just start to activate my fancy settings one by one until UBL stops working and I will have my answer of what caused the problem.

[Roxy-3D]

Or... Here is something easy to do and potentially helpful... Do a G29 Q 1. That will modify the mesh to have a diagonal line across it. Then, move the nozzle to a Z=1.00 mm, X=0mm and Y=300. You can do a G29 T to see the mesh with a diagonal line. Now do a G1 X599. You should see the nozzle step up as it crosses the line, and then drop back down.

If you can get that working... Now try moving to Z=1.00mm, X=300mm and Y=0mm. Give it a G1 Y Y599 and you should see similar stepping as the nozzle crosses the diagonal line.

[Flight77]

Yes, UBL is working now changing the Z compensation on bugfix-2.0.x

I flashed the firmware with just the bare minimum configuration changes as possible to make my printer work, ie board type, stepper direction, feedrates etc. (only 28 in total) everything else is untouched.

Once everything is running smoothly and consistently I will add my preferences/costume configurations later one by one. (and check UBL each time)

G29 Q 1 helped to see the Z level raise/drop clearly, thanks.

Now back to original reason I opened this post; the Y axis, I will be building a few meshes and see how accurately the printer levels everything.

[Roxy-3D]

You can check the leveling at different places on the Y axis by just shifting where you start on that G29 Q1 test pattern. If you move to Z=1.00mm, X=50, Y=0 and then do a G1 Y599 you should see the step on the Y axis happen much earlier (not in the center of the bed).

[Flight77]

Oh, to answer the question regarding my printer. It is called Modix Big 60 with a max print area of 610 x 610 x 610mm

It is on a cartesian system, aluminum heated bed with BuildTak surface setup to print 600 x 600 x 600mm, physical bed is 660 x 660mm The head in the Z is fixed, bed moves via 3 spiral poles in the Z by 3 motors in parallel. In the X and Y directions, the head moves via belts, one motor per axis.

[Flight77]

Ok, thanks I will look into that test method.

[Roxy-3D]

Yeah.... I thought I had a big printer. But 610mm x 610mm is BIG! (Much bigger than my printer!!!)

[Flight77]

Yeah, this thing is a monster took me several weeks to build it, but I wanted to build it slowly and as accurately as possible.

[Flight77]

What size is your printer? Is it the Creality?

[Flight77]

Here are 2 pics of the printer. You can see the monster size of the frame next to the washing machine.

[InsanityAutomation]

Roxy has a 400x400 Formbot that im aware of at least. Ive got a couple of the same machine and a couple of the 500x500 Creality's. One thing to keep in mind with such a large inset is to run your test patterns and movements completely inside the box so to speak. Crossing in and out can sometimes create some odd corrections depending on your off mesh compensation value.

[Flight77]

Thanks for the info the printers.

Yes I do take in consideration my inset setting and will only run the test patterns and look for correct compensation values inside the "Box" thanks

Yeah I have a Creality 500mm also, just upgraded the controller to a MKS Gen 1.3 (same as in my Modix in question in this post) Got it running pretty smoothly except I do not have a probe installed yet. I do manual leveling (probing) of the bed via UBL which renders pretty decent results so far.

On Mon, Nov 5, 2018, 3:47 PM InsanityAutomation notifications@github.com wrote:

Roxy has a 400x400 Formbot that im aware of at least. Ive got a couple of the same machine and a couple of the 500x500 Creality's. One thing to keep in mind with such a large inset is to run your test patterns and movements completely inside the box so to speak. Crossing in and out can sometimes create some odd corrections depending on your off mesh compensation value.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/12318#issuecomment-436028949, or mute the thread https://github.com/notifications/unsubscribe-auth/AGbX8J_TYczsTCcZNJp8zN3ECWtB5pHSks5usKPvgaJpZM4YM6b4 .

[Flight77]

I meant MKS Gen 1.4

[InsanityAutomation]

Keep us up to date on what you see with the current bugfix branch. Ill dust off my old Trex2 with the MKS 1.4 and BLTouch 400x400 machine and try to match what youre seeing if we can.

[Roxy-3D]

Got it running pretty smoothly except I do not have a probe installed yet.

Ugggghhh... That is painful to even think about. It is worth $10 to put a servo and a probe leg on your extruder!

[dcwalmsley]

On a seperate note, I found WinMerge to be as useful as Notepad ++. Comes with Compare built-in and not a plug-in as is in NotePad ++ application.

[dcwalmsley]

Also found that my Z-Axis hasn't adjusted either after I went onto Marlin 1.9 and later. Haven't tested Marlin 2.0.

Is there any plan to fix 1.1.9 or update bugfix-1.1.9?

[Flight77]

Thanks, I'll check out WinMerge sometime.

[Flight77]

FINALLY....I have some answers for those who been following my UBL leveling issues since the beginning of this post. I made some major breakthroughs after hours and hours of tests. I found the source of the 2 main problems.

 **** 1. The UBL leveling not working at all, even when active on the latest 3 Marlin versions ****

I though I found the problem to why UBL did not work all, when I flashed my board with a clean 2.0 version and just changed the bare minimum configurations needed to make the printer work. It worked then, so obviously I though I must've messed up somewhere on my custom and fancy configurations. No, that was not it! UBL leveling works when active on all 3 versions even with my original fancy/custom configuration changes. The problem is the LCD screen. It DOES NOT work with my LCD (Reprap Discount Full Graphic Smart Controller) on a non print move; just moving the head along the X and Y to check things out. Z compensation does not work when UBL is active. It does work when using a 2.8 or 3.2 TFT touch screen and it does work with g-code commands via a PC. I though it was not working at all because I use mainly the LCD. It does have an odd behavior; While in the "move X or Y axis" on the LCD the UBL Z compensation works the only the first time I turn the dial to make a X/Y move, on any subsequent moves, Z compensation dies. I tried with 2 LCDs same results. Also tried after flashing the board with my "bare minimum configurations" same results. Now the second I go the PC to move the X or Y via g-code it works again. (or my TFT screen) The LCD is deactivating the z compensation somehow but even when this happens I check the PC with a M503 and it shows UBL is active.

                                     **** 2. UBL not leveling correctly on Y ****

My leveling was very off after building the mesh via automatic probing (was always perfect when I did a manual probing) I found the source of the problem. It wasn't just on Y, it was also not leveling accurately on X but it wasn't that apparent so I missed it. Marlin UBL is working perfectly recording the probe points, creating the mesh and then applying its algorithms to calculate the z compensations. I know because I tested it probe point after probe point with my micrometer. The problem is the BLTouch probe at the point of recording the value. It is recording wrong values. The probe repeatability test I conducted showed an excellent result, mean deviation of 0.007mm but when it has to probe in different areas of the bed, it is a different story. Seems to be adding about 0.300 to 0.400mm extra to each value. I filmed with a camera at high FPS the movements of the probe and the micrometer as it was recording its 25 point mission to create the mesh. I knew how off my bed actually was as tested and measured it previously with my micrometer. I loaded the recording on a video editor I have where I can control it frame by frame in order to see the exact recording point with lasts for less then a second. My beds deviation at this time (lets only use 3 points and center is always 0) at X300 Y600 +0.150 (center back) X300 Y300 0.0 (center middle) X300 Y0 -0.100 (center front) I am using whole numbers for simplicity. The automatic leveling via BLTouch probe produced a mesh with values as such: ( I only will only mention the 3 same points) X300 Y600 +0.550 (center back) X300 Y300 0.0 (center middle) X300 Y0 -0.400 (center front) The mesh is off 0.400mm in the center back area and off 0.300mm in the center front. That's a lot enough to really mess up a good first layer. I though the probing was accurate and by some strange reason Marlin was doing some incorrect mesh translations but as I reviewed the video at exact moment of probe z recording, I can clearly see that the micrometer mesh points that has been recorded and shown in the topography report values are the same as shown on the actual micrometer values. IT IS THE PROBE ITSELF, that is recording the wrong values. It is not Marlins fault, Marlin it is creating a mesh at the 25 points exactly as has been recorded and applying the z compensation to make the bed level perfectly. This explains why when I do the mesh manually it levels the bed correctly. I do not know if it is a physical issue of the BLT, the internal circuitry, or it is acting like this by design which I doubt. I have a new in the box BLT 2.0 version which I will try. For now I would like to try something. Could someone tell where I can change the z axis speed when it is creating a mesh automatically? I know I can change the "global" feed rate value to make it slower but is there somewhere I can change its feed rate only when it is creating the actual mesh (G29 P1 command)?

So in summary: What changes can be done with the LCD configurations or code itself to make it work with UBL while moving around in a non print move along X or Y? How do I get BLT to record the mesh points correctly? (For now I will try to slow down the Z and will try the new BLT 2.0 and report.

[gloomyandy]

This may be obvious (in which case apologies), but just wanted to check. Looking at your machine, you have a fair offset from your micrometer to the nozzle and then again to the probe. I assume that when you are using the micrometer you are adjusting the X Y points so that the readings you get are for the same physical bed location tested by the probe?

So for instance let's say your probe is behind the nozzle by 20mm and your micrometer is in front of the nozzle by 30mm, to keep things simple lets assume the X offset is zero in both cases. During probe operations Marlin will apply probe offset values so that the probe is positioned at the correct point. So if you wish to probe say X300, Y300 Marlin will move the nozzle to X300, Y280 so that the probe is correctly located, but the micrometer will be at location X300, Y250. So if you record the probe value and micrometer reading during the same probing operation you will be seeing readings that are actually 50mm apart.

If you want to make a manual measurement using the micrometer you will need to move the nozzle manually to location X300, Y330 to measure the same point. Note that during non probe operations the probe offset is not applied so that a manual move to X300, Y300 will result in the micrometer being at X300, Y270.

As I said this may be all very obvious to you, but I think it can easily get very confusing and may not be obvious to others.

[Flight77]

Yes I agree I'm aware of the offset between the probe and the nozzle and also the offsets between the micrometer and the probe and nozzle. I have taken all the offsets into careful consideration. Yes the actual probe is safe homing at the "center of the bed" at X330 Y280 exactly......to compensate for my BLT offsets. The micrometer is located about 40mm to the right of the nozzle and a few more mm away from the probe. I used whole numbers in my illustration for the sake of simplicity so others can see the great deviation that the probe is recording which sometimes is almost off by half a millimeter. Here's something that needs to be understood about the bed of my printer it is a thick aluminum 660 mm by 660 mm which is very big, however I am very fortunate because the physical bed itself is extremely level. It only has a small dip towards the center front of no more than 0.150mm. At no point from one extreme to the bed to the other is there any deviation greater than 0.150mm I have also hand leveled the three Z motors to try to get the bed as level as possible in relation to the carriage. So between nozzle and the bed no matter where I move in the X and the Y I do not have any deviation greater then about +- 0.200mm (I can almost print without leveling active but I want to try to get it as perfect as possible) So even with such a great distance from my micrometer to the probe which I am aware of, and the fact that the bed is already leveled at some really tight tolerances, it does not justify such a huge difference in the recording of the probe points. Again I have verified in the video by freezing the frame where the probe is recording the points that it shows a recording of three to four times more than it would need to be recorded at that point. (with this huge amount of error it almost becomes irrelevant the big distance of my micrometer to the probe..... but still, I took that distance in consideration) The BLT is recording the points incorrectly almost like if the z is moving to fast and the probe trigger point "is late" in catching the recording.

Anyway to recap I will try my new 2.0 BLT and also will try to slow down the Z feed rate and report back.

Regarding my earlier question is there somewhere I can slow down the Z speed when it's doing the automatic probing?

On Nov 7, 2018 4:25 AM, "Andy Shaw" notifications@github.com wrote:

This may be obvious (in which case apologies), but just wanted to check. Looking at your machine, you have a fair offset from your micrometer to the nozzle and then again to the probe. I assume that when you are using the micrometer you are adjusting the X Y points so that the readings you get are for the same physical bed location tested by the probe?

So for instance let's say your probe is behind the nozzle by 20mm and your micrometer is in front of the nozzle by 30mm, to keep things simple lets assume the X offset is zero in both cases. During probe operations Marlin will apply probe offset values so that the probe is positioned at the correct point. So if you wish to probe say X300, Y300 Marlin will move the nozzle to X300, Y280 so that the probe is correctly located, but the micrometer will be at location X300, Y250. So if you record the probe value and micrometer reading during the same probing operation you will be seeing readings that are actually 50mm apart.

If you want to make a manual measurement using the micrometer you will need to move the nozzle manually to location X300, Y330 to measure the same point. Note that during non probe operations the probe offset is not applied so that a manual move to X300, Y300 will result in the micrometer being at X300, Y270.

As I said this may be all very obvious to you, but I think it can easily get very confusing and may not be obvious to others.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/12318#issuecomment-436559397, or mute the thread https://github.com/notifications/unsubscribe-auth/AGbX8Fs0tIMKnSUxcXqSuPDEQMnnkNGcks5usqcggaJpZM4YM6b4 .

[Flight77]

Quick correction...I meant to say "the actual probe is safe homing at the "center of the bed" at X300 Y300 exactly and the nozzle is at X330 Y280 to compensate for my BLT offsets"

[gloomyandy]

It looks like you have already adjusted the probing speed:

// Feedrate (mm/m) for the first approach when double-probing (MULTIPLE_PROBING == 2)
#define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z

// Feedrate (mm/m) for the "accurate" probe of each point
#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 3) // Stratus Tune Default is 2

Did that not slow it down? Does setting the number of probes to be > 1 make any difference?

[Flight77]

Yes I did those changes. That only slows it down when it's homing but not when it's actually doing the automatic probing.

Where can I change it when it's actually probing?

[AnHardt]

Haven't read the complete tread - but it's looking like a twisted y-axis to me.

[gloomyandy]

Are you sure that changing Z_PROBE_SPEED_SLOW does not change the probe speed for you? I've literally just tried this with a Marlin bugfix-2.0.x from a couple of days ago and changing the define of Z_PROBE_SPEED_SLOW from...

#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 2)

to

#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 8)

Certainly slowed both homing and probing Z speeds for me. Running UBL and testing with G28 and G29 P1

[Flight77]

Ok, let me try again with (Z_PROBE_SPEED_FAST / 8) to really slow it down so I can not miss the difference.

[Flight77]

Yes, my bad. It does slow down both homing and z probing. No change in results though from /2 to /8

       Z_PROBE_SPEED_FAST / 2
    ( 60,540)                      (540,540)
        0       1       2       3       4
 4 | +0.199  +0.271  +0.309  +0.398  +0.418
   |
 3 | +0.119  +0.190  +0.205  +0.303  +0.335
   |
 2 | +0.013  +0.034 [+0.003] +0.125  +0.205
   |
 1 | -0.159  -0.167  -0.204  -0.113  +0.039
   |
 0 | -0.397  -0.516  -0.542  -0.433  -0.245
        0       1       2       3       4
    ( 60, 60)                      (540, 60)

    Z_PROBE_SPEED_FAST / 8

( 60,540)                      (540,540)
        0       1       2       3       4
 4 | +0.206  +0.294  +0.326  +0.413  +0.420
   |
 3 | +0.133  +0.213  +0.210  +0.305  +0.342
   |
 2 | +0.019  +0.037 [+0.016] +0.124  +0.219
   |
 1 | -0.125  -0.157  -0.204  -0.106  +0.054
   |
 0 | -0.384  -0.479  -0.510  -0.428  -0.225
        0       1       2       3       4
    ( 60, 60)                      (540, 60

I stand by in my assessment that there is a major error in the over all BLT probe recording in relation to my bed but I do have to hand it to the BLT, it is very consistent showing same values for my bed. I almost want to say it is correct and it does a great job but I can't. The results make no sense and my bed is leveled better with the UBL off then on. Anyway, next step...I will install my new BLT 2.0 and report back.

[Roxy-3D]

I stand by in my assessment that there is a major error in the over all BLT probe recording in relation to my bed but I do have to hand it to the BLT, it is very consistent showing same values for my bed.

Haven't read the complete tread - but it's looking like a twisted y-axis to me.

Yes... I think it is very likely AnHardt has identified the problem.

I suggest you do this and report back the results: Do a G28. Then move the nozzle to each corner of the bed. In each corner of the bed, very carefully, lower the nozzle until it just touches the bed. Then measure and record the height of the BL-Touch pin from the bed.

[Flight77]

If all 4 measurements are the same I do not have a twisted Y axis correct?

[Roxy-3D]

If all four are the same, that would be evidence the gantry is not twisted. But if two of the corners are noticeably different from each other, that is evidence that gantry is twisted. The two most important corners to measure would be (0,0) and (600,600).

Also... A G26 Mesh Validation Pattern using the probed mesh would be very telling. That would show imperfections in the measured points.

[Flight77]

All 4 corners, I'd say, are within less then 0.050mm of each other, almost not a measurable distance. So for all practical purposes, yes, all 4 corners are exactly the same.

Each mesh point is assigned a exact number which is the Z deviation from 0 either positive or negative, what exactly are "imperfections in the measured point" could you explain what you mean? Thanks