@alpharesearch: 有很多你必须改变，它会涉及一些编码。首先，Grbl 假设您使用的主轴需要在继续之前加快速度。因此，改变激光强度时的停留。更改最小路口速度不应有任何影响。它会一直住下去。

制造 LazerBlade 的DarklyLabs人员已经完成了您正在尝试做的事情。他们使用的是 Grbl 的修改版本，但它是通过 MIT 许可的封闭源代码。要执行此类操作，您基本上必须通过规划器和步进算法保留主轴速度设置。在那里，您需要在执行规划器块时即时更新主轴 PWM。实施起来不是很难，但也不是微不足道的。

它已经在 CNC 设置上运行良好。此次升级不到 100 美元，安装和调试仅需 2 小时。这是一个有趣的周末项目，它为 ShapeOko 添加了更多选项。
感谢您提供 LazerBlade 的小费。至少在他们的 Kickstarter 常见问题解答中有一个声明，即“硬核黑客”将能够编译固件。我猜是因为产品尚未发布，固件 aka grbl 尚未发布。
@chamnit：我不想维护我自己的版本而不得不向后移植，你会接受一个补丁，将它添加为编译时间选项，但可以选择在 CNC 和激光模式之间切换作为设置吗？最后，我希望能够即时在路由器和激光器之间切换。

@alpharesearch：您可能对 Shapeoko 论坛中的这个话题感兴趣。
http://www.shapeoko.com/forum/viewtopic.php?f=24&t=4203

@PicEngraver感谢您的链接！这些雕刻非常漂亮，人们用 ShapeOko 做的事情总是让我感到惊讶！
我想用这种方法 Z 轴控制激光的功率。新轴会比主轴速度更有意义吗？还是在真实 Z 轴和激光之间切换的 M 命令？我想这将允许激光功率的插值，我想这经常用于雕刻？
到目前为止，我只是在测试剪纸和一种塑料“雕刻”，并没有过多考虑将灰度图片雕刻到木头上。
感谢到目前为止的所有输入！

@PicEngraver: 很狡猾！不过有一个问题。您是否观察到 Z 轴移动与特定点的预期激光功率之间存在任何滞后？

@alpharesearch：我愿意为 Grbl 添加实时主轴控制，但我认为它会比看起来更复杂。至少做对了。就个人而言，我不喜欢添加已发布命令之外的新 g 代码命令。你最终会得到像 Marlin 这样的东西，那里有几十个很难学习的专门 g 代码，你必须为它们定制你的程序。CAM 程序也不知道这些代码是什么，因此您每次都必须手动修改它们。

一个想法是创建一个 Grbl$命令或设置来控制主轴输出状态，在每次主轴更改时暂停（可能还有延迟设置），或者在实时更新 PWM 时不暂停。像这样的东西需要进入下一个版本的 Grbl。我对如何实施它有一些想法，但它需要对规划器和如何处理块进行一些重构。不过，我需要再考虑一下。现在，我可能建议只分叉并编写您自己的实现。

@alpharesearch： 谢谢！是的，这是我几年前使用绑定到 Z 轴的 MA3 磁轴编码器开发的即时可变激光强度 8 位照片雕刻工艺。使用 Z 轴可以让我根据材料高度将激光移动到正确的焦点。

我从使用 Mach3 的 CNC 路由器开始，现在在 Arduino、9g grbl 和 Shapeoko 2 上对其进行测试。感谢 Sonny 所做的所有开发工作！

我更喜欢使用 MA3，因为它为 8 位 Z 轴深度设置中的调制提供了 0-5 变化模拟电压的 10 位分辨率。我用的是Z0。将 PicLaser Lite 或 PicEngrave Pro 5 beta 图像中的 Z-.0256 设置转换为我使用的 gcode 程序。

US Digital 确实生产了这些编码器的 10 位和 12 位 PWM 版本，但我从未尝试过。我觉得模拟是为激光二极管的不同强度控制调制驱动器的最佳方式。

@chamnit：没有我可以检测或观察到的滞后。我必须注意不要过度锐化图像并保持适度的进给率（大约 60IPM），这样 Z 轴步进器就不会松动任何步骤。我将我的加速度设置为 1000，所有三个轴上的毫米/秒，连接偏差设置为 0.010 毫米。

我在模拟器中有一些工作，请参阅情节的屏幕截图：http ://alpharesearch.de/?p=259
@chamnit我听从了你的建议，并将主轴信息添加到规划器块中。现在步进准备缓冲功能可以设置主轴。我可以用 $40=0 切换到我们现在拥有的，用 $40=1 切换到新的激光模式。我确实开始添加编译时 #if 语句（请参阅链接上的示例）……但是那部分我还没有完成。

做得很好

@alpharesearch： 做得好！我很高兴您能够如此快速地运行它并且它看起来正在运行。

不过有几件事：

• 从技术上讲，准备缓冲区功能不应设置主轴。步进 ISR 应该作为直接 PWM 定时（OCR？）寄存器更新来执行此操作，但它们之间只有 50 毫秒的差异，所以我认为您在实践中不会真正注意到它。我想在判断之前我必须先看看你是如何实施一切的。:)
• 另一件事是，更改所有编译时选项的函数调用的专用 #defines 开始变得非常混乱。我认为始终将这些数据、主轴速度和行号传递给 mc_line 和 planner 函数是安全的。相反，定义仅启用和禁用内存要求及其用于工作的代码。

否则，看起来不错！

我从谷歌代码中分叉了一个图像雕刻程序，并做了一些改动以将 Z 轴映射到 S 值。这是代码：https ://github.com/alpharesearch/imagetolaser这是模拟的屏幕截图：http ://alpharesearch.de/?p=267

@chamnit： 谢谢。是的，对于传递这些值的所有 mc 和 planner 函数，#defines 开始变大。我不太喜欢 AVR，我也不知道节省内存的所有技巧，但如果您认为这可以正常工作，那将使代码更具可读性。如果不使用这些值，编译器不应该不注意吗？我想这就是你在暗示什么？
我只是使用 prep buffer 函数作为概念证明（我没有找到更好的地方），我只是暂时调用现有的 spindle 函数。但我同意将其尽可能靠近块的开头。

PicLaser Lite 将根据图像的阴影生成 S 命令 gcode 值，以控制激光雕刻图像的不同 PWM 输出。 http://www.picengrave.com/PicLaser%20Lite.htm

@PicEngraverToo我使用 Linux…但如果您可以发布邮票大小的雕刻 g 代码文件，我想用新固件对其进行测试。只有 XY 运动和 S0 到 S255 才能设置 pwm。谢谢你的帮助。

@alpharesearch: 你可以从这里复制代码。

PicEngraverToo/grbl-S-command-gcode@ 3966943 #diff-0

@PicEngraverToo: 谢谢 我确实用 grbl 模拟器测试了它，我可以看到一个戴着帽子的女人。它很小，我说的对吗？

@chamnit: 我把它从 ISR 的准备中移走了，我可以看到很大的不同。但是我仍然认为还有改进的余地。但至少现在我用新的快速方法和旧的慢方法得到了相同的结果。但是仍然有很小的偏移量。我也需要在真正的微控制器上进行测试。

@alpharesearch： 你是对的。尺寸为 12.7mm X 12.7mm，X 和 Y 跨距为 .254mm。我首先以 25.4mm X 25.4mm 生成了它，但是有大约 100,000 行代码，我不知道如何附加文件。新手在这里。:-) 弄清楚后，我可以生成一个更大的文件供您测试。

@alpharesearch: 好的，这里有一个更大的S命令代码供您测试。它的长度超过 700,000 行。

http://picengrave.com/downloads/MiscDownloads/Transportation680.txt

@alpharesearch： 惊人的。这方面的巨大进步！:)

至于定义，我检查了编译器是否忽略了传递给函数的未使用变量。它没有，但在这一点上，我认为保存每个字节都没有那么重要，因为我们很快就会转向功能更强大的处理器。更重要的是代码库 IMO 的可读性。现在保持原样，但我将开始考虑传递 gcode 解析器结构，这将需要对代码进行一些重构。

无论如何，让我们了解情况！我很喜欢你如何使用 grbl_sim 来完成所有这一切，并获得 Grbl 正在做的事情的那些伟大的可视化！

@PicEngraverToo: 现在这个文件运行很慢。是否有一个选项只具有完整的 S 值，而不是 S69.56 只有 S69。PWM 只有 8 位，我确实将 0 映射到 255，所以任何小数位都无关紧要。如果 S 值没有变化，则不需要处理。

@chamnit：当我将变量复制并粘贴到所有函数时，我也在考虑一个结构……
这是一张来自一些纸板的照片（看起来纸板燃烧得太快而且更像是数字 – 剩下的不多了灰度部分）：
http ://alpharesearch.de/wp-content/uploads/2014/09/IMG_20140920_121713.jpg
在照片上，左右两侧每隔一条线都有一些偏移。我不确定为什么，但我确实在没有修改的情况下用模拟器中的 master 重新测试了这个，我可以看到相同的偏移量。我一直认为这是因为我没有在正确的时间更改 S（在我的代码中，在 IRS 中进行主轴更新之前这个偏移量更糟）引起的…但是因为这在硬件和模拟器中以及在新旧版本我确定它是代码中的东西而不是我的机器中的东西。我在模拟中确实看到了同样的情况，只有一种方式（我使用 G0 返回 X0）。这可能与 PWM 的设置/工作方式有关吗？

@alpharesearch: 我很快看了你的源代码。主轴控制的实现方式不太对，因为你调用的是spindle_run()。函数执行的许多额外操作与步进 ISR 不兼容。相反，我会创建一个单独的函数，它只在 ISR 中设置 PWM OCR 寄存器。执行起来非常快。正确的 OCR 值的计算应该先验地完成，如果可能的话，但你现在可能没有它就可以快速工作。

@chamnit感谢您的输入！我能够将运行函数分开并将计算移动到准备函数中，并且只在 ISR 中设置位。

这是来自 grbl 模拟器测试的日志，只有 ISR 中的 OCR：

# block number 0
   1.002666950225830 0, 0, 0, 0But there are more bits than just OCR...
   ...
   1.760000109672546 182, 0, 0, 0
   1.770000100135803 187, 0, 0, 0
   1.780000090599060 192, 0, 0, 0
   1.786611795425415 195, 0, 0, 0
# block number 1
   1.790000081062317 197, 0, 0, 0
   1.800000071525574 201, 0, 0, 0
   1.810000181198120 206, 0, 0, 0
   1.820000052452087 212, 0, 0, 0
   1.830000042915344 217, 0, 0, 0
   1.840000033378601 222, 0, 0, 128
   1.850000023841858 227, 0, 0, 128
   1.860000014305115 232, 0, 0, 128
   1.870000004768372 238, 0, 0, 128
   1.880000114440918 243, 0, 0, 128
   1.890000104904175 249, 0, 0, 128
   1.900000095367432 254, 0, 0, 128
   1.910000085830688 260, 0, 0, 128
  ...
   2.130000114440918 399, 0, 0, 128
   2.133105516433716 401, 0, 0, 128
# block number 2
   2.140000104904175 406, 0, 0, 128
   2.150000095367432 413, 0, 0, 128
   2.160000085830688 420, 0, 0, 128
   2.170000076293945 427, 0, 0, 128
   2.180000066757202 434, 0, 0, 128
   2.190000057220459 442, 0, 0, 255
   2.200000047683716 449, 0, 0, 255
   2.210000038146973 456, 0, 0, 255
   2.220000028610229 463, 0, 0, 255
   2.230000019073486 470, 0, 0, 255
 ...
   2.490000009536743 633, 0, 0, 255
   2.492191553115845 634, 0, 0, 255
# block number 3
   2.500000000000000 638, 0, 0, 255
   2.510000228881836 643, 0, 0, 255
   2.520000219345093 649, 0, 0, 255
   2.530000209808350 654, 0, 0, 255
   2.540000200271606 659, 0, 0, 0
   2.550000190734863 664, 0, 0, 0
   2.560000181198120 669, 0, 0, 0
   2.570000171661377 674, 0, 0, 0
   2.580000162124634 679, 0, 0, 0

我不确定模拟器中的块编号有多精确，但我猜（或希望）这是真的。当然，我得到的错误越多，进给速度越快。但最让我感到震惊的是更新看起来像是落后了。我期待更喜欢在新块开始之前更新？

这是我用来测试的 g 代码

G0 X0.00 Y0.00
M3 S0
F4000
G1 X2.50 S0
G1 X5.00 S128
G1 X7.50 S255
G1 X10.0 S0

G0 X0.00 Y1.00
G1 X2.50 S0
G1 X5.00 S128
G1 X7.50 S255
G1 X10.0 S0
...
M5

@alpharesearch: 试试这个没有任何小数位的新 S 命令 gcode。

http://picengrave.com/downloads/miscdownloads/Transportation680.txt

@PicEngraverToo：感谢文件…如果这是相同的数据，它看起来像剃掉小数位保存 1.9MB…如果相同的 S 值不改变，主版本中的 g 代码解析器现在可以跳过. 这使得它在旧代码中更快，因为 S 的变化会触发整个缓冲区每次都被清空……

您好，
此信息不适合我！:-(

我的问题与反冲和车床卡盘正时有关。

谢谢特里
_

从三星手机发送

@PicEngraverToo：感谢文件…如果这是相同的数据，它看起来像剃掉小数位保存 1.9MB…如果相同的 S 值不改变，主版本中的 g 代码解析器现在可以跳过. 这使得它在旧代码中更快，因为 S 的变化会触发整个缓冲区每次都被清空……

—
直接回复此电子邮件或在 GitHub 上查看。

@alpharesearch：（如何）您如何根据运动速度调整激光功率？或者假设激光以恒定速度移动是否足够好？S 值不应该调整“每毫米激光能量输出”并且 grbl 管理同步加速/减速和“地面速度”的激光输出的上升/下降？

@chamnit：还记得我们关于“流式 S 值”的讨论吗？我非常喜欢在更新主轴值时不必总是清空缓冲区的想法。对于正常的数控操作，我们必须提供一种方法让机器等待主轴达到所需的转速，虽然……可能取决于变化率：如果变化小于 10%，则不等待，否则每 1000rpm 等待 1 秒…

@PicEngraverToo: 顺便说一句，你不能压缩掉相同 X 值的“X…”吗？应该将数据/文件大小再减少 ~40%。

...
X0 Y0 S98
Y0.127 S66
Y0.254 S75
...
Y95.123 S143
X0.127 Y95.123 S103
Y94.996 S46
Y94.869 S58
...

您好
，我不明白为什么我会收到这封电子邮件！
不过，一切都非常有趣
2014 年 9 月 22 日 09:06，“Markus Schorer” notifications@github.com写道：

@alpharesearch https://github.com/alpharesearch: (how) do you handle
adjusting laser-power depending on speed-of-motion? or is it good enough to
assume that the laser is moving at a constant speed? shouldn’t the S-value
adjust “laser energy output per mm” and grbl manage the ramping up/down of
laser output in sync to accel/decel and “ground-speed”?

@chamnit https://github.com/chamnit: remember the discussion we had
about “streaming S-values”? i very much like the idea of not always having
to empty the buffers when updating spindle values. for normal cnc operation
we would have to provide a way to make the the machine wait for the spindle
to reach the required rpm though … maybe depending on the change rate: no
wait if change is < 10%, else wait 1s per 1000rpm …

@PicEngraverToo https://github.com/PicEngraverToo: btw, couldn’t you
compress away the “X…” for the same X value too? should reduce
data/filesize by another ~40%.

…
X0 Y0 S98
Y0.127 S66
Y0.254 S75