3D heightmap problem



  • OK so this is odd… Maybe someone can clarify for me...

    I though the base point the hightmap is calculated to is to Z=0. So when I home Z this is the origin.
    In conclusion if I probe the same point which I use to home Z the heightmap should have 0 too (in theory, I know there might be a little differenc even if I probe that point right way without moving or doing anything else).

    So I tried this and here are my results:
    Run 1

    Run 3

    Run 4

    Run5

    Run 6

    I did 6 consecutive runs from from the webif (I hit the "Auto bed compensation" button).
    As you can see each run the grid is lower than before.

    This is my bed.g file:

    ; home all
    G28
    ; Clear any bed transform
    M561
    ; Probe the bed with grid compensation (IR Probe)
    G29
    
    

    What am I doing wrong?


  • administrators

    Try using M561 before G28 instead of after.


  • administrators

    PS - how are you homing Z in your homing files - in particular, do you have any G92 commands in there?



  • Ok that fixed it:
    Run 1

    Run 2



  • So the compensation has an influence on homing?
    If I follow the wiki there is no homing done in the bed.g. That description is still for the old leveling as you describe everything for the new G29 in a new section. But this section does not tell you about M561.
    The guide just tells you to home and then probe the bed. So if you do that consecutively you run into the same problem as I did…



  • OK but still I have issue with the heightmap in the browser…
    I think if I trigger bed leveling from the PanelDue the web interface still displays the last height map and not the save one...

    A second thing I found is that the display is not complete somehow.
    Compare this two pictures:
    Web interface:

    Excel:

    Above the excel diagram you can see the values.
    The webif seems to miss the first line…


  • administrators

    Hi Alex,

    1. You didn't answer my PS about G92 commands in the Z homing section of homeall.g. If you have a G92 command then bed compensation will certainly be affected by bed compensation. It has to be, because if you set G92 Z0 then when you next send G1 Z0 you want it to go to the same height.

    2. Please upgrade to DWC 1.14 if you are using a 1.14 beta or 1.14RC. I think I remember Chris saying that an issue with the browser caching the height map file has been fixed in the 1.14 release.



  • 1. no there are no G92 commands anywhere in my config files…

    2.:

    Firmware Name:	RepRapFirmware for Duet WiFi
    Firmware Electronics:	Duet WiFi 1.0 + DueX2
    Firmware Version:	1.17a (2017-01-02)
    WiFi Server Version:	1.03 (ch fork)
    Web Interface Version:	1.14
    
    


  • Just for reference, here is my homeall.g:

    ; Relative positioning
    G91
    
    ; Lift Z
    G1 Z2.5 F3600
    
    ; Move towards all axes endstops (first pass)
    G1 X-999 Y-999 U999 F2400 S1
    ; Go back a few mm
    G1 X5 Y5 U-5 F3600
    ; Move slowly to axes endstops once more (second pass)
    G1 X-999 Y-999 U999 F360 S1
    
    ; Absolute positioning
    G90
    
    ; Go to first bed probe point and home the Z axis
    T99
    G1 X150 Y100 F3600
    T-1
    ;G1 X150 Y100 F3600
    M401
    
    G91
    G1 Z-999 S1 F3600
    G1 Z3
    G90
    
    G30
    M402
    
    ; Uncomment the following line to lift the nozzle after probing
    ;G91
    ;G1 Z5 F100
    ;G90
    
    


  • I've resorted to placing a G29 S2 in my homeall.g just after the clear transformations M561. I've had the problem between prints where I'll do another G29 and everything goes red and shifted down. The G29 S2 appears to solve this issue as I always do a G28 before any print job.

    My bed.g now has

    G29 S2
    G29
    G29 S1

    This was suggested by another user and appears to work. I still also have the G29 S2 and M561 in the homeall.g file.

    I would love to see an official doc on G29 instead of going by what appears to work. I looked at the code and it seams to me a G29 by itself should work, if I do that however I get the Z shift issue.

    Jeff


  • administrators

    Can you please share your heightmap.csv so I can take a look at it?



  • @chrishamm:

    Can you please share your heightmap.csv so I can take a look at it?

    http://owncloud.alitecs.de/index.php/s/MkZ4TubqrwRhAY1

    It is just a small map because of all the issues I face I want the sequence to be fast…



  • @(In)Sanity well another command for the same thing I assume… The adding error that each consecutive execution some amount is added is fixed if I do M561 before homing. I think I can replace that with G29 S2 to clear the compensation...



  • I probe 24 points each print. I have a modded FFCP and the bed tends to move around a bit on the springs even though I have them pretty tight, Overall not too bad but I just don't trust it to stay the same. The one that kills me is the saggy gantry from it's former life with the MK10 extrudes. It's running a bowden driven E3D legends pack now.

    One thing that bugs me is I can move the carriage in a negative X position to get the probe closer to the edge of the bed, however doing so just results in 0's on the map. I find that very irritating.

    From a print that I just ran:

    RepRapFirmware height map file v1 generated at 2017-00-10 07:09, mean error 0.03, deviation 0.06
    xmin,xmax,ymin,ymax,radius,spacing,xnum,ynum
    22.00,220.00,8.00,142.00,-1.00,38.00,6,4
    0.118, 0.121, 0.138, 0.100, 0.040, -0.018
    0.047, 0.055, 0.055, 0.030, -0.038, -0.070
    0.007, 0.033, 0.055, 0.028, -0.009, -0.080
    0.004, 0.026, 0.039, 0.024, -0.020, -0.047

    Jeff



  • Looking at all the screens I posted it is pretty obvious. If the displayed axes are at 0,0,0 then the beginning of the rendered plane is always too far away from the origin in Y direction considering that my lowest Y value is 35…


  • administrators

    @(In)Sanity:

    One thing that bugs me is I can move the carriage in a negative X position to get the probe closer to the edge of the bed, however doing so just results in 0's on the map. I find that very irritating.

    Do you have a M208 S1 X-### command in config.g to tell the firmware that the carriage can move left as far as X-### ? If you don't, it will assume that X=0 is the lower limit.



  • @dc42:

    @(In)Sanity:

    One thing that bugs me is I can move the carriage in a negative X position to get the probe closer to the edge of the bed, however doing so just results in 0's on the map. I find that very irritating.

    Do you have a M208 S1 X-### command in config.g to tell the firmware that the carriage can move left as far as X-### ? If you don't, it will assume that X=0 is the lower limit.

    I do not, so many g-codes, a lifetime of learning. I'll give that a try, I'm sure it'll work by the sounds of things.

    Thanks,

    Jeff



  • @dc42:

    @(In)Sanity:

    One thing that bugs me is I can move the carriage in a negative X position to get the probe closer to the edge of the bed, however doing so just results in 0's on the map. I find that very irritating.

    Do you have a M208 S1 X-### command in config.g to tell the firmware that the carriage can move left as far as X-### ? If you don't, it will assume that X=0 is the lower limit.

    M208 did solve the problem, I can now get within 10mm of the left edge which is close enough. The rest of the build plate I can hit each corner.

    Thanks again,

    Jeff


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.