评论
.png "光栅问题：Smoothieware Jerkyness/我们是否需要一个新的协议，适当的讨论 #99"){kind=avatar}
.png "光栅问题：Smoothieware Jerkyness/我们是否需要一个新的协议，适当的讨论 #99"){kind=avatar}
|
也许最好从当前状态开始。你能举例说明现在生产的产品吗？ G0X0Y0
G1S10X0.1F20000
S20X0.2
S30X0.3
像那样的东西？这可能是最紧凑的表示。它已经是运行长度，因为一行中具有相同内容的多个像素 |
.png "光栅问题：Smoothieware Jerkyness/我们是否需要一个新的协议，适当的讨论 #99"){kind=avatar}
|
这是 LW4 (lw.raster-to-gcode) 生成的内容： 也许我们可以滥用评论？ |
|
在 g2core 中，我们使用“活动评论”，我们将 JSON 放在带括号的评论中。这就是我们如何避免 Marlin 的 M 代码噩梦。 例如，我们有两个有点不标准的 M 代码：
因此，在 3D 打印机中，您可以通过以下方式设置温度（使用 M100 ({"he1st":210})
然后等待它变为 At Temp ( M101 ({"he1at":true})
|
.png "光栅问题：Smoothieware Jerkyness/我们是否需要一个新的协议，适当的讨论 #99"){kind=avatar}
|
在我们开始走这条路之前，我想补充一点。
就个人而言，我不认为 g-code 本身是问题所在。如何接收节目同样重要，有很多方法可以独立于 g 代码和 LW 来改进流式传输过程。例如，通过使用机载存储，只需在工作期间消除流媒体。问题解决了。还有其他策略，例如缩短控制器的响应时间和更有效地执行光栅运动。 一般来说，我支持不要破坏 g 代码标准，因为它仍然是机器控制的通用接口。它被混为一谈的主要原因是由于标准中未定义的内容。Marlin 在这方面的许多方面都是有罪的，但有必要控制 3d 打印机上的所有其他东西。 如果我们开始沿着定义新 G 代码的道路前进。我想制定一些基本规则：
就个人而言，我想避免必须发明一些全新的东西，比如 Base64 压缩方案（即使这是一个很好的主意）或 XML/JSON 命令。我更愿意将其纳入标准，但是，据我所知，无法在 g 代码中传递矢量。所以，在这个问题上我可能是少数。 |
.png "光栅问题：Smoothieware Jerkyness/我们是否需要一个新的协议，适当的讨论 #99"){kind=avatar}
|
我真的认为我们不应该在这里创建一种新格式。位图 ( BMP ) 已经存在了几十年，它非常紧凑，非常简单，易于从微控制器解析，您可以使用任何图像编辑器打开生成的产品，非常适合调试，并且有大量的代码大约。让我们流式传输它。之后让每个微控制器做它想做的事。我们只需要主机发送位图，而微控制器有办法说明何时可以发送更多。在 Laserweb 方面，我很确定 skarab 可以通过谷歌搜索“javascript 位图”在短短几个小时内添加它。因为我们需要来回传输并以这种方式传输，所以我们只需要镜像每条偶数行，这不是问题。很简单，它’ 它的带宽和处理能力高效，已经存在了很长时间。我们甚至已经有了它的代码（例如： https://github.com/logxen/Smoothie/blob/laser_engrave/src/modules/tools/laser_engrave/LaserEngrave.cpp#L324 ) 8 位位图目前可能已经足够好了，但如果我们以后想超越它，我们可以，因为也有现有的 16 位标准。然后我们需要做的就是获得流式传输二进制的能力（我们现在只使用 ascii ），而鲍勃是你的叔叔。我强烈反对 base64，它只是一种使用二进制的方式，但它非常浪费。让我们做对吧。一旦我们完成了这项工作，我们需要做的就是就开始前“设置”作业的 Gcode 达成一致（大小、速度等），以及实际启动二进制流模式的 gcode。主机需要学会在流式传输时只发送二进制数据，这并不难。这是我认为这里的最佳实施，除了一件困难的事情外，它在所有方面都很容易，这让我们的通信系统学会处理二进制文件。我想我们可以做到。我的 2 美分。
|
|
@arthurwolf它是否支持像 gcode 一样在同一个文件中混合光栅和矢量？ |
|
这将使用与 Gcode 相同的通信通道，所有不是位图数据的都是 gcode，所以是的，当然。G1 X10（矢量雕刻东西）M1234 S100（设置二进制光栅雕刻速度）M12345 S123345（接下来的 123345 字节是光栅数据）<二进制光栅数据> G1 Y10（矢量雕刻东西）**显然**这里是完全随机的 gcode，不是提出建议:)
|
|
用 JS（或任何语言都非常容易）编写位图数据，我在谷歌搜索 5 秒后发现了这个：https ://gist.github.com/vukicevic/8112515
|
|
我同意@chamnit如果可能的话，我们应该尽量坚持使用核心 GCode。只有在确定有明显优势或需要时才使用 JSON 等。 我不认为二进制是一个好主意，除非你愿意放弃实时调整流的能力，例如进给保持、调整激光功率或进给率等。 我想我们真的应该确定需要什么样的数据吞吐量。在给定的进给率下，比如 1m/s，我们发送命令所需的速率是多少？我们希望支持的最大合理像素分辨率是多少？ 一旦我们确定了发送命令需要多快的速度，我们就可以就如何以能够通过我们正在使用的管道（串行、USB 等）的方式传输命令做出明智的决定。 |
|
2016 年 12 月 20 日星期二下午 6:04，Rob Giseburt ***@***.***> 写道：我同意@chamnit < https://github.com/chamnit > 我们应该尝试如果可能，坚持使用核心 GCode。只有在确定有明显优势或需要时才使用 JSON 等。我不认为二进制是一个好主意，除非你愿意放弃实时调整流的能力，例如进给保持、调整激光功率或进给率等。
我们可以牺牲 256 中的一个值（例如灰度从 1 到 255 而不是 0 到 255，我说的是缩放而不是排除，位图生成器会处理这个问题）并且让那个字节表示“返回 gcode 模式直到下一个\n”。然而，如果我们必须在快速数据传输和动态调整速度的能力之间做出选择，我什至不确定我们是否想要选择这种能力（尽管正如我所说，如果我们保存一个字节来表示“停止”，我们就不会不必做出那个选择）。传输速度确实*很多*人都在抱怨，Gcode 在这里真的不够用，太浪费了。即使是二进制位图雕刻也可能成为一个瓶颈，这将使我们大大降低我们原本可以达到的速度。
我想我们真的应该确定需要什么样的数据吞吐量。在给定的进给率下，比如 1m/s，我们发送命令所需的速率是多少？我们希望支持的最大合理像素分辨率是多少？
我不相信有一个。雕刻可以*真的*快。
|
|
并且要清楚为什么我认为我们不需要调整速度或功率的能力，这是因为即使在某些情况下它不应该，它也可能会在中途调整它可能会弄乱图片质量（如：顶部和底部“看起来”不同）
|
|
Serial @ 115200 波特可以发送超过 1,100 行，每行 10 个字符。或 1,100 像素/秒。这对于“慢速”串行接口来说非常好。假设我们能够通过创建一个 g 代码来将激光功率矢量与光栅传递一起放置，从而将其减半，这将使潜在性能翻倍至 2,200 像素/秒。适度的改进。 让我们看一下 12Mbit/s 或 480Mbit/s 的本机 USB 接口，每行 10 个字符理论上分别提供 11,000+ 像素/秒和 468000 像素/秒。至少好一个数量级。因此，流式传输 g 代码程序的带宽不是问题。这是流接口或控制器的问题。必须在那里进行改进。 @arthurwolf：我同意动态调整速度和功率（覆盖）的能力在光栅作业中并不那么重要，但它对其他一切仍然很重要。我不会从这次谈话中排除一个特定的功能，因为未来可能会有非常有趣的用例，这些用例可能被证明是非常具有开创性的。 |
|
我认为在拥有一个协议来尽可能快地传输光栅雕刻数据和关于 Gcode 的更一般性对话之间存在混淆（除非我不明白发生了什么）我认为我们应该坚持尝试找到最好的传输光栅雕刻数据的方法（我不认为 Gcode 是它）我们已经有了三种可能的传输方法（UART、USB/串行和以太网/Wifi，其他可能稍后出现），所有这些方法都有许多不同的速度不同的设置。我认为为了让尽可能多的用户满意，我们应该努力做到无论他们的通信方式有多快，他们都能获得最好的雕刻速度。雕刻工作很长，我们走得越快，大家越开心。从技术上讲，传输速度目前是许多用户的瓶颈。我相信这就是这次谈话的开始。使用当前的 Gcode 标准，使用模态 Gcode 和相对模式 ( X0.1S0.5\n )，您可以获得每像素 10 个字符以下的光栅雕刻文件。但是，如果我们可以将其降低到每个像素一个字符，为什么还要坚持这一点……专业机器可以以每秒几米的速度雕刻，分辨率很高，而且我们有硬件可以做到这一点，缺少的是一种传输方式目前，有效的数据和发送数据的软件。
|
|
@arthurwolf: 两者都有。第一篇文章展示了两个示例，说明如何更有效地命令光栅传递。这与改进 g 代码有关。对话的另一部分是问题是否出在命令上，是否出在流接口和控制器上。 恕我直言，g 代码是 CAM 和控制器之间的一个很好的分隔符。LW 的工作人员提出了通过消除过度运动来改进光栅处理的新方法，他们做得非常出色。如果您将位图上传到控制器，这会将 CAM 的责任完全放在控制器上。它使过程更加不透明和不灵活。我认为在我们的社区中保持责任的明确分离是个好主意。 FWIW，我很确定大多数专业机器仍然在 g 代码上运行。我实验室的制造车间有几台支持高速加工工具路径的生产级机器，包括 5 轴铣床和 CNC 车床。这些都仍然在直接的 g 代码上运行，并且通常在 100 的 MB 中有工作。 |
|
Well if we are just going to be using Gcode ( as in : not change what we are doing now ), there’s not so much need for discution I think : current
|
从与的讨论中解释@wolfmanjm十月：
@wolfmanjm说
也许是时候重新考虑一次发送光栅线的特殊 LW only 命令？
这将需要一些思考和计划，我们无法发送二进制数据，因此可能需要对其进行 uuencoded 或者可能仅是 ascii 的运行长度编码。
不太确定我们会在冰沙方面做什么，但我认为它应该让队列保持完整。
我认为这有点像我们处理分段弧和增量分段的方式。
值得思考。
@openhardwarecozasaid
那将是一个非常酷且有益的实现！
Marlin 使用 Base64 实现：https
://github.com/TurnkeyTyranny/buildlog-lasercutter-marlin/blob/master/Marlin/Marlin_main.cpp#L1070 Lasersaur 的协议记录在此处https://github.com/nortd/driveboardapp/ blob/6409230a68bb653ea43a197ce9c091c9fef01188/docs/protocol.md#raster-data-mode
@wolfmanjm 说
与 Marlin 的所有事情一样，我不会用驳船杆碰它；）（即使我知道他们在做什么）。
另一个协议也是我不会使用的。
您希望能够在每个像素或像素运行上设置不同的速度吗？所以这些都不允许。
我也不想在冰沙中解析光栅。
我正在考虑更多的方法来指定您当前发送的相同类型的 gcode，但以更紧凑的方式，以便一次通过串行（或从 sdcard 读取）发送更多行。然后 smoothie 简单地解压缩命令并将它们扩展到常规的计划行中。所以 LW3 完成了所有工作，而 smoothie 只是将它们解包并像处理常规 gcode 一样处理它们。这有任何意义吗？
这些行不需要超过 USB 串行缓冲区大小，但应包含与 gcode 序列相同的信息，例如起始位置、每个序列的激光功率和每个序列的进给率。沿着这些路线的东西。
话虽如此，这里有一些基本的基础知识：
无论我们最终决定什么，都需要成为一个新标准，至少对于 grbl@chamnit和Tinyg@giseburt
这三个都有相同的瓶颈：如何最好地通过串行获取流式栅格数据
我想用相同的数据格式支持 LW 中的所有三个！#yearofthelaser 和#laserweb 让激光成为主流，所以要么你帮助我们为所有人做出妥协，要么我可能会考虑从支持列表中删除你的固件。这不是“但我可以做得更好”的地方 – 我们在这里想要的只是足够好，适用于一切
目前，Smoothie 在这方面的表现最差。TinyG 目前状态未知，但由于他们的激光代码是早期的，所以我们让他们现在加入聚会（讨论），而他们仍然可以。Grbl 实际上超过了 1.1，现在是光栅上表现最好的（顺便说一句，只有普通的旧 gcode）
保持这一公民和结果的重点。让我们快速解决这个问题。它不是为了丰富某个特定的人，而是为了让激光更容易获得和更有用，进而确保 LW3 和我们所做的开放工作，确保您的各种板和固件，做用户想要的最好的