@109JB：这是设置归位的一般程序。我真的需要为此写一个 Wiki，因为这个问题每个月都会出现几次。

• 首先，确保您的坐标系和轴在其中正确移动。否则，接下来的一切都会变得一团糟。传统上，如果您站在机器前，Y+ 是工具相对于工作区域远离您，Z+ 向上，X+ 是工具相对于工作区域向右移动。如果你用谷歌搜索，有很多关于 CNC 坐标系的资源。
• 其次，确保您的限位开关接线正确。默认情况下，Grbl 需要连接到 GND 的常开限位开关。这意味着当关闭时，引脚变低。打开时，引脚为高电平。在引脚处测量这些。如果相反，要么反转限位开关设置以解决反向逻辑，要么重新正确接线。
• 第三，Grbl 指向所有轴的正方向。查看坐标系参考以查看 Grbl 是否归位到正确的方向以及您的限位开关是否位于正确的位置。如果不是，并且您需要在负方向上进行 Grbl 搜索，那就是您使用归位方向反转掩码的时候。
• 最后，Grbl 会将整个机器坐标系设置在负空间中。这是传统的。因此，原点将位于机器的 X+、Y+、Z+ 大部分，而机器体积限制为 (-Xmax、-Ymax、-Zmax) 行程。

感谢您的快速回复。解决您的意见。

1- 轴都正确移动，需要设置 $3=2
2- 限位开关接线正确。我已经反转了引脚，因为我的开关是通过分线板​​操作的，并且分线板在激活开关时将引脚设置为高电平。我已经在 GRBL 中对此进行了测试，如果开关被激活，它会在 GRBL 内正确运行并发出警报信号。
3- 正如我所说，奇怪的是，由于我的 z 限制处于最大 z 正值，所以我不得不反转归位方向以使轴在归位时移动正确的方向。归位方向设置为 $23=6，这与我的预期完全相反。但是，当开始归位时，所有轴最初都会正确移动。
4-我什至不能走到这一步，因为在找到开关后，GRBL 正朝着错误的方向移动。

@109JB: 听起来你的限位开关没有按照你想象的方式接线。Grbl 的硬限制会在任何引脚更改时发出警报（出于多种原因，我不会讨论），因此您的限制开关测试没有定论。如果您的 z 轴设置正确以进行正常操作，那么 Grbl 应该朝正方向移动，而不是负方向。那是除非你的限位开关是相反的。这不是第一次有人犯这种错误。

我向你保证轴在正确的方向上移动。我不是CNC机器的新手，无论是生产机器还是DIY，也不是新机器。它已经在 LinuxCNC 上运行多年。Homing 在这种配置下也已经在 LinuxCNC 上工作多年，并在尝试使用 GRBL 之前和之后使用 LinuxCNC 进行了测试。

当我发出 G91X0Z1 命令时，头部向上移动确认 z 方向移动是正确的。当头部一直向上移动时，限位开关被激活。

开关在 GRBL 中正常工作，通过向开关移动的归位运动确认，开关激活，轴稍微反转，再次前进以切换，重复，然后当应该发生拉断时，它会靠近到开关。

如果需要，我可以提供视频，但我非常确定轴在正确的方向移动，并且开关正在工作并被 GRBL 检测到。

@109JB: 明白了。验证我的想法的一种方法是更改​​归位搜索率。您应该看到归位搜索速度没有变化。如果您更改归位进给率，您应该会看到速度发生变化。当一切正常时，您应该看到相反的情况。

Grbl 的归巢程序相当愚蠢。它只会移动一次搜索/搜索速度。当它检测到开关时，它会以归位进给/定位速度执行以下所有移动。如果开关没有像你想象的那样工作，Grbl 会立即检测到触发开关并进入定位模式。

让我知道你发现了什么。如果这确实是 Grbl 端的问题，我将确保明天查看代码。无论哪种方式，我都在我的待办事项列表中限制了定位周期的行程，这样这种类型的混乱就不会再次发生。就像我说的，这种情况不止一次发生过，一位用户的所有接线都正确，但开关本身有故障。他不得不把它打开才能看到上面贴着与开关操作相反的标签。

@109JB: 另外，帮我一个忙，把$$设置和$I构建信息字符串发给你。如果代码确实有问题，这将有助于诊断问题。刚才我还在搞乱归巢周期，但不应该有任何改变会使事情出错。

我刚从店里进来。不幸的是那里还没有互联网，所以我只能在家里发帖。

仅供参考，我将我的 GRBL Arduino 连接到一个 DB25 连接器，以便 GRBL 与作为机器系统一部分的分线板通信。以这种方式设置我可以在 GRBL 和 LinuxCNC 之间来回切换，只需拔下 GRBL 的 DB25 并插入 LinuxCNC 机器上的 paraport。

在商店外时，我重新连接了 LinuxCNC 并确认一切仍在该设置上运行，确实如此。LinuxCNC 归位按预期工作。我慢跑了几分钟检查所有的轴。最后，在关闭 LinuxCNC 之前，我将机器轴在每个轴上移动了几英寸。

我想确保我使用的 GUI（通用 G 代码发送器）不是罪魁祸首，所以我使用 Arduino IDE 串行监视器执行了以下操作：

然后我切换回 GRBL 并启动机器。我重置 GRBL 只是为了确保 GRBL 已重新加载所有设置。我早些时候将 $23 设置恢复为 $23=1，以反映 Z 限制为 Z+，X 极限为 X-，Y 限制为 Y+，因为机器已设置并且 WIKI 描述了 $23 设置。重置后，我输入 $X 解锁机器，然后输入 G20 设置英寸单位。然后我键入 G91G0Z1，头部按预期向上移动了 1 英寸。我对 X 轴和 Y 轴进行了同样的操作，以确认它们的运动方向。然后我输入 $H 启动归位序列，头部开始向下移动。由于头部应该向上移动并且向下方向没有开关，所以我关闭了步进驱动器的电源以在机器崩溃之前停止机器运动。

下面是请求的 $$ 和 $I 信息，它们导致 Z 轴在归位时移动 Z-。下面的所有速度值都是从 linuxCNC 设置的速度值转换而来的。在 LinuxCNC 中，我的最大轴速度为 3.0 英寸/秒（180 IPM），归位进给率为 1.5 英寸/秒（90 IPM）。我确实尝试使用默认归位进给率在 GRBL 中归位，寻位速度分别为 50 和 635 毫米/分钟。结果与 Z 轴在错误方向上移动的结果相同。在归位期间。

此外，虽然我现在并不担心，但我确实发现我必须从 linuxCNC 设置中降低轴的加速度值。在 LinuxCNC 中，我在所有轴上的加速度都是 20 in/sec^2，应该等于 508 mm/sec^2，但是除非我将 GRBL 中的加速度降低到 175 mm/sec^2，否则我会遇到电机失速。

**** 连接到 COM3 @ 115200 波特 ****

Grbl 0.9i [‘$’寻求帮助]
[‘$H’|’$X’解锁]

$$
$0=3 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=2 (dir port invert mask:00000010)
$4=1 (step enable invert , bool)
$5=1 (limit pins invert, bool)
$6=1 (probe pin invert, bool)
$10=15 (status report mask:00001111)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm )
$13=1 (报告英寸, bool)
$20=0 (软限制, bool)
$21=1 (硬限制, bool)
$22=1 (归位周期, bool)
$23=1 (归位方向反转掩码:00000001)
$24= 1000.000（归位进给，毫米/分钟）
$25=2300.000（归位寻道，毫米/分钟）
$26=250（归位去抖动，毫秒）
$27=1.000（归位牵引，mm）
$100=314.961（x，步长/mm）
$101=314.961（y，步长/mm）
$102=314.961（z，步长/mm）
$110=4572.000（x 最大速度，mm /min)
$111=4572.000 (y max rate, mm/min)
$112=4572.000 (z max rate, mm/min)
$120=175.000 (x accel, mm/sec^2)
$121=175.000 (y accel, mm/sec [
_
_
_
_
_
_
_ 0.9i.20150315:]
好的

@109JB: 感谢您提供设置信息。今天晚些时候我会在我的测试设置上检查这个。

同时，您是否能够检查更改$25设置是否会改变您首先看到的归位速度？正如我之前所说，这应该有助于验证我对因果关系的怀疑。

此外，您可以在 config.h 中启用 LIMIT_STATE_REPORTING（重新编译和上传）。这将导致 Grbl 在其“？”中发送回极限状态。形式的状态报告Lim:010，其中 010 是 X（低）、Y（高）、Z（低）。GUI 不支持这个并且可能会崩溃，所以在使用这个调试功能时最好使用终端程序。

@109JB: 另外，至于你对加速的关注，我觉得你可以直接比较 Grbl 和 LinuxCNC 真是太好了！我从来没有时间深入检查性能差异。虽然，我听到过各种各样的报道。一方面，我听说 Grbl 在高速加工刀具路径上运行得更好，LinuxCNC 上的相同刀具路径会导致刀具过热和断裂。

这是我第一次听说加速。我很确定 Grbl 和 LinuxCNC 以不同方式处理加速和步骤生成，所以它可能与此有关。您可以为更快的机器调整一些配置参数。在 config.h 中，尝试将 ACCELERATION_TICKS_PER_SECOND 更改为 150 之类的值。您还需要取消注释 SEGMENT_BUFFER_SIZE 并将其增加到 8 之类的值。这样做将有助于平滑高加速度机器的加速斜坡。让我知道是否有任何区别。

@109JB: 好的，我花时间上传了新版本的 Grbl 并上传了您的设置。这应该是同类比较，因为 Arduino 是标准化的。没有什么不寻常的。一切正常。

再一次，如果我猜到底出了什么问题，那就是限位开关或限位开关和 Grbl 之间的接线/电子设备。请记住，Arduino 是裸机电子产品，可能比缓冲良好的 PC 端口对外部影响更敏感。您必须连接通常不会连接的东西，而奇怪的事情确实会发生。

今天大部分时间我都不在家，但确实有机会完成您的要求。

更改 $25 确实会更改归位时的初始移动速度。我尝试了许多不同的速度，但我认为不是这样。

我查看了 config.h，里面没有“LIMIT_STATE_REPORTING”，但我认为你指的是我未评论的“#define REPORT_LIMIT_PIN_STATE”。我跑了？多次查询，但我始终无法获得限制报告。状态行上打印的所有内容都是 Lim：如下面的剪切和粘贴所示。我什至通过更改 $5=0 并拔下 DB25 电缆进行了尝试，该电缆应该具有高限值的引脚，但状态查询中仍然没有显示任何内容。这是在警报中尝试的，如下所示，并且单个轴在极限上，所有轴都超出了它们的极限，在解锁模式下，等等。我尝试的任何事情都不会给状态查询提供任何结果。这是状态报告的示例（必须从状态行中删除左箭头，以便查询显示在这里）。

Grbl 0.9i [‘$’寻求帮助]
[‘$H’|’$X’解锁]
Alarm,MPos:0.0000,0.0000,0.0000,WPos:-8.0074,10.8974,15.0111,Buf:0,RX:1,林：>
好的

我还重新下载了 GRBL 并替换了我计算机上的所有 GRBL 文件，以防万一它是损坏的下载或类似的东西，但结果是一样的。

话虽如此，我认为真正的问题是归位时的轴在 $23=1 时在错误的方向上进行初始移动。如前所述，我的限位开关位于 Z+、X- 和 Y+，因此 $23 应该 =1。我终究无法弄清楚这是为什么。我已经多次确认轴在正确的方向上移动。我整理了一段视频，展示了正在发生的事情。该视频集中在 Z 轴上，因为它首先归位，但我发现要使运动朝正确的方向移动，我需要 $23=6，这与 $23=1 正好相反。我认为这是问题的症结所在。

请观看下面链接中的视频，我想您会更好地理解我在说什么。

http://youtu.be/iaKg6DeArz8

@109JB: 确实很奇怪。感谢您发布视频。我找到了限制引脚报告不起作用的问题。我会在几分钟后发布。但是，这不应该影响归巢周期的工作方式。我不明白的是为什么它可以在裸机 Arduino Uno 而不是您的机器上运行。我不记得你是否告诉过我，但是你如何将 Grbl 上传到你的 Arduino？

我使用 Arduino IDE V1.6.1 上传。我使用的方法如WIKI中所述，选择Examples | 杂音 | grbl 上传。我认为这不重要，但我为此使用的是 Arduino Nano 而不是 Uno。

@109JB：Nano 应该无关紧要，但我会订购一个，以便手头有一个进行测试。不过问题是，您的视频显示了 LinuxCNC 归位。当它这样做时，我看到 Z 首先回到正方向，然后是 X 正方向，然后是 Y 负方向。但是，您的第一篇文章说 X 开关为负，Y 开关为正。为什么会出现差异？打字错误？

没问题。很多人对此感到困惑，但这只是我的偏好。我在生产环境中的立式加工中心工作了几年。在那些特定的生产机器上，+X 时工作台向右移动，+Y 时工作台向右移动。仍然是右手坐标系，只是 XY 平面绕 Z 轴旋转 180 度。这是我以前的经验所习惯的，所以我以这种方式设置我的机器。

@109JB: 所以，我昨晚花了很多时间审查代码并测试它。我看不到任何会导致此问题的代码。我认为我们必须排除 Arduino Nano 或您的电气连接是否有问题。我建议你从 Arduino 上拔下除 USB 线以外的所有东西。针对这些情况监控 Z 方向 (D7) 和 Z 限制 (D12) 引脚。您需要将 Z 限位连接到 GND 或将 NC 开关接地以模拟您的限位开关，因为您已经在设置中反转了它们。

我们需要寻找的主要问题是 Z 方向引脚是否针对正常G91G0Z1移动和 Z 轴归位循环的开始设置正确，您会发现它以错误的方式移动。

好消息。我能够按照您的建议进行一些测试，他们向我指出了我认为是非常简单的解决方案。只需将 $5=1 更改为 $5=0 即可使其正常工作。这让我相信分线板并没有像我认为的那样工作。虽然分线板向 DB25 的限位引脚发送了一个 5V 信号，但它必须简单地将其接地，本质上使其像 NO 开关一样工作。

我在测试期间看到的情况是，在 Z 方向和地面上用一个连接到 Arduino 引脚的仪表进行测试时，引脚为 0V 以进行 +Z 移动。在没有任何其他引脚连接的情况下，如果 $5=0，无论发送 $H 命令之前的引脚状态如何，引脚在归位时都保持在 0V。在 $5=1 的情况下，我执行了一个 -Z 移动，将 Z-dir 引脚设置为 +5V。启动 $h 导致引脚变为 0V，然后很快回到 5V。所以，我相信在归巢期间，例程设置为 +Z，但立即检测到跳闸限制并反转为 -Z。

然而，如果上述情况属实，当机器远离所有限制时，销应该打开。如果 $5=1，GRBL 应该将此视为跳闸限制，并在我使用 MDI 输入时随时发出警报。正如您在视频中看到的那样，即使 $5=1..，我也能够毫无问题地进行 MDI。

我对此不确定，我想做更多测试。不幸的是，我必须出城几天工作，在我回来之前无法进行更多测试。

请保持这个问题开放，直到我有机会做这个检查，我应该能够在我回来后快速完成。

谢谢你的帮助。

@109JB: 感谢您的更新，我很高兴您能够诊断出问题。

至于缺少硬限制检查，您确实提出了一个很好的观点。当 Grbl 启动时没有一个，因为它只会让 Grbl 进入一个连续的冻结重置循环。但是，我认为如果只有当你关闭$X警报时才进行硬限制检查，那应该涵盖所有场景。我会将其添加到我的待办事项列表中，以帮助立即诊断像您这样的问题。

在重新阅读了一些东西之后，听起来限制是通过寻找引脚上的状态变化而不是特定的引脚状态来工作的。这样对吗？只是想了解逻辑是如何工作的。

@109JB：在归位期间，Grbl 检查引脚的实际状态。在正常操作期间，硬限制会在检测到任何引脚变化时触发，因为弹跳开关极有可能导致状态检查误读引脚。如果用户愿意，可以在 config.h 中禁用此行为，但不建议这样做，除非他们可以保证过滤良好的开关行为。

@chamnit：“我认为，如果仅当您 $X 关闭警报时才进行硬限制检查，那应该涵盖所有情况。我会将其添加到我的待办事项列表中，以帮助立即诊断像您这样的问题。”

我不同意在解锁 grbl 时检查限制。许多人（包括我自己）在机器崩溃时使用 $X 自动将机器移出极限（假设每个轴有 1 个限位开关和软限位）。当 $X 发生时，我投票不添加硬限制检查，因为这可以防止机器自动崩溃。

我们添加到我们的 Grbl 机器的 Uncrash 代码： –
重置连接-
解锁机器
-移动 XYZ -1，-1，-1 以超出限制 –
如果 Grbl 在限位开关状态更改时抛出错误，请重置（它并不总是做这个）
-Home

@doppelhub： 是的。你是对的。Grbl 的状态机变得相当复杂，因此像这样的过度关注可能会更加普遍。我们必须想出一个替代解决方案。

我限制检测的替代解决方案是用步进 ISR 中的快速检查替换变化中的 ISR。我的想法是，如果您在每一步之前检查限制，即使使用非常有弹性的开关，您也不会超过限制几步。在实践中，这工作得很好，尽管我没有在各种传感器上进行测试。

我用以下代码替换了 stepper.c 中清除轴锁的行：

  uint8_t must_stop = ((LIMIT_PIN^limits.expected)&limits.active);
  if (must_stop) {
    st.step_outbits &= ~limits_stop_axes(must_stop);
    }

limits_stop_axes ISR 中的警报检查在哪里，并返回受限轴的 stepbits 掩码。限制控制逻辑变得更容易，因为我可以根据需要设置expected值和active引脚。它还消除了对limits_go_home. 如果这对您有用，我可以提出拉取请求。

@ashelly: 好主意，尤其是限制检查例程的简化。但如果我没记错的话，我在归位例程中进行了严格的检查循环，因为它会在 ISR 的一侧更新归位锁定掩码。这在理论上应该允许它保持为非易失性变量并且只能由主程序写入。我从来没有检查过这是否真的是真的。

以为我会更新并发表评论。

我检查了我的分线板，我确实错了它的工作原理。这就是归巢的问题。与 GRBL 无关。

至于整个解锁和即使不回家也保持解锁，我不同意这一点。应读取开关状态并显示警报。至于能够关闭跳闸开关，有一些方法可以在不让机器无限期解锁的情况下做到这一点。也许将机器解锁一段时间（最多 10 秒到 1 分钟）将留出足够的时间来关闭跳闸开关，然后机器可以归位。LinuxCNC 解锁后允许一招。无限期地保持解锁状态可能会出现问题。例如，如果开关仅安装在轴的一端，可以解锁并在未归位、解锁状态下运行机器，然后机器可能会突然硬停。这可能会发生，因为如果它没有正确归位，机器就不会“ 不知道它在哪里，软限制毫无意义。在某些机器上，如果碰撞没有足够的能量或电机功率来造成损坏，这可能不是什么大问题，但在许多机器上，它可能会破坏某些东西。

@109JB： 感谢更新。解锁后的单一动作是个好主意，也很容易实现。我会将其添加到待办事项列表中作为调查对象。我必须确保通信协议和破坏某些东西没有任何其他影响。看样子，应该不会。