三菱PLC FB模块：从积木到乐高的结构化编程实战-平芜编程栈

1. 从“积木”到“乐高”：为什么FB模块是PLC编程的分水岭

如果你已经跟着三菱PLC的学习路径，从梯形图的基本指令玩到了定时器、计数器，甚至开始用一些简单的子程序，那你可能会觉得，编程不就是把一堆逻辑块堆起来吗？这就像用积木搭房子，一块一块往上垒，也能搭出个样子来。但当你开始接触稍微复杂点的项目，比如一条有十几个工位的流水线，或者一个需要协调多个执行机构的设备，你就会发现，用“积木”思维写的程序，维护起来简直是噩梦——改一个地方，可能牵一发动全身，查个故障得在几千行程序里大海捞针。

这时，FB模块就该登场了。你可以把它理解为乐高里的“功能组件”，比如一个完整的车轮组、一个带门窗的墙壁模块。在PLC编程里，FB（Function Block，功能块）就是这样一个预定义好的、封装了特定功能的“黑盒子”。你不需要关心盒子里面复杂的齿轮是怎么咬合的，你只需要知道：给它几个输入信号（比如“启动”、“速度设定”），它就能稳定地输出你想要的结果（比如“电机正转”、“当前转速”）。这次，我们就来彻底搞懂三菱PLC里的这个“乐高”神器——FB模块，它绝不仅仅是子程序的升级版，而是一种工程思维的跃迁。

对于工控新手来说，理解FB是摆脱“接线工”式编程、迈向结构化、可复用编程的关键一步。而对于有经验的工程师，深入掌握FB的封装、参数化和多重实例化，则是提升代码质量、实现快速开发和降低维护成本的核心技能。我们不仅会讲清楚FB是什么，更会通过对比、实例和踩坑经验，让你明白它“为什么”要这么用，以及在实际项目中“如何”用好它。

2. FB模块的本质：封装、复用与数据隔离

要理解FB，首先要把它和我们已经熟悉的两种东西划清界限：普通梯形图程序和子程序（Subroutine）。

想象一下，你要控制一台电机的启停和调速。用普通梯形图写，你会把启动按钮、停止按钮、过载信号、接触器线圈、频率设定等所有的触点、线圈和功能指令都铺在主程序里。如果产线上有10台相同的电机，你就得把这套逻辑复制粘贴10遍。这会导致程序冗长，且任何修改都需要重复10次，极易出错。

子程序前进了一步，它把这段逻辑打包成一个独立的“过程”，在主程序里用CALL指令来调用。这解决了代码复用的问题，但有一个致命的缺陷：数据是全局共享的。所有电机都操作同一组内部继电器（M）和数据寄存器（D）。为了让10台电机独立工作，你必须在调用子程序前，手动把每台电机的实际输入/输出点（X, Y）和参数赋值给这些全局变量，调用后再把结果传回去。这个过程繁琐且容易混淆，本质上还是在“裸奔”地操作数据。

而FB模块的核心突破在于“实例化”和“数据封装”。

实例化（Instance）：你可以把FB理解为一个“电机控制”的图纸或模具。每次你需要控制一台电机时，就用这个模具“实例化”出一个具体的、独立的对象，比如Motor_FB_1、Motor_FB_2。每个实例都拥有自己独立的一套内部数据存储区，互不干扰。
数据封装： FB有明确的接口，分为输入（IN）、输出（OUT）和输入输出（IN_OUT）。内部使用的变量（临时变量、静态变量）对外是不可见的。这就好比一个黑盒子，你通过插头（输入）给它供电和信号，它通过插座（输出）给你反馈，盒子内部怎么工作的，主程序不需要也不应该关心。

一个生动的类比：

普通梯形图：自己从零开始造一辆自行车，每个零件自己组装。
子程序：有一个“组装自行车”的说明书，但所有工具和零件都堆在公共工作台上，每次组装前要自己去认领零件，装完再放回去，容易拿错。
FB模块：有一个“自行车组装套件”盒子，里面零件、工具一应俱全。你需要几辆自行车，就买几个套件盒。每个盒子独立工作，互不干扰。

在三菱的编程软件（如GX Works2, GX Works3）中，FB通常使用ST（结构化文本）语言或梯形图（LD）在FB编辑器中编写。ST语言因其更接近高级编程语言，在描述复杂逻辑、数学运算和流程控制时比梯形图更清晰、紧凑，因此成为编写FB的首选。这也是为什么学习FB常常和接触ST语言同步进行的原因。

3. 手把手创建你的第一个FB：一个带报警的电机控制块

理论说再多，不如动手做一遍。我们以创建一个最经典的“电机启停控制带报警反馈”FB为例，在三菱GX Works3软件中走一遍全流程。这个FB将封装以下功能：启动、停止、故障复位输入；运行、故障、就绪输出；以及内置的故障检测逻辑（如过载、超时）。

3.1 环境准备与FB创建

首先，确保你使用的是支持FB编程的软件和三菱PLC系列（如FX5U, iQ-R, L系列等）。GX Works2对FB的支持有限，更推荐使用GX Works3。

新建工程：打开GX Works3，选择对应的PLC型号（例如FX5UJ），编程语言选择“结构化工程”（这是使用FB的前提）。
创建FB：在左侧工程树中的“程序部件”上右键，选择“新建数据” -> “功能块(FB)”。给它起个直观的名字，比如Motor_Control。语言可以选择“结构化文本(ST)”或“梯形图”。这里我们选择ST，因为它更适合FB逻辑的表述。
定义接口变量：这是最关键的一步，决定了FB的“插座”长什么样。在FB编辑器的“变量声明”区，我们需要定义三类变量：
- 输入(IN)：
  - xStart(BOOL): 启动按钮
  - xStop(BOOL): 停止按钮
  - xReset(BOOL): 故障复位按钮
  - xOverload(BOOL): 过载传感器信号
  - tMotorRunTime(TIME): 电机允许运行的最长时间（用于超时报警）
- 输出(OUT)：
  - yRun(BOOL): 运行状态输出（可连接至接触器或指示灯）
  - yFault(BOOL): 综合故障报警输出
  - yReady(BOOL): 设备就绪输出（无故障时）
- 内部变量：
  - ton_RunTimer(TON): 一个通电延时定时器实例，用于测量运行时间。
  - bInternalFault(BOOL): 内部故障锁存位。
  - rRunTime(TIME): 实际运行时间。

注意：在ST语言中，定时器、计数器都需要被声明为对应的功能块类型（如TON,TOF,CTU），并在FB中实例化。这是与梯形图中直接使用T0 K100这种形式最大的不同，体现了更强的结构化特性。

3.2 用ST语言编写FB内部逻辑

在FB的“程序本体”部分，我们用ST语言编写逻辑。代码清晰易读，如下所示：

// 电机控制FB逻辑 (ST语言) // 1. 故障检测与锁存逻辑 IF xOverload THEN bInternalFault := TRUE; // 过载触发故障 END_IF; // 超时检测：使用TON定时器 ton_RunTimer(IN:=yRun, PT:=tMotorRunTime); IF ton_RunTimer.Q THEN // 如果定时器到时 bInternalFault := TRUE; // 运行超时触发故障 END_IF; // 故障复位逻辑（优先于故障触发） IF xReset THEN bInternalFault := FALSE; ton_RunTimer(IN:=FALSE); // 复位定时器 END_IF; // 2. 启停控制逻辑（在无故障条件下） IF NOT bInternalFault THEN yReady := TRUE; // 无故障，设备就绪 // 标准的启保停电路逻辑 yRun := (xStart OR yRun) AND NOT xStop; ELSE yReady := FALSE; yRun := FALSE; // 有故障，强制停止运行 END_IF; // 3. 故障输出 yFault := bInternalFault;

这段代码做了三件事：

故障检测：持续监测过载信号和运行超时（使用TON定时器功能块），一旦发生即锁存故障状态bInternalFault。
启停核心：在无故障时，实现一个标准的“启-保-停”逻辑。有故障时，强制停止运行。
状态输出：根据内部状态，输出运行、就绪和故障信号。

3.3 在主程序中调用与实例化FB

FB创建好后，它只是一个“模板”。我们需要在主程序（如MAIN）中为每一台实际的电机创建其实例。

打开主程序：在工程树中打开主程序（通常是POU）。
调用FB：在梯形图或ST编辑器中，你可以像插入一个指令盒一样插入FB。在GX Works3的梯形图中，点击“工具”箱中的“功能块”，找到你创建的Motor_Control，拖拽到编辑区。
实例化与连线：这时会弹出一个对话框，让你输入“实例名”。这是关键！你必须为每个物理电机分配一个唯一的实例名，例如Motor1,Motor2。软件会自动为这个实例在后台分配独立的数据存储区。然后，将实际的PLC输入输出点（如X1,Y10）和常数连接到FB的输入输出引脚上。

一个调用Motor1实例的梯形图示意：

[Motor_Control Instance: Motor1] | EN | X1 ---|xStart |--- yRun --- Y10 X2 ---|xStop |--- yFault -- Y11 X3 ---|xReset |--- yReady -- Y12 X4 ---|xOverld| T#5S -|tMotorT|

为什么必须实例化？如果不实例化，或者多个地方共用同一个实例名，就会导致数据冲突，所有电机状态会乱套。实例化是FB实现数据隔离和多复用的技术基础。

4. FB高级应用与实战技巧：参数化与多重实例

当你掌握了创建和调用单个FB后，我们可以探讨更高级的用法，这能让你的代码威力倍增。

4.1 参数化设计：让FB更灵活

上面的FB中，超时时间tMotorRunTime是作为一个输入变量设定的。这本身就是一种简单的参数化。我们可以更进一步。

假设有的电机需要速度控制，有的不需要。我们可以在FB接口增加一个eMode（枚举类型）输入，和对应的rSetSpeed（实数）输入。

// 在变量声明中增加 VAR_INPUT eMode: (Manual, AutoSpeed); rSetSpeed: REAL; END_VAR // 在逻辑中 CASE eMode OF Manual: // 原有启停逻辑 AutoSpeed: // 复杂的调速逻辑，使用rSetSpeed END_CASE;

这样，同一个FB就能适应两种不同控制模式的电机，只需在调用时传入不同的参数即可。这种设计极大地提高了FB的通用性。

4.2 多重实例化与数组化调用：管理大量同类设备

这是FB在产线应用中最大的优势所在。假设一条流水线有20个相同的工位，每个工位都有一个电机和一个气缸。

创建工位FB：你可以创建一个Station_FB，内部实例化一个Motor_ControlFB和一个Cylinder_ControlFB（假设已创建），并协调两者的动作。
在主程序中用数组管理：在主程序中，你可以声明一个Station_FB类型的数组。
```
// 在主程序的变量声明中 VAR arrStations: ARRAY[1..20] OF Station_FB; END_VAR
```

循环调用：利用ST语言的FOR循环，可以简洁地处理所有工位。

FOR i:=1 TO 20 DO arrStations[i]( xStart := xStartButtons[i], xSensor := xSensorFeedback[i], // ... 连接其他IO ... yRun := yMotorOutputs[i], yExtend := yCylinderOutputs[i] ); END_FOR;

这样一来，你只需要编写和调试一次Station_FB的逻辑，就能管理20个工位。新增或减少工位，只需修改数组上下限和IO映射，核心逻辑无需变动。这是传统梯形图编程难以企及的效率。

4.3 FB与全局变量、标签的协作

在结构化工程中，三菱推荐使用标签（Tag）来代替传统的软元件地址（如M0, D100）。标签具有更直观的名字和数据类型。

FB内部：应尽量使用局部变量和输入输出变量，避免直接引用全局标签或软元件地址，以保证FB的独立性和可移植性。
FB与外部交互：所有数据交换都通过FB的接口（IN, OUT）进行。主程序将全局标签连接到FB实例的引脚上。
FB间通信：如果需要多个FB协作，最佳实践是通过主程序“中转”，或者将一个FB的输出作为另一个FB的输入进行连接，而不是让FB直接读写对方的内部变量或全局数据。

这种“高内聚、低耦合”的设计，是构建大型、稳定PLC程序的基石。

5. 避坑指南：FB开发与使用中的常见陷阱

FB功能强大，但使用不当也会带来新的问题。下面是我在实际项目中总结的几个关键坑点。

5.1 实例数据丢失与保持性设置

问题现象： PLC断电再上电后，所有电机的运行状态、故障锁存都清零了，设备无法保持断电前的状态。

根因分析： FB内部使用的变量，默认是“非保持性”的。PLC断电后，这些变量的值会丢失。例如，我们例子中的bInternalFault（故障锁存位）和ton_RunTimer的当前时间值。

解决方案：

声明保持性变量：在FB的变量声明中，对于需要断电保持的变量（如故障状态、累计运行时间），可以将其属性设置为RETAIN。
```
VAR RETAIN bInternalFault: BOOL; rTotalRunTime: TIME; END_VAR
```
注意定时器/计数器：TON等定时器功能块本身内部的ET（当前时间）是非保持的。如果需要保持，通常的做法是在FB中用一个RETAIN的TIME类型变量，在每次定时器运行时，将这个变量赋值给定时器的PT（预设值）虽然不直接，但更常见的做法是，在PLC启动时，通过初始化逻辑判断是否需要恢复定时器的状态。对于简单的故障锁存，直接用RETAIN布尔变量更可靠。
权衡使用：不是所有变量都需要保持。过多使用保持变量会占用PLC的电池备份区，且可能导致设备上电后处于不预期的历史状态。通常只对重要的工艺状态、累计量进行保持。

5.2 扫描周期与FB执行顺序引发的逻辑错误

问题现象：在同一个扫描周期内，电机A的FB输出状态，希望作为电机B的FB启动条件。但实际运行时发现B有时能启动，有时不能，行为不稳定。

根因分析： PLC程序是顺序扫描执行的。如果电机A的FB实例在程序中被调用的位置晚于电机B的FB实例，那么在本次扫描周期内，当执行到B的FB时，读取的A的输出状态是上一个扫描周期的旧值，从而导致逻辑判断错误。

解决方案：

规划调用顺序：在组织程序时，有意识地将产生条件的FB实例放在使用该条件的FB实例之前调用。这需要绘制简单的数据流图来理清依赖关系。
使用中间变量缓冲：如果依赖关系复杂，难以调整顺序，可以在主程序中，在所有FB调用之前，先将所有需要的外部输入（包括其他FB的输出）读取到一组中间变量中；然后，所有FB都使用这组中间变量作为输入；在所有FB调用之后，再将FB的输出更新到最终的外部输出或中间变量中，供下一个扫描周期使用。这是一种“输入-逻辑处理-输出”的批处理模式，能保证逻辑判断基于同一时刻的快照，避免顺序问题。
利用任务设置：在一些高端PLC（如iQ-R）中，可以为不同的FB分配不同的执行任务和周期，但这对初学者来说过于复杂，优先推荐前两种方法。

5.3 接口设计不合理导致的复用困难

问题现象：为项目A精心编写的FB，想复用到项目B时，发现接口不够用或多余，修改起来几乎和重写一样麻烦。

根因分析： FB设计时没有做好“抽象”，接口要么过于具体（绑定了项目A的特殊设备），要么过于简化（无法满足项目B的扩展需求）。

设计原则与技巧：

单一职责原则：一个FB只做好一件事。例如，“电机控制”FB就只负责启停、保护和基本状态管理。调速、定位等复杂功能应该拆分到另一个“电机驱动”FB中，两者通过接口协作。不要做一个“巨无霸”FB。
参数化配置：将可能变化的属性设计为输入参数。例如，电机的额定功率、加减速时间、是否启用本地/远程模式等。通过枚举类型（eMode）或结构体（stConfig）来组织相关参数，使接口更清晰。
提供标准接口：参考PLCopen等国际组织定义的运动控制功能块标准，设计兼容的接口。这样，你写的FB更容易被其他工程师理解，也更容易与第三方库协作。
版本与注释：在FB内部和工程文档中，清晰记录FB的版本、修改历史和每个接口的详细说明。使用有意义的变量名（如xStart而非X1）。

6. 从FB到更大的蓝图：结构化编程与项目架构

掌握了FB，你实际上已经踏入了结构化编程的大门。FB是结构化编程的核心载体。那么，如何用FB来搭建一个完整的项目呢？

一个典型的中小型自动化项目程序结构可以这样组织：

设备层FB：最底层，对应具体的物理设备，如Motor_FB,Valve_FB,Sensor_FB。它们只关心如何驱动和读取这个设备。
单元层FB：中间层，由多个设备层FB组合而成，完成一个工艺单元的功能。例如FeedingUnit_FB（上料单元），内部可能包含一个传送带电机FB、一个定位气缸FB和几个传感器FB，并编排它们之间的动作顺序。
流程控制层（主POU）：最高层，通常就是主程序。它实例化各个单元层FB，并接收来自HMI（人机界面）的指令（如自动启动、急停、模式选择），协调各个单元之间的配合，处理全局性的连锁和安全逻辑。

这种分层架构的好处显而易见：

分工协作：资深工程师可以设计单元层和流程层的框架，并定义好设备层FB的接口；新手工程师可以专注于实现具体的设备层FB。
调试方便：设备故障时，直接找到对应的设备层FB实例查看状态；工艺问题则查看单元层FB。
移植性强：下次遇到类似的阀门，直接把Valve_FB拿出来用，只需修改接口连接的实际IO点。

与HMI通讯的要点：在这种架构下，HMI不应该直接去访问设备层FB的内部变量。最佳实践是，在主程序或一个专门的“HMI接口”FB中，将需要显示给HMI的状态（如电机运行、故障、速度）汇总映射到一片连续的全局标签或数据块（DB）中；需要从HMI接收的命令也通过这片区域下发。这样，FB内部逻辑与外部交互清晰分离，HMI画面制作和程序调试都能更高效。

学习FB模块，绝不仅仅是学习一个新的编程工具，更是接受一种更高效、更可靠的工程化思维。它要求你在动手写第一行代码之前，先思考如何“分而治之”，如何设计“接口契约”。这个过程初期可能会觉得有些束缚，不如直接写梯形图来得痛快，但当你面对一个成百上千个IO点、逻辑错综复杂的项目时，一个由清晰、独立的FB搭建起来的程序，其可读性、可维护性和可扩展性的优势将是决定性的。从复制粘贴的“积木式”编程，转向模块化、实例化的“乐高式”编程，这是每一个希望进阶的PLC工程师的必经之路。