GRBL解析G代码时的单位切换（G20/G21）：操作指南

GRBL中的G20/G21单位切换：毫米与英寸的精准控制实战指南

你有没有遇到过这样的情况？明明在CAD软件里画的是25.4mm长的槽，结果CNC机床切出来只有约1mm——像被“压缩”了25倍。或者设置进给速度F1000，机器却慢得像爬行？

别急，这大概率不是机械问题，而是单位制混乱惹的祸。

在使用GRBL作为控制器的数控系统中，一个看似不起眼的指令——G20或G21，往往就是决定加工成败的关键。它不炫技、不出众，但一旦出错，后果可能是整块材料报废，甚至撞刀损坏设备。

今天我们就来深入拆解GRBL如何处理G代码中的单位切换机制，从原理到实战，彻底搞懂 G20（英寸）和 G21（毫米）到底怎么用、为什么必须用，以及那些新手最容易踩的坑。

一、G21：设定为毫米模式（Metric Mode）——现代加工的默认选择

它是什么？

G21是 RS-274 标准中定义的一个模态指令，作用是告诉 GRBL：“接下来所有的坐标值、速度参数都按毫米来理解。”

比如这条代码：

G21 G0 X10 Y5 F1000

它的含义非常明确：
- 切换到毫米单位
- 快速移动到 X=10mm, Y=5mm
- 进给速率为 1000 mm/min

整个过程清晰直观，符合绝大多数现代设计流程的习惯。

为什么推荐优先使用 G21？

1. 国际通用标准
   几乎所有主流 CAD/CAM 软件（如 Fusion 360、SolidWorks、Mastercam）默认输出单位都是毫米。

2. 精度表达更友好
   毫米体系下常用小数点后一位或两位即可精确描述尺寸（如 12.7mm），而英寸则容易出现冗长的小数（如 0.5” = 0.500”）。

3. 避免换算错误风险
   使用统一单位可减少人为转换带来的误差，尤其在团队协作或多国项目中尤为重要。

✅ 实践建议：除非明确需要兼容英制图纸，否则一律在程序开头写上G21。

二、G20：设定为英寸模式（Imperial Mode）——北美传统系统的遗留需求

它存在的意义

G20的功能正好相反：启用后，所有数值都将被解释为英寸。

例如：

G20 G1 X1.0 Y0.5 F60

表示：
- 当前单位为英寸
- 直线插补至 X=1.0 英寸（≈25.4mm）、Y=0.5 英寸（≈12.7mm）
- 进给速率 60 in/min ≈ 1524 mm/min

虽然在全球范围内逐渐式微，但在以下场景仍有实际用途：

• 北美地区的工程图纸仍广泛采用英寸标注
• 某些老版本 CAM 软件默认输出 G20
• 微小特征加工时，“mil”（千分之一英寸）单位便于表达（如 0.001”）

常见误解澄清

很多人以为G20只影响坐标的显示方式，其实不然。GRBL会在内部将所有输入值乘以 25.4 转换为毫米进行计算，因为其底层运动规划器始终以毫米为基准运行。

也就是说：
- 输入X1.0（G20 下）→ 内部当作X25.4mm
- 输入F60（G20 下）→ 自动转为F1524 mm/min

这一点至关重要，直接影响速度限制判断和脉冲生成逻辑。

三、GRBL是如何处理单位的？源码级解析

要真正掌握单位切换机制，就得看看 GRBL 内部是怎么做的。

单位处理全流程图解

[串口接收] → [词法分析] → [单位判断] → [数值缩放] → [运动规划] → [脉冲输出] ↑ (G20/G21 决定是否 ×25.4)

每一步都在parser.c和planner.c中完成。关键点如下：

1. 解析阶段：提取单词并标记单位

当 GRBL 收到一行 G代码时，会逐字符扫描，识别出诸如G,X,F等“字”（Words），然后根据当前模式决定是否缩放数值。

2. 数值转换的核心逻辑（来自 parser.c）

if (gc_state.modal.units == UNITS_INCH) { gc_values.feed_rate *= MM_PER_INCH; // 即 ×25.4 }

这段代码说明了一切：无论用户输入什么单位，最终都会被统一转换成毫米/分钟参与加减速计算。

这意味着：
- 所有运动算法（S曲线、梯形加减速）都基于毫米单位设计
- 避免因单位不同导致算法异常
- 提高系统稳定性和一致性

3. 步数配置参数始终以毫米为单位！

这是另一个极易被忽视的重点：

⚠️ 注意：这些参数永远不会自动适应英寸！即使你在 G20 模式下发送F1000，GRBL 也会先将其转换为F25400 mm/min，再与$110对比限速。

所以如果你设定了$110=3000，而在 G20 模式下发F120，实际等效于F3048 mm/min，已经超限！

四、真实开发中的典型问题与解决方案

❌ 问题一：加工尺寸缩小为 1/25.4

现象：本应走 25.4mm，结果只走了约 1mm
原因分析：
- G代码中含有G20
- 但设计意图是毫米单位
- 控制器将X25.4解释为 “25.4 英寸”，然后 ×25.4 → 被当成 645.16mm 处理？不对！

等等，这里有个反直觉的地方！

实际上，如果 G代码写的是：

G20 G0 X25.4

那么 GRBL 会认为你输入的是25.4 英寸，然后 ×25.4 → 换算成645.16mm，远大于预期！

那为什么会出现“变小”的情况？

真相往往是：
- 上位机生成的是毫米数据（如 X25.4）
- 忘记加G21，而 GRBL 当前处于 G20 状态
- 结果X25.4被当作25.4 英寸处理 → ×25.4 → 实际目标变成645.16mm
- 但由于行程受限或报警中断，电机根本没走到，看起来像是“没动”

更常见的情况是：
- 用户误以为 G20 表示“用英寸数值”，但实际上它改变了整个解释规则
- 正确做法是：确保 G代码输出单位与 G20/G21 设置一致

✅解决方法：
- 在每个 G代码文件开头强制加入G21或G20
- 使用 NC Viewer 工具预览路径长度
- 开发 HMI 时实时显示当前单位状态

❌ 问题二：进给极慢或频繁触发速度报警

现象：设置F1000，但移动缓慢；或提示“速度超限”
原因：
- 处于 G20 模式
-F1000被解释为 1000 in/min ≈ 25400 mm/min
- 若$110=3000，则严重超限，被限幅至最大允许值 → 实际运行速度仅为 3000 mm/min

你以为设置了高速，其实被系统“温柔地”压了下来。

反之，如果你在 G21 模式下设置F40，想对应 G20 下的常见值，其实是慢得离谱（仅 40 mm/min）！

✅正确做法：
- 统一使用 G21 + mm/min 单位
- 若必须使用 G20，请调整 F 值量级（如 F40 ~ F80 较合理）
- 查看$110~$112设置是否匹配单位模式下的合理范围

五、实用技巧与最佳实践

1. 强制初始化：永远不要依赖“默认状态”

GRBL 上电后的默认单位取决于编译选项，有些版本是 G21，有些可能由$I中的设置决定。

安全做法：在每段 G代码开始时显式声明单位。

% G21 ; 明确设定为毫米模式 G90 ; 绝对坐标 G17 ; XY平面选择 M3 S1000 ; 主轴启动 ... %

这样可以避免继承前一次运行的状态，防止“上次忘了改单位”的连锁错误。

2. 添加调试函数：实时查看当前单位

你可以向 GRBL 固件添加一个简单的诊断函数，用于查询当前单位模式：

void print_current_unit_mode(void) { if (sys.state != STATE_IDLE) return; if (gc_state.modal.units == UNITS_METRIC) { serial_write("[UNIT:MM]\r\n"); } else { serial_write("[UNIT:INCH]\r\n"); } }

绑定到某个自定义命令（如$U），就能通过串口工具快速确认当前状态。

3. 修改默认单位（高级用户）

如果你长期只使用毫米单位，可以在编译前修改config.h文件：

#define DEFAULT_UNIT_SYSTEM UNIT_SYSTEM_MM

这样每次上电都会自动进入 G21 模式，降低误操作概率。

4. 上位机配合：确保G代码源头正确

推荐在 CAM 软件中设置输出单位，并自动生成对应的 G20/G21 指令：

让单位声明成为自动化流程的一部分，而非手动补救措施。

六、结语：单位虽小，责任重大

G20和G21看似只是两个简单的字母组合，但在 CNC 控制系统中，它们是连接数字设计与物理制造之间的第一道门槛。

一个错误的单位设置，足以让精密加工变成灾难现场。而一个正确的G21，则是通往“所见即所得”的基石。

随着 GRBL-HAL、Smoothieware 等新一代固件的发展，未来或许会出现：
- 自动检测 G代码单位并告警
- 支持 µm、cm 等更多单位制
- 更智能的上下文感知解析

但在今天，工程师依然是最后一道防线。

所以，请记住这个简单却重要的原则：

🔧每一次运行前，都要确认：我的 G代码单位和控制器状态是否一致？

这不是多此一举，而是专业性的体现。

如果你正在开发自己的 CNC 控制界面，不妨在显眼位置加上一个动态单位指示灯——小小的 UI 改动，可能会拯救一块即将被切废的铝板。

欢迎在评论区分享你的单位踩坑经历，我们一起避坑前行。