Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Mesh compensation results backwards

    Scheduled Pinned Locked Moved
    General Discussion
    5
    44
    4.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Gamefanatic3Dundefined
      Gamefanatic3D @Gamefanatic3D
      last edited by Gamefanatic3D

      @gamefanatic3d

      Okay I'm back and after much testing over the past week, I'm convinced there is nothing wrong with my Z-Motors, even though the issue I experienced was real. I believe the Duet may have just been having a moment as I was getting a homing error with negative values when performed the first homez.g after startup. Any future homing would be successful. This appears to have cleared itself up as easily as it came with me doing nothing to the system other than turning it off and back on a few times...

      Moving back to the issue at hand here I have mounted a Dial Indicator tool to my system and validated my original statement that the Z-Probing being done and recorded is in fact opposite of what I would expect.

      Note: I made the mount for the Dial Indicator such that I could probe with the BLTouch while having the Dial Indicator tool attached. I realize there is a tension that is created as the Dial Indicator gets closer to the end of its measuring.

      Probing at a point with the BLTouch will return a positive value to the homing file when it should in fact be a negative value.

      My BLTouch trigger value is 0.9.

      I validated this by performing the following procedure:

      Step 1: Setup

      • G28
      • Disable Mesh Compensation
      • Attach Dial Indicator tool. (Manual process for now)
      • G1 X180 Y227 Z6 (Move the BLTouch to a center point on bed)
      • G30
      • G1 X206.8 Y143.4 Z15 (Move Dial Indicator to same point on the bed with specific height/trigger point)
      • Set the Dial Indicator to 0.000

      Now I go to a spot on the bed shown on the heightmap that I know to be a low spot (further away from tools)

      Step 2: Probing Low

      • G1 X328.23 Y224.37 Z6
      • M98 P"/macros/Homing/Bed/MyMeshCompStep1"
      • G1 X355.03 Y140.77 Z15

      The result of BLTouch

      8/28/2021, 2:37:40 PM	G1 X355.03 Y140.77 Z15
      8/28/2021, 2:37:29 PM	Stopped at height 0.987 mm
      -0.085
      8/28/2021, 2:37:28 PM	M98 P"/macros/Homing/Bed/MyMeshCompStep1"
      Stopped at height 0.983 mm
      8/28/2021, 2:36:46 PM	G1 X328.23 Y224.37 Z6
      8/28/2021, 2:36:14 PM	G1 X206.8 Y143.4 Z15
      8/28/2021, 2:36:03 PM	G30
      

      Dial Indicator: -0.08

      I repeat this procedure 3 times in the same spot to validate any potential mechanical issues. Keeping in mind the dial indicator is not as accurate as of the BLTouch and validate the numbers are still roughly the same.

      The heightmap.g in this area is showing a positive value in this area. I believe this is due to the BLTouch returning a positive number when subtracting the two probing values which are greater than my trigger (Z-0) value.
      IE)
      Probe1 returns: 0.918
      Probe2 returns: 0.923
      The resulting value would be acceptable as it's within 0.005
      The value returned should be:

      -0.0205 = 0.9 - ((0.918+0.923)/2)

      But what is recorded in the heightmap is 0.0205

      This is my assumption of what is happening based on the heightmaps I am obtaining. I could be missing something here still...

      MyMeshCompStep1

      var probezHeight = 6
      var TravelSpeed = 6000
      
      var probezOne = 0
      var probezTwo = 0
      
      	while true
      		if iterations = 5
      			abort "Too many auto calibration attempts"
      
      		G1 Z{var.probezHeight} F{var.TravelSpeed}
      		G30 S-1
      		set var.probezOne = sensors.probes[0].lastStopHeight
      		G1 Z{var.probezHeight} F{var.TravelSpeed}
      		G1 Z{var.probezHeight} F{var.TravelSpeed}
      		G30 S-1
      		set var.probezTwo = sensors.probes[0].lastStopHeight
      		G1 Z{var.probezHeight} F{var.TravelSpeed}
      		if var.probezOne - var.probezTwo <= 0.005
      			echo sensors.probes[0].triggerHeight-((var.probezOne + var.probezTwo)/2)
      			break
      
      fcwiltundefined Phaedruxundefined 2 Replies Last reply Reply Quote 0
      • fcwiltundefined
        fcwilt @Gamefanatic3D
        last edited by

        @gamefanatic3d

        In your MyMeshCompStep1 file you have

        if var.probezOne - var.probezTwo <= 0.005
        

        Ignoring any floating point errors:

        if var.probezOne = 1.006 and var.probeTwo = 1.000 then var.probezOne - var.probezTwo = 0.006 and the test fails.

        if var.probezOne = 1.000 and var.probeTwo = 1.006 then var.probezOne - var.probezTwo = -0.006 and the test succeeds.

        In both cases the difference is 0.006.

        I don't understand what you are testing for.


        Also the number returned by G30 S-1 does not have a fixed relationship to the probe Z Trigger Height setting.

        Thanks.

        Frederick

        Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

        Gamefanatic3Dundefined 1 Reply Last reply Reply Quote 0
        • Phaedruxundefined
          Phaedrux Moderator @Gamefanatic3D
          last edited by

          @gamefanatic3d said in Mesh compensation results backwards:

          I believe the Duet may have just been having a moment as I was getting a homing error with negative values when performed the first homez.g after startup. Any future homing would be successful. This appears to have cleared itself up as easily as it came with me doing nothing to the system other than turning it off and back on a few times...

          Have you tried a homez.g without the conditional gcode?

          Z-Bot CoreXY Build | Thingiverse Profile

          Gamefanatic3Dundefined 1 Reply Last reply Reply Quote 0
          • Gamefanatic3Dundefined
            Gamefanatic3D @Phaedrux
            last edited by

            @phaedrux said in Mesh compensation results backwards:

            @gamefanatic3d said in Mesh compensation results backwards:
            Have you tried a homez.g without the conditional gcode?

            I started off without the conditional code and only added it due to a recommendation by @fcwilt.

            1 Reply Last reply Reply Quote 0
            • Gamefanatic3Dundefined
              Gamefanatic3D @fcwilt
              last edited by

              @fcwilt said in Mesh compensation results backwards:

              @gamefanatic3d

              In your MyMeshCompStep1 file you have

              if var.probezOne - var.probezTwo <= 0.005
              

              Ignoring any floating point errors:

              if var.probezOne = 1.006 and var.probeTwo = 1.000 then var.probezOne - var.probezTwo = 0.006 and the test fails.

              if var.probezOne = 1.000 and var.probeTwo = 1.006 then var.probezOne - var.probezTwo = -0.006 and the test succeeds.

              In both cases the difference is 0.006.

              I don't understand what you are testing for.


              Also the number returned by G30 S-1 does not have a fixed relationship to the probe Z Trigger Height setting.

              Thanks.

              Frederick

              I'm attempting to get a height value from the BLTouch that represents the difference from Z-0 which I am interpreting to be in direct relation to when I run my G30.
              In this case, I'm interested in the return values so I can better understand what is happening and see the variations. I'm not so sure how much it matters on the macro as it's not what's actually coming up with the heightmap values, I'm just using it to test my theory and why I can manually set my values in the heightmap vs using the BLTouch and the G29.

              fcwiltundefined 1 Reply Last reply Reply Quote 0
              • fcwiltundefined
                fcwilt @Gamefanatic3D
                last edited by

                @gamefanatic3d

                Thanks.

                I just got back from testing on my printer. I setup the M557 to probe a 3x3 grid. I placed a 1mm thickness gauge at the point at the center of the grid. I created the height map. Below are the values. As you can see the 1mm thickness gauge is showing as a positive value which is as it should be.

                 -0.243, -0.082,  0.013
                 -0.217,  1.115,  0.050
                 -0.195, -0.053,  0.027
                

                Here I used a larger and thicker object leaving it in place at the center of the bed so it's thickness was affecting the Z=0 Datum. As you can see the center point is now reading near 0 and all that other points are reading low by appx the thickness of the object.

                 -3.311, -3.171, -3.068
                 -3.306,  0.001, -3.036
                 -3.278, -3.145, -3.065
                

                So all I can think of is your Z=0 Datum is off.

                Frederick

                Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                Gamefanatic3Dundefined 1 Reply Last reply Reply Quote 0
                • Gamefanatic3Dundefined
                  Gamefanatic3D @fcwilt
                  last edited by Gamefanatic3D

                  @fcwilt

                  Going with where you are headed I did 3 heightmaps. All will use the same points and were done with the bed at 70°C.

                  Map1
                  Normal height map

                   -0.050, -0.086,  0.053
                    0.067,  0.007,  0.090
                    0.251,  0.020, -0.019
                  

                  Map2
                  Normal level with 0.8 feeler gauge put in after in the middle:

                   -0.031, -0.124, -0.038
                    0.061,  0.836, -0.013
                    0.242, -0.035, -0.120
                  

                  Map3
                  0.8 feeler gauge in place when G30 performed:

                   -0.927, -0.969, -0.847
                   -0.833, -0.004, -0.807
                   -0.653, -0.874, -0.904
                  

                  Now taking a look at just the difference between Map1 and Map2 we can see the obvious and expected difference at the middle point. I am a little plagued by the right values being nearly 0.1mm difference. I now wonder if this is my probe or my hardware.

                  When I run my Dial Guage out from the middle I get a negative value of ~ -0.14 after setting its Z-0 at my middle probing point. This is about what I expect based on my manual leveling.

                  https://youtu.be/GCf9Ta9aJSo

                  fcwiltundefined 1 Reply Last reply Reply Quote 1
                  • fcwiltundefined
                    fcwilt @Gamefanatic3D
                    last edited by

                    @gamefanatic3d

                    Hmm... Curious.

                    Some Z axis movement error perhaps?

                    What is your Z axis setup? What is the Z axis movement for one full stepper step - not a micro-step?

                    Frederick

                    Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                    Gamefanatic3Dundefined 1 Reply Last reply Reply Quote 0
                    • Gamefanatic3Dundefined
                      Gamefanatic3D @fcwilt
                      last edited by Gamefanatic3D

                      @fcwilt
                      So I'm not exactly sure how to move a single step, but mechanically this is how I am setup:
                      Dual 1.8° steppers w/ TR8*2 lead screws

                      M350 X16 Y16 Z16 E16:16 I1                ; Configure microstepping with interpolation
                      M92 X201.2499 Y201.2499 Z1601.584008 C100 E421.1332199:690    ; T8x2 1-Start Lead Screw
                      

                      When I perform a single rotation of the Z motor my Dial Gauge reads 2mm at bed center, which is expected. It reads the same when moved to the lead screws and moved one full rotation.

                      Maybe I need to perform some tests for repeatability?

                      fcwiltundefined 1 Reply Last reply Reply Quote 0
                      • fcwiltundefined
                        fcwilt @Gamefanatic3D
                        last edited by

                        @gamefanatic3d

                        Great.

                        That's what I needed to know. You have plenty of resolution even at full steps. A 1.8 degree stepper has 200 steps per revolution. You have 2mm of movement per full revolution. Which means one full step moves 2mm / 200 or 0.01mm.

                        I have heard tell of inexpensive lead screws having poor linearity (moving the same amount for each revolution) . I don't know how common that may be. You could easily use the dial gauge to measure that at different Z positions if you have a 123 block or something to perform the same function.

                        I get my lead screws from these folks: McMaster Carr

                        Frederick

                        Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                        Gamefanatic3Dundefined 1 Reply Last reply Reply Quote 0
                        • Gamefanatic3Dundefined
                          Gamefanatic3D @fcwilt
                          last edited by

                          @fcwilt

                          Thank you for your help up until now. I'll continue to do some testing later this week to see if this is motor-related.

                          I got my Lead Screws from ZYLTech a few years ago. Never thought to look at McMaster. I suspect if there were variations I should see those in my layer lines, which I don't normally have an issue with since upgrading to these. However the anti-backlash nuts are brass and could have some play. I do my best to keep them greased.

                          ccdbb348-b3b0-4716-a64e-22065dc2e568-20210826_054436 (3).jpg

                          8748dcee-a21f-499f-90be-87df60da8694-20210829_134923.jpg

                          I am thinking there may be some play in my Tool Carrier. I know that I can get flex up to 0.14mm when I put some pressure on it, but it does want to return back to 0. Today looking into this further I dove the tool into the bed and found it didn't want to return to its normal height. So I docked and undocked it and picked it up again, the tool height was back to normal. I'm suspecting that it's shifting in the kinematics and even though it's a ball bearing and has no scoring it's not able to return. This would not explain the BLTouch variation, but maybe a factor when it comes to printing.

                          1 Reply Last reply Reply Quote 1
                          • First post
                            Last post
                          Unless otherwise noted, all forum content is licensed under CC-BY-SA