我没有改变探测周期，所以应该没有区别。但我会调查的。
你能把你的探测命令发给我吗？

G38.2 Z-5 F20

那是我一直在测试的那个。

这似乎是一个权衡问题。您要么具有良好的高速性能，要么具有良好的低速性能。

将https://github.com/Schildkroet/GRBL-Advanced/blob/software/grbl/Config.h#L312更改为 512（或类似）并
减少https://github.com/Schildkroet/GRBL-Advanced/blob/ software/grbl/Config.h#L440至 16（较低 = 较少停止时间）
如果将段大小设置为原始 (6)，则停止时间应小于 100 毫秒。但是你还必须将每秒的 acc ticks 降低到 ~100，否则移动之间会有停止（规划器无法跟上步进器）

我对其进行了测试，当我将段大小减小得更低时，它确实会更快停止。我将尝试一些代码，看看是否有可能在探测期间使其变小。

谢谢再次让你知道我是怎么弄出来的。
注意事项

仅在探测期间为更短的序列修改了程序。现在测试它切割一些铝。似乎运作良好。还修改了主轴通讯，使用RS485启动、停止和改变VSD的速度。

我会在测试和调试后发布我的结果

@Northernboy，你让这个工作了吗？这似乎是原始 grbl 中的一个严重错误。
我才刚刚开始研究 z 探针，因为我想设置某种工作台调平补偿。

如果减速停止需要 0.1 秒，那就是个问题。即使以保守的 F 速度，在精度方面也有很长的路要走。

这是否仅仅意味着它迫使探针（工具提示）进入库存但不影响准确性？您测试的重复精度是多少？

如果你只是在进行面铣操作之前开始接触，也许没问题，但如果你试图拾取现有表面作为参考，这听起来不太好。

TBO 直到现在我一直在使用旧的 fag-paper 方法。我可能会坚持使用 z-probe ；）

是的，我修改了较短的序列将探测的代码。似乎修复它。我仍在努力微调我的 VSD RS 485 控件，但我不介意分享探测修复程序。

谢谢，那会有用。如果更改很少，可能是 PR 或者只是发布一些代码片段。

我今晚会发送我的更改。

@J-Dunn，给我你的电子邮件地址，我会把我更改的文件传给你，你可以自己测试一下。如果它对您有用，那么我会弄清楚如何与他人分享。

谢谢。

@J-Dunn，你拿到文件了吗？如果有，有什么检测结果吗？

是的，感谢代码。我将需要一些时间来浏览这个端口的各个文件，并找出连接到哪里的内容。然后，我将构建一个带有经典 Dir/Step 驱动器和一个电机的测试装置。我希望今天能看到它。

顺便说一句，我对现有的 stm32 构建进行了探针测试，探针触发时的 z 值与机器的静止位置之间存在 0.1mm 的差异！关于我之前估计的。我认为要做的第一件事是在将机器归零之前退回该位置。事实上，这必须通过在力学中弯曲来解决。一旦我开始这样做，我将添加一个双啄 z 探针，它会后退 0.5 毫米，并以 5 或 10 倍的速度进行第二次啄，以提高准确性。如果我得到的只是 0.1 毫米的精度，我还不如坚持使用 fag-paper 方法！

你好，我只是想尝试测试这个代码，所以我设置了一个运行一个电机测试，一个 F411RE Nucleo 与 X step/dir/enable 通过 DM542 驱动单元连接到 NEMA23。

我构建了代码，Flash 看起来不错：

2021-05-31T17:35:44 INFO flash_loader.c: Clear DFSR
2021-05-31T17:35:44 INFO common.c: enabling 32-bit flash writes
2021-05-31T17:35:45 INFO common.c: Starting verification of write complete
2021-05-31T17:35:45 INFO common.c: Flash written and verified! jolly good!

我打开 Arduino IDE 作为 /dev/ttyACM0 的串行接口

在连接 USB 为 F411RE 供电时，我收到了几个垃圾字符，没关系。

然后我按 Enter 向 GRBL 发送一个空行并返回“ok”。看起来不错。

但是，无论我输入什么，它似乎都被锁定了。在我重新启动它之前，我什么都得不到。我发送了 $$ locked: $# locked: ? 锁定。

现在这可能是我愚蠢，因为我已经很长时间没有在这样的精简钻机上工作了，所以你能告诉我我是否搞砸了。谢谢

尝试解锁命令，$X

谢谢，但这不应该停止串行通信。$$ $# 等应该仍然有效。这看起来有点乏味。你有 f411re 板来测试吗？

我可以在明天晚上对我的进行测试。如果你喜欢把你的闪光灯发给我，我可以测试一下。

谢谢，我最初想知道您是否可以运行该项目的普通 git 克隆。你最后一次提取工作副本是什么时候？

谢谢你的文件。结果基本一样。

我宁愿劫持你的探测线程。一旦我解决了发生的问题，我们将返回您的探测器调整。

如果你想在那里加入我们，我已经打开了关于这个问题的另一个问题。
#66

这似乎是一些外部硬件/软件的问题。

是的，我一直在看那个方向。我已经更改了盒子上的硬件端口（两个前面板，两个后面板）和几条不同的电缆。我只有 USB 而不是 USB2.0 电缆，OTG 以 115kbaud 结束，甚至“低速”USB1.1 也可以处理 1.5 Mbit/s。

它似乎也与 st-link 运行完美闪烁和验证数据不一致。如果存在不太可能完美工作的端口/电缆问题，请验证闪烁的图像。

顺便说一句，.bin 与 .hex 有什么区别，后者似乎只是十六进制数据的 ASSCI 表示。也可以寄吗？st-flash 会处理所有这些并将完全相同的内容发送到目标吗？

只是有不同的文件格式可供选择。全部包含相同的 grbl。

好的，正在检查，谢谢。
那么，闪光灯工作正常的事实是否排除了 PC 和 F411 之间的问题？
如果它正在转储大约 100kB 的程序，为什么它不能传输几个 100 字节？

至少你的电缆似乎没问题。但是 st-link 和 serial 使用不同的端点和驱动程序。你能试试像 putty、tera term 等不同的终端吗？

到目前为止，我一直在使用 arduino IDE 作为终端和 minicom 进行测试。本质上是一样的问题。事实上，minicom 往往会得到更少的回报，甚至一无所获。

我想知道是否有其他一些自动运行的进程寄生在 ttyACM0 上。
好的，我已经在另外两台 PC 上试过了：连接到 CNC 的旧 Fedora 和运行与问题系统相同的当前 Fedora 版本的旧 PC。

两者都工作正常。

看起来这与我通过系统迁移到的新硬件有关。前面板和直接安装在主板上的 USB 插槽均无法正常工作。遗憾的是，它都是 PCI-express 插槽，所以我没有任何卡可以插入单独的 USB 端口。

有问题的 BIOS？

[编辑]
好的，这原来是 BIOS 问题。我在 BIOS 中切换了几个 USB 选项，它工作正常。

st-flash 过程顺利进行似乎有点奇怪，这在缩小范围时有点分散注意力。其中一个选项是 EHCI 切换，因此在同一条电缆上的不同 USB 端点之间进行协商时可能存在问题。

现在回到整理探测….

到目前为止，我从未使用过 z-probe，尽管我用光电缓冲了 GPIO 线并将其所有布线就位。

由于我使用的是 STM STEP01 驱动程序，而不是通常的 STEP/DIR 引脚，因此需要进行一些调试。

我仍然有一些问题，但初始测试显示探针触发器上的 Z 坐标与一次性测试中的最终位置之间的差异为 0.05mm（2 thou），即使用 F30（0.5mm/s）的“fag paper”精度。那是一个单一的测试，所以可能不具有指示性。

也许 NB 可以发布类似 PRB output Z 和 machine rest Z 之间的区别的东西，有和没有他的模组。

我的倾向是让机器回到触发点。

当我进行测试时，我正在测量输出到步进驱动器的实际脉冲，因为它被减少到普通 Arduino GRBL 会做的事情。我从来没有真正测量过差异。如果您认为您需要它更近一些，您可以将 config.h 中的“Seqment_Buffer_Size_Probe”设置为小于 6。

我现在有了带有基本网格阵列探测功能的 stm32 grbl（不是这个端口）。所以现在我可以开始速度和可重复性测试了。
使用 F30 (0.5mm/s) 时，我没有看到很好的可重复性。我有大约 4 个 z 步（每个 1/80mm）的范围。

我将在 38.2 之后测试 38.4，因为这是非常早的行程，减速缓冲区将非常短。38.4 也可能是非常慢的速度，因为它几乎不移动。

停止的执行路径非常长且复杂。我确定它可以被修整，但我认为需要减速路径可能是关键部分。您为探测设置一个简短的计划缓冲区的方法可能是一个很好的解决方案。

作为记录，我目前已经在我的机器上使用了以下内容（与此问题无关）。
#define ACCELERATION_TICKS_PER_SECOND 100
#define SEGMENT_BUFFER_SIZE 6

已确认，使用探针回缩似乎可以提供更一致的结果。

而不是破解 ACCEL TICKS 等。我认为这里的基本问题是 AMASS_LEVEL 中缺乏动态范围

我发现缓慢的 mm/min 速率从未发生过，因为时间计数器溢出并且 GRBL 正确地将其限制为 0xffff 。

我添加了更多的 amass 级别，然后可以对低速 gcode F rates 进行编程并且它们起作用了。

我现在在 F60 处探测，然后在我修改后的“G38.9”网格探测周期中，我在 f/5.0 处重复拉出探测周期并取平均值，这些慢速现在起作用了。

在五次重复中，我有最大 +/-1 步长可变性。我更喜欢 +1/-0 但这可能归因于机器的灵活性。

#define MAX_AMASS_LEVEL 5
// AMASS_LEVEL0: Normal operation. No AMASS. No upper cutoff frequency. Starts at LEVEL1 cutoff frequency.
#define AMASS_LEVEL1 (F_CPU/8000) // Over-drives ISR (x2). Defined as F_CPU/(Cutoff frequency in Hz)
#define AMASS_LEVEL2 (F_CPU/4000) // Over-drives ISR (x4)
#define AMASS_LEVEL3 (F_CPU/2000) // Over-drives ISR (x8)
#define AMASS_LEVEL4 (F_CPU/1000) // Over-drives ISR (x16)
#define AMASS_LEVEL5 (F_CPU/500)  // Over-drives ISR (x32)

      if (cycles < AMASS_LEVEL1) { prep_segment->amass_level = 0; }
      else {
        if (cycles < AMASS_LEVEL2) { prep_segment->amass_level = 1; }
        else if (cycles < AMASS_LEVEL3) { prep_segment->amass_level = 2; }
        else if (cycles < AMASS_LEVEL4) { prep_segment->amass_level = 3; }
        else if (cycles < AMASS_LEVEL5) { prep_segment->amass_level = 4; }
        else { prep_segment->amass_level = 5; }    
        cycles >>= prep_segment->amass_level; 
        prep_segment->num_steps<<= prep_segment->amass_level;
      }

G38.2 Z-5 F20

那是我一直在测试的那个。

你有没有测量脉冲时间或旅行时间来检查速度？它真的以 20 毫米/分钟的速度前进吗？
也许它没有减速，因为它已经处于最长的计数器间隔。这就是我所看到的。添加质量级别修复了它。

我对 robomechs 的另一个 STM32 叉子也有同样的问题。试探不准确。
我尝试优化 ACCELERATION_TICKS_PER_SECOND 和 SEGMENT_BUFFER_SIZE，但我对结果并不十分满意。

阅读本主题后，我将 AMASS_LEVEL4 和 AMASS_LEVEL5 添加到代码中。我认为这解决了探测问题，并且运动更好更顺畅。

我很高兴这个解决方案有用。我将在上游打开一个问题，这可能应该在 grbl 1.1 中