PLC编程中FC与FB的本质区别：从内存模型到工程选型实战

1. 从一次产线停机说起：为什么“功能”和“功能块”总被混为一谈

很多做工业自动化控制的朋友，在刚接触PLC编程或者DCS组态的时候，都会遇到一个绕不开的坎：功能（Function，FC）和功能块（Function Block，FB）到底有什么区别？我见过不少工作三五年的工程师，写出来的程序里FC和FB混用，逻辑上看似跑通了，但一到产线联调、设备换型或者后期维护的时候，问题就全暴露出来了。轻则程序改一处崩三处，重则设备在自动运行中突然停机，排查半天找不到原因。

这个问题的本质，其实不是编程语法的问题，而是对“状态”和“数据保持”的理解深度问题。FC和FB在PLC编程里，看起来都是把一段逻辑封装起来反复调用，但它们在内存模型、数据生命周期、调用方式上有着根本性的差异。你如果只是照着教程抄一段电机启停逻辑，用FC也能跑，用FB也能跑，感觉不到区别。但一旦逻辑复杂起来，涉及多设备协同、配方管理、累计计时、报警锁存这些场景，选错了封装方式，程序就会变成一团乱麻。

这篇文章，我想从实际工程的角度，把FC和FB的实质讲透。不是照本宣科地念手册，而是结合我这些年踩过的坑、改过的烂摊子，把“为什么要这样设计”“什么场景该用哪个”“用错了会怎样”这些问题一次说清楚。无论你用的是哪家品牌的PLC，底层逻辑都是相通的，理解了实质，换平台也就是换个软件界面的事。

2. 拆开看内存：FC和FB在数据存储上的根本分野

2.1 FC的“即用即走”模型：没有记忆的纯逻辑

FC，中文叫“功能”，在大多数PLC编程环境里，它就是一个无状态的代码块。什么叫无状态？就是它自己不保存任何数据。你调用它的时候，传入参数，它执行逻辑，返回结果，然后拍拍屁股走人，不留下一片云彩。

我习惯把FC比作一个纯函数——就像数学里的 y = f(x)，你给同样的x，永远得到同样的y，它不会记得你上次调用它的时候传了什么。FC的临时变量（在西门子里叫Temp，在三菱里叫局部变量）是存在堆栈上的，调用时分配，返回时释放。这意味着两件事：第一，FC的执行效率通常比FB高，因为没有额外的背景数据管理开销；第二，FC里的临时变量在调用结束后就失效了，你下次再调用，它又是全新的。

这个特性决定了FC的适用场景：纯组合逻辑、数学运算、数据转换、条件判断。比如你要写一个“根据温度值判断是否超限”的逻辑，输入是温度，输出是布尔值，这种没有“记忆”需求的场景，用FC最合适。代码干净，调用方便，不占额外的数据块。

但这里有个坑，很多新手会踩：在FC里用临时变量做自锁或者状态保持。比如写一个电机启停逻辑，把运行标志位放在Temp变量里，想着下次调用还能用。结果程序跑起来，电机要么启动不了，要么停不下来。原因很简单，Temp变量在FC返回后就没了，下次调用是全新的值。这种错误在调试时特别隐蔽，因为在线监控的时候，你看到Temp变量在FC内部是有值的，但一出FC就丢了。

2.2 FB的“随身携带笔记本”模型：自带记忆的逻辑单元

FB，中文叫“功能块”，它的核心特征是拥有自己的背景数据块（Instance DB）。你可以把FB理解成一个带记忆的逻辑单元，每次调用它，它都会从自己的背景数据块里读取上次保存的状态，执行完逻辑后，再把新的状态写回去。

这个背景数据块是FB的“随身笔记本”，里面记录着这个FB实例的所有静态变量（Static）和输出变量的值。你可以在一个程序里多次调用同一个FB，每次调用分配不同的背景数据块，它们之间互不干扰。比如你写了一个“电机控制”FB，里面有启动、停止、故障复位、运行计时、报警锁存这些逻辑，然后你有10台电机，就调用10次，分配10个背景数据块，每台电机的状态独立维护，程序结构非常清晰。

FB的这个特性，决定了它适合有状态保持需求、需要多次实例化、逻辑相对复杂的场景。比如PID控制、累计流量计算、设备运行时间统计、配方管理、多工位协同控制等等。这些场景的共同点是：逻辑需要“记住”之前发生了什么，而且同样的逻辑要在多个设备上重复使用。

2.3 一张表看清FC和FB的核心差异

这张表建议你存下来，下次写程序之前扫一眼，能避免80%的选型错误。

3. 调用方式背后的设计哲学：为什么FB必须带背景块

3.1 从“函数指针”到“对象实例”的思维转变

如果你有高级语言的编程经验，可以把FC理解成静态方法，把FB理解成类的实例。FC是面向过程的思维，你定义一段逻辑，到处调用；FB是面向对象的思维，你定义一个“模板”，然后实例化出多个“对象”，每个对象有自己的属性（数据）和行为（逻辑）。

这个思维转变很重要。很多从传统继电器控制转过来的工程师，习惯把所有的逻辑都写成一段一段的FC，然后靠全局变量来传递状态。程序小的时候没问题，一旦设备多了，全局变量满天飞，改一个地方要全局搜索，维护成本极高。而FB的思路是：把相关的数据和逻辑封装在一起，形成一个高内聚、低耦合的单元。你需要控制一台电机，就实例化一个电机FB；你需要控制一个阀门，就实例化一个阀门FB。每个FB实例自己管好自己的数据，程序结构一目了然。

3.2 背景数据块里到底存了什么

很多人用FB的时候，只知道它“能保持状态”，但说不清楚背景数据块里具体存了什么。我拆开来说：背景数据块里主要存三类数据。

第一类是静态变量（Static）。这是FB的核心，你在FB的变量声明区里定义为Static的变量，都会存在背景数据块里。比如电机的运行标志、故障标志、累计运行时间、上次启动时间等等。这些变量在FB的整个生命周期内都存在，每次调用FB时，PLC会自动从背景DB里读取它们的值，执行完再写回去。

第二类是输出变量（Output）。FB的输出变量也会存在背景数据块里，这样你可以在FB外部通过背景DB来访问这些输出值，而不需要每次都通过FB的引脚来读。

第三类是输入变量（Input）和输入输出变量（InOut）。这两类变量本身不存储在背景DB里，它们是在调用时通过引脚传入的。但它们的值会在FB执行期间被使用，如果FB内部修改了InOut变量，修改后的值会写回到调用者指定的地址。

理解了这个存储模型，你就能明白为什么FB能保持状态，而FC不能。FC没有背景DB，所有的临时变量都在堆栈上，调用结束就释放，自然无法保持状态。

3.3 多重背景：FB嵌套调用时的内存管理

在实际项目中，FB往往不是孤立使用的，而是嵌套调用的。比如你有一个“生产线控制”FB，里面调用了多个“工位控制”FB，每个工位FB又调用了多个“电机控制”FB。这时候，如果每个FB都分配独立的背景DB，背景DB的数量会爆炸式增长，管理起来非常麻烦。

为了解决这个问题，大多数PLC平台都支持多重背景（Multi-Instance）。所谓多重背景，就是在一个FB的背景DB里，为它内部调用的其他FB预留存储空间。这样，你只需要为最外层的FB分配一个背景DB，里面嵌套的所有FB实例都共用这个背景DB，只是偏移地址不同。这大大减少了背景DB的数量，也让程序结构更加紧凑。

但多重背景也有代价：调试的时候，你无法单独监控某个内层FB实例的背景数据，必须通过外层FB的背景DB来查看。而且，如果外层FB的背景DB损坏，里面所有的内层FB实例都会受影响。所以，多重背景适合逻辑紧密相关、生命周期一致的FB嵌套；如果内层FB需要独立调试或者独立复用，还是单独分配背景DB更稳妥。

4. 选型实战：什么场景该用FC，什么场景必须用FB

4.1 这些场景，用FC就够了，别过度设计

我见过一些工程师，学了FB之后，恨不得所有逻辑都用FB来写，连一个简单的“与或非”逻辑都要封装成FB。这就是典型的过度设计。FC在以下场景里，比FB更合适。

纯数据转换和计算。比如你把一个模拟量输入值转换成工程值，或者做一个单位换算，这种逻辑没有状态保持需求，输入确定输出就确定，用FC最干净。你不需要为它分配背景DB，调用的时候直接传参就行。

条件判断和报警生成。比如你根据多个条件组合判断是否触发某个报警，这种逻辑也是纯组合逻辑，用FC写，代码清晰，执行效率高。报警的锁存和复位可以放在FB里做，但判断逻辑本身用FC就够了。

一次性执行的初始化逻辑。比如设备上电时的一些初始化操作，只执行一次，不需要保持状态，用FC或者直接用主程序里的网络段都可以。

数学运算和字符串处理。这些操作本质上都是纯函数，输入输出确定，没有状态，用FC最合适。

用FC的时候，有一个铁律：不要在FC里用临时变量做状态保持。如果你发现某个逻辑需要“记住”上次的值，那就说明它不适合用FC，应该改用FB。这个判断标准非常简单，但能帮你避免很多隐蔽的Bug。

4.2 这些场景，必须用FB，用FC会出大问题

反过来，以下场景如果你用FC来写，程序迟早会出问题。

PID控制。PID控制器需要保持积分项和微分项的历史值，这些状态必须跨调用周期保持。用FC写PID，你只能把积分值放在全局变量里，但这样就没法多次实例化了。用FB写，每个PID回路分配一个背景DB，积分值、微分值、上次误差都存在背景DB里，多个回路互不干扰。

累计计时和计数。比如你要统计一台设备的累计运行时间，这个时间需要跨扫描周期累加。用FC写，你没法在FC内部保存累计值，只能靠全局变量。用FB写，累计值放在Static变量里，每次调用自动累加，干净利落。

设备状态机和流程控制。设备的运行往往有多个状态（待机、启动中、运行、暂停、故障、复位中），状态之间的切换需要记住当前状态。这种场景用FB写，把当前状态放在Static变量里，逻辑清晰，调试方便。用FC写，状态只能放全局变量，程序一复杂就乱。

多工位、多设备的复用逻辑。你有10台同样的设备，控制逻辑完全一样，只是数据不同。用FB写一次，调用10次，分配10个背景DB，程序结构非常优雅。用FC写，你要么复制10份代码（维护噩梦），要么用全局变量数组（可读性差）。

报警锁存和首出记忆。报警需要锁存，直到操作员确认才复位；首出记忆需要记住第一个触发的报警。这些都需要状态保持，用FB写最合适。

4.3 一个真实案例：电机控制从FC改成FB的代价

我之前接手过一个项目，前任工程师用FC写电机控制逻辑，每台电机的运行标志、故障标志、累计运行时间都放在全局变量里，变量名是Motor1_Run、Motor1_Fault、Motor1_Time、Motor2_Run、Motor2_Fault……一共20台电机，全局变量表里密密麻麻几百个变量。程序能跑，但问题很多。

第一个问题是改一处要改二十处。电机的控制逻辑要加一个“启动延时”功能，他得在20个FC调用里逐个修改，漏一个就出问题。第二个问题是变量名容易写错。有一次他把Motor13_Fault写成了Motor13_Falut，编译不报错（因为全局变量可以隐式声明），但运行的时候故障信号丢了，排查了半天。第三个问题是程序可读性极差。新来的工程师看程序，根本分不清哪些变量属于哪台电机，维护成本极高。

后来我把它改成了FB方案：写一个MotorControl的FB，里面有Run、Fault、RunTime、StartDelay等Static变量，然后调用20次，分配20个背景DB。改完之后，程序从原来的几千行缩减到几百行，逻辑清晰，维护方便。加功能只需要改FB内部逻辑，所有实例自动生效。这个改造花了两天时间，但后续维护节省的时间远远超过这个投入。

5. 那些年我踩过的FC和FB的坑

5.1 坑一：在FC里用Temp变量做自锁，程序时好时坏

这是我刚入行时踩的第一个坑。当时写一个水泵控制逻辑，启动按钮按下，水泵运行；停止按钮按下，水泵停止。我用FC写，把运行标志放在Temp变量里，逻辑是：如果启动按钮按下或者运行标志为真，则运行标志置位；如果停止按钮按下，则运行标志复位。逻辑看起来没问题，但实际运行时，水泵偶尔会自己停，偶尔又停不下来。

排查了很久才发现，Temp变量在FC返回后就失效了，下次调用时它的值是随机的。有时候随机到True，水泵就意外启动了；有时候随机到False，水泵就意外停了。这个问题的隐蔽性在于，在线监控的时候，你看到Temp变量在FC内部是有值的，逻辑也跑通了，但一出FC就丢了。后来改成FB，把运行标志放在Static变量里，问题立刻消失。

这个坑给我的教训是：FC里的Temp变量，只能用于当前扫描周期内的临时计算，绝对不能用于跨周期保持状态。如果你需要保持状态，要么用FB的Static变量，要么用全局变量（但不推荐），没有第三条路。

5.2 坑二：FB背景DB被意外覆盖，设备行为异常

有一次调试一条包装线，设备运行一段时间后，某个工位的动作时序突然乱了。排查发现，这个工位的FB背景DB里的某个Static变量被意外修改了。追查下去，发现是另一个FB的背景DB地址分配重叠了，两个FB共用了同一块内存区域，互相覆盖。

这个问题的根源是背景DB的地址分配。在有些PLC平台里，背景DB的地址是手动分配的，如果你分配的时候不小心让两个FB的背景DB重叠了，就会出现这种问题。避免的方法是：尽量使用符号寻址，让编程软件自动分配背景DB地址；如果必须手动分配，一定要做好地址规划，留足余量，并且在编译后检查背景DB的大小和地址范围。

另外，多重背景虽然节省背景DB数量，但也要注意内层FB的实例数据不要和外层FB的Static变量冲突。大多数编程软件会自动处理偏移，但如果你手动指定了绝对地址，就要格外小心。

5.3 坑三：FC和FB混用时，参数传递的陷阱

FC和FB混用的时候，参数传递也有讲究。FC的输入输出参数是通过引脚传递的，调用时传值；FB的输入输出参数也是通过引脚传递，但FB的Static变量是存在背景DB里的，不通过引脚。

有一个常见的错误是：在FC里调用FB，但FC本身没有背景DB，所以FB的背景DB必须由FC的调用者提供。如果你在FC里调用了一个FB，但没有正确指定背景DB，编译会报错。解决方法是：要么把FC改成FB，让FB的背景DB嵌套在FC的背景DB里（多重背景）；要么在FC的调用者那里为FB分配独立的背景DB，然后通过参数传给FC。

还有一个错误是：在FB里调用FC，但FC的Temp变量和FB的Static变量重名了。虽然大多数编程软件会区分作用域，但为了代码清晰，建议变量命名时加上前缀，比如FC的临时变量用tmp_开头，FB的静态变量用st_开头，避免混淆。

5.4 坑四：以为FB一定比FC慢，结果优化错了方向

有些工程师听说FB有背景DB读写开销，就认为FB一定比FC慢，于是在性能敏感的场景里强行用FC，结果程序逻辑复杂到无法维护。实际上，在现代PLC上，FB的背景DB读写开销非常小，对于大多数应用来说，FC和FB的执行时间差异可以忽略不计。真正影响性能的是逻辑的复杂度和扫描周期，而不是FC和FB的选择。

我做过一个测试，在同一个PLC上，用FC和FB分别实现同样的PID控制逻辑，扫描周期差异不到5%。但用FC实现的版本，因为要把状态放在全局变量里，代码可读性差，调试困难，后期维护成本高得多。所以，不要为了微小的性能差异牺牲代码的可维护性。除非你的扫描周期已经紧张到毫秒级，否则优先考虑代码的清晰度和可维护性。

6. 从FC到FB的重构思路：什么时候该动手改

6.1 识别需要重构的信号

不是所有的FC都需要改成FB。但如果你的程序里出现了以下信号，就该考虑重构了。

信号一：全局变量泛滥。你的全局变量表里有大量以设备编号命名的变量，比如Motor1_Run、Motor2_Run、Valve1_Open、Valve2_Open，而且这些变量只在对应的FC里使用。这说明你的逻辑需要封装成FB，用背景DB来管理状态。

信号二：复制粘贴的代码。你有多个FC，逻辑几乎一样，只是操作的变量不同。这说明你应该把这段逻辑封装成FB，然后多次实例化。

信号三：改一处要改多处。你修改一个FC的逻辑，需要同步修改多个调用点，或者修改多个类似的FC。这说明你的逻辑没有封装好，应该用FB来统一管理。

信号四：调试时找不到状态变量。你在线监控的时候，发现某个状态变量的值不对，但不知道它是在哪里被修改的。这说明你的状态管理太分散，应该用FB把相关的状态和逻辑封装在一起。

6.2 重构的步骤和注意事项

重构不是推倒重来，而是逐步演进。我的做法是：先识别出可以封装的逻辑单元，然后写FB，再逐步替换原来的FC调用。

第一步，梳理逻辑，找出那些“有状态保持需求、需要多次复用”的逻辑单元。比如电机控制、阀门控制、PID回路、累计计时等。

第二步，为每个逻辑单元设计FB的接口。输入是什么（启动、停止、复位等），输出是什么（运行、故障、就绪等），需要保持哪些状态（运行标志、故障标志、累计时间等）。

第三步，写FB的内部逻辑，把状态变量定义为Static，把输入输出定义为Input/Output/InOut。

第四步，在程序里逐步替换原来的FC调用。每替换一个，就测试一个，确保逻辑正确。不要一次性全部替换，那样出了问题很难定位。

第五步，清理不再使用的全局变量和FC。这一步要谨慎，确认没有其他地方引用后再删除。

重构的过程中，有一个注意事项：保持接口的兼容性。如果原来的FC已经被其他地方调用，你改成FB后，调用方式会变（需要指定背景DB），所以要同步修改调用点。如果调用点很多，可以考虑保留原来的FC作为包装层，内部调用FB，这样外部调用方式不变，但内部状态管理已经改成了FB。

6.3 重构后的收益：一个真实项目的对比

前面提到的那个20台电机的项目，重构前后的对比如下：

这个对比不是要证明FB一定比FC好，而是说明：在适合的场景里，选对封装方式，收益是巨大的。FC和FB不是对立的，而是互补的。纯逻辑用FC，状态控制用FB，两者配合，才能写出既高效又易维护的程序。

7. 不同PLC平台上的FC和FB：换汤不换药

7.1 西门子S7系列：FC和FB的经典实现

西门子的S7系列PLC里，FC和FB的区别非常清晰。FC没有背景DB，FB有背景DB。FB的背景DB可以是单独的（Single Instance），也可以是多重背景（Multi-Instance）。在博途（TIA Portal）里，你创建一个FB，系统会自动生成一个背景DB的数据类型，调用的时候可以选择分配单独的DB或者多重背景。

西门子还有一个概念叫系统功能块（SFB）和系统功能（SFC），这是西门子预置的FC和FB，用于实现一些系统级功能，比如读写系统时间、处理中断等。SFB和SFC的调用方式和用户自定义的FB/FC类似，但它们的背景DB是系统管理的，用户不需要手动分配。

在西门子里，有一个细节要注意：FB的Static变量在背景DB里的偏移地址是固定的，如果你在FB里添加或删除Static变量，背景DB的结构会变，已经下载到PLC里的背景DB需要重新下载。如果是在运行中修改，可能会导致背景DB数据丢失。所以，在修改FB的Static变量之前，最好先备份背景DB的数据，或者选择在停机时修改。

7.2 三菱FX和Q系列：FB的另一种表达

三菱的PLC里，FB的概念叫“功能块”，但实现方式和西门子略有不同。三菱的FB也有背景数据，但它的背景数据是存在FB内部的，不需要单独分配背景DB。调用FB的时候，系统会自动为它分配存储空间。

三菱的FB有一个特点：支持在线修改。你可以在PLC运行的时候修改FB的内部逻辑，下载后不需要重启PLC，FB会自动使用新的逻辑。这个特性在调试阶段非常方便，但也带来一个风险：如果你在运行中修改了FB的Static变量，可能会导致状态丢失。所以，在线修改FB的时候，要确认修改的内容不会影响正在运行的状态。

三菱还有一个概念叫FB的嵌套，和西门子的多重背景类似。你可以在一个FB里调用另一个FB，内层FB的背景数据会嵌套在外层FB的背景数据里。三菱的编程软件会自动处理偏移，用户不需要手动管理。

7.3 欧姆龙和罗克韦尔：FB的变体

欧姆龙的PLC里，FB的概念叫“功能块”，和西门子类似，也有背景数据。欧姆龙的FB支持变量标签，你可以用符号名来访问FB的变量，不需要关心绝对地址。这个特性让程序的可读性更好，但也要求编程软件支持标签数据库。

罗克韦尔的PLC里，FB的概念叫“Add-On Instruction（AOI）”，本质上和FB是一样的，有输入输出参数，有本地标签（相当于Static变量），可以多次实例化。AOI的特点是支持版本管理，你可以定义AOI的版本，不同版本可以共存，方便程序升级。

不管哪个平台，FC和FB的核心区别都是一样的：FC无状态，FB有状态。理解了这一点，换平台只是换个软件界面和术语的事。

8. 写给新手的建议：先想清楚数据，再动手写代码

8.1 写程序之前，先画一张数据流图

我见过很多新手，拿到需求就开始写代码，写着写着发现状态变量没地方放，于是到处加全局变量，最后程序乱成一团。我的建议是：写程序之前，先画一张数据流图。

数据流图里，你要标出：哪些数据是输入（来自传感器、HMI、其他设备），哪些数据是输出（去执行器、HMI、其他设备），哪些数据需要保持状态（运行标志、累计值、报警锁存等）。然后，根据数据的生命周期和复用需求，决定哪些逻辑用FC，哪些用FB。

如果某个逻辑单元需要保持状态，而且可能在多个地方复用，那就用FB。如果某个逻辑单元是纯计算，输入确定输出就确定，那就用FC。这个判断标准简单有效，能帮你避免大部分选型错误。

8.2 从简单的FB开始练手

如果你还没用过FB，建议从一个简单的场景开始练手。比如写一个“累计计时器”FB：输入是使能信号和复位信号，输出是累计时间。内部逻辑是：当使能信号为真时，累计时间按扫描周期累加；当复位信号为真时，累计时间清零。累计时间放在Static变量里，跨周期保持。

这个FB虽然简单，但涵盖了FB的核心要素：输入、输出、Static变量、背景DB。你把它写出来，调用几次，观察背景DB里的数据变化，就能直观理解FB的工作原理。然后，你可以逐步增加复杂度，比如加上“计时到达”输出、“计时中”输出、累计时间的高低位处理等。

练手的时候，有一个技巧：在线监控背景DB。在大多数PLC编程软件里，你可以打开FB的背景DB，实时观察里面每个变量的值。这是理解FB状态保持机制的最直观方式。你会看到，每次调用FB，Static变量的值都在变化，而且下次调用时读取的是上次的值。这个观察过程，比看十遍手册都管用。

8.3 不要害怕重构，但要控制重构的范围

最后一点建议：不要害怕重构，但要控制重构的范围。如果你发现之前的程序用FC写状态逻辑，导致了一堆全局变量，不要想着一次性全部改成FB。那样风险太大，容易引入新问题。

我的做法是：新功能用FB写，老功能逐步改。每次修改或扩展一个功能的时候，顺便把相关的FC改成FB。这样，重构的风险被分散到每次小改动里，不会影响整体稳定性。而且，每次重构后你都能看到收益，更有动力继续下去。

重构的时候，一定要做好版本管理。每次重构前，备份当前程序；重构后，充分测试，确认逻辑正确再下载到现场。如果现场设备正在运行，重构最好安排在停机检修的时候进行，避免影响生产。

说到底，FC和FB的实质，不是语法问题，而是数据管理问题。你想清楚数据怎么存、怎么传、怎么保持，自然就知道该用FC还是FB了。这个道理，放在任何PLC平台上都成立，放在任何编程语言里也都成立。