将我的激光分支中的所有相关部分添加到边缘 #498

@alpharesearch： 谢谢！在合并和审查新的探测函数之后，我将不得不在今晚或本周晚些时候处理这​​个问题。如果我碰巧忘记了，请联系我。（我不应该）:)

@chamnit: 请慢慢来。

还有一些命名问题，我愿意接受更好、更具描述性的名称：

1. config.h 中的 LASER_SPINDLE
2. defaults.h 中的 DEFAULT_LASER
3. 报告和设置中的 $40=1（打开激光模式，bool）
4. settings.h 中的 BITFLAG_LASER
   现在所有代码仅用于激光，计划器中没有任何处理来在提高进给率的同时调整 RPM。但我认为这可以在以后进行。但我想这需要新的变量来以某种方式讲述激光。现在可以处理的另一部分是也为主轴添加它。
   最后一部分我不确定是否在 stepper.c 中——现在每个打开主轴的块和 S 值将始终设置两个寄存器。我不确定在中断“如果”或只是重新设置时需要更多时间？我想如果没有人知道，我们可以看一下十六进制文件/汇编代码。如果“if”是更好的选择，我会在准备函数中对旧块进行所有检查，并在中断中只包含一些“if”。

@alpharesearch激光方面的出色工作。
您是否建议主轴速度根据进给率而变化？用于一般加工还是用于激光模式？
不确定在加工钢或铝时我会想要这个 有太多因素，电机功率，切屑负载，是否使用冷却液，机器刚度，刀具上的凹槽数量。现在对于车床模式，这意味着我们可以有基本的常量 SFM（每分钟表面积英尺）:-)

@gerritv：我认为他想根据实时进给率而不是编程来改变主轴速度。这对于激光切割来说尤为重要，以确保始终有均匀的功率切割材料。如您所知，有加速规划，但不能保证机器会按照程序运行。

但是，你确实提出了一个非常有趣的观点。实时主轴速度更新可用于车床常数 SFM，这太棒了，因为我想尽快购买一台小型车床。:)

我有一个 Taig，之前我在我的 Unimat 中添加了步进器。不难做到，尤其是。如果您已经有一个铣床/数控铣床来制作支架。

对于车床模式，将主轴与 Z 轴同步（沿着车床）更有用，它允许螺纹加工！！！虽然有很多 gcode 更改以获得适当的支持，不同的 G 块和额外的 I、J、K 等词。

@alpharesearch 你知道 GBRL 的任何官方激光模式或者可能是一些成功实践的链接吗？

@mkeyno: Grbl v1.1 刚刚发布并且有激光模式。

这太棒了。我得到了很好的结果。以 2000-3000 的进给率自由移动。没有暗边（多亏了 M4 模式）。我正在将我所有的硬件从 Marlin 转移到 GRBL V1.1。

@mkeyno新的 1.1 版本比我们过去 2 年的任何版本都要好得多。正如其他人所说，检查 M4 模式。
@tklus关于开发威胁人们谈论 laserweb3，我试过了，它很好。但我不知道是什么@mayhem2408正在使用。

我用过 LaserWeb3，只是用一个文本编辑器把 M3 改成了 M4。结果不言自明。

在将它们输入 Laserweb3 之前，我还对照片进行了 Photoshop 处理，因为我发现我的激光阴影不是线性的。60% 及以上看起来几乎相同，而 15% 及以下则什么都不做。38% 的一半在我的设置中太暗了，所以我调整了伽马曲线，它在屏幕上看起来很糟糕，但在激光上很好。我目前正在开发一个 Inkscape 扩展，它将完成所有工作并生成 g 代码。随着它的发展，我会发布更多相关信息。

大家好，好消息。我需要一些空闲时间来测试新的 GRBL。目前我使用旧的 alpharesearch 版本，因为我获得了比最新的 alpharesearch 更好的性能（没有 micropicauses 的雕刻速度更快）。

…对于那些使用图像到 gcode 应用程序的人，您可以从此处测试 3dpBurner Image2gcode 和发送器应用程序http://3dpburner.blogspot.com/p/files.html

再次嗨，在激光模式下测试了新的 GRBL 1.1，但我仍然通过使用日期为 2015 年 2 月 4 日可用版本的 GRBL Alphareseach mod 获得最佳性能（更高的雕刻速度而没有微暂停）（https://drive.google .com/file/d/0B5Y1gEmSHMjMS1R4RUhsamV3QXc/view?usp=sharing )

使用 3dpBurner 型激光雕刻机并根据雕刻分辨率，我可以达到这些速度而无需微暂停 = 恒定速度和更平滑的雕刻：分辨率
（毫米）速度（毫米/分钟）
0.08 2800
0.07 2600
0.06 2300
0.05 1700
0.04 1500

使用相同配置的 GRBL 1.1，我无法达到该速度。
这也可以从工作时间上看出。雕刻相同的 40x35mm 图片：使用 Alpharesearch 时为 9 分 37 秒，使用 GRBL1.1 时为 10 分 59 秒

@villamany: 其他人没有报告过这么大的速度差异。它应该几乎相同。可能的主要区别在于 M3、M4 和 M5 命令的处理方式。每当这些变化时，我都会强制停止。您可以通过编程零主轴速度来避免停止和关闭激光器S0。这是关闭主轴而不改变其模态状态的有效 g 代码。

还要确保您使用新的“M4”动态模式。它仅在 M3、M4、M5 更改时暂停。

@villamany：还有一个考虑因素是，v1.1 必须通过为 v1.1 中的新实时覆盖减少一两个块来释放更多的 RAM。进给倍率改变速率，但不改变动态缩放的功率，而主轴倍率改变动态缩放的功率。这使您可以快速拨入激光作业。

较小的规划器缓冲区可以降低最大速度，因为规划器必须在其中的运动中进行规划。换句话说，光栅作业的短线段可以限制规划器内的距离量。并限制最高速度。但是，这种情况非常罕见，尤其是对于激光切割机。他们通常具有非常高的加速度设置，使他们能够在更短的距离内计划到编程速度。

您可以尝试的一件事是增加机器的加速度。您可以通过将加速度提高几个百分点来轻松地测试和验证这一点。如果您遇到此特定限制，您应该会看到 v1.1 的执行时间略有下降。

我很快也会将 Mega2560 分支更新到 v1.1。您将在那里拥有至少两倍的规划器缓冲区，并且可能比任何一个版本的性能都要好得多。

过去，我测试了较新的 Alpharesearch 版本，但由于性能更好，我总是回到 2015 年 2 月 4 日的版本。

当光栅雕刻时，我从不使用 M5 关闭激光电源，我使用 M3S0 代替，所以从这里没问题。

我现在正在为同一文件测试 GRBL1.1 的 M4 模式，而不是使用 M3，但这真的很慢（估计剩余时间约为 1 小时而不是几分钟）。

我对 1.1 的配置是这样的，也许你可以在这里看到任何原因（注意未使用 Z 轴）：
$0=10
$1=255
$2=0
$3=0
$4=0
$5=0
$6=0
$10=6
$11=0.020
$12=0.010
$13=0
$20=0
$21=0
$22=1
$23=1
$24=200.000
$25=4000.000
$26=0
$27=0.000
$30=255
$31=0
$32=0
$100=80.000
$101=80.000
$102=0.001
$110= 12000.000
$111=12000.000
$112=12000.000
$120= 1200.000 $
121 =1200.000
$122=12000.000
$130=355.000
$131=520.000
132 美元=10000.000 美元

测试用的文件比较简单，用记事本打开，在文件开头修改F Speed和M3/M4模式即可。它是 40x35mm 对角光栅雕刻，激光从 0-255 功率值缩放：https ://drive.google.com/file/d/0B5Y1gEmSHMjMckRJS1hqU3A1SDA/view?usp=sharing

@villamany: 您是否启用了激光模式（$32=1）？您的设置显示它仍处于禁用状态。

哎呀。对不起，我忘记了它，因为我的电脑上打开了很多文件。
但是，现在用 $32=1 和 M4 进行测试，结果相同，电机声音不平稳，总时间更长：
v1.1 M4 模式
11 分钟 13 秒 v1.1 M3模式 10 分钟 59 秒 Alphareserach 9 分钟 37
秒

@villamany: 不确定为什么运动不流畅。你不应该。你如何流式传输你的gcode？

通过使用字符计数系统，使用 3dpBurner Sender 应用程序https://github.com/villamany/3dpBurner-sender/releases/download/v1.1/3dpBurnerSender.exe

缓冲区块报告在 Alpharesearch 上保持大约 17，而完整的工作，如果我是正确的，它应该相当于较新的 v1.1 缓冲区自由报告中的大约 0，但始终保持在 0 以上

@villamany： 很公平。我下载了你的文件，看起来你远远超出了 Arduino 的能力。您平均每 3.0 毫秒发送一条 g 代码行。这太快了。按照这个速度，v1.1 有点慢我并不感到惊讶。与 v0.9 相比，它需要做更多的工作才能启用覆盖。（如果您还没有使用过覆盖，请使用。它们会改变您使用机器的方式。）

在最坏的情况下，我将 v0.9 计时为每行 g 代码需要大约 4 毫秒。它通常会更快一些。可能下降到每行 3.0 毫秒。我还没有计算出 v1.1 的最低 g 代码速率是多少，但根据您的测试，它大约是每行 3.3 毫秒。我认为这是完全可以接受的。任何更好的都必须等到 Grbl ARM 版本即将推出。:)

我想现在的问题应该是，质量有什么区别吗？特别是 M4 动态电源模式？它应该明显更清洁并且燃烧更少。

此外，在这些高速率下，我认为您正在看到略小的计划缓冲区的影响。与更大的代码行相比，它计划每行 g 代码多一到两个块。我不会解释为什么，但在某些情况下确实如此。在大多数情况下，我认为这不是 Grbl 的问题，而是达到了 Arduino 可以做的事情的极限。

太好了，等待 ARM 版本。是的，我知道我在 Arduino 功率的极限上，我搜索了我用于雕刻的每个分辨率的极限，还测试了降低步数/毫米和步进分辨率以降低 Arduino 负载，但没有太大区别。
激光需要更快的速度来提升他的所有能量。在这个 3000mm/min 的速度下，我需要将最大功率降低到大约 PWM180 而不是最大 PWM255，所以任何速度的提高都会加快速度。我的激光是 2-3W，但现在市场上有更强大的激光二极管，所以速度更快是非常受欢迎的。

Overrride 是一个很好的工具，可以像 v1.1 上的其他强大功能一样获得最佳设置，但如果速度超过它，那么可能仍在我的实际版本上。
目前，矢量雕刻或切割的加速度没有太大问题，只有在图片周围有方形标记的光栅雕刻上才有问题，但是通过向图像添加白框可以轻松解决问题，通过这种方式所有加速度都在白框上进行没有燃烧，所以没有痕迹。

非常感谢您的出色工作，我真的很感激。可能是创客世界最好的项目之一

@villamany：主要问题之一不是控制器，而是控制激光器的 g 代码。没有一个命令可以很好地处理光栅过程。它们是非常短的直线，通常间隔均匀，只有主轴速度变化。无论控制器是什么，甚至是 ARM，您总是会遇到流式传输这些 G1 Sx 线段的速度限制。我真的认为需要一个特殊的 g 代码来进行光栅化，以便在较长的线段上插入多个 Sx 值。但这是一个应该在适当的线程上讨论的话题。

使用 M4 动态模式，您不需要图像周围的额外空白。您应该能够删除它并缩短处理时间。不确定要短多少，但如果您尝试这样做，它可能会比之前的测试更快。

我以 F4000 的速度进食。我的光栅分辨率为 0.1 毫米，所以我每秒燃烧不到 700 像素。我还生成了 100 级灰度的 gcode，因此代码非常大，因为几乎每个像素都被发送了。我已经优化了我的 g 代码以使其尽可能小，例如
G1X14.5S545
我可以毫无问题地保持缓冲区满。

我什至测试过 F6000，但虽然我的激光不够强大，无法以该速度产生良好的燃烧效果，但 GRBL 能够跟上。

话虽这么说，我一直在为激光使用 Marlin 的修改版本，它有一个名为 G7 的光栅 gcode，您可以设置分辨率、方向并将其 base64 编码字符串提供给光栅。它产生更少的串行数据和更小的文件。例如，在 50 个像素的 G1 gode 上将消耗大约 600 个字节。使用 Marlins G7 同样的事情只需要大约 70 个字节。Marlin 比 GRBL 慢得多，这也是创建 G7 模式的主要原因。

有人认为我已经并且将要进行试验，但还没有时间开始考虑代码是允许 G1 在 1 行上有多个 S 参数。示例
G1 X10 S123 S234 S524 S126 S765
我们的想法是让 GRBL 计算出线路的长度，并根据发送的 S 参数的数量在规划器中将其分成更小的段。
例如，

G0 X0 Y0
F1500
G1 X10 S123 S234 S524 S126 S765

将在规划器中创建以下内容

G0 X0 Y0
F1500
G1 X2.0 S123 
G1 X4.0 S234
G1 X6.0 S524
G1 X8.0 S126
G1 X10.0 S765

这会将 5 个像素所需的串行数据从 60 个字节减少到 26 个。
只是一个想法……

@mayhem2408: 好吧，你赢了。每个线段 1.7 毫秒是惊人的。感谢分享。

我在 Marlin 上快速搜索了 G7。看起来 LW3 的人反对乱用 g 代码，除非他们必须这样做。我支持不要过多地修改 g 代码，但我认为这样做是有充分理由的。不仅仅是文件大小，我认为当你接近几十微秒的燃烧时间/像素时，这将成为一个更大的问题。它只是无法扩展。

有趣的讨论。

• 还有一个想法：在未来的 ARM 版本中，接口可能是 USB RAW-HID（io.Serial），它可以提供高达 12 Mbps 的通信速度。

• 关于新 G-Code 词的想法：我认为在其生命周期中，GCode 已经进化了很多，以适应机器 HW 的进化。GCode 起源于我们拥有 3D 打印机和激光切割机之前。我认为用一些新词来扩展语言以有效地满足这些新型机器是可以的。

@chamnit当您谈论 ARM 版本时，您的目标是什么板？像这样： 重新武装？

If taking the step to ARM, I would advise to at least go to a Cortex M4F processor, as it can do ‘float’ math in hardware.. eg
float multiply : 1 cycle
float divide : 14 cycles
float sqrt : 14 cycles
This way a lot of things can be done in the real-time part, which in turn simplifies design..

The Re-ARM has a Cortex M3 which has no floating point HW.
The few $$ price difference between M4F and M3 are probably irrelevant in the total cost of your machine..

@Strooom你有想法吗？我想 Teensy 3.5 和 3.6 符合要求。
我想有可能创建某种连接板，它可以同时使用 RAMPs 1.4 和 Teensy 3.5/6 并建立连接。
还是您建议从头开始设计一些东西？