注释
也许不是 show stopper 问题,但是在做了一个干净的拉动(以防我搞砸了什么)并重置了 eeprom(需要一种更简单的方法将 eeprom 恢复为默认值)之后,我改变了两件事,每秒滴答声和 3 美元=40000.000。 然后我做了一个 g1 X600 F20000,我得到了一个
和
我意识到这超出了频率能力,但它应该重置吗? |
谢谢@wolfmanjm. 不幸的是,直到明天我都没有电脑可以工作和检查代码。你能说出这个问题是否仅限于你的情况吗?还是所有进给和加速度(较低)都会发生这种情况?像这样的错误很难追踪,所以任何信息都会很棒。 至于设置,我必须对设置结构的组织进行大量更改才能在其中获取新的设置参数,因此向后兼容性被破坏了。我没有时间真正解决这个问题,并且一直认为它可能不值得为 v0.9 主版本进行修复。不过就目前而言,我认为不会再有戏剧性的变化。回答有关使加载默认值更容易的问题。我会用设置命令编写一个文本文件并将它们流式传输到 Grbl 以便轻松编写它们。 |
哦,我想我知道问题出在哪里了。我将加速度计数器内部变量从 uint32 更改为 uint8。因此,当您将中断速率更改为 35kHz 时,这也会将 INTERRUPTS_PER_ACCELERATION_TICK 更改为大于 255 的值。您还必须更改 ACCELERATION_TICKS_PRE_SECOND,以便该值低于 255。因此,对于 35kHz,将 ACCELERATION_TICKS_PER_SECOND 更改为 140。这应该解决减速问题,希望第二个问题也能解决(虽然我不确定这是否相关,但它可能是。) |
好的 然后我建议你将它添加到 config.h..
为避免此错误,我会尽快尝试此操作,看看是否能解决问题。- 谢谢 更新是的,解决了减速问题,谢谢 |
仅供参考,当我流式传输设置时出现一些错误,我怀疑缓冲不适用于设置…
|
然而,如果你给 F 一个非常高的值,它并没有修复重置和 eeprom 损坏…… 鉴于上述设置,如果我做… 然后它重置并重新加载默认的eeprom …
|
回到家,有一点时间检查一下。我无法重现您的重置和崩溃问题。您是否仍在将 ISR 频率增加到 35kHz?您的测试与上次边缘推送之间还有其他区别吗? |
我认为我从边缘所做的唯一改变是……
然后..
一旦设置完成,我就会……
那就是它重置并且似乎也重新加载 eeprom 的时候。 顺便说一句,您甚至不必为此测试连接步进器。 如果您将速度推得更高(但设置 $3 以适应)或设置,它可能更容易崩溃
这会将所需的频率推得更高。 看起来如果你超过了 MCU 重置时的步进速率。 |
行。我得到它来重现这个错误,但这是一个非问题的 IMO。如果您将步进频率设置为超出支持的速率,那么所有赌注都将关闭。可能发生的情况是 ISR 执行速度不够快并且相互重叠,以至于导致 MCU 崩溃。或者一个 integer32 值溢出并且对 ISR 造成严重破坏。作为预防措施,我会考虑在设置中安装一些步进频率检查,以提供一些用户反馈,它们超出了支持的频率,但我可能会等到我知道闪存中有额外的空间可以添加这个。 至于设置和流式传输,理论上它应该像您所做的那样工作,但我今天早上会检查一下。 |
我认为设置流与 EEPROM 写入有关。我记得听说 EEPROM 写入可以阻止 ISR 触发,这意味着串行读取可能会丢失并丢失一个字符。因此,我尝试使用 simple_stream.py 来验证,它使用的简单调用和响应方法修复了这个问题。(simple_stream.py 可能会在流式传输结束时锁定,但可以正常完成。我稍后会对此进行修复。更新:我使用的是旧版本。github 版本很好。) |
仅供参考,我不认为我在 35000 时将步进频率设置得太高,我所做的是设置速度(例如 F30000)对于设置的频率来说太高了。我在 github 中将频率设置为默认值时遇到了相同的崩溃/重置。 但我同意这不是一个表演障碍,尽管将 eeprom 重置为默认值有点令人不安。 |
我拉了最新的修复,现在减速时有问题。我将设置恢复为默认值,我发现做类似的事情……
导致它按预期缓慢加速,达到全速然后开始减速,但在结束前大约 100 毫米,它会减慢速度,每隔几秒就会爬行,而且似乎从未达到目标。
这是对最后一组合并的回归。
我有
这是我当前的设置,虽然不是默认设置,但很接近。我将步进脉冲设置为 3us