开源改变世界!!
> 推推 > 某些步进脉冲的持续时间比 $0 中配置的持续时间长得多（基于 STM32F103 的板） #14

某些步进脉冲的持续时间比 $0 中配置的持续时间长得多（基于 STM32F103 的板） #14

推推 grbl 2年前 (2023-02-08) 148次浏览
关闭
dmitriybabintsev 打开了这个问题 2022 年 2 月 16 日 · 8条评论
关闭

某些步进脉冲的持续时间比 $0 中配置的持续时间长得多（基于 STM32F103 的板）#14

dmitriybabintsev 打开了这个问题 2022 年 2 月 16 日 · 8条评论

评论

某些步进脉冲的持续时间比 <img decoding= 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="@dmitriybabintsev" width="80" height="80" />

嗨，大家好。
首先，我要非常感谢 Terje Io 和所有其他参与 GRBL 开发的人。这是一个非常好的工作。

最近，我遇到了一个奇怪的问题，即连接到基于 STM32F103 的电路板 (STM32F103CBT6) 的步进电机运行不正确。在启动我的 G 代码程序几个小时后，我注意到电机移动的距离与执行的 G 代码中指定的距离不一致。这是我的程序：
_all_3.txt
该程序由 Z 轴方向的多次重复移动组成。

下面是我的 GRBL 设置。步进脉冲持续时间和 Z 轴加速度在此测试中有意义。
gmsc3u_grbl_backup_2022-02-16_grblHAL.txt

当我开始深入研究这个问题时，我注意到 Z 轴上的某些步骤的持续时间比 GRBL 设置中指定的持续时间更长。
下面是在我的电路板的 Z-step 引脚上捕获的一些具有不同时间戳分辨率的波形。

20us分辨率：
中配置的持续时间长得多（基于 STM32F103 的板） #14" target="_blank" rel="noopener noreferrer nofollow">某些步进脉冲的持续时间比 <img fetchpriority= 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 中配置的持续时间长得多（基于 STM32F103 的板） #14" width="600" height="400" />

8us分辨率：
中配置的持续时间长得多（基于 STM32F103 的板） #14" target="_blank" rel="noopener noreferrer nofollow">某些步进脉冲的持续时间比 <img loading= 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 中配置的持续时间长得多（基于 STM32F103 的板） #14" width="600" height="400" />

分辨率为 4us：
中配置的持续时间长得多（基于 STM32F103 的板） #14" target="_blank" rel="noopener noreferrer nofollow">某些步进脉冲的持续时间比 <img loading= 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 中配置的持续时间长得多（基于 STM32F103 的板） #14" width="600" height="400" />

正如您所看到的，在最坏的情况下，2 个步进之间的时间间隔小于 2us，并且看起来一些电机驱动器将这 2 个脉冲检测为单步脉冲，这会导致跳过步进，从而导致电机的行进距离出现错误。

要重现该问题，无需运行程序。只需执行一个简单的命令：
G0Z500
，您将看到许多脉冲的持续时间比 $0 参数中指定的持续时间更长：
中配置的持续时间长得多（基于 STM32F103 的板） #14" target="_blank" rel="noopener noreferrer nofollow">某些步进脉冲的持续时间比 <img loading= 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 中配置的持续时间长得多（基于 STM32F103 的板） #14" width="600" height="400" />

你能帮忙解决这个问题吗？
某些步进脉冲的持续时间比 <img loading= 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="某些步进脉冲的持续时间比 @terjeio 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 @terjeio 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="@terjeio" width="80" height="80" />
贡献者

USB 或 UART 连接？
最后一次测试是从请求实时报告的发件人运行的还是从像 PuTTY 这样的简单终端程序运行的？
不是从一个简单的终端程序，你能从一个重新运行测试吗？问题仍然可见？如果不是，则可能必须降低 UART 或 USB 通信的中断优先级。
某些步进脉冲的持续时间比 <img decoding= 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="@dmitriybabintsev" width="80" height="80" />
作者

我正在使用带 USB 连接的 G 代码发送器。

我要么认为根本原因是中断优先级配置错误。看起来 TIM3 中断时常延迟。

好的，我会尝试腻子
某些步进脉冲的持续时间比 <img decoding= 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="@dmitriybabintsev" width="80" height="80" />
作者

与串行终端连接时看起来好多了。
下面是运行G0Z500命令后的波形。我仍然有更长的脉冲，但差异比以前小得多。

中配置的持续时间长得多（基于 STM32F103 的板） #14" target="_blank" rel="noopener noreferrer nofollow">某些步进脉冲的持续时间比 <img loading= 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 中配置的持续时间长得多（基于 STM32F103 的板） #14" width="600" height="400" />
某些步进脉冲的持续时间比 <img loading= 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="某些步进脉冲的持续时间比 @terjeio 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 @terjeio 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="@terjeio" width="80" height="80" />
贡献者

尝试降低串行和 USB 中断的优先级：

中配置的持续时间长得多（基于 STM32F103 的板） #14" target="_blank" rel="noopener noreferrer nofollow">某些步进脉冲的持续时间比 <img decoding= 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 图像 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="图像" />

增加第二个参数会降低优先级，例如：

HAL_NVIC_SetPriority(xxx_IRQn, 1, 0);

将使步进脉冲关闭中断抢占这些。

系统计时器的优先级也应该降低吗？IIRC 我已经为一些司机做到了。

我炸了我唯一的 F103 板所以我无法检查自己……
某些步进脉冲的持续时间比 <img decoding= 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="@dmitriybabintsev" width="80" height="80" />
作者

谢谢泰杰。我会测试它然后更新你。
某些步进脉冲的持续时间比 <img decoding= 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="@dmitriybabintsev" width="80" height="80" />
作者

嗨，泰耶。
所以我降低了 USB 中断优先级（USART1 和 USART3 对我来说是关闭的），现在好多了。

diff --git a/USB_DEVICE/Target/usbd_conf.c b/USB_DEVICE/Target/usbd_conf.c
index f9587a6..1488723 100644
--- a/USB_DEVICE/Target/usbd_conf.c
+++ b/USB_DEVICE/Target/usbd_conf.c
@@ -78,7 +78,7 @@ void HAL_PCD_MspInit(PCD_HandleTypeDef* pcdHandle)
     __HAL_RCC_USB_CLK_ENABLE();
 
     /* Peripheral interrupt init */
-    HAL_NVIC_SetPriority(USB_LP_CAN1_RX0_IRQn, 0, 0);
+    HAL_NVIC_SetPriority(USB_LP_CAN1_RX0_IRQn, 1, 0);
     HAL_NVIC_EnableIRQ(USB_LP_CAN1_RX0_IRQn);
   /* USER CODE BEGIN USB_MspInit 1 */

但有时当我运行之前附带的 G 代码程序时，我看到 ~16us 脉冲（而不是 10us）。

中配置的持续时间长得多（基于 STM32F103 的板） #14" target="_blank" rel="noopener noreferrer nofollow">某些步进脉冲的持续时间比 <img loading= 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 中配置的持续时间长得多（基于 STM32F103 的板） #14" width="600" height="400" />
某些步进脉冲的持续时间比 <img loading= 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="某些步进脉冲的持续时间比 @terjeio 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 @terjeio 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="@terjeio" width="80" height="80" />
贡献者

尝试将优先级降低到 2，应该没关系，但谁知道呢……
我不知道抢占 USB 中断需要多长时间，也不知道 USB 驱动程序代码是否禁用代码关键部分的中断。如果最小抖动是必须使用 USB <> UART breakout IMO 可能是更好的选择。或者切换到更快的处理器，F1xx 系列非常慢并且没有 FPU。
某些步进脉冲的持续时间比 <img decoding= 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" title="某些步进脉冲的持续时间比 @dmitriybabintsev 中配置的持续时间长得多（基于 STM32F103 的板） #14" alt="@dmitriybabintsev" width="80" height="80" />
作者

顺便说一句，在您搬到新家之前，我尝试了以前的 grblHAL 版本：
https ://github.com/terjeio/grblHAL/tree/master/drivers/STM32F1xx

并且所有步进脉冲在那里都很好（USB 中断优先级为 1）。
所以可能在新版本上有一些“重”代码。

无论如何，感谢您的帮助 Terje。问题已解决。
喜欢 (0)