mirror/Grbl_Esp32
1
0
Fork 0
mirror of https://github.com/bdring/Grbl_Esp32.git synced 2025-08-29 09:10:03 +02:00
Code Issues Releases Wiki Activity

Fix a few issues with VFDSpindle critical error handling (#705)

Browse Source 
If a command is critical and fails to receive a response, it should trigger an Alarm. However, because the critical check was only evaluated if the spindle was not already unresponsive, it meant that a critical command failure would be silently ignored if a non-critical command failed before it (putting the VFDSpindle in unresponsive state). Therefore, I've moved the critical check to occur regardless of whether the spindle was already unresponsive.

Second, I believe that setting `sys_rt_exec_alarm` is not sufficient to stop the machine and put it into alarm state. Other alarm conditions (such as hard limits) also run an `mc_reset()` to stop motion first. It appears that without this, motion will not be stopped, and in fact, the alarm appears to get cleared if it occurs during motion!
This commit is contained in:
Scott Bezek
2020-12-14 10:00:26 -08:00
committed by GitHub
parent a1b4cbc192
commit 1a46f444fe
1 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
Grbl_Esp32/src/Spindles/VFDSpindle.cpp
View File

@@ -194,12 +194,13 @@ namespace Spindles {
if (retry_count == MAX_RETRIES) {
if (!unresponsive) {
grbl_msg_sendf(CLIENT_SERIAL, MsgLevel::Info, "Spindle RS485 Unresponsive %d", next_cmd.rx_length);
if (next_cmd.critical) {
grbl_msg_sendf(CLIENT_SERIAL, MsgLevel::Info, "Critical Spindle RS485 Unresponsive");
sys_rt_exec_alarm = ExecAlarm::SpindleControl;
}
unresponsive = true;
}
if (next_cmd.critical) {
grbl_msg_sendf(CLIENT_SERIAL, MsgLevel::Info, "Critical Spindle RS485 Unresponsive");
mc_reset();
sys_rt_exec_alarm = ExecAlarm::SpindleControl;
}
}
vTaskDelay(VFD_RS485_POLL_RATE); // TODO: What is the best value here?