1. 我相信时间问题，产生一个？响应可能需要很长时间才能完成，从而影响准确性（轮询开关状态）。源代码 (limits.c) 中的评论暗示了这一点。

2. 我不知道任何。一个简单的测试是检查报告标志并在归位 do…while 循环中生成报告，看看是否会导致任何问题。如果只有准确性是一个问题，则可以更改为中断处理限位开关状态，最好不要使用软件去抖动。

“？” 归巢时没有报告，因为 grbl 的运行水平比正常水平低得多。在归位时，grbl 禁用限位开关中断，绕过 mc_line()，并直接计划运动以朝向或远离每个限位开关移动。grbl 然后直接执行运动，然后快速轮询限位开关，直到它们跳闸。一旦限位开关跳闸，步进器就会迅速停止（即使规划器短暂地认为它仍在移动）。结束低级归位例程的唯一方法是使限位开关跳闸、行进太远（没有跳闸限位开关）、无法拉下限位开关或发送 cycle_stop/reset 命令……其他所有内容都将被忽略，因为没有时间在循环中运行 protocol_execute_realtime() 。

真的没有理由发送 ‘?’ 在归位期间……归位时没有任何有用的返回，加上处理中断会影响限位开关的可重复性。基于我对 grbl 的深入理解，我不建议添加 ‘?’ 归巢时的反应。限位开关的可重复性会受到影响。当然，您可以通过降低归位进给速度来克服这个问题，但是您的可重复性仍然会根据循环中的时间“？”而无关紧要。收到。

我能想到的唯一原因是您想要回应“？” 而归位是指如果您在 GUI 中计算行数并在发送每行后寻找 grbl 的“OK”。如果是这种情况，请在串行实时命令处理器 (system_set_exec_state_flag
) 中添加一个非常短的串行响应：if(sys.state==homing && char==’?’){return(STATUS_OK);}。

谢谢你的信息，它们真的很有用，我想我会完全按照你的建议去做。您猜对了，我所追求的只是在主循环运行时获得自定义 GUI 的一些反馈以保持 GUI 活动。大约需要 2 分钟到我最长的 (1.2m) 主轴，如果工具头碰巧停在远端附近，例如停电，我觉得屏幕上应该有一些活动。

关于准确性论点……我不太同意。归位周期的第 1 阶段（寻找归位开关）就像任何其他运动一样，所以响应？不应该造成任何伤害。一旦机器找到一个开关，它就会以非常低的速度执行第二种方法，恕我直言，这是准确性真正重要的时候，这是我不会回应的时候？直到刀头完成精细定位。虽然归巢的第 1 阶段可能需要几分钟，但第 II 阶段仅需几秒钟，因此在如此短的时间内没有任何反馈是可以接受的。

不过我会听从你的建议。

再次感谢！

您的机器通常需要 2 分钟以上才能行驶 1.2 米吗？那真的很慢。您可以在归位时设置两个参数……“寻找”可以非常快……之后，（较慢的）归位进给率接管，但它只需要移动一小段距离。

虽然机器的最大运行速度设置为大约 1200 米/分钟，但我将归位保留为默认设置，我认为第一阶段的速度为 300 米/分钟，第二阶段的速度甚至更低。

我认为这对我的机器来说是一个很好的设置。所有正常结束的 G 代码程序都会将工具头带回 0/0/0，它就在结束开关附近。通常归位只需几秒钟。如果机器必须走完主轴的整个长度，就会出现严重错误，可能是停电，或者有人出于某种原因紧急停止。

我确实启动了一个故意缓慢的归位程序，以便最终从刀具路径中移除任何障碍物然后解除紧急停止并告诉机器重置的人有足够的时间在需要时再次按下紧急停止。考虑到我的机器将由未经培训的人员操作，这对我来说感觉更安全。

感谢 doppelhub，我认为我有足够的信息来进行所需的更改。

如果任何主要开发人员曾考虑在归巢（第一阶段）完成之前保留反馈 – 我鼓励这样做，也许将其列入愿望清单。恕我直言，它不会造成任何伤害，并使 GUI 在归位期间更具响应性。

我同意在初始归航过程中启用实时状态报告不会造成任何损害。这可能不会超过 4 行代码来实现。

因为?在归位时被禁用，所以在归位时不可能显示x,y和z坐标？