我将插入一个简单的后处理步骤，将其去除并去除单独的 S 值。在 Smoothie 上运行时，“G0 F1500”会抛出矢量操作。

它现在从 lw.raster-to-gcode 输出中去除“G0 F…”和单独的 S 值。

成立。这是https://github.com/lautr3k/lw.raster-to-gcode @lautr3k上的一个参数，rapidRate
有什么办法可以防止它被使用？无论如何，G0 可以作为机器设置或光栅设置公开。

传统上G0 feed是gcode无法触及的设置。Reprap 人们添加了 G0 F 因为 reprap 很奇怪。因为 Reprap，Smoothie 添加了它。我们不需要它，它会弄乱后面的矢量操作。

如果我们将它添加为设置，那么我们会将用户与 grbl 混淆，而 grbl 忽略它是正确的。

好的，但是当 RepRap 来的时候，这个问题肯定会出现……

这是一个特性，而不是错误；)
如果 rapidRate 设置为 0，我们不能忽略 F 值，暂时将 rapidRate 固定为 0 吗？

稍后，当/如果我们集成 3dp，我们可以向用户公开此功能。

@tbfleming添加一个后处理器来修复我们也可以在生成上修复的东西不是有点简单吗？

我们无法在生成时修复它

除非我们 fork 它并且不使用 npm 包。

如果@lautr3k 不想将这个 repo 移到 Laserweb 组织中（或者至少给我们推送他的 repo 的权利），那么我们真的应该 fork 它，因为我们依赖它。

我发现我们已经在组织中有一个分支（21 天前）。

嗯..我做了一个叉子并为他的回购贡献了一些代码。就那么简单。

@jorgerobles您的叉子是 laserweb 组织中的叉子吗？我更愿意使用它。

他反对解决单独的 S 问题，并声称这是一个 Smoothie 问题。我们需要将其发布出来，因为它会扰乱 Smoothie 和 grbl-lpc。

@cprezzi会做。

LaserWeb/lw.raster-to-gcode@6d82cd7 _

skarab42/lw.raster-to-gcode#3

我已经在本地测试了 PR 并且工作正常，但是在构建和使用我们的 git 而不是 npm 时遇到了问题。暂时等待。

@tbfleming后处理器是之前评论过的一个好主意。我们如何才能使该方法通用，从而使社区贡献的后处理器满足他们的需求？

我没有考虑过这个。支持用户贡献的代码存在潜在的安全问题，尤其是在 Electron 下，因为它提供直接的文件系统和操作系统访问。

是的。我们总是可以让他们通过 PR 做出贡献，并在编译前进行测试。

如果@lautr3k 不想将这个 repo 移到 Laserweb 组织中（或者至少给我们推送他的 repo 的权利），那么我们真的应该 fork 它，因为我们依赖它。

@cprezzi你必须这样做@jorgerobles 刚刚为skarab42/lw.raster-to-gcode#4 PR 做了：

1. 从 lautr3k/lw.raster-to-gcode/ master branch 在 LaserWeb 仓库上创建一个新分支
2. 将其命名为set-rapidRate-optional，或描述新功能/修复的名称。
3. 进行更改（无需重新格式化源代码）并遵循代码样式。
4. 在没有构建文件的情况下制作您的 PR，只有修改后的源文件。

@tbfleming我将修复单独的 S 值。

@lautr3k 太棒了！

@jorgerobles @tbfleming lw.raster-to-gcode@0.6.3 已出局：

• 单独修复 S 值（重复第一个点）
• rapidRate 现在是可选的（设置为无效值以禁用）

@DarklyLabs 请测试关闭:)

遇到与向量相同的问题。似乎只有在作业完成前中止后才会发生。目前再次不可重复。
我已经要求团队在下次发生时导出/检查 gcode。

@DarklyLabs 请特别测试光栅。Vector 是完全不同的代码。

由于 G0 被剥离，我们还没有经历过光栅雕刻的这种放缓。