FluidNC项目中表达式逻辑运算符OR的解析问题分析

问题背景

在FluidNC项目中，用户在使用G代码宏功能时发现了一个关于逻辑运算符的问题。当尝试在表达式中使用"OR"逻辑运算符时，系统会返回错误，而使用"AND"或"XOR"则能正常工作。这个问题影响了用户在宏中编写复杂逻辑判断的能力。

问题表现

用户在测试脚本中使用了如下代码：

o100 if[1 EQ 1 OR 0 EQ 1]
(print, hello)
o100 endif

系统返回了错误信息：

[MSG:DBG: O100IF[1EQ1OR0EQ1]]
[MSG:DBG: Bad GCode: O100IF[1EQ1OR0EQ1]]
[MSG:ERR: 173 (Expression Unknown Operator) in /sd/test.nc at line 1]

而当用户移除"OR"及后面的条件后，代码可以正常执行。

技术分析

经过代码审查，发现问题出在Expression.cpp文件中。该文件负责解析G代码中的表达式逻辑。具体问题点有两个：

1. 在read_operation函数中，对'R'字符的处理逻辑有误。当前代码将'R'作为"RR"(NotExclusiveOR)运算符的起始字符处理，而实际上应该处理'O'字符作为"OR"运算符的起始字符。

2. 在binary_ops映射表中，定义了"RR"作为Binary_NotExclusiveOr运算符的键，而没有定义标准的"OR"运算符。这个映射表虽然当前未被使用，但为了代码完整性也应修正。

解决方案

正确的实现应该：

1. 修改read_operation函数中的case语句，将'R'改为'O'，以正确处理"OR"运算符。

2. 更新binary_ops映射表，添加"OR"作为Binary_NotExclusiveOr运算符的标准键名，同时保留"RR"以保持向后兼容性。

相关数学运算问题

在问题讨论中还涉及到了变量赋值和数学运算的相关问题。经过测试发现：

1. 在print语句中不能直接进行数学运算
2. 变量赋值时需要使用方括号[]包裹数学表达式
3. 未定义的变量在print语句中会显示为#

这些行为是设计预期内的，不属于bug范畴。

总结

这个问题的核心在于表达式解析器对"OR"逻辑运算符的支持不完整。修复方案相对简单直接，只需调整字符匹配逻辑和运算符映射表即可。对于FluidNC用户来说，在修复发布前可以暂时使用"RR"替代"OR"来实现相同的逻辑功能。

该问题展示了开源固件开发中常见的边缘情况处理挑战，也提醒开发者在实现运算符解析时需要全面考虑所有可能的运算符形式和变体。