Strange AutoLevel Behaviour

shaiss

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)

gcode: https://drive.google.com/file/d/0B1drD8vmGXPxbG03cWtMd1hieDQ/view?usp=sharing</div><div style="font-size: 13.3333px;">repetier log: http://pastebin.com/xz1LDvCF</div><div style="font-size: 13.3333px;">video: https://goo.gl/photos/H7j8JYnfA1Ky8J2a9 (skip to 22 seconds for the issue)

config.h: https://1drv.ms/u/s!ApzOdVx9w7haifw1Tc8G1fmHvbuZ6Q</div><div style="font-size: 13.3333px;">eeprom dump: https://1drv.ms/u/s!ApzOdVx9w7haif4D1T4dzVBpg2W5tg</div><div><br/></div><div><img src="http://mprime.io/wp-content/uploads/2016/08/M_Prime_One_4-1024x683.png" />

Repetier

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.

shaiss

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.

shaiss

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.

Repetier

<font face="Arial, Verdana">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.</font>

I guess

<font face="Arial, Verdana">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.</font>

<font face="Arial, Verdana">One thing could be distortion correction if enabled, so test G33 L0 to see if there are somehow big values not belonging in it.</font>

<font face="Arial, Verdana">Maybe after the tests we see clearer where it went wrong.</font>

shaiss

<font face="Arial, Verdana">Yes, the BLtouch light turns off when its probing (aka online).</font>

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

<font face="Arial, Verdana">https://pastebin.com/YFv2dQJX</span></font><br/></div>

shaiss

Then G32 and here's the output

<font face="Arial, Verdana">https://pastebin.com/xi4QGQpN</span></font><br/></div><div><font face="Arial, Verdana">
</font>

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

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.

Repetier

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.