Contact me: hankecnc@gmail.com
> 推推 > G38.2+ #491

G38.2+ #491

推推 grbl 3年前 (2023-01-22) 354次浏览

对话

G38.2+ #491
贡献者

这主要是我在底部包含的#490描述的副本

这好像是@chamnit对登陆这个有一些保留，所以我想解释我的用例是值得的。

我真的很想在我的机器附近的某个地方有一个开关0,0,-z，我可以结合使用G43（G43 工具长度偏移）在手动工具更改后自动设置工具（现在的深度）。

我主要关心的是G38.2，一旦按下开关，它就会在EXEC_FEED_HOLD/deceleration 阶段继续移动到开关中，并最终报告它的静止位置。这是有道理的，您当然不想破坏机器执行硬停止和丢步的状态。对于具有快速加速设置的机器来说，这可能不是一个大问题。

然而，为了对各种机器配置保持稳健，关闭开关似乎是一个合理的下一个操作，以确保工具恰好位于按钮的高度。这大致类似于当前执行归巢的方式（即后退、重新参与等）

如果可以访问探针引脚状态或G38.{4,5}很像归位循环的循环，可以在用户端工具（即 python/node/java）中创建，以帮助消除工具更改之间的任何差异。我在这里选择了标准方式，以避免向输出添加更多的报告噪音，并希望它对使用其他类型探头的人也有用

复制自#490

这是通过添加一个 sys.probe_away 标志来实现的，该标志用于根据我们正在探测的方向翻转开关的方向。

真值表

            towards (G38.2, G38.3)    away (G38.4, G38.5)
before       sys.probe_away  = 0       sys.probe_away  = 1
             sys.probe_state = 0       sys.probe_state = 1 

after        sys.probe_away  = 0       sys.probe_away  = 1
             sys.probe_state = 1       sys.probe_state = 0

这假设开关在“探测离开”开始时接合，考虑到 linuxcnc 描述中的措辞，这似乎是合理的

G38.2 - probe toward workpiece, stop on contact, signal error if failure
G38.3 - probe toward workpiece, stop on contact
G38.4 - probe away from workpiece, stop on loss of contact, signal error if failure
G38.5 - probe away from workpiece, stop on loss of contact

带有此补丁的 grbl 构建为 27758 字节，而 master 为 27654 字节

G38.2+ #491
成员

@tmpvar： 感谢您的解释。我只是想澄清一下为什么我们需要添加更多探测工具。代码看起来不错而且很小，所以吃掉太多闪存应该没有任何问题。不过，在稍后集成和审查代码后，我可能会添加或更改一些内容，例如单独的消息（或没有 G38.3/.5 的消息）。

一些东西：

  • 您将永远无法摆脱探测周期中的减速。所以，我仍然无法了解 G38.4/.5 g 代码的用途。您必须首先让探头接合，这些 g 代码才能工作，这涉及到它们的运动和减速。我想我只是想知道这些 g 代码的典型用例。例如，它们的行为是否有所不同，例如在检测到探针触发时不强制进给保持，只是继续移动到目标点？
  • 当前安装的 G38.2 探测循环记录它首先检测到开关触发然后发出进给保持以减速的位置。然后是一个回拉动作，将其带回到探头触发位置（这不太正确，但当时我这样做是有意义的）。此回调可能会破坏 G38.4/.5 命令，因为它可能会重置开关。
  • 最后，大多数开关没有相同的触发点和复位点。因此，当您执行 G38.2 后执行 G38.4 时，您可能会发现这些位置并不相关。

我并不完全反对添加这些。我通常不想让刚开始使用 CNCing 的新用户感到困惑。这些探测 g 代码在它们之间非常相似，并且不能立即清楚它们的区别和用例。
G38.2+ #491

阿雪莉 评论 2014 年 9 月 16 日

查看更改
gcode.c
//案例 40： // 不支持。
//案例 50： // 不支持。
案例 20：
系统。probe_away = false ;

是否应该sys在第 985 行附近完成更改，在该行的其余错误检查完成之后？

贡献者作者
G38.2+ #491 变量 

在当前位置运行探测之前将设置正确的状态，但我推迟@chamnitwrt 状态更改在文件中的位置

G38.2+ #491
贡献者作者

我绝不是这应该如何工作的权威！我唯一的经验是使用我的一些业余爱好者级自制数控系统。

  • 您将永远无法摆脱探测周期中的减速。所以，我仍然无法了解 G38.4/.5 g 代码的用途。您必须首先让探头接合，这些 g 代码才能工作，这涉及到它们的运动和减速。

我同意，那很好。我主要担心的是工具长度的变化会影响探测循环发生的速度。如果我们可以在以合理的速度行进时触发开关，那么我们就有了执行probe_away循环的基础，可以更慢地完成循环以消除由于减速引起的超调。

我想我只是想知道这些 g 代码的典型用例。例如，它们的行为是否有所不同，例如在检测到探针触发时不强制进给保持，只是继续移动到目标点？

这是个好问题。我天真的回答是行为应该是一样的

  • 当前安装的 G38.2 探测循环记录它首先检测到开关触发然后发出进给保持以减速的位置。然后是一个回拉动作，将其带回到探头触发位置（这不太正确，但当时我这样做是有意义的）。此回调可能会破坏 G38.4/.5 命令，因为它可能会重置开关。

根据我的经验，即使在拉回之后，开关仍然被压下，将它固定到位的 1/8″ 杆仍然偏转。偏转量在较高的探测速率下更大。

我的情况（并且我敢猜测其他人）如果您退回到开关触发点，开关仍应被触发（即使开关具有完全相同的打开和关闭位置）。

不过我确实明白你的意思，并且很好奇为什么在回撤阶段后柱线仍然偏斜。

  • 最后，大多数开关没有相同的触发点和复位点。因此，当您执行 G38.2 后执行 G38.4 时，您可能会发现这些位置并不相关。

是的，这就是我所依赖的。用于38.{2,3}任意长度刀具38.{4,5}找开关，慢进给退刀找关断点
G38.2+ #491
成员

@tmpvar： 行。现在我明白你要做什么了。您希望使用 G38.2/.3 作为寻道循环，使用 G38.4/.5 作为定位循环。说得通。不过我想，我需要移除回拉动作才能使其正常工作。也许我们可以为其余的探测周期做一些类似于编译时选项的事情，这样我们就可以为新用户保持简单。这是一个可以接受的解决方案吗？

@ashelly： 是的。我想我会重写这段代码的一部分来修复这些小错误。我不认为这样问是对的@tmpvar修复 Grbl 代码的细微差别。
G38.2+ #491
贡献者作者

@chamnit编译时选项对我来说很好。另外，如果您指的是 上的回拉动作G38.{4,5}，我认为您是正确的。拉回动作G38.{2,3}看起来不错，但删除它不应该影响我的用例。

我也愿意修复这个补丁集，使其符合 grbl 风格，到目前为止这似乎只是问题所在@ashelly提及。还有其他的尼特吗？
G38.2+ #491
成员

@tmpvar: 不研究代码就很难说清楚，但有两件事突然出现。第一，我会尝试找到一种方法来删除 sys.probe_away 变量并将其移至探测循环函数。必须有一种方法可以在不添加永久变量的情况下做到这一点。其次，我可能会重新设置 probe_get_state() 函数。我一直在尝试将任何特定于引脚的调用保留为可以出于可移植性原因轻松更改或更新的函数调用。
G38.2+ #491
成员

@tmpvar: 我不确定你是否还在处理这个拉取请求。我应该等待吗？
G38.2+ #491
贡献者作者

@chamnit是的，在考虑了一下之后，我又开始尝试了。

我已经通过将sys探测模式打包到 中成功地删除了变量gc_block.modal.motion，但看起来这很容易出错/不是未来证明的变化。

为了解决这个问题，我认为uint8_t在里面的堆栈上添加一个gc_execute_line会使它更清楚一点
G38.2+ #491

tmpvar 审查 2014 年 9 月 23 日

查看更改
运动控制.c
@@ -303,7 +303,7 @@ void mc_homing_cycle()
#结尾
 
//激活步进模块中的探测监视器。
系统。probe_state = PROBE_ACTIVE;
系统。探测状态= PROBE_ACTIVE | 模式；
贡献者作者
G38.2+ #491 变量 

因为probe_get_state是从 ISR 调用的，所以我们必须将模式放在某个地方，以便我们可以传递它。这看起来和其他地方一样好，因为我们只使用了 8 的 1 位。

G38.2+ #491
贡献者作者

刚刚意识到这仍然需要在 G38.3 和 G38.5 上安装“无错误”模式
G38.2+ #491
成员

@tmpvar： 是的。我上周末开始研究它，然后才想起先问你。所以我们没有做同样的任务。（然后我被 Windows 更新地狱所困扰，试图恢复旧的 PC 笔记本电脑。）我认为“无错误”不会成为问题。探测调用之前的所有内容都应该相同。退出处理只需要避免设置警报并将存储的探头位置更新为故障位置。

根据 linuxcnc 的说法，还需要一个额外的布尔参数，用于跟踪探测是否成功。而且，这可能需要与$#视图参数一起打印。不确定如何干净利落地做到这一点并且不破坏任何 GUI（但支持它的人不多）。也许我们可以将布尔值附加到探测打印输出中$#……[PRB:0.000,0.000,0.000,1]不确定。
G38.2+ #491

我的投票：将其添加到 PRB 响应使其在正确的上下文中可用。

你不能在数学模式下使用“宏参数字符#”
$# 目前返回轴值，而不是状态值。如果/当 GUI 实现 G38 支持时，它将对其上下文中的状态感兴趣，即紧接在探测命令之后。制作 GUI 然后执行 $

# 获取状态不是很整洁。
G38.2+ #491
成员

@gerritv: 同意。我不喜欢将布尔探测参数添加到$#打印输出的前景。它在实践中并不是真正需要或重要的。我想它是否只有在您没有关于探测状态的即时反馈时才真正有用，但在这种情况下，我们可以将其作为 Grbl[]消息提供，就像当前反馈一样。也许像[PRB:Fail].
G38.2+ #491

@chamnit，这正是我为我的自动化界面所做的。我要么在好的时候得到“[PRB:]”，要么在坏的时候得到“[PRB:Not Found]”。它适用于我的用例。
G38.2+ #491

根据我所读的内容，不成功的探测会返回 0 作为点的状态和位置（我想是失败点的位置）。G38.3 和G38.5 也只是增加了一个Error 指示，否则它们分别执行与G38.2 和G38.4 相同的功能。（并不是说我已经使用过任何探测命令。尽管很快就会添加到我的 GUI 中）由于失败也可能表示错误，因此我们应该发送一个错误：子代码。允许更通用和更强大的错误处理程序。
G38.2+ #491
贡献者作者

当未触发开关时，G38.3/G38.5 的当前行为将返回原点。

grbl> G38.3 Z10 F100
?
RUN Machine(0.000, 0.000, 5.704) Work(0.000, 0.000, 5.704)
?
RUN Machine(0.000, 0.000, 7.032) Work(0.000, 0.000, 7.032)
?
RUN Machine(0.000, 0.000, 9.068) Work(0.000, 0.000, 9.068)
?
RUN Machine(0.000, 0.000, 7.272) Work(0.000, 0.000, 7.272)
?
RUN Machine(0.000, 0.000, 5.300) Work(0.000, 0.000, 5.300)
?
RUN Machine(0.000, 0.000, 2.048) Work(0.000, 0.000, 2.048)
?
RUN Machine(0.000, 0.000, 0.760) Work(0.000, 0.000, 0.760)
[PRB:0.000,0.000,0.000]

这应该在下一次提交中通过跳过 pull-off 部分来修复
G38.2+ #491
贡献者作者

功能性，减去 PRB 报告上的标记。

grbl> G38.5 X10 F1000
[PRB:10.000,0.000,0.000]
grbl> ?
IDLE Machine(10.000, 0.000, 0.000) Work(10.000, 0.000, 0.000)

我认为添加一个 bool 来跟踪成功是一个好主意，这样格式通常是相同的，这使得编写解析器时不那么令人惊讶。我确实认为应该立即返回状态，但是如果您清除了终端或其他东西，您也应该能够在$#查询中看到它
G38.2+ #491
成员

@gerritv: 我在error:第一次安装G38.2的时候争论过要不要使用这个协议，但是不太合适。oks 和指示Grblerror:是否已收到命令并正确处理以执行。探测失败是不同的。

使用 G38.2 很容易，我需要做的就是启用警报并根据 g 代码定义停止所有执行。干净简单。

G38.3/.5 有点乱，因为它有点不同。如果探测失败，发送error:将导致 GUI 停止流式传输 g 代码（如果遵循了正确的协议大纲）。GUI 无法判断是探测命令失败还是探测周期本身失败，除非跟踪错误的内容。也不是那么好。

如果 G38.3/.5 探测命令有效（响应“确定”）并且循环失败，则 GUI 应接收单独的反馈并继续流式传输 g 代码。我想如果发送了多个探测命令，然后 GUI 需要确定哪一个失败了……该死。当没有一个干净明显的解决方案时，我讨厌它。
G38.2+ #491

如果您始终将探测失败/成功状态作为 [PRB: 响应的一部分发送，则 1 部分已解决。对于 G38.2 和 G38.4，您可以额外设置 Alarm? .3 和 .5 根本不应该发送错误，只是将探测状态位设置为 0。

发送/响应的协议问题是一个普遍问题，将消息编号添加到 Gcode 数据包和 ok/error (Ack, NAK) 将使它们保持一致。但这需要 Grbl 和所有 GUI 的完全不同的实现。也许当 Arduino Zero 发布到野外时，我们可以考虑添加额外的“真实”协议。（我曾经在同步通信时代设计和实现协议，SDLC、X.25、Uniscope 和一些专有协议，我们遇到的问题很常见）
G38.2+ #491

http://www.linuxcnc.org/docs/2.4/html/gcode_main.html#sub:G38.2:-Straight-Probe
G38.2+ #491

做一些测试，尝试 G38.2 如果它失败，那么预期的响应是“ALARM：Probe fail”，但是在进行 Reset 之后，你直接进入 <Alarm, state? 我没有启用软限制，也没有触发任何限制开关。
G38.2+ #491
G38.2+ #491
贡献者作者

@gerritv你需要解锁/回家才能退出闹钟模式

grbl> ?
IDLE Machine(0.000, 0.000, 0.000) Work(0.000, 0.000, 0.000)
grbl> G38.2 X-1 F100
ALARM: Probe fail
grbl> [Reset to continue]
grbl> reset
grbl> Grbl 0.9g ['$' for help]
['$H'|'$X' to unlock]
grbl> ?
ALARM Machine(0.000, 0.000, 0.000) Work(0.000, 0.000, 0.000)
grbl> $x
[Caution: Unlocked]
grbl> ?
IDLE Machine(0.000, 0.000, 0.000) Work(0.000, 0.000, 0.000)
G38.2+ #491

我知道我需要这样做，这就是为什么我认为这是实施中的错误。这是一个错误，而不是灾难性的失败。它使 G38.2 无用或至少使用起来非常危险：如果它失败了。我失去了所有的位置，进给率等只是因为探头失败？我不完全确定这是什么@chamnit故意的。

当探头失效时，机器仍然知道它在相同的 X 和 Y 位置，它甚至知道控制点在 Z 轴上的位置。不需要强制归巢周期等？
G38.2+ #491
成员

@gerritv：目的是将故障的 G38.2 探头置于警报状态。这是 grbl 的错误机制来停止一切。gcode 标准没有明确列出应该发生什么的确切细节，但它确实说程序执行必须停止，这实际上是一个警报。从我对专业 CNC 的接触来看，警报仅用于解决从限制到简单的 g 代码错误的所有问题。这迫使用户确保他们的 g 代码程序是好的。

但是，机器位置不应丢失。在发出警报之前，探测器应该已经停止。在这些情况下，如软限制，机器位置将被保留。但是你确实提出了一个很好的观点，如果你设置了 G92 偏移和其他 g 代码模式，你确实会在 G38.2 探测失败时丢失这些。它确实使它不太有用，但在其他情况下可能很有用。这也是另一个原因@tmpvar也在推动安装 G38.3/.5，因为这些不会强制程序执行停止。我们只需要弄清楚这两个不会停止程序的g代码的错误机制。
G38.2+ #491

我理解需要停止，崩溃了几次以及刀具损坏 :-)
出于这个原因，我在我的 GUI 上实现了错误暂停，除非您非常确定代码中的代码，否则不应忽略失败的代码块文件。例如，M06 导致错误，而不是警报。

IMO 实施 .3 和 .5 的真正好消息是不需要错误或警报，只需将状态位设置为 0 而不是 1。对于 .2 和 .4，警报可以保留。这允许探测程序继续，即使它在稀薄的空气中探测，如果我正在映射模型车身以进行复制，这正是我需要它做的。
G38.2+ #491

@chamnit re: the modes being lost, if you have the preset loaded in Gbl it will apply those after the Unlock? And a Gcode program should have its required settings at the top anyway. So that doesn’t worry me either now. Thank you for clarifying the intent.
G38.2+ #491
Member

@gerritv : Hmm. I just re-read the NIST and linuxcnc definitions. I must have hallucinated the program execution stop, because I don’t see it. It just says “error is signaled”, whatever that means. I suppose I interpreted it as a program stop. Has anyone use Mach3 or linuxcnc’s probing feature? What’s it behavoir?

If we need to change the “error is signaled behavior, we may need to think about a new feedback mechanism to indicate these
喜欢 (0)