注释
|
您可以在https://github.com/gnea/grbl/blob/edge/doc/markdown/interface.md中找到有关配置选项、错误消息和警报状态的信息。 |
.png "激光模式问题 #38"){kind=avatar}
|
它看起来更像是整个系统只是重置然后（默认情况下）以锁定状态启动 – 因此警报 这是终端输出（来自 LaserWeb3） 这是它停止的 gcode： 我想没什么不寻常的。 |
|
这些是我的设置：： |
|
你有没有点击停止按钮？ |
|
顺便说一下，您的设置看起来不错。 |
.png "激光模式问题 #38"){kind=avatar}
最后请粘贴您的 |
$I: 现在我看到一个问题，当我重置时，激光管会在 3 次短脉冲中触发。 |
|
如果是 EMI 导致您的硬重置，那么这不是 Grbl 问题。 硬重置会将 Arduino 引脚置于浮动状态。Grbl 对此也无能为力。我记得 Arduino 引导加载程序将启动序列保持一两秒钟。通过 ISCP 标头与编程器一起闪烁可以摆脱引导加载程序。它可以减少或消除此引导顺序。如果您有程序员或备用 Arduino 用作程序员，我会尝试这样做。 |
.png "激光模式问题 #38"){kind=avatar}
|
@chamnit您同意更新到 v1.1 后需要重置 EEPROM 吗？ （使用“$RST=*”命令完成） |
|
@Protoneer：是的，但是 Grbl 应该会在第一次使用 v1.1 固件启动时自动执行此操作。它检查设置版本号（不同于固件版本）。v0.9j -> 9 和 v1.1 -> 10。 |
|
仅通过 USB 重新连接串行连接（通过软件，电缆保持连接）时也会发生短激光发射行为，但这不应该导致重启，对吗？ |
|
谢谢，同时找到它；） 你有没有时间看看为什么在 ctrl-x 之后 gcode 队列没有被清除？ 我正在考虑断开并重新连接串口，但这会短时间发射激光，这不好（安全）。 |
|
@cprezzi: 抱歉，过去几周我没有太多时间。几份报告即将到期，并且在研究 Grbl ARM 时也有点偏离了方向。我今晚试着看一下。 是的，重新连接时不受控制的激光发射非常不安全，但我不完全确定该怎么做。我会认真尝试与另一个 Arduino 或程序员通过 ISCP 标头编写 Grbl。这将摆脱引导加载程序，并可能大大减少或消除此问题。不幸的是，我现在无法检验该理论。 |
|
对于普通用户来说，通过 ICSP 对 Arduino 进行编程可能不太实用。我希望找到另一种解决方案，最终基于硬件。我认为问题在于，pin11 在复位期间处于浮动状态，直到它被配置为集电极开路输出并且 pwm 设置为零。如果我可以设计一个简单的外部电路，将引脚拉到地，直到 Arduino 准备就绪，就可以解决问题。是否还有一个引脚可以用来告诉外部电路固件正在运行（或串口已连接）？ 我希望你能找到缓冲区转储的解决方案。一个额外的实时命令来清除缓冲区可能会有所帮助，所以我们可以先保持然后重置队列。 |
|
您是否尝试过只添加一个高值下拉电阻？也许从100k开始。 |
|
舒尔我会先尝试下拉 |
|
@cprezzi: 我不担心挂起问题。这可能只是我的状态机疏忽。几行代码应该可以修复它。 至于用于清除队列的附加实时命令，我不会那样做。这将引入大量需要考虑和适当处理的运行时和安全条件。当控制器允许时，这种类型的控制也经常被严重滥用。Grbl 有意限制仅使用 Ctrl-X 软重置或电源循环来清除缓冲区。主要是因为，如果您处于需要这样做的情况下，那么您很可能需要中止并重新开始您的工作。 如果您询问更好的慢跑处理，Grbl v1.1 有一个新的慢跑模式。在处理慢跑运动时，它有一个内置的方法来清除缓冲区。只有在 JOG 状态下，进给保持才会使机器停止，然后自动清除计划器缓冲区。还有一个单独的点动取消实时命令将执行相同的任务。强烈建议您使用它而不是进给保持命令，因为它不会在点动停止后意外调用保持状态。 |
|
我不是在谈论慢跑，我只是在研究暂停和停止行为，这些行为应该立即停止。对于暂停，我们发送 hold，它会立即停止，但 ctrl-x 会在停止之前发送队列的其余部分。刚刚出现这个问题是因为我们开始使用字符计数的方法，在grbl中填充gcode缓冲区。我不确定我的 ctrl-x 是否被执行了。 |
|
@cprezzi: 我碰巧有一个 Arduino，只是做了一个快速测试。Hold 然后按 Ctrl-X 可以正常工作。它将中止保持、重置 Grbl 并刷新计划器和串行缓冲区。 我想我知道问题出在哪里了。在发送 Ctrl-X 之前，您的主播必须停止将 g 代码流式传输到 Grbl。否则，Grbl 将在重置完成后执行流式传输给它的任何 g 代码。这发生在 HOLD->reset 之后，因为 Grbl 重新初始化为 IDLE 状态。不是阻止所有 g 代码命令的警报状态。 HOLD->reset 被认为是“安全”重置，其中位置仍然由 Grbl 保证，因此它不必调用警报。它允许您立即继续操作机器。如果机器在重置期间移动，这会调用警报状态，因为它必须在加速度设置之外立即停止机器并且不能保证位置。我希望这能解决问题。 |
|
我在发送 ctrl-x 之前停止了流媒体，但我认为我的 ctrl-x (0x18) 没有正确发送，因为我没有看到 grbl 的任何反应。我仍然收到状态查询的回复。如果 ctrl-x 将由 grbl 执行，我应该得到欢迎字符串“Grbl 1.1d [‘$’ for help]”，对吗？ |
|
@cprezzi： 是的。您应该在每次重置后看到欢迎字符串。Grbl 直接从串行 ISR 中提取实时命令。它永远不会进入串行 RX 缓冲区，您可以在其中使用 CC 协议存储其他数据。因此，只要发送了 Ctrl-X，Grbl 就应该标记系统并开始重置。我的猜测是出于某种原因没有发出 Ctrl-X。 |
|
好的，找到问题了！我必须做一个 String.fromCharCode(0x18) 来让节点序列快乐。 |
|
关于浮动针主题… 如果我们使用连接到主轴引脚和冷却液/主轴方向引脚的硬件与门来启用激光会怎样？ 使用此配置，冷却剂/主轴方向引脚需要高以及主轴引脚才能发射激光。 |
|
您可能仍然需要在两个输出（和门输入）上进行下拉，因为它们会在重置时浮动并且仍然可以随机触发有源输出。 |
.png "激光模式问题 #38"){kind=avatar}
|
有没有人修复激光打开？删除引导加载程序并没有解决我的问题。 |
您好，
我正在 Protoneer 的 Raspberry Pi CNC Shield 上运行 1.1 beta。我用它来控制结合了 LaserWeb3 的自制 40W CO2 激光器。
由于激光模式，我从 0.9j 切换到 0.9j – 看起来很有希望！
到目前为止我的发现：
在执行“$$”命令时，我错过了对设置的评论。这可能是我缺少的编译标志？
我在连接到屏蔽的 pi 上编译。冗长的编程会显示一些关于多次声明 true、false、max 和 min 的警告。这不是什么大事，但仍然是警告。
系统在任意点停止并给出“警报”状态 – 有没有办法获得有关导致警报的原因的详细信息？
首页提到“激光模式由 $ 命令激活” 你能澄清说 $32=1 启用激光模式吗？查看所有设置时可以节省一些时间