企业官网建设流程全解析

1. 三种语言到底在解决什么问题

1.1 从一次产线改造说起

前年我接手一个包装线的改造项目，PLC用的是S7-1500，程序框架是前任工程师留下的。打开TIA Portal那一刻我有点懵：同一个项目里，LAD、FBD、SCL三种语言混着用，而且不是随便混的——安全回路用FBD，气缸动作逻辑用LAD，配方管理和数据换算用SCL。当时我第一反应是"这人怎么不统一一下"，但改了两周之后我服了，人家是故意的。

这件事让我意识到，很多刚接触S7-1500的朋友会把LAD、FBD、SCL当成"三种可以互相替代的写法"，选哪个全凭个人喜好。实际上不是这样。这三种语言在西门子的设计哲学里各有各的生态位，选错了不是不能跑，而是后期维护、调试、交接的时候会持续给你上强度。

这篇内容我想把这三门语言掰开揉碎讲清楚：它们各自的底层逻辑是什么、什么场景下用哪个最省事、在TIA Portal里具体怎么落地、以及我这些年踩过的坑。不管你是刚学PLC的新人，还是用了几年LAD想往SCL转的老手，应该都能捞到点东西。

1.2 先给三种语言画个像

在深入之前，先用大白话给三者定个位，方便后面展开。

LAD（Ladder Diagram，梯形图）：本质是把继电器控制电路"画"进软件里。左边是电源轨，右边是回路，触点和线圈的符号跟电气图纸几乎一模一样。它的最大价值是电气工程师能直接看懂，不需要额外学习成本。

FBD（Function Block Diagram，功能块图）：用方框表示功能块，用连线表示信号流向。它比LAD更接近"信号处理"的思维，尤其适合做逻辑运算、模拟量处理、安全逻辑。西门子的安全程序（F-CPU）基本都用FBD写，这不是偶然。

SCL（Structured Control Language，结构化控制语言）：高级文本语言，语法接近Pascal。能写循环、条件分支、数组操作、自定义函数。它的定位是处理LAD/FBD搞不定的复杂算法和批量数据。

三者不是竞争关系，是协作关系。一个成熟的S7-1500项目，往往是三种语言各司其职。下面我逐个拆。

2. LAD梯形图：电气思维的软件延伸

2.1 LAD的核心逻辑与适用边界

LAD的底层是"能流"（Power Flow）概念。你可以想象电流从左侧母线出发，经过一个个触点（条件），最终到达线圈（输出）。触点串联就是"与"，并联就是"或"，常闭触点就是"非"。这套逻辑跟继电器回路完全对应，所以电气出身的人上手几乎零门槛。

但LAD的边界也很明显。它擅长的是布尔逻辑——开关量、互锁、顺序控制、状态机。一旦涉及数值运算、循环、字符串处理，LAD就开始别扭了。我见过有人用LAD硬写一个冒泡排序，那画面太美，几十个比较指令堆在一起，改一个参数要动一大片。

所以LAD的选型原则很简单：逻辑能用触点线圈表达的，就用LAD；表达不了的，别硬撑。

2.2 在TIA Portal里写LAD的关键操作

新建块的时候，语言选LAD。TIA Portal的LAD编辑器有几个细节值得说。

第一，网络（Network）的划分。我习惯一个功能一个网络，网络标题写清楚这段在干嘛。比如"1#气缸伸出条件"、"急停复位逻辑"。别把所有逻辑塞一个网络里，后期排查会想死。

第二，触点的排列顺序影响可读性。串联触点里，把"最可能为假"的条件放前面，这样能流中断得早，虽然对PLC扫描时间影响微乎其微，但人看的时候逻辑更顺。

第三，善用中间变量（M点）和临时变量（Temp）。复杂逻辑拆成几段，中间结果存到M点，比一条长串的触点链好维护得多。Temp变量只在当前扫描周期有效，适合做临时计算，但要注意它不能跨周期保持。

举个实际例子，一个气缸的伸出逻辑：

Network 1: 气缸伸出条件 |--[ 自动模式 ]--[ 启动按钮 ]--[ / 气缸伸出到位 ]--[ / 气缸缩回到位 ]--( 气缸伸出线圈 )--|

这里"/"表示常闭。逻辑是：自动模式下，按启动，且气缸没伸到位、没缩回到位（即不在两端），才允许伸出。这种互锁用LAD表达一目了然，换成SCL反而要多写几行if。

2.3 LAD的实操心得与常见坑

坑一：双线圈问题。同一个线圈在多个网络里被赋值，PLC只认最后一个。这是新手最容易犯的错，而且TIA Portal默认不报错，运行时行为诡异。我的习惯是每个线圈只在一个网络里出现，需要多处控制就用置位/复位指令（S/R）。

坑二：常闭触点的思维陷阱。物理上是常闭按钮，程序里到底用常开还是常闭触点？记住一个原则：程序里的触点状态反映的是"信号为1还是0"，不是"物理触点通还是断"。急停按钮物理常闭，正常时信号为1，所以程序里用常开触点检测"急停未按下"。这个逻辑绕，但必须理清。

坑三：LAD的扫描顺序。PLC是从上到下、从左到右扫描的。如果网络2用了网络1的输出，那没问题；反过来就会用到上一周期的值。这个在写顺序逻辑时特别要注意。

提示：LAD里做数值比较（比如大于、小于）是可以的，用比较指令块就行。但如果比较逻辑超过三四个，建议考虑转SCL，可读性会好很多。

3. FBD功能块图：信号流的可视化表达

3.1 FBD和LAD的本质区别

很多人觉得FBD就是LAD换个画法，其实两者的思维模型不一样。LAD是"电流从哪流到哪"，FBD是"信号从哪个块传到哪个块"。FBD里没有能流的概念，只有输入输出和功能块的连接。

这个区别在复杂逻辑里会放大。比如一个模拟量处理链：原始值→滤波→标定→限幅→报警判断。用FBD画出来就是一条清晰的信号流水线，每个方框一个功能，连线就是数据流。用LAD画同样的东西，会比较指令和数学指令堆在一起，可读性差一截。

FBD的另一个主场是安全程序。西门子的F-CPU（故障安全CPU）编程，官方推荐且大部分场景强制用FBD。原因是安全逻辑需要严格的、可验证的结构，FBD的方框化表达更容易做形式化验证和认证。

3.2 FBD在TIA Portal中的实现要点

FBD编辑器和LAD编辑器在TIA Portal里是同一个框架，切换语言很方便。几个实操要点：

功能块的引脚连接。FBD的块有输入引脚（左侧）和输出引脚（右侧），用线连起来。TIA Portal支持自动连线，也支持手动拖。我建议关键信号手动连，避免自动连线把不该连的连上。

AND/OR块的输入数量。默认是2个输入，可以点块上的小箭头扩展，最多能到几十个。但输入太多可读性会下降，建议超过4个就拆成两级。

RS/SR触发器的使用。FBD里做状态保持，用RS（复位优先）或SR（置位优先）触发器。这两个的区别是当置位和复位同时为1时谁赢。安全逻辑里通常用复位优先（RS），确保故障时能可靠复位。

举个模拟量处理的FBD例子，用文字描述连接关系：

AI_Value --> [FILTER] --> [SCALE] --> [LIMIT] --> Alarm_Check | | | 滤波时间 量程上下限 限幅上下限

每个方框是一个功能块，参数在块属性里配。这种结构一眼就能看出信号经过了哪些处理，调试时逐个块查值就行。

3.3 FBD的适用场景与避坑

FBD最适合三类场景：模拟量处理链、安全逻辑、纯组合逻辑（没有状态保持的与或非运算）。

不适合的场景：顺序控制。FBD画状态机很痛苦，因为没有LAD那种直观的线圈，也没有SCL的case语句。顺序逻辑还是LAD或SCL更合适。

坑一：FBD的连线交叉。复杂FBD里连线会交叉，TIA Portal虽然会自动绕线，但太复杂时还是乱。我的做法是把相关功能块放一起，用网络分隔，别让连线跨太多网络。

坑二：FBD里的取反。输入引脚上有个小圆圈表示取反，这个跟LAD的常闭触点对应。但FBD里取反容易看漏，尤其是引脚多的时候。建议关键取反加注释。

坑三：FBD和LAD混用的类型匹配。同一个变量在FBD里当BOOL用，在LAD里当WORD用，会出问题。TIA Portal有类型检查，但跨语言调用时要留意。

4. SCL结构化控制语言：复杂逻辑的终极武器

4.1 SCL为什么值得学

如果说LAD和FBD是"画"出来的，SCL就是"写"出来的。它的语法接近Pascal，有if-else、for、while、case、数组、结构体、自定义函数。这些在LAD/FBD里要么没有，要么极其难用。

SCL的真正价值在三个地方：批量数据处理、复杂算法、代码复用。举个例子，你有20个同样的阀门，每个都要做开度计算、故障判断、超时报警。用LAD你得复制20遍逻辑，改一个参数要改20处。用SCL写一个函数块（FB），数组传参，循环处理，20个阀门一套代码搞定。

再比如配方管理。配方数据存在DB里，要按索引读取、校验、写入。LAD做这个要一堆间接寻址，SCL几行代码就完事。

4.2 SCL基础语法与TIA Portal实操

SCL的基本结构：

FUNCTION_BLOCK "ValveControl" VAR_INPUT Enable : Bool; Setpoint : Real; END_VAR VAR_OUTPUT Position : Real; Fault : Bool; END_VAR VAR Timer : TON; END_VAR BEGIN IF #Enable THEN #Position := #Setpoint * 0.1; IF #Position > 100.0 THEN #Position := 100.0; #Fault := TRUE; END_IF; ELSE #Position := 0.0; #Fault := FALSE; END_IF; END_FUNCTION_BLOCK

几个语法要点：

变量前缀#。SCL里引用块内变量要加#，引用全局变量（DB里的）要加DB名，比如"DataBlock".Value。这个跟LAD不一样，LAD里直接写变量名。

分号结尾。每条语句以分号结束，这个跟C语言类似。忘了分号是最常见的编译错误。

类型严格。SCL是强类型语言，Real不能直接赋给Int，要显式转换。用REAL_TO_INT()这类函数。这个比LAD严格，但能避免很多隐式转换的bug。

数组和循环。这是SCL的杀手锏：

FOR #i := 1 TO 20 DO #ValvePos[#i] := #Setpoint[#i] * #Gain; IF #ValvePos[#i] > #MaxLimit THEN #Alarm[#i] := TRUE; END_IF; END_FOR;

这段代码如果用LAD写，得展开成20组比较和赋值，代码量爆炸。

4.3 SCL进阶：函数、函数块与代码复用

SCL里有两类可复用单元：FC（Function）和FB（Function Block）。

FC没有记忆，每次调用都是独立的，适合纯计算。FB有背景数据块（Instance DB），能保持状态，适合需要记忆的逻辑，比如定时器、状态机。

我个人的经验是：能用FB就用FB。因为FB的状态存在背景DB里，调试时能直接看到内部变量，排查问题方便。FC虽然轻量，但调试时看不到中间状态。

SCL还支持自定义数据类型（UDT）。比如定义一个"阀门"类型，包含开度、状态、故障码等字段，然后声明一个阀门数组。这样代码结构非常清晰，跟面向对象有点像。

TYPE "ValveType" STRUCT Position : Real; Status : Int; FaultCode : Word; END_STRUCT END_TYPE

然后在FB里用VAR Valve : ARRAY[1..20] OF "ValveType"; END_VAR，操作起来就是#Valve[#i].Position，可读性拉满。

4.4 SCL的坑与调试技巧

坑一：SCL的执行顺序。SCL代码是顺序执行的，跟LAD的扫描逻辑一样，但SCL里没有"网络"概念，所有代码在一个块里从上到下跑。所以变量的赋值顺序很重要，别在赋值前就用了。

坑二：定时器的调用。SCL里用定时器要调用TON/TOF功能块，并且要传背景DB。新手常犯的错是忘了给定时器分配背景DB，或者多个地方用同一个定时器实例导致冲突。

坑三：除零错误。SCL里做除法，如果除数是0，CPU会报错停机。一定要加判断：

IF #Divisor <> 0.0 THEN #Result := #Dividend / #Divisor; ELSE #Result := 0.0; END_IF;

调试技巧：SCL块可以在线监控，但只能看变量值，不能像LAD那样看"能流"。我的做法是在关键位置加临时变量，把中间结果存下来，监控这些变量。调试完再删掉。

注意：SCL的注释用//（单行）或(* *)(多行)。注释写清楚，因为SCL代码密度高，没注释后期自己都看不懂。

5. 三种语言怎么选：一张决策表

5.1 选型决策的核心维度

选语言不是拍脑袋，我一般看四个维度：逻辑复杂度、数据处理量、维护人员背景、认证要求。

逻辑复杂度低、以开关量为主，LAD最合适。逻辑涉及信号流、模拟量链，FBD更清晰。逻辑复杂、有循环和批量数据，SCL是唯一选择。维护人员如果是电气出身，LAD/FBD友好；如果有编程背景，SCL没问题。安全相关，FBD优先。

下面这张表是我这些年总结的选型参考：

5.2 混合编程的实战策略

实际项目里，纯用一种语言的情况很少。我的习惯是分层：

底层设备控制用LAD或FBD，因为要跟电气图纸对应，方便现场调试。中间数据处理用SCL，做换算、报警、统计。上层逻辑协调用SCL或LAD，看复杂度。

关键是接口要清晰。不同语言的块之间通过DB变量交互，别直接跨块访问内部变量。我一般会建一个"接口DB"，专门存放跨语言传递的数据，谁读谁写一目了然。

还有一个经验：同一种功能尽量用同一种语言。比如所有气缸控制都用LAD，所有模拟量都用FBD，所有配方都用SCL。别这个气缸用LAD那个用SCL，后期维护会精神分裂。

5.3 从LAD转SCL的过渡建议

如果你LAD用得很熟，想学SCL，我的建议是从改写小功能开始。找一个你熟悉的LAD逻辑，用SCL重写一遍，对比两者的差异。你会发现SCL在数值处理上确实香，但在纯开关逻辑上反而啰嗦。

别一上来就用SCL重写整个项目，风险太大。先在新增功能里用SCL，跑稳了再逐步替换老代码。TIA Portal支持块级别的语言切换，但切换后代码结构会变，建议新建块而不是直接切。

6. 常见问题与排查实录

6.1 编译与下载阶段的典型问题

问题一：SCL编译报"未定义变量"。九成是忘了加#前缀，或者DB名写错了。SCL里全局变量必须写全路径，比如"MotorDB".Speed，不能只写Speed。

问题二：LAD网络报"双线圈"。前面提过，同一个线圈多处赋值。TIA Portal会在编译时给警告，别忽略。改成S/R指令，或者合并逻辑。

问题三：FBD连线报类型不匹配。比如把Real输出连到Bool输入。检查引脚数据类型，必要时加转换块。

问题四：下载后CPU报错停机。常见原因是SCL里的数组越界或除零。下载前先在仿真里跑一遍，或者加边界判断。

6.2 运行阶段的排查思路

现象：逻辑不动作。先查输入信号有没有进来（监控输入点），再查中间变量状态，最后查输出。LAD/FBD能看能流，SCL只能看变量值，所以SCL调试要提前埋监控点。

现象：数值不对。SCL里查数据类型转换，LAD/FBD里查比较指令的参数。特别注意Int和Real的混用，Int除法会丢小数。

现象：定时器不准。检查定时器背景DB是不是被多个地方调用，或者定时器在条件不满足时没被调用（SCL里定时器必须在每个扫描周期都执行）。

现象：安全逻辑不响应。FBD安全程序要检查F-CPU的签名和编译状态，安全块修改后必须重新编译并下载整个安全程序，不能只下单个块。

6.3 我的避坑清单

• 变量命名规范：LAD/FBD用驼峰或下划线，SCL用同样的规范，别混。我见过一个项目里同一个变量有"Motor1_Start"和"motor1start"两种写法，找起来要命。
• 注释必须写：尤其是SCL，代码密度高，没注释三个月后自己都不认识。
• 版本管理：TIA Portal项目文件很大，建议用项目归档功能，每次大改前归档一份。
• 仿真先行：TIA Portal自带PLCSIM，复杂逻辑先在仿真里跑通再下现场。SCL的循环和数组尤其要仿真验证。
• 备份再改：现场改程序前，先把当前版本上载备份。改崩了能回退。

提示：TIA Portal的交叉引用功能很好用，能查一个变量在哪些块里被用了。改代码前先查交叉引用，避免改一处崩一片。

7. 一些个人体会

写了这么多，最后说几句掏心窝的话。这三种语言没有高下之分，只有合不合适。我见过LAD写得极其优雅的老工程师，也见过SCL写得一团乱麻的年轻人。工具是死的，思维是活的。

我自己的成长路径是LAD入门、FBD补模拟量、SCL处理复杂逻辑。每一步都是被项目逼出来的，不是刻意学的。所以如果你现在只会LAD，别焦虑，先把LAD用透，遇到LAD搞不定的场景，自然就会去学FBD或SCL。

还有一点，别为了炫技用SCL。我见过有人用SCL写一个简单的启保停，就为了显得高级。结果现场电工看不懂，排查故障多花两小时。语言是给人看的，不是给机器看的。能让维护人员快速看懂的代码，才是好代码。

TIA Portal这个平台还在迭代，新版本对SCL的支持越来越好，Openness接口也能做自动化生成。但底层逻辑没变：LAD管开关、FBD管信号、SCL管数据。把这个分工记牢，选型就不会错。