›

Strange AutoLevel Behaviour

shaissshaiss
edited March 2017 in Repetier-Firmware
I had my reprap working great with the bltouch on the latest dev fw, no issues other than slicing and slightly loose x axis.
Today, I setup repetier server on an old windows pc (just for testing before I go by a Pi3) and proceed to setup.  No issues with setup and the movements seem ok.  

I print a gcode file that I printed yesterday with repetier host, but this time through repetier-server.  I tried the same gcode over an SD card and the same thing happens.  In both cases after the G32 S2 command completes, the nozzle is lowered beyond Z0 and therefore the head crashes into the bed.  

NOTE, this is the mprimeone which uses has the z axis sitting on a nylon nut (its the white part on the threaded rod in the picture below).  because of this the nozzles just sit on the buildplate, tell the z axis reverses and turns in the positive direction.

If I take the same gcode below and remove the G32 S2 command this DOES NOT happen.

So my ultimate question is, if the only change in hardware was tightening an X axis belt, no changes to fw or eeprom (aside from max z height), could repetier server have changed something or raised a bug?  I have tried this of an SD card NOT with the USB unplugged and the same thing happens.

Any help would be appriciated as I'm completely lost as to what is causing this.   And yes, I know I don't have to run G32 S2 on every print, but for the sake of this discussion, let's leave that out)


image


Comments

  • RepetierRepetier
    Furthermore you should remove S2 if you do not reuse it to reduce eeprom writes.

    No server does not change anything in eeprom which would be the only way to change it.
    What might have happened is that a eeprom error invalidated the checksum and then values are set to configuration.h values which might include a different z probe height. Only reason I see why it changed without uploading something.

  • shaissshaiss
    I'll remove that S2.  Without that, where does the z height get stored?  Is it in memory until the board is powered off, then lost?

    Would you suggesting reloading the FW at this point with a different eeprom version to start clean?

    If the eeprom checksums fail, would I still be able to read the eeprom via the LCD or repetier-host?  Seems like that would fail too.

    If you look @ the end of the video, what throws me off is that the print eventually starts.  But before starting it goes -Z for a few mm, then back up 30mm or so.  Very odd behaviour.
  • shaissshaiss
    Just checked:
    config.h has Z_PROBE_HEIGHT 2.080 
    eeprom dump has value="1.225">Z-probe height

    That's a difference of .855mm.  I don't see how that distance would be driving the nozzle atleast 10mm into the bed.
  • RepetierRepetier
    I guess if it is lighted the probe is offline? So it looks like the 3 points get measured, probe disabled. Just chkecked the source and there should be no extra move from G32 but you could test that by manually sending G32 and see if it then stops.

    I guess 

    G1 Z0.256 F360

    is the command driving it in the bed also that should not be the case. So try G32 and then M114 to see where it thinks it is and then move Z to a safe position to see what the error distance is like.

    One thing could be distortion correction if enabled, so  test G33 L0 to see if there are somehow big values not belonging in it.

    Maybe after the tests we see clearer where it went wrong.

  • shaissshaiss
    edited March 2017
    Yes, the BLtouch light turns off when its probing (aka online).
    If I send G32 S2 I know it probes the 3 points and stores the new z height, I've done that several times with no issues.

    I've done the following and it works fine.
    G28
    G32 S2
    G1 Z2

    If I don't home to z max before g32 then the z height is thrown completly off and G1 Z2 will crash the nozzle into the bed

    I'll check G32 and M114 too when I get back home:

    Here's the output of G33 L0.  notice the "13:52:03.276: G33 X10.00 Y150.00 Z-52.125" on line 5.  How the heck did this happen?  Looks like I need to run G33 R0
  • shaissshaiss
    edited March 2017
    Ran G33 R0
    Then G32 and here's the output

    Then G33 L0
    17:19:41.340: N959 G33 L0
    17:19:41.440: ok 959
    17:19:41.440: G33 X10.00 Y10.00 Z0.000
    17:19:41.440: G33 X10.00 Y45.00 Z0.000
    17:19:41.440: G33 X10.00 Y80.00 Z0.000
    17:19:41.440: G33 X10.00 Y115.00 Z0.000
    17:19:41.440: G33 X10.00 Y150.00 Z0.000
    17:19:41.440: G33 X51.25 Y10.00 Z0.000
    17:19:41.440: G33 X51.25 Y45.00 Z0.000
    17:19:41.440: G33 X51.25 Y80.00 Z0.000
    17:19:41.440: G33 X51.25 Y115.00 Z0.000
    17:19:41.440: G33 X51.25 Y150.00 Z0.000
    17:19:41.440: G33 X92.50 Y10.00 Z0.000
    17:19:41.440: G33 X92.50 Y45.00 Z0.000
    17:19:41.440: G33 X92.50 Y80.00 Z0.000
    17:19:41.440: G33 X92.50 Y115.00 Z0.000
    17:19:41.440: G33 X92.50 Y150.00 Z0.000
    17:19:41.440: G33 X133.75 Y10.00 Z0.000
    17:19:41.440: G33 X133.75 Y45.00 Z0.000
    17:19:41.440: G33 X133.75 Y80.00 Z0.000
    17:19:41.440: G33 X133.75 Y115.00 Z0.000
    17:19:41.440: G33 X133.75 Y150.00 Z0.000
    17:19:41.440: G33 X175.00 Y10.00 Z0.000
    17:19:41.440: G33 X175.00 Y45.00 Z0.000
    17:19:41.440: G33 X175.00 Y80.00 Z0.000
    17:19:41.440: G33 X175.00 Y115.00 Z0.000
    17:19:41.440: G33 X175.00 Y150.00 Z0.000

    M114
    17:20:18.836: N960 M114
    17:20:18.868: ok 960
    17:20:18.868: X:20.00 Y:150.06 Z:10.690 E:0.0000

    Trying a print now and it worked.  The gcode still has G32 S2 in it.

    So the issue was the bump map on line 5 above.
  • RepetierRepetier
    Glad you found it, also it is mysterious to get such a big value in one place. If everything is 0 you should disable distortion correction for improved speed.
Sign In or Register to comment.