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

Height map has a substantial Z offset error with mesh

Scheduled Pinned Locked Moved
Tuning and tweaking
9
30
4.6k
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.
  • undefined
    Origami
    last edited by Origami 24 Jul 2019, 21:03

    Just an update.. I did absolutely no modifications beside the heater stuff yesterday, however today i just did another mesh and there was 1 point that was below 0 and the warning message went away. I started another print and my z babystepping value went from -0.95mm to -0.45mm which is much better than before but still not what I had before which is max -0.25mm.

    alt text

    undefined 1 Reply Last reply 22 Feb 2021, 13:53 Reply Quote 0
    • undefined
      Veti
      last edited by 25 Jul 2019, 05:53

      you are probing on glass with an Ir sensor.
      check that the point where you are probing does not have any special feature, since its the center and that is where the thermistor is.

      do check the repeatrability of your probe at different places.
      https://forum.duet3d.com/topic/6962/m48-measure-z-probe-repeatability-and-print-to-serial-output/7

      1 Reply Last reply Reply Quote 1
      • undefined
        gueee78
        last edited by 25 Jul 2019, 17:18

        Hey Veti,

        no he's not probing on glass he uses a TH3D sheet, completely opak and it worked flawlessly before. That phenomenonm started to appear all of a sudden with nothing changed. Btw it got better again, but the repeatability is still rather bad.
        Switchin the printer off and on again usually trows the settings off by about 0.3mm wich is way too much imo.

        1 Reply Last reply Reply Quote 1
        • undefined
          mjnewman
          last edited by 28 Dec 2020, 00:20

          I'm now having the identical issue. Origami did you ever solve this issue you were having???

          1 Reply Last reply Reply Quote 1
          • undefined
            pkos
            last edited by 11 Feb 2021, 18:22

            I'm also seeing the problem.

            Home Z works flawlessly, sets the distance exactly right, but mesh is always too high, which impacts the quality of the print...

            Voron 2.4 (Duet 3 6HC + 3HC standalone), Voron SW (Duet 3 mini 5+ standalone), Voron Trident (Duet 3 mini 5+ standalone), Voron 0.1

            1 Reply Last reply Reply Quote 0
            • undefined
              ziggymanpopo
              last edited by 11 Feb 2021, 19:02

              Im wondering if it might have somthing to to with the distance of the sensor from the print surface, more than the progaming or the ver. Instaled. Could a new ver. affect the readout of bed leveling mesh? And does the value returned by the senor get funky at a certain hight??? I know sensors have a sweet spot. That would chainge with type of sensor Just a thought 🙂

              1 Reply Last reply Reply Quote 0
              • undefined
                pkos
                last edited by 11 Feb 2021, 19:10

                That is a good question.

                What I see is really weird.

                I run G28 - everything gets set perfectly. I check if the nozzle touches the bed on z0 - it does. I move the carriage around a bit, come back to probing point - still, nozzle touches the bed just fine.

                But the moment I hit G29 - it seems as if 0.25 is added to the readings. I don't exactly understand why only then this happens.

                Voron 2.4 (Duet 3 6HC + 3HC standalone), Voron SW (Duet 3 mini 5+ standalone), Voron Trident (Duet 3 mini 5+ standalone), Voron 0.1

                undefined 1 Reply Last reply 11 Feb 2021, 20:56 Reply Quote 0
                • undefined
                  fcwilt @pkos
                  last edited by 11 Feb 2021, 20:56

                  @pkos said in Height map has a substantial Z offset error with mesh:

                  But the moment I hit G29 - it seems as if 0.25 is added to the readings. I don't exactly understand why only then this happens.

                  We are missing a lot of information - you should start a new topic.

                  Did you move to the center of the bed and issue a G30 before creating the height map AND before loading the height map?

                  Frederick

                  Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6

                  1 Reply Last reply Reply Quote 0
                  • undefined
                    JKonopacki @Origami
                    last edited by 22 Feb 2021, 13:53

                    @Origami

                    Im encountering the same issue. My setup is a Duet Ethernet 2 + PanelDue 7i on an Ender5plus mechanicals which uses a BLtouch probe. My mesh has ~.5mm offset from Z-zero which I can assure you is not correct. The mesh values are generated by using the "built in" IMG_1764.jpg mesh compensation routine P0. My observation is that the velocity which this routine runs the Z travel during probe is significantly faster than the velocity commands I use in my manual level macros. I would assume that the the velocity would affect the trigger point by the fixed sampling + filtering of the signal.

                    undefined 1 Reply Last reply 22 Feb 2021, 14:22 Reply Quote 0
                    • undefined
                      fcwilt @JKonopacki
                      last edited by 22 Feb 2021, 14:22

                      @JKonopacki said in Height map has a substantial Z offset error with mesh:

                      The mesh values are generated by using the "built in" mesh compensation routine P0.

                      Are you talking about the symbol below the P0?

                      There is no built-in routine - that symbol just executes a G32 command which in turn invokes bed.g.

                      The intended purpose of bed.g is to implement one of the bed leveling features.

                      Somehow a lot of folks end up using it for mesh bed compensation which is something else entirely.

                      If it behaves differently it has something to do with your code.

                      Frederick

                      Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6

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