注释
.png "UGS 的慢跑问题和一些可能的修复 #714"){kind=avatar}
|
谢谢，你能做一个PR吗？以这种形式进行评估会容易得多。 |
|
我认为如果我们将这些分解成单独的 PR，将有助于测试和审查。让我们先从竞争条件开始，因为我最近深入研究了 protocol_exec_rt_system，所以我对它还比较新鲜。 您可能已经注意到变量 cycle_stop 与 sys_rt_exec_state 中的位域是分开的。情况并非总是如此。我们遇到了 .bit.CycleStop 的竞争问题。我们通过将 cycle_stop 变成一个单独的布尔值来修复它，它可以用单个字节存储自动设置，不需要读/或/写序列。类似的更改可能适用于 .bit.CycleStart => cycle_start 。这种更改的一个缺点是您无法再一次测试所有位 |
.png "UGS 的慢跑问题和一些可能的修复 #714"){kind=avatar}
|
嗨米奇，谢谢 – 我不知道 cycle_stop 的历史。这有助于了解。 我正准备为我使用的 getter 方法提交 PR，但我认为分解成单独的 bool 可能是更好的方法。它涉及到更多的代码，但我担心的是是否可能需要一个单独的任务（不是 Serial.cpp 或主程序）来监视或更改这些标志。似乎没有任何现有代码属于这种情况（CoreXY.cpp 在其自己的循环中使用标志进行归位，但在主程序上调用）。不过，它似乎可能会在未来发生。 我将整理一个单独的 PR 以分解为单独的布尔值，我们可以看看这是否是最佳方法。 |
|
理想情况下，标志仅在一处进行测试/清除，即 protocol_exec_rt_system。其中一些是从几个地方设置的 – cycle_start 的 6 个地方。我认为设置已经设置的标志不是问题。 Limits.cpp 中的归位代码和 CoreXY.cpp 中该代码的副本违反了“仅一个测试/空白位置”规则。这很麻烦 – 事实上它阻止了我将 protocol_exec_rt_system 转换为适当的事件队列驱动状态机的尝试。但是不涉及cycle_start。 |
.png "UGS 的慢跑问题和一些可能的修复 #714"){kind=avatar}
|
我的修复是在收到点动取消命令时刷新串行缓冲区和线路输入缓冲区。代码可以在这个补丁中找到。 |
.jpg "UGS 的慢跑问题和一些可能的修复 #714"){kind=avatar}
.png "UGS 的慢跑问题和一些可能的修复 #714"){kind=avatar}
大家好 –
在最新版本的 Grbl_Esp32（Ver 1.3a 日期 20201212）和 UGS (2.0.7) 上，我看到一个慢跑问题，从连续慢跑中释放有时会导致慢跑继续并到达终点。还有其他人看到这种行为吗？主要发生在 UGS 中的点动进给速率设置为远高于轴最大速度时。
我是代码库的新手，但我对其进行了调查并进行了一些更改，为我修复了它。不过，我对我所做的更改是最好的解决方案感到不舒服，所以我不想做拉取请求，而是想解释我发现的内容，以防它对任何人都有帮助。
欢迎您使用其中的部分或全部，或者如果您对它如何更好地适应项目有任何建议，我可以对其进行改进。
我的更改在 fork 中：https ://github.com/treib/Grbl_Esp32
我相信我已经将其归结为几件事：
竞争条件设置 sys_rt_exec_state
sys_rt_exec_state更改全局和主程序的 Serial.cpp 任务之间的竞争条件。我怀疑主要命中点在protocol_auto_cycle_start()它设置cycleStart位的位置，但可能在主程序中设置位的任何地方都是有风险的，因为我怀疑底层的按位或和存储是非原子的。这是一个罕见的命中率，可能有 1% 的失败率，但我在现实世界中观察到了它。精心放置的调试字符串确认已收到命令，但该位最终丢失了。
我测试了一个修复程序，其中 Serial.cpp 存储了 的任务本地版本
sys_rt_exec_state，并且它是在开始protocol_exec_rt_system()使用受保护的 getter 函数时获取的vTaskEnterCritical()。这可行，但可能需要修改自定义模块以调用此显式 getter，而不是假设这些值会自行更改。（我正在考虑像 CoreXY.cpp 这样的模块）。取消/保持错过 mc_line() 中正在进行的移动
慢跑问题的另一个不相关的原因似乎更像是一个 grbl 问题：当 a
jogCancelorfeedHold到达时，规划器被清空并且 gcode 解析器状态重置为当前位置，这很好。但是此时下一个点动命令可能已经在运行中，mc_line()在机器减速时等待，目标位置是根据 gcode 确定的，该 gcode 由于保持/取消而被丢弃。UGS 通过在按住点动方向按钮的同时发送一系列连续的增量点动命令来轻松实现这一点。这些将目标位置累积到一个很大的数字，并且由于 a
jogCancel或feedHoldduringState::Jog导致返回到State::Idle，因此将停滞在飞行中的移动添加到规划器中，并保持大目标值不变。然后机器移动并到达终点挡块。这更容易重现（对我来说可能有 30% 的时间发生），并且当 UGS 设置为远大于轴可以支持的点动进给率时尤其明显和有问题（因为飞行中的移动变得更大并且容易出界目标位置）。我对此的简单解决方法是创建一个全局变量来跟踪
mc_line(). 在protocol_exec_rt_suspend()我寻找sys.suspend.bit.jogCancel真实的情况下，如果飞行中的命令是慢跑，我设置了一个标志， mc_line() 会注意到并且不会将其添加到计划程序中。我添加了一个is_jog标志来plan_line_data_t跟踪它是否是慢跑，并添加了一个 return bool frommc_line()来表示它放弃了命令，这样就jog_execute()可以发回gc_execute_line()它被放弃的信号，这样它就可以跳过gc_state.position.我没有触及到 的运动学路径
mc_line()，所以我不确定那些是否仍然存在问题。protocol_execute_realtime()我主要担心的是，如果在移动进入时被调用，这只会捕获这些飞行中的移动mc_line()。也许某些场景或自定义代码可以protocol_execute_realtime()在 gcode 行被解析之后但在到达mc_line(). 但我想在那种情况下，它与没有修复的情况下的行为没有什么不同。UGS也有点不靠谱
我应该提一下，我还看到 UGS 在释放点动按钮时不发送 feedHold。我解决这个问题的方法是停止使用 UGS。:)
无论如何，我希望其中的一些内容会有所帮助。感谢您为这个伟大的项目所做的辛勤工作！
菲尔