dev2: Leveling and Bump Correction Question

Using dev2 on Rumba32 at a test setup and have a question regarding Leveling, Bump Correction:
This is how the setup is on my selfmade cartesian:
  • The bed is mechanically mounted using 3 screws. I test the bed height at the screw position with G29 (test 3 defined positions)
  • G32 is used to get bed rotation, while G32 is testing at 3 positions (defining a plane). I run G32 regularly
  • G33 is used to get the bump map using a 7x7 Grid. G33 is performed very seldom.
Trying this szenario in dev2 I found (but may be wrong):
  • G29 is still commented out (no problem, can wait for it to be implemented)
  • Bump Correction (and G33) is active only if LEVELING_METHOD = 3 (Grid)
  • Both G32 and G33 seem to use LEVELING_METHOD. In this case G32 also uses GRID and not 3 points any more.
  • If I define a 7x7 Grid for G33, G32 will also use this 7x7 Grid, which takes to much time.
  • In my understanding the method of G32 and G33 should be defined separately.
My question is:
 Is the way I'm using Leveling and Bump Correction now (with V1.0.4) how it it thought to be?

If yes, is it planned to have separate leveling methos for G32 and G33 mid term?

Thanks in advance.



Comments

  • G29 is not really a good invention in my opinion. It just takes average height. If it should be physically leveled and you do not want software correction that is the only reason to use it. But if it is leveled you can also just ignore it and home with 1 point.

    If you assume rotation changed you need G32 anyway. I assume you used the physical calibration with 3 motors here.

    G33 should always run directly after G32 to reflect the new rotation so it stays in sync. That is the reason we merged it in V2 into one solution. That way we mathematical split rotation and bump correction in one pass reducing time for measurement and improving precision as we are based on same data base. I think the result is much better then in V1 that way.Therefore I have no real plans to make a separate G33. It is also not really possible to split them for grid leveling. Bump correction is part of the leveling method. You would then need to add bump correction to all other leveling methods with extra settings. Then you really would need a 2 pass process and they should run in a row so adding even more points which makes no sense. But in that case it would be splitable as you like it.
  • Thank you very much for the explanation.

    Of course this is OK for me, despite some steps may take more time.

    Just for having heard the use case:

    The bed is not motorized, just 3 mechanical screws.
    I used G29 and its log output of the three heights for manually adjusting the three bed screws to reach a tolerance < +- 0,1mm

    G32&G33:
    Have a PEI bed (320x320mm) which is working fine for most filament types, but not for TPU (sticks to much).
    So I took a glas pile with a PET film which works good for TPU. The pile is placed on top of the PEI bed.

    G33 was performed on each plate with a 9x9 Grid (The "precision" Alu plate has tolerances of +- 0,25 mm).
    It took about 25 minutes (not speed optimzed, because performed very seldom).

    G32 was configured to measure just 3 points.

    Both bump maps are stored in a script. They contain: G28, G32 S2, 81x G33 X.. Y.. Z.., M323 S1

    When I now place the glas bed on the PEI bed, I run the glas bump map script, which may correct some height position variations.
    When i remove the glas bed, I run the PEI bump map script. Takes about 2 min.

    If G32 and G33 functionality is combined in the V2 G32, my scenario will take more time --- and surely will have more precise results.
    But my printer is not a printer in heavy production ;-)


    Please take this just as information about a possibly exotic use case.

    Regards
  • Thanks for the insight. 25 minutes is in deed a long time.You might reduce it considerably if you reduce min bed height. When you do it regularly 2mm might be enough and time comes linear with that value more or less.
  • Repetier said:
    Thanks for the insight. 25 minutes is in deed a long time.You might reduce it considerably if you reduce min bed height. When you do it regularly 2mm might be enough and time comes linear with that value more or less.
    Good afternoon. Where can this parameter be changed to 2mm?
  • Except grid size (only in configuration.h) you can change z probe settings in eeprom editor in our server for example.
  • Repetier said:
    Except grid size (only in configuration.h) you can change z probe settings in eeprom editor in our server for example.
    When entering G33, the height is again 20 mm (In the journal: Reference Z for measurement:20.000)(

  • #define Z_PROBE_BED_DISTANCE \
    5.0 // Higher than max bed level distance error in mm

    is what defines start height when probing - or the equivalent eeprom value.
  • I found where it changes in the #define ZHOME_HEAT_HEIGHT parameter, thanks
Sign In or Register to comment.