我应该补充一点，我还必须在这个块内注释掉CONTROL_RESET_BIT、CONTROL_FEED_HOLD_BIT和以获得我想要的行为，如果我不这样做，当我触发门时会出现各种古怪行为（导致警报状态）。CONTROL_CYCLE_START_BITif

我通常默认假设 grbl 是正确的，因为很多人都成功地使用了它，但我同意它看起来很奇怪并且似乎只是因为一些怪癖才起作用。与旧的 grbl 代码相比，它是倒置的

您是否还启用了 control_mask 反转？@ line 185 // #define INVERT_CONTROL_PIN_MASK CONTROL_MASK // 默认禁用。取消注释以禁用

pin 变量被 CONTROL_MASK 屏蔽，我相信这就是为什么“pin”值保持为零而不进入 if 块的原因。本质上，if 块正在检查“pin”是否大于零。

@shooter64738请看第一篇文章，我包括了INVERT_CONTROL_PIN_MASK我正在使用的参考，我做的不对吗？

是的，我看到了，但是有 2 个面具彼此相邻。我也不确定你指的是哪一个。
在进一步检查之后，pin 正在设置其位，然后如果定义了 INVERT_CONTROL_PIN_MASK，我们将第 47 行的 pin 位反转……因此 pin 应该是大于零的某个值并进入 if 块。但是然后..我们检查门位是否为 false/0..并且它不能同时为 false 和 true..

我倾向于，如果反转打开并且它将 0 切换为 1 以进入 if 块，它应该检查该位是否为真。我看到你的困惑。:)

查看这个函数的历史，Sonny Jeon 重命名并重组了一些东西，还反转了所有测试。评论说“移动（并调整）反转控制引脚掩码定义并放入 config.h，而不是 cpu_map.h 文件中。在那里更有意义。” 此更改于 2016 年 3 月 30 日进行。我不明白…

正如我提到的，我的门开关是 NC，如果我能理解的话，用计算机术语来说就是“1”或“真”。这就是为什么我把它倒过来的原因，我想如果门是开着的，我希望它是“真”的。我删除了反转并恢复了 Sonny 的更改，它现在按照我想要的方式运行。有问题的代码现在对我来说看起来像这样：

    #ifdef ENABLE_SAFETY_DOOR_INPUT_PIN
      if (bit_istrue(pin,(1<<CONTROL_SAFETY_DOOR_BIT))) { control_state |= CONTROL_PIN_INDEX_SAFETY_DOOR; }
    #endif
    if (bit_istrue(pin,(1<<CONTROL_RESET_BIT))) { control_state |= CONTROL_PIN_INDEX_RESET; }
    if (bit_istrue(pin,(1<<CONTROL_FEED_HOLD_BIT))) { control_state |= CONTROL_PIN_INDEX_FEED_HOLD; }
    if (bit_istrue(pin,(1<<CONTROL_CYCLE_START_BIT))) { control_state |= CONTROL_PIN_INDEX_CYCLE_START; }
  }

仍然对为什么我必须做出这样的改变感到困惑（以及为什么 Sonny 做出了他的改变）。

请记住，该pin变量读取端口引脚的状态。1 为高，0 为低。只要跟踪它，就很容易辨别那里的几行代码。

理解它为什么有效对我来说实际上并不重要，尽管我是一名程序员，所以我可能会为此失眠……

正如我所说，我唯一感兴趣的控制是门，所以我将其设置为cpu_map.h：

#define CONTROL_MASK ((1<<CONTROL_SAFETY_DOOR_BIT))

因为我想反转它，所以我将其设置为config.h：

#define INVERT_CONTROL_PIN_MASK ((1<<CONTROL_SAFETY_DOOR_BIT))

这是行不通的。我有了反转所有控制引脚的想法，我用这个替换了上面的内容：

#define INVERT_CONTROL_PIN_MASK ((1<<CONTROL_RESET_BIT)|(1<<CONTROL_FEED_HOLD_BIT)|(1<<CONTROL_CYCLE_START_BIT)|(1<<CONTROL_SAFETY_DOOR_BIT))

这可以按预期工作，尽管肯定不直观。我不明白，但无论如何，它正在工作。谢谢。

@dastultz： 等待。如果理解它的工作原理对您来说并不重要，那么在 2016 年 3 月 30 日的拉取请求中跟踪一个小的代码更改并发布这个问题有什么意义：“ chamnit 你能在这里解释逻辑反转的原因吗（bit_istrue 到 bit_isfalse）？ ”

为了再次明确说明，bit_isfalse()更改是为了代码简洁。更具体地说，它消除了在时间关键的引脚更改中断中反转整个引脚变量的需要，并节省了几个字节的闪存（对于某些关键配置，328p 上实际上还剩下 100 个字节）。

此外，请记住，Grbl 还必须支持反转引脚状态，其中引脚可以反转为正常低电平并触发引脚高电平，而不是触发正常高电平和引脚低电平。在这种情况下，bit_false()根据您的定义， the 现在可以解释为“正确”。事实上，bit_isfalse()检查并没有明确表示触发或未触发。这是模棱两可的。它不询问引脚是否被触发。它只是检查 pin 变量的位是否为假。

老实说，我真的不明白几行紧凑的代码有什么大惊小怪的。像这样的代码在科学研究中很常见（我的背景）。您一直在尝试平衡优化性能和可读性。对我来说，如果您花时间了解 pin 变量获取端口上的 pin 状态并且您可能有不同的触发状态，那么这段代码就非常清楚了。

我要求解释，以便它可以帮助我了解如何配置我的设置。我应该寻求更直接的帮助，对此感到抱歉。GRBL 是一款很棒的产品，我对它的出色表现感到惊讶。谢谢你。我不是出色的 C 程序员，也不是出色的微控制器程序员。但我是一个优秀的程序员。在其上下文之外简单地查看有问题的块，这就是我看到它的方式（简化代码）：

 if (pin) {
      if (bit_istrue(bit_1)) { do_a_thing }
      if (bit_istrue(bit_2)) { do_a_different_thing }
      if (bit_istrue(bit_3)) { do_yet_another_thing }
  }

我认为if (pin)这是一种优化。我们对许多引脚的真实状态感兴趣。如果没有任何引脚为真，则无需测试每个引脚。代码更改为：

 if (pin) {
      if (bit_isfalse(bit_1)) { do_a_thing }
      if (bit_isfalse(bit_2)) { do_a_different_thing }
      if (bit_isfalse(bit_3)) { do_yet_another_thing }
  }

现在我们对引脚的假状态感兴趣。为什么我们应该要求至少有一个 pin 为真才能进入区块？如果所有的引脚都是假的，我们应该采取所有的行动，但我们不会采取任何行动，因为if (pin)。所以我认为这if (pin)不再是逻辑优化。为了让它工作，我被迫配置我不感兴趣的引脚。

对不起，如果我冒犯了。