企业官网建设流程全解析

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

1.1 从一次产线改造说起

去年接手一条包装线的电控改造，原系统用的是某日系品牌PLC，程序里大量步进指令和中间继电器逻辑，维护工程师换了两拨，没人敢动那段码垛机的逻辑。改造方案定下来用S7-1500，硬件选型很快敲定，真正让我纠结了三天的是编程语言怎么选：梯形图（LAD）最直观，功能块图（FBD）适合做模拟量处理，结构化控制语言（SCL）写算法最省事。三种语言在TIA Portal里可以混用，但混到什么程度、哪些块用哪种语言写，直接决定了后期调试效率和别人接手时的痛苦程度。

这个问题不是个例。S7-1500作为西门子当前主力控制器，在TIA Portal平台上同时支持LAD、FBD、SCL、GRAPH、STL等多种编程语言，其中LAD、FBD、SCL是使用频率最高的三种。很多刚接触1500的工程师会问：既然都能实现同样的逻辑，为什么还要分三种？答案在于它们各自的表达能力和适用边界完全不同。LAD用电路符号表达逻辑，FBD用逻辑门和功能块表达信号流，SCL用类Pascal的高级语言表达算法和数据处理。选错了语言，就像用螺丝刀去敲钉子，能敲进去，但费劲且容易出事。

这篇文章面向的是已经上手TIA Portal、能独立完成简单项目、但在中型以上项目里对语言选型感到困惑的工程师。我会把三种语言的核心差异、各自的实现细节、混编策略、以及实际项目中踩过的坑全部摊开讲。不堆理论，只讲能直接用到项目里的东西。

1.2 三种语言的本质差异

先建立一个基本认知：LAD和FBD本质上都是图形化编程，底层编译后生成的指令结构非常接近，区别在于表达习惯。LAD沿用了继电器控制电路的视觉语言，常开常闭触点、线圈、置位复位，电气工程师看一眼就能明白。FBD则更像数字电路图，与门、或门、异或门、RS触发器以方框形式呈现，信号从左到右流动，做布尔逻辑运算和模拟量处理时比LAD更紧凑。

SCL则是另一条路线。它是一门结构化文本语言，符合IEC 61131-3标准，语法接近Pascal，支持IF-THEN-ELSE、CASE、FOR、WHILE等控制结构，能直接写数学表达式、字符串处理、数组操作。在TIA Portal里，SCL代码块的编辑体验接近现代IDE，有语法高亮、自动补全、断点调试。关键区别在于：LAD/FBD一个网络只能表达一个逻辑结果，而SCL一个代码块里可以写几十行逻辑，处理循环和复杂条件判断时效率差距是数量级的。

从编译结果看，三种语言最终都会生成MC7代码在PLC上运行，执行效率的差异在大多数应用场景下可以忽略。真正影响性能的是代码结构：SCL里一个FOR循环处理1000个数组元素，比LAD里展开1000个网络要快得多，不是因为语言本身快，而是因为循环结构避免了大量重复的指令调用开销。

1.3 选型决策的核心维度

我在实际项目里总结了一个简单的决策框架，按优先级排序：

• 逻辑复杂度：纯布尔逻辑、互锁、启停控制优先LAD；组合逻辑、信号选择优先FBD；条件分支多、需要循环或数学运算优先SCL。
• 维护人员背景：如果现场维护以电气人员为主，LAD是唯一选择；如果有软件背景的工程师参与，SCL可以承担更多。
• 代码复用需求：需要做成库文件反复调用的功能块，SCL的封装性最好；LAD/FBD的库块在参数传递上限制更多。
• 调试便利性：LAD在线监控最直观，每个触点的通断状态一目了然；SCL需要借助监控表或断点，调试复杂逻辑时反而更灵活。

这个框架不是绝对的，但能覆盖80%的选型场景。接下来我会逐个拆解三种语言在TIA Portal里的具体实现方式，以及混编时需要注意的细节。

2. LAD梯形图：最直观的逻辑表达

2.1 LAD的核心元素与编程习惯

LAD的编程元素不多，但组合方式极其丰富。基本元素包括常开触点、常闭触点、输出线圈、置位线圈、复位线圈、上升沿/下降沿检测触点、定时器、计数器、比较指令、数学运算框。在TIA Portal里，这些元素通过拖拽或快捷键放置到网络中，每个网络从左边的母线开始，经过一系列触点逻辑，最终到达右边的线圈或功能框。

一个典型的电机启停控制网络：启动按钮常开触点与停止按钮常闭触点串联，再与电机运行反馈常开触点并联，最后接输出线圈。这个结构对应的是“启-保-停”电路，任何电气工程师都能在30秒内看懂。这就是LAD最大的价值：视觉即逻辑，不需要注释就能理解意图。

但LAD的局限也很明显。当逻辑涉及多个条件组合、需要中间变量、或者要处理数组和循环时，LAD的网络会迅速膨胀。我见过一个用LAD写的配方管理程序，200多个网络，每个网络处理一个配方参数的比较和赋值，维护时要在网络列表里反复滚动，改一个参数要跳转十几个网络。这种场景就是SCL的用武之地。

在TIA Portal V21里，LAD编辑器有一些值得注意的改进：网络注释支持富文本格式，可以插入表格和图片；触点支持直接显示变量注释和数据类型；在线监控时可以强制单个触点状态。这些细节在调试阶段能省不少时间。

2.2 LAD的典型应用场景与实现细节

LAD最适合的场景是离散控制逻辑：设备启停、互锁、模式切换、报警处理、步序控制。这些逻辑的特点是条件明确、分支有限、状态转换清晰。

以报警处理为例，一个典型的报警网络需要检测触发条件、做延时确认、锁存报警状态、记录报警时间戳。用LAD实现时，通常会用一个功能块（FB）封装报警逻辑，输入参数包括触发条件、延时时间、报警文本，输出包括报警激活、报警确认、报警历史。这个FB内部用LAD写，外部调用时只需要连接参数，看起来像一个自定义指令。

这里有一个实操细节：LAD功能块的静态变量（Static）在多次调用时保持各自的值，适合做状态记忆；临时变量（Temp）每次调用后清零，适合做中间计算。很多新手会把需要保持的状态误用Temp变量，导致功能块行为异常。这个坑我在早期项目里踩过，一个用Temp变量做计数中间值的FB，在多次调用后计数完全乱了，排查了半天才定位到变量类型问题。

另一个细节是边沿检测。LAD里的上升沿触点（P触点）需要配合一个存储位使用，这个存储位必须放在静态变量或全局DB里，不能放在Temp里。TIA Portal在编译时会检查这一点，但有时候警告容易被忽略。我习惯在FB里为每个边沿检测单独定义一个静态BOOL变量，命名规则是“Edge_”加信号名，这样既清晰又不会遗漏。

2.3 LAD的调试与在线监控技巧

LAD的在线监控是它最大的优势。下载程序后，点击“在线”按钮，所有触点的通断状态、线圈的得电状态、功能块的输入输出值都会实时显示。绿色表示导通，蓝色表示断开，灰色表示未扫描。对于排查逻辑错误，这种可视化反馈比任何调试工具都直接。

但有几个监控技巧值得掌握：

• 监控表配合使用：对于不在当前屏幕上的变量，可以建立监控表，把关键变量集中在一个表里实时观察。我习惯为每个设备区域建一个监控表，调试时切换表比滚动程序快得多。
• 强制与修改：调试时经常需要强制某个输入点或修改某个变量的值。TIA Portal支持在监控状态下直接修改BOOL变量，但要注意强制操作在下载或模式切换后会失效，不能作为长期手段。
• 交叉引用检查：在复杂项目里，一个变量可能在多个地方被读写。用交叉引用功能可以快速定位所有使用位置，避免遗漏。我通常在程序修改后跑一遍交叉引用，确认没有意外的地址冲突。

还有一个容易被忽视的点：LAD网络的执行顺序。PLC从上到下、从左到右扫描程序，后面的网络能看到前面网络的结果，但前面的网络看不到后面的。如果两个网络之间有逻辑依赖，顺序就至关重要。我见过一个项目因为网络顺序放反了，导致互锁逻辑失效，设备动作异常。后来养成的习惯是：在关键互锁网络前加注释，标明“此网络必须在XX网络之前执行”。

3. FBD功能块图：信号流的紧凑表达

3.1 FBD与LAD的本质联系与差异

FBD和LAD在TIA Portal里共享同一套底层指令系统，很多功能块在两种语言里可以互相转换。但它们的表达哲学不同：LAD强调“电路通断”，FBD强调“信号流动”。在FBD里，你看不到触点和线圈，看到的是与门、或门、非门、RS触发器、数学运算框，信号从左侧输入引脚进入，从右侧输出引脚流出。

这种表达方式在处理组合逻辑时特别高效。比如一个“三选二”表决逻辑，用LAD需要多个触点串并联，用FBD只需要两个与门和一个或门，信号流向一目了然。再比如模拟量处理，一个工程量转换需要做减法、乘法、加法、限幅，用FBD把这些功能框串联起来，数据流像水管一样从一端流到另一端，比LAD里分散的网络清晰得多。

但FBD的缺点也很明显：可读性依赖布局。如果功能框摆放混乱、连线交叉过多，程序会变得难以理解。我见过一个用FBD写的PID控制程序，功能框和连线铺满了整个屏幕，信号从左边绕到右边再绕回来，调试时根本追不上信号路径。后来我强制自己遵守一个规则：FBD程序里，信号流向必须从左到右、从上到下，不允许反向连线，复杂逻辑拆分成多个网络，每个网络只做一件事。

3.2 FBD在模拟量与运算处理中的优势

FBD最擅长的领域是模拟量处理和数学运算。在过程控制项目里，模拟量输入需要做量程转换、滤波、报警限值判断、累积计算，这些操作在FBD里可以用功能框直接串联，不需要中间变量。

以量程转换为例：一个4-20mA压力变送器，量程0-10MPa，PLC的模拟量输入模块将4-20mA转换为0-27648的整数。转换公式是：实际压力 = (原始值 - 0) / 27648 * 10.0。用FBD实现时，依次放置减法框、除法框、乘法框，把原始值、27648、10.0作为输入，输出就是实际压力。整个过程在一个网络里完成，不需要任何中间变量。

如果要做滤波，可以在后面串联一个一阶滞后滤波功能块，输入是原始值和滤波时间常数，输出是滤波后的值。TIA Portal的标准库里有现成的滤波块，直接拖出来用就行。这种“搭积木”式的编程方式，在FBD里比LAD自然得多。

还有一个FBD的隐藏优势：功能框的输入输出可以取反。在功能框的输入引脚上点右键，可以选择“取反”，引脚上会出现一个小圆圈，表示信号在进入功能框前先取反。这个特性在LAD里需要额外加一个常闭触点，在FBD里只是一个引脚属性，程序更紧凑。

3.3 FBD编程的注意事项与常见误区

FBD虽然直观，但有几个坑必须注意：

• 功能框的执行顺序：FBD网络里的功能框按照数据依赖关系执行，但如果两个功能框之间没有直接连线，它们的执行顺序由摆放位置决定。TIA Portal会按照从左到右、从上到下的顺序编译，但依赖隐式顺序的程序可读性很差。我的做法是：有依赖关系的功能框必须用连线明确表达，不允许依赖位置顺序。
• 数据类型的隐式转换：FBD功能框的输入输出引脚有数据类型，如果连接了不匹配的类型，TIA Portal会尝试隐式转换，但可能丢失精度或产生意外结果。比如把INT连接到REAL输入，整数会被自动转换，但把REAL连接到INT输入，小数部分会被截断。我习惯在关键位置显式使用转换指令，避免隐式转换带来的隐患。
• EN/ENO机制：FBD功能框有EN（使能）和ENO（使能输出）引脚。当EN为FALSE时，功能框不执行，ENO为FALSE。这个机制可以用来做条件执行，但如果多个功能框串联，ENO的连接需要特别注意。我见过一个项目因为ENO连接错误，导致某个计算在条件不满足时仍然执行了上一次的结果，造成数据异常。

还有一个经验：FBD程序在打印或截图时，如果网络太大，打印出来会看不清。我通常会把FBD网络控制在A4纸能打印清楚的范围内，超过就拆分成多个网络。这个习惯在项目交付时特别有用，甲方拿到打印版程序也能看懂。

4. SCL结构化控制语言：算法与数据处理的利器

4.1 SCL的语法基础与编程思维

SCL的语法接近Pascal，如果你写过C、Java、Python或者任何现代编程语言，上手SCL会很快。基本结构包括变量声明区、代码执行区，支持IF、CASE、FOR、WHILE、REPEAT等控制语句，支持算术运算、逻辑运算、比较运算、字符串处理、数组操作。

一个简单的SCL代码块示例：假设要计算一个数组中所有大于阈值的元素的平均值。用LAD做这件事需要循环展开，用SCL只需要几行：

FUNCTION_BLOCK "AvgAboveThreshold" VAR_INPUT Array : ARRAY[1..100] OF REAL; Threshold : REAL; END_VAR VAR_OUTPUT Average : REAL; Count : INT; END_VAR VAR i : INT; Sum : REAL; END_VAR BEGIN Sum := 0.0; Count := 0; FOR i := 1 TO 100 DO IF Array[i] > Threshold THEN Sum := Sum + Array[i]; Count := Count + 1; END_IF; END_FOR; IF Count > 0 THEN Average := Sum / Count; ELSE Average := 0.0; END_IF; END_FUNCTION_BLOCK

这段代码在LAD里实现同样的功能，至少需要100个比较网络加100个加法网络，程序体积和执行效率都不可接受。这就是SCL的核心价值：用循环和条件结构处理批量数据。

SCL的编程思维和图形化语言完全不同。写SCL时，你关注的是数据结构和算法流程，而不是信号的通断。这种思维切换需要练习，但一旦适应，处理复杂逻辑的效率会大幅提升。

4.2 SCL在数据处理与算法实现中的实战

SCL最典型的应用场景包括：配方管理、数据记录、PID算法变种、字符串处理、通信协议解析、数组排序与查找。

以配方管理为例，一个中型设备可能有几十个配方，每个配方包含几十个参数。用LAD做配方切换需要大量的MOVE指令和比较指令，程序冗长且容易出错。用SCL可以把配方定义成结构体数组，切换配方时只需要改变数组索引，所有参数自动更新：

TYPE "RecipeType" STRUCT Name : STRING[20]; Temperature : REAL; Pressure : REAL; Speed : REAL; Time : TIME; END_STRUCT END_TYPE FUNCTION_BLOCK "RecipeManager" VAR_INPUT RecipeIndex : INT; Load : BOOL; END_VAR VAR_OUTPUT CurrentRecipe : "RecipeType"; END_VAR VAR Recipes : ARRAY[1..50] OF "RecipeType"; Edge : BOOL; END_VAR BEGIN IF Load AND NOT Edge THEN IF RecipeIndex >= 1 AND RecipeIndex <= 50 THEN CurrentRecipe := Recipes[RecipeIndex]; END_IF; END_IF; Edge := Load; END_FUNCTION_BLOCK

这个FB封装了配方管理的核心逻辑，外部只需要给出配方号和加载信号，就能获取完整的配方数据。这种封装性在LAD里很难做到，因为LAD的功能块对结构体数组的支持有限。

另一个SCL的强项是字符串处理。在需要与上位机或MES系统通信的项目里，经常要拼接和解析字符串。SCL提供了CONCAT、LEFT、RIGHT、MID、FIND等字符串函数，处理起来比LAD灵活得多。我做过一个项目，需要把设备状态拼接成JSON格式发送给上位机，用SCL写了一个通用的JSON构建函数，所有设备状态通过数组传入，函数内部循环拼接，代码量不到100行，用LAD写至少需要500个网络。

4.3 SCL代码的组织与调试方法

SCL代码的组织方式直接影响可维护性。我的习惯是：

• 一个FB只做一件事：不要把配方管理、报警处理、通信解析混在一个FB里。每个FB有明确的职责，通过输入输出参数与外部交互。
• 变量命名规范：输入变量用“i_”前缀，输出用“o_”前缀，静态变量用“s_”前缀，临时变量用“t_”前缀。这个习惯来自西门子的编程规范，在大型项目里能显著提升代码可读性。
• 注释密度：SCL代码的注释不是“解释代码在做什么”，而是“解释为什么这样做”。比如一个限幅逻辑，注释应该说明限幅值的来源和依据，而不是重复代码本身。

SCL的调试和LAD不同。LAD可以直观看到每个触点的状态，SCL需要借助监控表或断点。TIA Portal支持在SCL代码里设置断点，程序运行到断点处会暂停，可以查看所有变量的当前值。这个功能在调试复杂算法时非常有用，但要注意断点调试会暂停PLC扫描周期，在线调试时不能长时间停在断点处，否则会影响设备运行。

另一个调试技巧是用监控表批量监控变量。SCL代码里的变量通常比较多，逐个在代码里查看效率低。我习惯在监控表里把关键变量按功能分组，调试时打开对应的监控表，所有相关变量一目了然。TIA Portal V21的监控表支持导出和导入，可以把调试好的监控表保存下来，下次调试直接加载。

还有一个容易忽视的点：SCL代码的编译优化。TIA Portal在编译SCL时会做优化，但优化级别可以调整。在项目属性里，可以设置编译优化级别，级别越高，生成的代码越紧凑，但编译时间越长。对于最终交付版本，我通常用最高优化级别；对于调试版本，用默认级别以便于调试。

5. 三种语言混编策略与选型实践

5.1 混编的边界与接口设计

S7-1500允许在同一个项目里混用LAD、FBD、SCL，甚至可以在同一个FB里用不同语言编写不同网络。但混编不是随意混，需要遵循一些原则：

• 按功能分层：设备控制层用LAD，数据处理层用SCL，模拟量处理用FBD。层与层之间通过明确定义的接口交互。
• 接口标准化：不同语言编写的FB之间通过输入输出参数交互，参数的数据类型和含义必须明确。我习惯为每个FB写一个简短的接口说明，包括参数含义、取值范围、调用条件。
• 避免循环依赖：FB之间的调用关系应该是单向的，避免A调用B、B又调用A的情况。如果确实需要双向交互，通过全局DB或共享变量实现。

一个典型的混编架构：主程序（OB1）用LAD写，负责调用各个功能块和处理设备级逻辑；模拟量处理FB用FBD写，负责信号转换和滤波；配方管理、报警记录、通信解析用SCL写，负责数据处理和算法实现。这种架构下，每种语言都在自己擅长的领域工作，整体程序结构清晰。

5.2 从项目规模看语言选型

项目规模是选型的重要参考。我按经验划分了几个档次：

这个表格不是绝对的，但能反映一个趋势：项目越大，SCL的占比越高。原因很简单：大型项目的复杂度不在于单个设备的逻辑，而在于设备之间的协调、数据的流转、状态的同步。这些用图形化语言表达会非常臃肿，用SCL可以用数据结构和算法来管理。

5.3 团队协作中的语言规范

在团队项目里，语言选型不只是技术问题，还是协作问题。如果团队里有人只会LAD，有人只会SCL，混编策略就需要考虑人员分工。我的做法是：

• 制定编程规范：明确哪些功能用哪种语言，变量命名规则，注释要求，FB接口标准。规范一旦确定，所有人都要遵守。
• 代码审查：定期做代码审查，检查是否符合规范，逻辑是否正确。审查时重点关注接口一致性和异常处理。
• 文档同步：每个FB都要有对应的文档，说明功能、参数、调用示例。文档和代码同步更新，避免脱节。

我经历过一个项目，因为前期没有统一规范，三个人用三种风格写程序，最后集成时接口对不上，变量名冲突，调试花了两周时间。后来痛定思痛，制定了详细的编程规范，后续项目再没出现过类似问题。

6. 常见问题与排查技巧实录

6.1 语言选型相关的典型问题

问题一：LAD程序网络过多，维护困难。这是最常见的抱怨。解决方案不是换语言，而是优化程序结构。把重复的逻辑封装成FB，用LAD写一次，多次调用。如果逻辑本身就很复杂，考虑用SCL重写。我的一般原则是：如果一个LAD网络超过20个触点，或者一个FB超过50个网络，就应该考虑用SCL替代。

问题二：SCL程序调试困难，看不到中间状态。SCL确实没有LAD的直观监控，但可以通过监控表和断点弥补。我的习惯是在SCL代码的关键位置插入临时变量，把中间计算结果赋值给临时变量，然后在监控表里观察。调试完成后删除临时变量。另一个技巧是用“监控”功能，在SCL代码里选中一个变量，右键选择“监控”，可以在代码旁边直接显示当前值。

问题三：FBD程序打印后看不清。FBD网络太大时，打印或截图会丢失细节。解决方案是拆分网络，每个网络控制在10个功能框以内。另外，TIA Portal支持调整FBD的显示比例，在打印设置里可以设置缩放比例，但缩放后字体可能变小。我通常把FBD网络拆到A4纸能1:1打印的程度。

6.2 混编项目的排查速查表

6.3 独家避坑经验

坑一：FB的Temp变量在多次调用间不保持。这是新手最容易犯的错误。Temp变量在每次FB调用结束后清零，如果用它做状态记忆，行为会完全不可预测。我见过一个用Temp变量做计数器的FB，在单次调用时正常，多次调用后计数完全乱了。解决方案：需要保持的状态一律用Static变量或全局DB。

坑二：SCL的FOR循环在PLC上执行时间过长。SCL的FOR循环在PLC上是顺序执行的，如果循环次数太多（比如遍历10000个数组元素），会显著增加扫描周期。我做过测试，一个10000次的FOR循环在S7-1516上大约需要2-3ms，如果每个扫描周期都执行，扫描周期会明显变长。解决方案：把大循环拆分成多次小循环，或者用状态机分步执行。

坑三：FBD的ENO连接错误导致逻辑异常。FBD功能框的ENO输出表示功能框是否成功执行。如果多个功能框串联，前一个的ENO连接到后一个的EN，当第一个功能框不执行时，后面的也不执行。这个机制本身没问题，但如果误把ENO当作普通输出使用，会导致逻辑错误。我见过一个项目把比较框的ENO连接到输出线圈，结果比较条件不满足时线圈也不输出，完全违背了设计意图。

坑四：LAD的置位/复位指令在多次调用时状态冲突。如果同一个置位/复位指令在多个地方出现，或者在一个扫描周期内被多次执行，最终状态取决于最后执行的那次。这种问题在大型项目里很难排查。我的做法是：置位/复位指令只在一个地方出现，用交叉引用检查确认。

坑五：SCL字符串处理未考虑编码问题。SCL的STRING类型默认使用ASCII编码，如果处理中文或特殊字符，需要确认编码格式。TIA Portal V21支持Unicode字符串，但需要显式声明。我做过一个项目，上位机发送的字符串包含中文，SCL解析时出现乱码，后来改用WSTRING类型才解决。

7. 从选型到落地的完整实践建议

7.1 新项目的语言选型流程

接手一个新项目时，我通常按以下流程做语言选型：

1. 梳理功能清单：把项目需要实现的功能列出来，按类型分类：设备控制、模拟量处理、数据处理、通信、报警、配方。
2. 评估复杂度：对每个功能评估逻辑复杂度和数据量。简单布尔逻辑标记为LAD，模拟量运算标记为FBD，批量数据处理标记为SCL。
3. 确定人员能力：了解团队成员的编程背景，如果以电气人员为主，LAD占比要高；如果有软件背景，SCL可以承担更多。
4. 制定混编方案：确定各功能模块的语言，定义接口标准，规划程序结构。
5. 原型验证：对关键功能做原型验证，确认选型方案可行。

这个流程看起来繁琐，但能避免后期返工。我见过太多项目因为前期选型随意，后期维护成本极高。

7.2 现有项目的语言迁移策略

如果接手一个已经用单一语言写好的项目，想迁移到混编架构，需要谨慎。我的建议是：

• 不要为了迁移而迁移：如果现有程序运行稳定、维护正常，没必要大规模重构。只在新增功能时采用新的语言策略。
• 逐步替换：从最痛的点开始，比如把最复杂的LAD数据处理逻辑用SCL重写，验证效果后再推广。
• 保持接口兼容：迁移后的FB接口要和原FB一致，避免影响调用方。
• 充分测试：迁移后的代码要经过完整测试，包括正常工况和异常工况。

7.3 我个人在实际操作中的体会

做了这么多年项目，我对三种语言的感情是：LAD是根基，FBD是工具，SCL是武器。LAD让我能快速搭建设备逻辑，和电气人员无障碍沟通；FBD让我在处理模拟量和组合逻辑时保持清晰；SCL让我能实现复杂的算法和数据处理，把程序从“能用”提升到“好用”。

但语言只是工具，真正决定程序质量的是架构设计和编程规范。我见过用LAD写出优雅程序的高手，也见过用SCL写出混乱代码的新手。选对语言只是第一步，更重要的是理解每种语言的适用边界，在合适的场景用合适的工具。

最后分享一个小技巧：在TIA Portal里，可以给每个FB设置“语言”属性，指定用哪种语言编辑。如果打开一个FB发现语言不对，可以在FB属性里切换语言，TIA Portal会自动转换。但要注意，LAD和FBD之间的转换是无损的，SCL和图形化语言之间的转换是有损的，复杂逻辑转换后可能需要手动调整。这个功能在维护旧项目时特别有用，可以快速查看不同语言下的程序结构。