Work092: Auto-bed leveling screws up non-leveled printers!

[kyrreaa]

There seems to be multiple issues with the bed leveling and eeprom handling as well as probing now. Don't know why people still insist on this crap when what they really need to do is just adjust their bed and be done!

Firstly, there is misisng checks on the leveling data from eeprom apparantly. The printer keeps printing Info: NaN NaN NaN NaN NaN NaN NaN NaN... whenever it reads it. This is interesting by itself, but for the fact that bed leveling is disabled. It should not care. Turning bed leveling on leads to full stop with illegal delta coordinates.

Z-probing works sometimes but other times it just retracts as if already hit and reports same number always to host.

All I need to do here is set my calib to 0, and not use it so I can dial in my endstops and bed, but the state of the code now prevents this. Can someone clean it up?

Edit: Erasing eeprom completely and restoring with new defaults seems to have cleared up the Info: NaN NaN stuff. It now lists; Info: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 But, it should have repaired these values by itself...

I've tried every value I can think of for the probe parameters but it still refuses to probe. After a reset and reflashing I managed to get 1 full prbe run of the bed map but have since not been able to get it to run again. It's as if the successfull running of the bed map does something to the firmware/eeprom?

[repetier]

Ok, I have updated the matrix problem. It now even tests if the sum of squared values is 3, which it should for a rotation matrix. So now it repairs on start if it was used without autoleveling before. Also fixed the decouple tests.

If it retracts directly it is normally that the z-probe is already signalling a hit. Check what G31 is telling you. I have already probed with this version successfully. Also you could check the eeprom values that influence probing. Wrong/too low values can cause strange results like repeat probing not working if minimum lift is too low.

[kyrreaa]

Thanks! Wonderfull!

It turned out the probe pin on the board had a bad joint so you are absolutely right on the triggering hit. May I suggest it in the future return a failed probe instead? It cannot measure the height when it is already detecting a hit on the start of motion so it is a failed attempt and returned data is invalid.

As for the matrix, super! Now all I need to do is find out why homing does not go all the way and in addition is very slow... I see it calculating a possible max length to travel but on the printer it moves only a lot sloeer than I ask it to, and it stops after 1/3 printer height. (400mm travel on 140 steps/mm btw)

[pascallanger]

Hi,

"May I suggest it in the future return a failed probe instead? It cannot measure the height when it is already detecting a hit on the start of motion so it is a failed attempt and returned data is invalid."

This is exactly what I've proposed in the past but the code change was not accepted. Here is how I implemented it in my printer.cpp (tested and working):

void Printer::waitForZProbeStart() { // Begining of change if(isZProbeHit()) {

if UI_DISPLAY_TYPE!=0

    uid.setStatus("Release Z-Probe");
    uid.refreshPage();
  #endif
  while(isZProbeHit())
  {
      defaultLoopActions();
  }
  HAL::delayMilliseconds(30);
}

if Z_PROBE_WAIT_BEFORE_TEST

// End of change

if UI_DISPLAY_TYPE!=0

uid.setStatusP(Com::tHitZProbe);
uid.refreshPage();

endif

ifdef DEBUG_PRINT

debugWaitLoop = 3;

endif

while(!isZProbeHit())
{
    defaultLoopActions();
}

ifdef DEBUG_PRINT

debugWaitLoop = 4;

endif

HAL::delayMilliseconds(30);
while(isZProbeHit())
{
    defaultLoopActions();
}
HAL::delayMilliseconds(30);
UI_CLEAR_STATUS;

endif

}

Basically, it displays a message on the LCD that the probe needs to be realeased (due to bad connection, probe already activated, ...) and wait for ever before continuing. If you are able to release by hand the issue then the process will continue normally.

Regards, Pascal