| 129 | } |
| 130 | |
| 131 | bool BLTouch::stow_proc() { |
| 132 | // Do a STOW |
| 133 | if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPGM("BLTouch STOW requested"); |
| 134 | |
| 135 | // A STOW will clear a triggered condition in the probe (10ms pulse). |
| 136 | // At the moment that we come in here, we might (pulse) or will (SW mode) see the trigger on the pin. |
| 137 | // So even though we know a STOW will be ignored if an ALARM condition is active, we will STOW. |
| 138 | // Note: If the probe is deployed AND in an ALARM condition, this STOW will not pull up the pin |
| 139 | // and the ALARM condition will still be there. --> ANTClabs should change this behavior maybe |
| 140 | |
| 141 | // Attempt to STOW, wait for STOW_DELAY or ALARM |
| 142 | if (_stow_query_alarm()) { |
| 143 | // The stow might have failed |
| 144 | if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPGM("BLTouch ALARM or TRIGGER after STOW, recovering"); |
| 145 | |
| 146 | _reset(); // This RESET will then also pull up the pin. If it doesn't |
| 147 | // work and the pin is still down, there will no longer be |
| 148 | // an ALARM condition though. |
| 149 | // But one more STOW will catch that |
| 150 | // Last attempt to STOW |
| 151 | if (_stow_query_alarm()) { // so if there is now STILL an ALARM condition: |
| 152 | if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPGM("BLTouch Stow Failed"); |
| 153 | probe.probe_error_stop(); // Something is wrong, needs action, but not too bad, allow restart |
| 154 | return true; // Tell our caller we goofed in case he cares to know |
| 155 | } |
| 156 | } |
| 157 | |
| 158 | if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPGM("bltouch.stow_proc() end"); |
| 159 | |
| 160 | return false; // report success to caller |
| 161 | } |
| 162 | |
| 163 | bool BLTouch::status_proc() { |
| 164 | /** |
nothing calls this directly
no test coverage detected