注释
.png "BLOCK_BUFFER_SIZE 越小越好吗？ #1066"){kind=avatar}
成员
|
@cspwcspw：块缓冲区衡量 Grbl 将提前多少块来规划最佳时间工具路径。如果减小尺寸，您会减少 Grbl 可以计划的距离。这对于具有许多非常小的线段（如圆弧）的运动可能会有问题，但这需要一台加速度相当低的机器才能在当前设置下变得明显。但是，通常情况下，计划在前几个区块中是最优的，除非在提到的情况下。 |
BLOCK_BUFFER_SIZE 越小越好吗？ #1066
|
@cspwcspw：块缓冲区衡量 Grbl 将提前多少块来规划最佳时间工具路径。如果减小尺寸，您会减少 Grbl 可以计划的距离。这对于具有许多非常小的线段（如圆弧）的运动可能会有问题，但这需要一台加速度相当低的机器才能在当前设置下变得明显。但是，通常情况下，计划在前几个区块中是最优的，除非在提到的情况下。 |
我的 GUI 可以暂停/恢复其发送者。但是因为 GRBL 可以在 RX 缓冲区中有多行缓存代码，并且在其规划器缓冲区中有多达 18 个排队的线性运动，所以机器可能需要几分钟才能空闲。（是的，如果我想要立即响应，我可以保持和恢复。）但是在 v0.9 中有更快的串行通信并且只允许一行预发送 RX 缓冲，我还没有发现任何消费者超过的现实情况生产者和线性运动块“饥饿”发生。所以对我来说，更少的排队块缓冲区意味着事情变得“越来越敏感”。（我承认，我主要是在调试/玩耍，而不是在生产环境中，所以你的里程可能会有所不同！）
由于代码说“Grbl 使用的绝大多数 RAM 都基于此缓冲区大小”，因此减少此大小是否是一个很好的权衡（释放内存以获得更雄心勃勃的功能）？或者换句话说，是否存在真正受益于 18 大小的线性规划块缓冲区的机器或情况？
有没有人试图减少很多？我们能走多低？
谢谢
彼得