› ›

Autobed Leveling Issue/Behavior

meetsuebeshemeetsuebeshe
edited October 2019 in Questions & Answers
Hello,

i have a strange behavior which i cannot solve for quite a while now. I've searched the forum and internet but did not find a solution, so i ended up here. Hopefully i've posted in the correct subforum.

I'am running a Delta at currently 0.92.9 and i want to update my machine to the lastest FW Version.

I'am using a 3 point FSR system underneath the bed that works flawless with 0.92.9 (see attached config.h). When i use G32 the printer homes to his max.Endstops then lowers the Nozzle about 5mm over the bed and then triggering the FSR and i get an almost even bed. Rest is done by dist. correction. Also Single Probing via G30 works.

When i update to 1.0.3 (or anything between 0.92.9 and 1.0.3) the printer works just fine up to that point when i start ABL. Printer homes once then the effector goes down ~50mm above the bed, then homes again, go down once again and begin the Leveling routine. When the Nozzle triggers the FSR it moves up a bit an i get an error. No matter if G32 or G30.
(z-probe did not untrigger on repetitive measurement - maybe you need to increase distance!)

I switch back to 0.92.9 and it works.

I've used the same settings for both Versions and i did not change anything on the printer. I've also played around with heights (Sensing Distance, Z-height and so an) if maybe i've some errors in my math but still not working.
Maybe i've just overlooked something. If you need additional information please let me know.

Thanks in advance.

Gruesse aus Oesterreich,
Mfg,
Gerald

Comments

  • meetsuebeshemeetsuebeshe
    edited October 2019
    1.0.3 config.h   - https://ufile.io/grmxwtho
    0.92.9 config.h - https://ufile.io/8e7gs3wx
  • RepetierRepetier
    Ok, for repetitive moves you need to go back up a bit to untrigger sensor, but you have
    #define Z_PROBE_SWITCHING_DISTANCE 0
    so it will stay with triggered sensor. That would be one problem.

    The odd thing is you have
    #define Z_PROBE_REPETITIONS 1

    and when I look into current version 1.0.4dev you would not go into the repeated mode where that message is generated.

    So please increase first Z_PROBE_SWITCHING_DISTANCE and update to dev version. That is the last stable one and where I checked the code. Just did not have time to replace 1.0.3 officially with it. Now the problem should be gone.
  • meetsuebeshemeetsuebeshe
    Hello and thanks for your fast reply.

    I've tested it right now but it did'nt solve my problem, no matter if repetitions are activated or not (and if, i've tested it with different switching distances) - config.h for 1.0.4dev is here https://ufile.io/6mbtvnim

    The Error now:
    (z-probe did not untrigger - maybe you need to increase distance!)

    Now i've also played around with signal handling and tried to invert the signal and so on.
    The Probe triggers correct (high on hit at M119)
    Question is why does it work on 0.92.9 with same settings.

    mfg,
    Gerald
  • RepetierRepetier
    No idea why it does not work and 0.92 does. Maybe 0.92 did not test fro these errors. Not sure when all the checks were added. What I see is

    #define Z_PROBE_SWITCHING_DISTANCE 0
    #define Z_PROBE_REPETITIONS 0

    should be

    #define Z_PROBE_SWITCHING_DISTANCE 2
    #define Z_PROBE_REPETITIONS 1

    You might need to set
    #define Z_PROBE_DELAY 200

    depending on how long the sensors keep the signal high after unloading. Especially these electronic sensors sometimes hold signal for a few ms so reading directly afterwards might still show wrong signal.

    If it does not work do a G30 in middle and describe what happens exactly. Does it go up, does it do repeats.
  • meetsuebeshemeetsuebeshe
    Haha...durchs reden kommen die leut' zam!

    The Problem could be considered as solved.

    It was the Sensing Delay. When i first hooked up my FSR i have set Z-min should be 500ms on high ;)

    And if i'am not totally blind when i look to 0.92.9, you just simply dont look for any delay, even if there is some. So it's almost clear why it has worked in 0.92.9...

    with 100ms on the sensor and 150ms in the Firmware it looks like it will work now ;)

    thanks,
    Gerald
Sign In or Register to comment.