注释
.jpg "显示串行缓冲区几乎已满的硬件引脚 #106"){kind=avatar}
贡献者
|
@luben111：我很难看出这有什么用或者它会如何简化事情。我对流量控制的体验实际上是相反的。流量控制的调整取决于主机以及其他因素，以免缓冲区溢出并保持快速运行。这是因为它没有很好地考虑系统的整体通信延迟。Grbl 的字符计数协议要有效得多，它的出现是因为 XON/XOFF 软件流控制很糟糕。 |
显示串行缓冲区几乎已满的硬件引脚 #106
|
@luben111：我很难看出这有什么用或者它会如何简化事情。我对流量控制的体验实际上是相反的。流量控制的调整取决于主机以及其他因素，以免缓冲区溢出并保持快速运行。这是因为它没有很好地考虑系统的整体通信延迟。Grbl 的字符计数协议要有效得多，它的出现是因为 XON/XOFF 软件流控制很糟糕。 |
你好，
当将多个 GCode 小段发送到 GRBL 以在曲线上移动以获得平滑移动时，内部串行缓冲区应保持半填充状态。我同意通过 <?> 轮询串行缓冲区和规划器的状态，可以了解还剩多少空间并发送或保留下一个字符（以更密集的通信为代价）。
添加一个引脚以显示串行缓冲区几乎已满（例如还剩 2-3 个字节）怎么样？这将允许 USB 桥接器将数据传输到 GRBL，但仍然接受来自 PC 的数据（如果内部缓冲区很大） ). 如果 USB 桥缓冲区变得半满，则可以断言 CTS 以防止 PC 进一步发送数据。
我的观点是 – SEMI_FILLED 引脚可用于为 GRBL 开发合适的 USB 缓冲器/桥接器，它可以容纳更多数据，并允许用户在曲线上平稳移动，而不必担心丢失数据。这将允许简单地将 GCode 文件复制到串行 COM（使用硬件 hand shacking）并完成整个任务。