顺手捡起这个话题STL里FC看着就像一段普通程序往里塞逻辑就行了实际上它比FB“自由”得多也正因为这种自由坑特别多。前面几篇写了STL指令和逻辑结构的常见错误这次把FC单拎出来讲清楚——它没有背景数据块、临时量生命周期特殊、还能直接操作状态字和整个数据块寄存器任何一个环节没考虑周全现场就是一台间歇性抽风的设备。一次“看不见的内存残留”引发的排查先讲个真事。有一台包装线设备S7-300做主站程序里有个FC负责根据光电信号计算包装膜的长度补偿值。设备调试时一切正常交付三个月后客户突然报故障补偿值偶尔会跳到异常大导致切膜位置偏了十几毫米。一天出现一两次完全没有规律。到现场把程序翻了个底朝天梯形图看不出问题后来把FC用STL打开一行行盯终于发现了嫌疑FC内部用了一个TEMP变量做中间值但这个变量在块开头没有赋初值只有某一条分支路径上才会被写入。当另一条路径执行时它读到的就是L堆栈里上次残留的随机数据。那“随机数据”可能是任何东西取决于上一次哪个块占用了这块局部数据区。这就是FC在STL编程里最典型的坑也是我这篇要讲的第一个问题TEMP变量的脏数据。后文会逐个拆FC相关的高频错误包括临时量生命周期、ENO/BR位检查、参数类型、DB寄存器和地址寄存器的“副作用”、定时器编号冲突最后给一份能直接拿去用的自查清单。1. 为什么FC是STL项目里的“重灾区”1.1 FC与FB的本质区别没有“自己的内存”很多从梯形图转STL的人容易把FC当成“一个筐”什么逻辑都往里装。但FC和FB的底层模型完全不同FB有背景数据块背景DB块里的静态变量会永久保存在背景DB中每次调用之间数据不丢失相当于FB自带一个小仓库FC没有背景DB也没有静态变量它的所有局部变量都放在局域数据堆栈L堆栈里调用结束即释放。这个差异直接决定了FC的TEMP变量行为。L堆栈是全局共享的一块内存区域OB1、FC1、FC2、FB10等所有块在运行时都用同一块区域只是各自划分窗口。一个FC退出后它占用的L堆栈区域不会被清零下次无论哪一个块用到这块区域读到的都可能还是上一次的数据。打个比方这就像多人合租公寓每个租客退房后管家不做保洁下一个租客进门发现前一任留下的垃圾还在。你运气好垃圾是没用的废纸运气不好垃圾里有一张写着“错误补偿值”的便签程序就照着执行了。1.2 一段“看着正常”的STL代码是如何踩雷的看一个简化后的例子。下面这个FC用于模式切换客户希望它根据输入信号决定输出值同时内部用一个TEMP计数器做简单统计FUNCTION FC100 : VOID VAR_INPUT Mode : INT; END_VAR VAR_OUTPUT OutVal : INT; END_VAR VAR_TEMP TempCount : INT; TempMode : INT; END_VAR BEGIN L #Mode T #TempMode L #TempCount L 1 I T #TempCount L #TempMode T #OutVal END_FUNCTION表面上看逻辑完整把输入模式传给输出TEMP计数器自增一次。但这里有两个致命问题第一TempCount未经初始化直接自增第一次调用时它可能是0也可能是65535甚至任意值第二TempCount根本没有存储介质下一次调用时它不会延续上次的值这个“计数器”是虚假的。如果在程序里把这个FC用在一个循环逻辑中你会看到计数器忽大忽小完全没有规律。这就是典型的把FC当FB用——真正需要跨调用保持的数据应该用外部DB地址通过IN_OUT接口传入或者干脆改成FB。1.3 给TEMP变量“上户口”初始化的正确姿势解决脏数据问题只有一个可靠办法FC入口处对所有会用到的TEMP变量统一赋初值。注意是“所有”不是“可能用到”因为你无法保证哪条分支会执行。养成固定习惯在FC声明区下面直接写初始化段L 0 T #TempCount T #TempMode L 0.000000e000 T #TempFloatValue有的人觉得这样啰嗦程序跑起来也没问题就省略了。但在现场省略一行初始化的代价可能是三天的排查时间。我的习惯是FC模板里预置初始化段所有人都按这个模板写新人的程序评审首先查这一条。顺便说一句TEMP数组也一样如果FC内用TEMP做缓冲区初始化时可以用循环或者直接MOVE一整个数据块区域比单个初始化可靠得多。需要跨调用保持的数据不要侥幸塞进TEMP。FC没有静态区要么用IN_OUT接入外部DB要么换成FB。这是个设计决策不是语法问题但后面所有“间歇性故障”几乎都从这里来。2. 调用FC后不检查ENO和BR相当于闭着眼开车2.1 ENO在STL里是怎么工作的LAD和FBD里功能块都有ENO引脚它告诉你这个块有没有正常执行完。STL里没有图形连线但CALL指令执行后状态字的BR位二进制结果位会携带类似的信息FC内部无异常时BR1内部出现某些错误比如算术溢出、访问错误时BR0。问题在于STL里CALL完之后你看到的就是一条孤立指令后面可能马上接着其他逻辑很多人根本不看一眼BR。这在FC内部只是简单赋值逻辑时问题不大但只要FC内部有数学运算、数据转换、间接寻址就一定要处理状态字。2.2 除法溢出一个典型的BR/OV连环坑继续开头的案例。FC300把速度换算成变频器频率内部逻辑简化如下L #SpeedValue L #Denominator /R T #FreqOutput正常情况下Denominator是一个不为零的系数。但现场上位机偶尔会下发一个特殊状态字经过中间变量转换后Denominator变成了0。STL的浮点除法遇到除数为0时会置位状态字的OV位和OS位结果变为无穷大或无效值然后程序并不会停止而是继续往下执行把无效结果写到FreqOutput变频器收到一个乱值。排查链路是这样的在线监控FC300的输入输出输入正常故障时刻输出突然变成0或极大值用STL单步执行在/R指令后观察状态字的OV和OS位发现置位检查Denominator的来源追到上位机状态字转换逻辑确认极端工况下会变成0在FC内部除法后面加上溢出判断或者在调用FC300后检查BR位发现异常时置故障标志并保持上一次有效输出。这个案例的关键不是除法本身而是溢出后FC还会继续往下走。STL的数学指令不像高级语言会抛异常它只修改状态字后续一切照常。所以FC内部如果有除法、类型转换、间接寻址这类危险操作应当显式检查状态字至少让异常能被上层感知而不是让错误结果在程序里“带病运行”。顺带说清一个容易混淆的点在STEP 7中FC调用的BR位并不总是自动反映FC内部是否有错。如果FC内部没有显式处理状态字BR的值取决于最后一条指令的状态不一定可靠。因此最稳妥的做法是在FC内部末尾用SET或者根据错误标志显式设置RLO再通过不影响BR的指令流转出去在调用侧则习惯性地在CALL之后跟一条CALL FC300 A BR #CallOK JCN ERR这样即使FC内部出了问题调用侧也能拿到一个明确的“成功/失败”信号而不是看着输出结果发愣。2.3 ENO0不代表程序停下来了更不代表输出安全有现场经验的工程师都有一个共识程序里最危险的故障不是CPU停机而是CPU继续跑但算错了。FC调用后不检查BR恰恰就是给这种“算错还继续跑”开了绿灯。我的做法是对于关键功能FC在调用后不但检查BR还要对输出参数做合理性判断比如范围检查、变化率限制。有些算法错误BR位并不会变0但输出一看就不合理这种二次检查往往能在故障还没造成损失之前就把问题暴露出来。3. 参数传递里的类型陷阱REAL、INT、常量的“暗战”3.1 最容易翻车的三种传参写法STL里给FC传参表面看很简单实际上类型问题相当隐蔽。以下几种是我在评审程序时反复见到的。第一种整型常量传给REAL形参。例如接口里定义了一个REAL输入调用时直接CALL FC500 Input : 1010在S7中是INT型字面量直接传给REAL形参并不安全。正确写法是写成浮点字面量Input : 10.0别小看这个小数点项目现场因为这种低级类型错误导致计算结果偏差的情况并不少。第二种同一个地址既做输入又做输出。比如接口有Input和Output两个参数调用时如果把两个都填成MD10FC内部先读MD10做运算再写回MD10一旦运算逻辑里输入和输出还参与了别的计算结果就会以你意想不到的方式互相覆盖。第三种隐式的REAL和INT混算。STL中不会自动把INT转成REAL再计算L 5 L 3 /R看起来没问题但如果5是INT、3是REAL指令本身就会编译报错。真正的麻烦来自那些通过M区传递数据的FC一个FC把值以REAL格式写到MD100另一个FC以INT格式从MW100读取。由于REAL占32位、INT只读16位读出来的一定不是原来的数。这种错误交叉引用查不出来因为两个FC各自都“合法”纯粹是数据契约没对齐。3.2 为什么STL传参比SCL更容易出事SCL有相对严格的编译期类型检查写错了IDE直接红字提示。STL的“自由度”恰恰是双刃剑——它允许你用绝对地址、允许你直接操作状态字、允许你用各种指针转换编译器的很多错误提示在STL里会变成运行期的不可预期行为。特别是从STEP 7老项目迁移到TIA Portal时移植过程中的数据类型自动调整可能会掩盖一部分问题导致现场出现时好时坏的怪异现象。遇到这类问题不要急着改FC内部逻辑先把接口定义打出来核对每个参数的名称、类型、注释再看每个调用点的实参。很多“FC计算结果不对”的故障根源根本不在FC内部而在某个调用点把参数传歪了。3.3 接口变更后的未同步隐藏的版本冲突修改FC的接口比如增加一个输入参数、调整参数顺序之后如果项目里这个FC被多个块调用必须把所有调用点同步更新。TIA Portal有自动更新块调用的功能但如果你是从STEP 7迁移过来的老项目、或者项目里存在大量间接寻址调用点可能不会被全部识别。现象很典型PLC运行一段时间后CPU进入STOP诊断缓冲区显示“块调用参数错误”之类的信息或者某个调用点得到的输出一直是默认值。排查办法很简单右键FC选择“交叉引用”看所有调用处逐个核对参数列表。我曾经在一个老项目里发现一个FC被OB1和OB10两个组织块调用只更新了OB1里的调用OB10里的还是旧接口导致每天凌晨定时执行OB10时数据全是乱的。4. 全局资源带病使用OPN DB、定时器编号和M区“打架”4.1 FC里打开DB却不还原调用者跟着遭殃STL的OPN指令用来打开数据块寄存器打开之后后续所有不带DB号的DBW、DBD访问都针对这个被打开的DB。这个机制用来写短小快速的代码非常方便OPN DB100 L DBW0 T #Value问题出现在FC边界。如果FC内部打开DB100后没有在退出前恢复原来的DB那么调用这个FC的上一级程序在FC返回后继续使用DBW0访问数据块时访问的就不再是它自己以为的DB而是DB100。举个例子OB1里有一段逻辑在访问DB1中间调用FC200FC200内部OPN了DB100退出时没还原。OB1在FC200后面的指令L DBW0时实际读到的是DB100.DBW0。程序不报错因为语法完全合法但数据就串了。排查这种问题在线监控时注意观察调用前后DB寄存器的值。修复方式有两种一种是在FC入口把当前打开的DB号保存到TEMP退出前再OPN回去另一种是彻底放弃依赖OPN的寻址方式全项目使用符号寻址类似DB100.DBW0。第二种更治本因为符号寻址不依赖“当前打开的DB”这个全局状态FC之间不会因为这个互相影响。4.2 在FC里直接使用T1、C1调用两次就打架功能块FC没有背景数据块因此如果FC内部直接使用定时器T1、计数器C1这个FC就只能在整个项目里调用一次。一旦你在两个不同的地方调用同一个FC这在FC的使用场景里很正常同一时刻两个调用点共享同一个T1定时逻辑必然互相干扰。正确做法是把定时器编号作为参数传入FUNCTION FC400 : VOID VAR_INPUT TimerNo : TIMER; END_VAR调用时传入不同的实际定时器CALL FC400 TimerNo : T1如果使用IEC定时器TONR、TP等它们需要DB实例同理把实例DB作为IN_OUT参数传入。这样FC就变成可重入的也就是可以在项目中被多次调用而互不影响。判断自己的FC是否可重入有一个简单标准把这个FC复制成FC_A和FC_B分别在不同地方调用如果两边行为互不干扰它就是可重入的。4.3 M区标志位冲突一个M10.0搅乱三个FCM区是全局共享存储区老项目里经常用M10.0做“启动标志”、用MB11做“状态字节”。如果多个FC各自维护一套M区逻辑又没有规范的分配记录时间一长就会互相覆盖。更隐蔽的变种是用MOVE指令把一组M区当数据缓冲区。比如FC_A把一组数据MOVE到MB20开始的区域FC_B也把自己的数据MOVE到MB20两个FC的调用时间稍有重叠缓冲区就被踩踏。这类问题最难受的地方在于它不具备一致性不是每次运行都出错而是取决于FC_A和FC_B谁先执行、谁后执行。排查时用PLC变量表把所有M区的使用列出来交叉引用看哪些地址被多个块访问重点盯那些既是写又是读的地址。长期看新项目应该尽量用DB块替代M区把数据归属明确到块存量项目至少要建立一张M区地址分配表谁用了哪个地址、干什么用记录清楚。5. AR1/AR2和间接寻址的暗雷5.1 地址寄存器不是局部变量系统不会替你保存AR1和AR2是CPU内部的地址寄存器用于STL的间接寻址。很多STL程序员喜欢在FC里用AR1做数组遍历、指针偏移操作。但AR1/AR2是全局资源不是某个FC的私有变量系统在块调用边界不会自动保存和恢复它们。考虑一个场景OB1在调用某个FC之前已经用AR2指向了一个正在处理的结构体调用FC后如果FC内部修改了AR2返回后OB1再用AR2寻址得到的就是错误位置。这几乎不会报错只会产生错误数据。正确的做法是FC内部若要用AR1/AR2进入块后立刻把原值保存到TEMP变量退出前恢复LAR1 P##TempSave // 先把原AR1存入TEMP ... LAR1 P##TempSave LAR1 // 退出前恢复原AR1更稳妥的做法是项目统一约定凡是用了AR1/AR2的FC必须在块内部自己保存、自己恢复调用者也不要做任何假设。5.2 偏移量计算字节、字、双字的错位间接寻址中有一个高频错误偏移量单位搞错。AR1里的地址是字节地址访问REAL数组第N个元素时偏移量应该是N4字节访问INT数组是N2字节访问BYTE数组才是N*1字节。很多人写的时候直接用索引加上偏移忘了乘以元素所占字节数。正确的STL片段LAR1 P##ArrayStart L #Index SLD 2 // 乘以4因为每个元素是REAL占4字节 D LAR1 L D [AR1, P#0.0] T #Result这里的SLD 2左移两位就是乘以4。如果Index是INT类型还要先转成双整数如ITD因为地址运算要求32位。忽略了这一步程序实际访问的地址完全错位读出来的数据自然不对。5.3 递归与嵌套深度FC迟早被“堆”爆发FC理论上可以自己调用自己但实际工程中递归几乎总是坏事。调用链每深一层就会消耗一块L堆栈区域而CPU的L堆栈大小有限。多个FC嵌套调用、每个FC的TEMP数组又比较大时L堆栈可能溢出CPU直接进入STOP。S7-300系列对局部数据要求尤其敏感OB1的本地数据大小设置过小也会加剧这个问题。遇到CPU偶发STOP、诊断缓冲区提示“本地数据溢出”时优先检查调用链深度和FC的TEMP变量规模。一个不太合理但常见的现象是有人把一个大数组直接放在FC的TEMP区又在多个地方嵌套调用这个FC单个L堆栈窗口就捉襟见肘了。改善方向有两个一是把大数组挪到DB里通过IN_OUT接口传递二是压缩TEMP变量、减少嵌套层数。这不是改某一个指令的问题而是整个块设计需要重新考虑。6. 把FC写成“规范件”一份能救命的自查清单6.1 高频错误速查表检查项要求典型错误TEMP初始化FC入口处全部赋初值分支路径未覆盖读取L堆栈残留状态字BR/OV关键运算后检查状态位除零、溢出后继续执行参数类型实参与形参严格一致常量传REAL、REAL/INT混用DB寄存器使用OPN后退出前还原DBW访问串到其他数据块定时器/计数器编号通过参数传入FC内部写死T1/C1AR1/AR2内部保存并恢复调用后地址寄存器被改M区使用建立分配表避免冲突多个FC复用同一M区嵌套深度控制L堆栈占用大TEMP数组嵌套调用溢出接口变更所有调用点同步更新旧接口调用点残留6.2 用可重入性检验FC设计的质量一个FC真正合格的标准是它能被安全地多次复用。这意味着它不依赖未初始化的TEMP、不写死全局资源、不破坏调用者的全局寄存器状态。每次评审新人的程序我不看逻辑对不对先看这几条底线。TEMP有初始化、BR有处理、DB操作有还原、AR寄存器有保存恢复、定时器编号靠参数传入满足这五条FC的“坏脾气”基本就治好了。6.3 我排查FC问题的标准顺序遇到FC相关的疑难故障我习惯按固定顺序来比乱翻程序高效得多先查交叉引用确认这个FC在项目里被谁调用过、调用点的参数和接口是否完全一致在线监控块调用前后对比L堆栈和DB寄存器的变化锁定异常逐行单步执行FC内部的数学运算观察状态字的OV/OS、BR位变化检查FC内部是否有OPN DB、定时器编号、M区写入这类全局操作如果还查不出来把FC的TEMP变量全部赋初值后再投入运行看故障是否消失以此反推是否脏数据问题。这个方法在多次现场调试中都奏效尤其是第5步虽然看起来粗暴但十次里有八次能快速定位TEMP相关问题。最后再分享一条个人经验。以前我带项目时团队写STL的FC风格五花八门有人不初始化TEMP有人把定时器直接写在FC里有人OPN完DB不还原。后来我把所有FC都改成统一模板开头是初始化段中间是业务逻辑末尾是状态字处理段评审只看这几处。坚持了两三个项目之后FC相关的疑难故障明显少了一大半。编程语言的自由度是一把双刃剑STL给了你无限操作空间也给了你足够的犯错机会。把容易出问题的环节用规范管住剩下的才真正是你的业务逻辑。