1. 工控人绕不开的三座大山：LAD、FBD、STL到底怎么选

刚入行那会儿，我第一次打开STEP7 TIA博图，看到新建块时弹出的语言选择框，整个人是懵的。LAD、FBD、STL三个选项摆在那里，每个都认识，但每个都不知道什么时候该用。后来在产线上摸爬滚打了几年，做过冷库监控、红绿灯控制、抢答器、大棚灌溉这些典型的PLC项目，才慢慢摸清楚这三种语言各自的脾气。

这篇文章就是把我这些年踩过的坑、总结出来的经验，系统地聊一聊。不管你是刚接触西门子PLC的新手，还是从三菱、汇川转过来的老手，只要你在用STEP7或者TIA博图，这三种编程语言的基本概念、适用场景和切换技巧，都是必须吃透的基本功。我会从实际项目出发，告诉你什么场景该用什么语言，怎么在博图里灵活切换，以及那些只有真正调试过设备才知道的细节。

先给一个最直观的结论：LAD是给电工和现场调试人员看的，FBD是给习惯逻辑门电路的人用的，STL是给追求效率和灵活性的老手准备的。但这只是最粗的划分，实际项目中三者往往是混用的。一个典型的西门子PLC程序，可能主程序用LAD写，方便现场排查；数据处理和复杂运算用STL写，追求执行效率；模拟量处理和逻辑运算用FBD，因为看起来更接近信号流。

注意：TIA博图和STEP7 V5.x在语言支持上有差异。TIA博图支持LAD、FBD、STL、SCL、GRAPH等多种语言，而STEP7 V5.x主要支持LAD、FBD、STL三种。如果你是从STEP7 V5.6升级到TIA博图的，这一点要特别留意。

2. 三种语言的核心概念拆解：从继电器到逻辑门再到指令表

2.1 LAD梯形图：电工看得懂的编程语言

LAD的全称是Ladder Diagram，中文叫梯形图。它的设计初衷就是让习惯了继电器控制柜的电工能够平滑过渡到PLC编程。你打开一个LAD程序块，看到的就是一条条横线，左边是母线，右边是输出线圈，中间是各种触点、线圈、功能块。这些符号和继电器电路图几乎一一对应：常开触点就是继电器常开触点，常闭触点就是常闭触点，线圈就是继电器线圈。

这种对应关系不是巧合，而是刻意设计的。早期PLC就是用来替代继电器控制柜的，所以编程语言必须让现场电工能看懂。我见过很多老电工，他们不懂什么数据类型、指针、间接寻址，但看LAD程序比看什么都明白。一条产线出了故障，他们拿着图纸对着LAD程序，顺着线路一路查下去，很快就能定位到问题。

LAD的核心元素包括：触点（常开、常闭、上升沿、下降沿）、线圈（普通线圈、置位、复位）、功能块（定时器、计数器、比较器、数学运算等）。这些元素通过导线连接，形成完整的逻辑回路。一个典型的LAD程序段，左边是输入条件，右边是输出结果，中间是逻辑处理。

LAD最大的优势是直观。程序执行顺序一目了然，从左到右、从上到下，和继电器电路的分析方法完全一致。现场调试的时候，你可以直接在程序上看到哪个触点是通的、哪个线圈是得电的，不需要额外工具就能快速判断。博图还支持在线监控，程序运行时触点和线圈的状态会实时显示，绿色表示通，蓝色表示断，非常直观。

但LAD也有明显的局限。复杂逻辑处理能力弱，比如多层嵌套的条件判断、循环、指针操作，用LAD写会非常臃肿。数据处理能力也有限，虽然博图的LAD支持数学运算和移动指令，但写起来远不如STL灵活。另外，LAD程序占用的存储空间相对较大，对于资源紧张的PLC来说，可能是个问题。

2.2 FBD功能块图：逻辑门电路的直系后代

FBD的全称是Function Block Diagram，中文叫功能块图。如果你学过数字电路，看到FBD会觉得特别亲切，因为它就是逻辑门电路的图形化表达。与门、或门、非门、异或门，这些在数字电路里用符号表示的逻辑关系，在FBD里用方框和连线表示。

FBD的核心是信号流。信号从左边输入，经过功能块处理，从右边输出。功能块可以是简单的逻辑运算（AND、OR、NOT），也可以是复杂的数学运算（加、减、乘、除、PID控制等）。多个功能块可以串联、并联，形成复杂的信号处理网络。

我刚开始用FBD的时候，觉得它比LAD抽象，不如LAD直观。但用久了发现，FBD在处理模拟量信号和复杂逻辑运算时，比LAD清晰得多。比如一个PID控制回路，用LAD写需要调用PID功能块，然后处理各种参数，程序段会拉得很长；用FBD写，PID功能块就是一个方框，输入输出一目了然，参数设置也集中在一个地方。

FBD的另一个优势是便于模块化设计。你可以把常用的逻辑封装成自定义功能块，然后在主程序里反复调用。这在大型项目中特别有用，比如多条相同的产线、多个相同的控制回路，封装一次，到处复用。

但FBD也有缺点。程序执行顺序不如LAD直观。LAD是从左到右、从上到下，FBD虽然也有执行顺序，但信号流的方向可能和阅读顺序不一致，初学者容易搞混。另外，FBD的在线监控不如LAD直观，虽然博图也支持FBD的在线监控，但显示效果不如LAD的触点和线圈那么一目了然。

2.3 STL语句表：追求效率和灵活性的终极武器

STL的全称是Statement List，中文叫语句表。它是三种语言中最接近机器指令的，也是效率最高、最灵活的。STL程序由一条条指令组成，每条指令占一行，执行顺序就是书写顺序。

STL的指令分为几大类：位逻辑指令（A、AN、O、ON、=、S、R等）、定时器指令（SD、SF、SP、SE等）、计数器指令（ZV、ZR、ZS等）、数据传送指令（L、T等）、数学运算指令（+I、-I、*I、/I等）、比较指令（==I、<>I、>I等）、跳转指令（JU、JC、JZ等）、指针和间接寻址指令等。

STL最大的优势是执行效率高。同样的逻辑，用STL写通常比LAD和FBD占用的存储空间小，执行速度也更快。这在大型项目中特别重要，因为PLC的扫描周期直接影响控制精度。我做过一个高速包装线的项目，扫描周期要求控制在5ms以内，用LAD写怎么优化都超，后来把关键部分改成STL，扫描周期降到了3ms左右。

STL的另一个优势是灵活性强。LAD和FBD能做的事情，STL都能做；但STL能做的事情，LAD和FBD不一定能做。比如间接寻址、指针操作、循环、复杂的条件跳转，这些在STL里很自然，在LAD和FBD里就很别扭甚至无法实现。

但STL的缺点也很明显。可读性差，特别是对于不熟悉STL的人来说，一堆指令堆在一起，根本看不出逻辑关系。调试困难，STL的在线监控只能看到累加器和寄存器的值，不像LAD那样直观地看到触点和线圈的状态。对编程人员要求高，需要熟悉PLC的寄存器模型、寻址方式、指令系统，学习曲线比较陡。

提示：在TIA博图中，STL程序块可以转换为LAD或FBD，但转换不是无损的。复杂的STL逻辑转换后可能变得非常臃肿，甚至无法转换。所以如果项目后期可能需要转换，最好从一开始就规划好语言选择。

3. 语言切换的实操技巧：什么时候换、怎么换、换了之后注意什么

3.1 语言切换的典型场景

在实际项目中，语言切换通常发生在以下几种场景：

场景一：从LAD切换到STL优化性能。这是最常见的场景。项目初期用LAD快速搭建逻辑，功能验证通过后，发现某些程序段扫描周期太长，或者存储空间不够，就把这些程序段改成STL。我通常会把频繁调用的子程序、复杂的数学运算、大数据量的数据处理改成STL，主程序和逻辑控制部分保留LAD。

场景二：从STL切换到LAD方便调试。有时候接手别人的项目，核心逻辑是用STL写的，看起来非常费劲。这时候可以把STL程序块复制一份，尝试转换成LAD，虽然转换后可能比较臃肿，但至少能看懂逻辑。看懂之后再回到STL版本去修改。

场景三：从FBD切换到LAD适应现场习惯。有些项目现场维护人员习惯了LAD，看到FBD就头疼。这时候可以把FBD程序块转换成LAD，虽然逻辑关系一样，但现场人员看起来更顺眼。

场景四：混合编程。这是最推荐的方式。一个程序块用一种语言，不同程序块用不同语言。比如主程序OB1用LAD，数据处理FC用STL，模拟量处理FB用FBD。这样各取所长，既保证了可读性，又保证了性能。

3.2 在TIA博图中切换语言的具体步骤

在TIA博图中切换程序块的语言，操作路径是：右键点击程序块 -> 属性 -> 常规 -> 语言，然后在下拉菜单中选择目标语言。但这里有几个关键点需要注意：

第一，不是所有程序块都能随意切换。OB、FB、FC都可以切换语言，但有些程序块如果包含了特定语言的专有元素，切换时可能会报错。比如LAD程序块里如果用了LAD专有的触点线圈，切换到STL时会被转换成对应的STL指令，但反过来从STL切换到LAD时，如果STL里用了LAD不支持的指令，就无法转换。

第二，切换语言后程序逻辑可能发生变化。虽然博图会尽量保持逻辑一致，但由于不同语言的执行模型有差异，切换后需要仔细验证。特别是涉及扫描周期、边沿检测、定时器这些与执行顺序相关的逻辑，切换后一定要重新测试。

第三，切换前建议先备份。我吃过这个亏，有一次把一个复杂的STL程序块切换到LAD，转换后程序变得面目全非，想切回STL发现原来的版本已经被覆盖了。从那以后，我养成了一个习惯：切换语言前，先把程序块复制一份，或者导出源文件备份。

3.3 语言切换后的验证要点

切换语言后，不能直接下载运行，必须经过验证。我的验证流程通常是这样的：

第一步，静态检查。在博图里打开切换后的程序块，逐段检查逻辑是否和原来一致。重点关注边沿检测、定时器、计数器、跳转这些容易出问题的指令。

第二步，仿真测试。用PLCSIM或者PLCSIM Advanced做仿真，模拟各种输入条件，观察输出是否符合预期。这一步可以发现大部分逻辑错误。

第三步，在线调试。下载到实际PLC或者仿真PLC，在线监控程序运行状态，观察关键变量的值。如果条件允许，最好做一次完整的工艺流程测试。

第四步，性能对比。如果切换语言的目的是优化性能，需要对比切换前后的扫描周期、存储占用等指标。博图可以在线查看这些数据。

注意：PLCSIM Advanced在启动仿真时可能会遇到启动不了且没有报错的情况，这通常是因为虚拟网卡配置有问题，或者之前的仿真实例没有完全关闭。可以尝试重启电脑，或者检查虚拟网卡的IP设置是否和项目中的PLC地址冲突。

4. 三种语言在典型项目中的实战应用

4.1 十字路口红绿灯程序：LAD的主场

红绿灯控制是PLC入门的经典案例，也是LAD最擅长的场景。一个标准的十字路口红绿灯，通常有东西向和南北向两组灯，每组灯有红、黄、绿三色，加上倒计时显示，逻辑关系清晰，时序要求明确。

用LAD写红绿灯程序，思路非常直接：用定时器控制各个灯的点亮时间，用比较指令或者计数器控制倒计时，用互锁逻辑保证东西向和南北向不会同时绿灯。程序段从左到右，从上到下，执行顺序一目了然。现场调试的时候，哪个灯不亮，直接看对应的程序段，很快就能定位问题。

如果用STL写红绿灯程序，虽然也能实现，但可读性会差很多。一堆定时器指令、比较指令、赋值指令堆在一起，不仔细看根本看不出逻辑关系。所以对于这种逻辑清晰、时序明确的控制程序，LAD是最佳选择。

但红绿灯程序也有复杂的地方，比如夜间模式（黄灯闪烁）、紧急模式（全红）、手动控制模式等。这些模式切换如果用LAD写，程序段会比较多，但逻辑依然清晰。如果用STL写，可以用跳转指令实现模式切换，程序会更紧凑，但可读性会下降。

4.2 冷库监控系统：FBD和STL的配合

冷库监控系统是我做过的一个比较典型的项目，涉及温度采集、PID控制、报警处理、数据记录等功能。这个项目里，三种语言都有用到，但主力是FBD和STL。

温度采集和PID控制用FBD写。温度传感器信号经过模拟量输入模块转换成数字量，然后经过标定转换成实际温度值，再送入PID功能块进行控制。FBD的信号流非常清晰：传感器信号 -> 标定 -> PID -> 输出 -> 执行器。每个环节都是一个功能块，参数设置集中，调试的时候可以单独调整每个环节。

报警处理和数据记录用STL写。报警处理涉及大量的比较、判断、延时、确认逻辑，用STL写效率高、灵活性强。数据记录涉及数组操作、指针寻址、循环，这些用STL写很自然，用LAD和FBD写就很别扭。

主程序和模式切换用LAD写。主程序负责调用各个子程序、处理模式切换、管理设备启停。这部分逻辑用LAD写，现场维护人员看起来最顺眼。

这个项目的经验是：不要强行用一种语言写所有程序。每种语言都有它的适用场景，混合使用才能发挥最大优势。但混合使用也有代价，就是程序结构会复杂一些，需要做好文档和注释。

4.3 8人抢答器：STL的效率优势

抢答器程序看起来简单，但要做好并不容易。8人抢答器要求：8个抢答按钮，任何一个按下后，对应的指示灯亮，同时封锁其他按钮，直到主持人复位。这个逻辑用LAD写也能实现，但程序段会比较多，而且响应速度可能不够快。

用STL写抢答器，可以用字逻辑指令和位逻辑指令配合，实现快速响应。比如把8个抢答按钮的状态读入一个字节，然后用位逻辑指令判断哪个位先为1，再输出对应的指示灯。这种操作在STL里很自然，在LAD里就很麻烦。

抢答器的关键是响应速度和公平性。响应速度取决于PLC的扫描周期，STL的执行效率高，扫描周期短，响应更快。公平性取决于逻辑设计，要保证先按下的按钮一定先响应，不能因为扫描顺序导致后按下的反而先响应。这需要在STL里用边沿检测和优先级判断来实现。

提示：抢答器程序如果用LAD写，建议把抢答逻辑放在中断程序里，用硬件中断或者定时中断来保证响应速度。但中断程序用LAD写会比较复杂，用STL写更合适。

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

5.1 语言切换后程序不执行或执行异常

这是语言切换后最常见的问题。原因通常有几个：执行顺序变化、边沿检测失效、定时器行为差异、数据类型不匹配。

执行顺序变化是最隐蔽的问题。LAD和FBD的执行顺序是固定的（从左到右、从上到下），但STL的执行顺序就是书写顺序。如果切换后没有调整指令顺序，可能导致逻辑错误。比如一个先置位后复位的逻辑，在LAD里可能因为网络顺序而正确执行，切换到STL后如果顺序反了，结果就完全相反。

边沿检测失效也很常见。LAD和FBD有专门的边沿检测触点（P触点、N触点），STL里用FP、FN指令或者边沿检测位来实现。切换后如果边沿检测位没有正确分配，或者被其他程序段重复使用，边沿检测就会失效。

定时器行为差异也需要注意。LAD和FBD的定时器是功能块形式，有背景数据块；STL的定时器是直接使用定时器资源（T0、T1等），行为有差异。切换后要检查定时器的编号、类型、时间基准是否一致。

5.2 STL程序无法转换为LAD或FBD

STL程序无法转换为LAD或FBD，通常是因为STL里使用了LAD和FBD不支持的指令。比如间接寻址、指针操作、循环指令、复杂的跳转指令等。这些指令在STL里很自然，但LAD和FBD没有对应的图形化表示。

遇到这种情况，有几个处理方式：一是保留STL版本，不强行转换；二是把STL程序拆分成多个程序段，把能转换的部分转换成LAD，不能转换的部分保留STL；三是用SCL（结构化控制语言）重写，SCL虽然也是文本语言，但比STL更接近高级语言，可读性更好。

我个人的建议是：如果STL程序逻辑复杂，不要强行转换成LAD。转换后的LAD程序可能非常臃肿，可读性反而下降。不如保留STL版本，但加上详细的注释和文档，方便后续维护。

5.3 在线监控时看不到预期状态

在线监控是调试PLC程序的重要手段，但有时候监控状态和预期不一致。常见原因有：程序块没有被调用、监控的是离线程序、变量被其他程序段修改、PLC处于停止模式。

程序块没有被调用是最常见的原因。博图里可以单独打开一个程序块进行在线监控，但如果这个程序块没有被主程序调用，监控状态就不会更新。这时候需要检查调用关系，确保程序块在运行。

监控的是离线程序也很常见。博图里可以同时打开离线和在线程序，如果不小心看的是离线程序，监控状态当然不会更新。这时候需要确认打开的是在线程序块。

变量被其他程序段修改也需要注意。同一个变量可能在多个程序段里被读写，如果监控的是写入前的值，可能和预期不一致。这时候需要用交叉引用功能，查看变量的所有使用位置。

5.4 常见问题速查表

提示：博图的交叉引用功能是排查问题的利器。通过交叉引用，可以快速查看某个变量、某个程序块、某个定时器的所有使用位置，避免遗漏。

6. 从STEP7 V5.x升级到TIA博图的注意事项

6.1 语言支持的差异

STEP7 V5.x和TIA博图在语言支持上有明显差异。STEP7 V5.x主要支持LAD、FBD、STL三种语言，而TIA博图除了这三种，还支持SCL、GRAPH、CFC等。如果你是从STEP7 V5.x升级到TIA博图的，需要了解这些新语言的特点和适用场景。

SCL（Structured Control Language）是结构化控制语言，语法类似Pascal，适合写复杂的算法和数据处理。GRAPH是顺序功能图，适合写状态机类的程序。CFC是连续功能图，适合写模拟量处理和过程控制。

从STEP7 V5.x升级到TIA博图时，原有的LAD、FBD、STL程序可以导入，但可能需要进行一些调整。比如STEP7 V5.x的STL指令和TIA博图的STL指令有细微差异，导入后需要检查。STEP7 V5.x的定时器、计数器在TIA博图里也有变化，需要重新配置。

6.2 程序块结构的差异

STEP7 V5.x的程序块结构是OB、FB、FC、DB，TIA博图也是类似的结构，但有一些变化。比如TIA博图引入了优化块和非优化块的概念，优化块访问速度更快，但不支持绝对地址访问；非优化块兼容STEP7 V5.x的访问方式，但速度较慢。

从STEP7 V5.x升级到TIA博图时，原有的程序块默认是非优化块，可以保持兼容。但如果新建程序块，建议使用优化块，以获得更好的性能。优化块和STL的配合需要特别注意，因为STL里的绝对地址访问在优化块里可能无法使用。

6.3 调试方式的差异

STEP7 V5.x的调试主要靠在线监控和变量表，TIA博图的调试功能更丰富，除了在线监控和变量表，还有跟踪、测量功能、诊断等。跟踪功能可以记录变量随时间的变化曲线，对于分析时序问题非常有用。测量功能可以测量程序段的执行时间，对于优化性能很有帮助。

从STEP7 V5.x升级到TIA博图时，需要花时间熟悉这些新功能。我刚开始用TIA博图的时候，觉得在线监控不如STEP7 V5.x方便，后来发现是没找对方法。TIA博图的在线监控需要先建立在线连接，然后才能监控程序块，和STEP7 V5.x的操作习惯不太一样。

注意：STEP7 V5.6 SP1及后续版本在升级到TIA博图时，需要注意项目文件的兼容性。建议先用STEP7 V5.6打开项目，另存为低版本格式，再导入TIA博图。直接导入高版本项目可能会失败。

7. 给新手的几点实在建议

7.1 先精通一种，再扩展其他

我见过很多新手，一开始就想把LAD、FBD、STL都学会，结果每种都学个半吊子。我的建议是：先精通LAD。LAD是最直观、最容易上手的，也是现场调试最常用的。把LAD学透了，理解了PLC的扫描机制、输入输出处理、定时器计数器这些基本概念，再学FBD和STL就会容易很多。

LAD学到什么程度算精通？能独立完成一个中等复杂度的项目，能看懂别人的LAD程序，能快速定位和解决现场问题。达到这个程度，再学FBD和STL，就是水到渠成的事情。

7.2 多动手，少看书

PLC编程是实践性很强的技能，看书看视频只能入门，真正提高要靠动手。我的建议是：买一个二手PLC或者用仿真软件，自己动手写程序。从最简单的电机启停开始，到红绿灯、抢答器、流水线控制，一步步增加难度。每写一个程序，都要下载运行，观察实际效果，分析问题原因。

仿真软件推荐PLCSIM和PLCSIM Advanced。PLCSIM适合基本的逻辑仿真，PLCSIM Advanced支持更复杂的仿真场景，包括网络通信、OPC UA等。但PLCSIM Advanced对电脑配置要求较高，启动时可能会遇到各种问题，需要耐心配置。

7.3 养成好的编程习惯

好的编程习惯比技术本身更重要。我总结了几条：程序结构清晰，主程序只负责调用，具体逻辑放在子程序里；变量命名规范，用有意义的名称，不要用M0.0、M0.1这种；注释详细，每个程序段、每个关键变量都要有注释；版本管理，每次修改都要备份，标注修改内容和日期。

这些习惯在项目小的时候看不出优势，但项目大了、维护时间长了，优势就非常明显。我接手过很多别人的项目，有的项目虽然功能实现了，但程序结构混乱、变量命名随意、注释几乎没有，维护起来非常痛苦。所以从一开始就养成好习惯，受益无穷。

7.4 关注实际需求，不要过度设计

新手容易犯的一个错误是过度设计。一个简单的电机启停，非要用STL写，还要加各种保护、各种模式，结果程序复杂得自己都看不懂。我的建议是：根据实际需求选择方案，不要为了炫技而复杂化。能用LAD简单实现的，就不要用STL；能用基本指令实现的，就不要用高级指令。

当然，这不是说不要学习高级技术，而是说要在合适的场景使用合适的技术。一个红绿灯程序，用LAD写就很好，没必要用STL。一个复杂的算法，用STL或者SCL写更合适，就不要强行用LAD。判断标准很简单：哪种方式让程序更清晰、更易维护、更高效，就用哪种。

7.5 多和现场人员交流

PLC编程最终是为现场设备服务的，所以要多和现场人员交流。电工、操作工、维修工，他们对设备的了解往往比程序员更深入。他们知道哪个环节容易出问题、哪个操作容易误触、哪个报警最频繁。这些信息对编程非常有价值。

我做过一个冷库项目，最初按照常规逻辑设计，后来和现场操作工聊天，发现他们实际使用中有很多特殊需求，比如夜间要降低报警音量、除霜周期要根据季节调整等。这些需求在技术文档里是看不到的，只有和现场人员交流才能发现。

提示：现场调试时，建议带上笔记本电脑和编程电缆，随时准备修改程序。很多问题只有在实际运行中才会暴露，现场修改是最快的解决方式。但修改前一定要备份原程序，避免改出问题后无法恢复。

8. 关于AI辅助PLC编程的一些观察

最近两年，AI辅助编程工具越来越多，有人问AI能不能写PLC程序。我的观察是：AI可以辅助，但不能替代。AI可以根据描述生成LAD、STL或者SCL代码片段，对于标准逻辑（比如电机启停、定时控制、PID）生成的质量还不错。但PLC编程涉及大量的现场知识、设备特性、安全要求，这些是AI不掌握的。

我试过用AI生成一些标准程序段，比如星三角启动、正反转控制，生成的代码基本可用，但需要人工检查和调整。AI生成的代码往往缺少必要的保护逻辑、注释不完整、变量命名不规范。所以AI可以作为提高效率的工具，但不能完全依赖。

对于新手来说，AI可以帮助理解一些基本概念和标准程序，但不能代替动手实践。PLC编程的核心能力是分析问题、设计逻辑、调试优化，这些能力需要通过实际项目来培养。AI可以给你答案，但不能给你经验。

9. 最后分享几个实用小技巧

技巧一：善用书签和网络注释。博图支持在程序块里添加书签和网络注释，对于大型程序，合理使用书签可以快速定位到关键程序段。我习惯把每个功能模块的起始位置加书签，调试的时候直接跳转，效率很高。

技巧二：用变量表批量监控。博图的变量表可以同时监控多个变量的值，比逐个程序块监控效率高。我习惯把关键变量整理到一个变量表里，调试的时候打开变量表，所有关键状态一目了然。

技巧三：用跟踪功能分析时序问题。时序问题用在线监控很难分析，因为变化太快。博图的跟踪功能可以记录变量随时间的变化曲线，对于分析定时器、边沿检测、状态切换这些问题非常有用。

技巧四：定期导出源文件备份。博图的项目文件是二进制格式，损坏后很难恢复。建议定期导出源文件（.scl、.stl、.lad等），用文本格式备份。这样即使项目文件损坏，也能从源文件恢复。

技巧五：建立自己的程序库。把常用的功能块（比如PID控制、报警处理、数据记录）封装成自定义功能块，建立自己的程序库。新项目直接调用，省时省力。我这些年积累了几十个自定义功能块，新项目至少能省30%的开发时间。

这些技巧看起来简单，但都是实际项目中总结出来的，用好了能大幅提高效率。PLC编程是个需要不断积累的活，技术更新不快，但经验值钱。多动手、多总结、多交流，时间长了自然就成了。