注释
.png "GRBL 响应格式缺乏一致性 #342"){kind=avatar}
|
我没有注意到你的英语有什么糟糕的地方。您使用的格式以及建设性的建议很容易理解。
我有点同意你的看法，但 WCO 数据并非严格冗余，原因有一个：它在更改后包含在下一条状态消息中。与请求相比，您更有可能发送状态
我们要求的第一个故障排除步骤之一是“将输出发送到‘$$’”，因此此建议会使支持变得更加困难。许多 GUI 还通过CSV 翻译来增强单行响应，这使得这在支持期间更有帮助。 虽然使用的建议
你在某种程度上回答了你自己的问题。特殊的启动器模式是 虽然
看来这又是一个单字的问题。我认为将所有状态排成一行是一项具有历史意义的 CNC 公约，这可能就是 GRBL 以这种方式完成的原因。 这里的主题似乎是多行响应，你不喜欢多字符模式。但是在这两种情况下，您都声称这会阻止您为 GRBL 响应使用无状态解释器。那不是真的（也许 如果您好奇，可以在 GitHub 上找到许多示例，但根据您的评论中的详细信息，我确信您不需要它。它们可能不严格匹配 Martin Fowlers 设计模式之一，但许多也不是特别复杂。这是我的，5 年前写的，那时我还不知道 CQRS 是什么。它不仅一次解析一行 GRBL 响应，而且可以处理从 0.7 到 1.1 的任何 GRBL 消息。我什至将其命名为类似于 我最担心的是这些单位没有明确包含在状态消息中，即使是间歇性的 |
.jpg "GRBL 响应格式缺乏一致性 #342"){kind=avatar}
|
首先，我很高兴有一位贡献者选择了我的话题并给了我一个直接的答案。
您刚刚用一句话完美地总结了我的主要目标：“为 GRBL 响应提供无状态解释器”。是的，现在有可能，我刚刚做了一个，我只是不喜欢它，让我向您展示我解析答案的方式：
它在恭敬上是可行的，但您将需要 3 种不同的方法，而且我看不出额外复杂性的意义/好处，当我们谈论可维护性时，它会强烈反击，但这只是冰山一角。 让我们假设 2+1 事物：
现在，我们需要尽快获得所有信息。可视化需要了解 CNC 的大小，因此首先您必须查询连接设置（我们不信任首次启动时的缓存数据）。但是最好向用户显示保存的坐标（例如 G28）。因此，您还需要 GCodeParameters。当前模态状态是另一个非常重要的信息。也拿那个。 你从哪里知道 – 比方说 – 设置已加载？通信的基石是 \r\n，但您不能使用它。一行不是完整的图片，只是完整请求数据的一个片段。’Ok’ 是一种回应，$132=0 是另一种。我可以发布一个事件说，嘿，ZMaxTravel 信息已准备好使用，但您不能确定 XMaxTravel 数据是否也是如此。我真的不想触及 SettingPrintoutParser 中的“确定”响应，因此我不得不添加一个中间层来捕获来自 SettingParser 的所有已发布事件并监视它们。它基本上是一个检查列表，可确保您拥有一个完全加载的设置模型，现在您的 GUI 可以决定使用哪些功能，哪些不使用。一个请求 => 多个答案 => 你的解析器可以是无状态的唯一方法，如果你在通信层的顶部添加一个有状态的服务 – 如果你愿意的话，一个聚合器。在一天结束时，您将必须知道以前的响应以确保请求得到满足。您可以将问题推到更高的层次，并说解析器本身是无状态的，但这只是问题的一方面。问题还是一样，只是你把它隐藏起来了。 我怎么强调都不为过：我们都知道，为 GRBL 编写一个非常复杂的 GUI 非常容易，如果一个小组件不能以无状态方式编写：谁在乎呢？但另一方面：这看起来像是一个设计缺陷，很容易修复，并且与现有 GUI 的向后兼容性只是 config.h 中标志的问题。 |
.jpg "GRBL 响应格式缺乏一致性 #342"){kind=avatar}
|
@dani88: 一个建议。如果你写了一篇很长的文章，不要指望立即回复。尽量让你的问题简短。否则它变成 TL; DR。直到今天早上我才有时间坐下来仔细研究你的观点。
至于你关于“想法”的帖子的后半部分，我很难理解。如果你的意思是你想改进通信协议以包括发送多条线路，我已经在着手解决这个问题。很难让它像当前协议一样简单，但我认为它会起作用。 我首先承认 Grbl 的通信协议并不完美，但一旦你处理了它的怪癖，它就会起作用。有很多依赖关系使得很难显着改变事情。你会破坏所有现有的图形用户界面并激怒很多人。从 v0.9 到 v1.1 风格协议的转换是非常谨慎的。我得到了所有主要 GUI 开发人员和 OEM 的意见，看看他们是否对新的 v1.1 协议有任何问题。花了很长时间才把事情整理好。然而，它并不完美，但已经足够好了。 使用新的 ARM 版本，我有足够的闪存和内存来尝试一些东西，并且仍然支持 v1.1 协议。当事情发布时，我很乐意讨论改进它的方法。 |
|
谢谢。我真的没想到会很快得到答复，我认为这应该更像是一次讨论，而不是错误报告或帮助请求。即使需要两周的时间，我也会很感激你的回答。但是你一天之内就回复了。谢谢你。 根据您的回答，我觉得 GRBL 似乎在沟通方面存在严重问题，必须加以解决。那不是真的。没有错误或错误，通信已经在许多不同的 GUI 中工作，文档完整，没有漏洞。 您在回答中多次提到语义，这正是我所说的。是的，status 是状态报告响应中的第一个字段，正如文档中所说的那样，这很清楚。文档是准确的，没有未记录的行为等等。 状态报告不是完美的例子，但你的答案是基于状态报告本身，所以我会继续这个，即使状态报告有点太具体而且我的整篇文章都是关于所有的语义的一致性反应不只是在一个。 首先：感谢世界海关组织的澄清。完全有道理，它不是重复的数据。
可能它让你了解我的观点。我通过易于阅读的回复理解您的想法，所以让我从以下方式着手： 如果有一种机器友好的方式与 GRBL 进行通信，那就太好了。在“好的解析器”再次出现之前：一个好的解析器本身是微不足道的，而且很容易实现。您可以按照您希望的任何格式向我发送回复，虽然所有消息都保持一致，但我会很高兴。让我们使用人类可读的字符串标签、结构布局或整数键。不要紧。但要让语义严格一致，无 L’art pour L’art 例外。 顺便说一句，正如我上面所说，我主要关心的仍然是多行响应，这可以再次用人类可读性来解释，在这种情况下我可以重复我自己：例如，一个机器友好的解决方案在 ARM 版本上会很好，当然是在遥远的未来。 由于现在所有的响应都是人类友好的，是否可以为机器通信添加替代响应格式，而我们不必对边缘情况和异常进行硬编码？ 例如，将 $$ 作为人类友好的设置打印输出请求，但添加任何 ascii 代码请求以在一行中以非常可靠的格式获取设置。GUI 不需要花哨的键或标签，或状态字符串，它们只会让事情变得更糟。有了这个解决方案，GUI 可能会更健壮，并且由于消息会更小，通信甚至会更快。如果我们谈论机器通信，一条规则优于 42 条规则，但有 35 条例外。 |
|
@dani88: 您的担忧已被听到并且已经在处理中。328p 上的 Grbl 只能提供一个协议的空间。该协议必须是人类可读的。它还必须保持与先前 GUI 的兼容性，以防止完全重写。您陈述的很多问题都可以追溯到我第一次在 Grbl v0.7 中安装的东西。这些决定和错误在今天的 v1.1 中得到了延续。启动消息和多行就是其中的例子。 正如我之前提到的，我打算在 ARM 版本中试验其他通信协议，因为我有足够的空间来这样做。您的多行问题很容易消除。可以完成其他事情，例如将所有东西都放入漂亮的隔间盒中，但我发现并不是所有东西都可以有效地放入一个方案中。最大的限制因素是消息长度和开销的最小化。如果您尝试将所有内容都放入 JSON，消息很快就会变得巨大，充满冗余字符。如果你以预定义的方式编码信息，就像深空卫星那样，你可以塞进更多的数据。 然而，事情可能会保持最低限度的人类可读性。如果您必须不断地在表格中查找内容，那只会阻碍采用。另外，如果您使用 ASCII 字符作为值，人类可读的缩写在消息大小上不会大很多。 二进制或 ASCII 基本压缩消息也是可能的。我们将看看结果如何。 |
.jpg "GRBL 响应格式缺乏一致性 #342"){kind=avatar}
|
@chamnit 请问ARM版Grbl的发布时间？ |
|
即将发布 Beta 版。自去年六月以来，我有一个刚刚完成的 NASA 项目。这花了我所有的时间。我一直在重新熟悉代码，但还有很多工作要做。 |
免责声明：这没什么大不了的，在任何其他方面使用 GRBL 都很棒，但它仍然让我感到烦恼——而且非常让我烦恼，正是因为 GRBL 在任何其他方面都非常一致。
我们有很多不同类型的状态/设置/配置/选项/参数，所有这些都是独一无二的并且绝对是必需的，但是您可以识别和解析它们的方式非常不同，有时不合逻辑，有很多例外。
让我总结一下最重要的：
请求-响应：一个实时命令 => 一行没有“ok”的响应（完美！）
检测：简单。第一个字符是
<.解析：两个级别：键值对按管道拆分，键值对按 拆分
:。（但这不是真的，请参阅关注点）关注点：
想法：<key_integer:single_value | >，例如：<0:2|1:1,2,3|2:35| … > 严格一致的格式，更少的内存消耗，界面编写者可以使用枚举作为键，以获得更具可读性的代码。是的，对人类不友好…
请求-响应：一个流命令 => 多行响应“确定”（最坏情况）
检测：一行容易，完整设置列表非常困难且有风险。
解析：和检测一样，一行容易，全图难。
关注点：
想法：
但它变得更糟：
请求-响应：一个流命令 => 多行响应“ok”（最坏情况）
检测：噩梦。没有简单的方法来识别参数响应只有当你确切地知道你期望什么（再次：读取和写入紧密耦合，或者响应是硬编码的）
解析：不一致。键值分隔符是“:”，但只有一个没有任何充分理由的例外（PRB 有两个值，具有完全相同的分隔符）
问题：
想法：还有什么。那太愚蠢了。所有键都应该有一个且只有一个值。所有行都必须易于识别为参数响应。多线情况使情况变得更糟。与往常一样，解决方案与往常一样（这正是一致性的关键所在）：一个请求 => 一行响应，带有键值对（其中键是整数）。’:’ 作为键值分隔符，管道作为对分隔符。
请求-响应：一个流命令 => 具有多个数据的一行响应。
检测：可能会好得多，因为第一个字符在这里不占主导地位，您需要读取行的开头以将该行识别为解析器状态。使用这样的东西是不可能的： https ://i.imgur.com/WmcjIRR.png你必须在没有任何反馈消息的情况下编写子处理器。
解析：不好玩，但还不错。我喜欢它的工作方式。T/S/F 参数是例外，但我没有更好的主意。这是有道理的，T/S/F 是解析器状态的一部分，它们是数字，所以是的。我可以忍受它。仅针对这 3 个参数的单独解析器状态响应我猜会太多了吧？
关注点：
想法：将 [GC: 替换为一个独特的字符，我是一个快乐的人（谁在乎，我知道）
我还有很多其他类似的担忧/想法，但我已经太长了。我很乐意就这些进行讨论。
是的，我的英语很糟糕，我可能犯了数百个错误。我正在努力，请原谅我。