企业官网建设流程全解析

简介：《PLC程序常用100案例》是一份面向三菱PLC初学者与工业自动化现场工程师的实例合集，覆盖电机启停与正反转控制、Modbus RTU串行通讯、模拟量采集处理、触摸屏监控界面设计等典型工程任务，能够帮助读者将基础指令转化为可运行的设备控制方案。压缩包共714个文件、约33.01MB，工程文件以GX Works2/Developer项目（gpj/gps/gxw）为主，搭配触摸屏画面（wpa/wpg/wcd）、参数配置与数据库文件（inf/mdb）以及PDF说明、演示图片和少量视频，便于按案例索引、复制程序和修改测试。目前已有3913人学习。除常规的电机控制逻辑外，案例还给出了Modbus通讯的寄存器读写配置、模拟量模块量程设置与数值换算方式，并包含GT触摸屏与PLC联动的设计示例；同时收录了文本屏与变频器485通讯的实测工程，适合作为现场排错、程序移植和通讯调试的参考资料。

1. 一份“PLC程序常用100案例.rar”被搜索时，真正在找什么

当检索框里出现“PLC程序常用100案例.rar”这种带文件扩展名的搜索词，意图通常不是“学PLC”，而是想直接拿到一份能跑的工程文件，最好是解压即用、能抄能改。但反直觉的结论是：这类案例包下载量很大，真正派上用场的比例很低。原因不在文件本身，而在打开方式——多数人直接全量解压，却漏掉了目录结构里的品牌分区、程序后缀对应的软件版本，以及案例里已经隐含的接线习惯。对一个五年以上经验的工程师来说，这份rarl包的价值同样不在“100个程序”，而在于它是一次现场逻辑的抽样：起保停怎么写、定时器怎么排队、顺序控制怎么切步。这篇顺着这条线，把案例包拆开，读完目录再读代码，最后回到文件本身的安全习惯上。

2. 拆开案例包：目录结构、命名规则与工程文件怎么认

2.1 按品牌分目录，不只是整理习惯

大多数网上流传的PLC程序案例包会先按厂商分目录：西门子、三菱、欧姆龙、台达、汇川，再往下一层放应用场景名，比如“电机控制”“恒压供水”“包装线”“步进伺服”。按品牌分目录有实际原因：PLC程序的语言方言差异比想象中更大。同样是电机启保停，三菱GX Works里写LD X0 / OR Y0 / ANI X1 / OUT Y0，西门子TIA Portal用A I0.0 / O Q0.0 / AN I0.1 / = Q0.0，而欧姆龙又是另一套英式助记符。案例包如果不分区，新手很容易把三菱的X/Y地址直接套到西门子上，上来就编译报错。

这类目录还有一个隐藏价值：它能直接反映程序的年代。案例里出现大量M0.0中间继电器、CPU型号是S7-300的，大概率是STEP 7 V5.x的老项目；出现DB块和UDT自定义类型的，才可能是TIA Portal时代的东西。拿到文件先看目录树，比打开工程更快。

2.1.1 文件后缀就是程序的方言标识

工程文件的后缀最能说明问题。常见对应关系如下表，这也是我拿到案例包后第一眼要看的东西：

这里最容易踩的坑是：rar 包里的文件夹叫“西门子1200案例”，里面放的却是.zap15_1的旧工程文件——TIA Portal V13/V14 打不开 V15 的备份，不是程序坏了，是版本问题。我一般先看后缀再决策，能省下大量下载软件的时间。

2.2 用最小命令把RAR变成可检索的文件清单

我在本地拿到这种案例包，第一件事不是解压，而是先生成文件清单。用unrar的lb参数只输出包内文件路径，不加任何额外信息，方便后面用grep筛后缀：

unrar lb PLC程序常用100案例.rar > manifest.txt # 筛出 PLC 工程文件后缀 grep -E "\.(awl|scl|zap15_1|ap15_1|gxw|gpp|cxp|smc)$" manifest.txt | head -n 80 # 看有没有分卷压缩 grep -E "part[0-9]+\.rar$" manifest.txt | head -n 10

lb是 list bare 的缩写，相比l参数，它不打印时间戳和压缩比，输出纯路径，方便脚本处理。第二步把常见的 PLC 工程后缀筛出来，能看出这套案例里哪类程序占比最高。第三步查part1.rar这样的分卷文件——如果源文件是分卷压缩，只下第一个卷是解不开的，这是下载站资源最常出的问题。

如果机器上连unrar都没有，可以先用7z l列出内容，效果接近，只是输出格式略宽。这里不推荐直接把整个包解压到桌面上再翻文件夹，案例包动辄几百兆，里面常混入 PDF 手册、触摸屏组态文件，甚至无关的安装包，先在清单层过滤是效率最高的习惯。

2.3 解压时的中文乱码与跨平台处理

这类案例包大多在国内制作传播，Windows 上压包时文件名用的是 GBK 编码。在 Linux 或 macOS 下解压，文件名会显示成乱码。原因很直接：RAR 文件头里没有显式编码标记，解压工具默认按系统编码读取，跨平台时 GBK 被当成了 UTF-8 或 Latin-1。unrar x命令本身不提供指定编码的参数，常见的做法是用 Python 的rarfile库在解压后做一次重命名：

import rarfile import os rf = rarfile.RarFile("PLC程序常用100案例.rar") rf.extractall("workspace") for info in rf.infolist(): # 文件名先按 cp437 取回原始字节，再按 GBK 解码 raw_name = info.filename.encode("cp437", errors="replace") real_name = raw_name.decode("gbk", errors="replace") src = os.path.join("workspace", info.filename) dst = os.path.join("workspace", real_name) if src != dst and os.path.exists(src): os.rename(src, dst)

这里cp437是解压工具在无法识别编码时常用的“逃生”编码：它把每个字节原样映射回字符，再从字符恢复字节，就能拿到原始文件名序列。随后用gbk解码成正确中文。这个技巧在处理老案例包时几乎必用，尤其是包含三菱案例的目录，因为 GX Developer 时代的注释和文件名大量依赖 Shift-JIS 和 GBK 的本地化习惯。

提示：如果案例包是从网盘下载的，优先确认是否为分卷压缩。part1.rar缺少后续分卷时，某些工具会报“压缩包已损坏”，实际是文件不完整，重新下载缺失分卷即可，不要直接删包重下。

3. 从100个案例里抽出的四类PLC程序骨架

3.1 起保停电路：几乎所有案例包都绕不开的底层逻辑

案例包里的程序五花八门，但九成以上的电机控制、阀门控制、泵控制都能拆成一个起保停电路：启动信号置位输出，输出自保持，停止信号优先复位。AI 生成 PLC 代码的模型也是在大量这种结构上学出来的。用一个结构化文本 ST 写最小逻辑：

// 电机起保停：停止优先 IF "stop_btn" THEN "motor" := FALSE; ELSIF "start_btn" THEN "motor" := TRUE; END_IF;

为什么先判断停止再判断启动？因为当启动和停止按钮同时按下时，这段逻辑里停止优先，输出为 OFF。对设备安全来说，停止信号永远应该具备最高优先级。案例包里有些老程序是反着写的，先把启动传给输出，再用停止去复位，这在启动信号常闭点接法下也能工作，但若外部接线改成了常开点，同时按下时会产生竞争。拿到案例先看停止信号在 IF 里的位置，比看注释更可靠。

三菱案例包中对应的指令表写法是：

// 三菱 FX 系列指令表 LD X0 // 启动按钮 OR Y0 // 自保持回路 ANI X1 // 停止按钮，常闭点 OUT Y0 // 电机输出

这段的OUT Y0是把它之前的逻辑结果写入线圈。两者的差异值得注意：西门子和三菱在“停止按钮是接常闭还是常开”这件事上的约定不同，案例包里的程序是按它本身接线画的，复制到现场时务必按实际硬件点表重新映射地址，不能照抄硬点。

3.2 定时器不是用在“延时”上，而是用在“排队”上

新手看案例里的 TON 指令，第一反应是“延时启动”。实际上工业程序用定时器解决的是排队问题。多台电机同时启动会造成母线压降冲击，案例里的标准做法是用一个定时器链错开启动相位：

// 两台电机错峰启动，第二台延时 2 秒后置位 "T_Start2"(IN := "start_cmd", PT := T#2S); "motor1" := "start_cmd"; IF "T_Start2".Q THEN "motor2" := TRUE; END_IF;

注意这段代码只演示了定时器相位关系，真实工程里motor2必须另加自保持逻辑，否则start_cmd断开后motor2会跟着复位。TON 的PT是预设时间，ET是已计时时间，IN为 TRUE 时ET增加，达到PT后Q输出 TRUE；IN一旦变 FALSE，ET清零。这是 TON 与 TOF 的本质区别：TON 是延时接通，TOF 是延时断开。

同一个案例包里不同品牌的定时器也略有差异，比如三菱的T0是累积型还是掉电保持，要看标注里的T0 K200还是T0 D0。K200是常数预设，D0是数据寄存器预设，后者意味着定时值可以在触摸屏上在线修改。判断案例包设计水平，就看定时器预设是写死在程序里还是放在寄存器里。

3.3 模拟量不是“算出来”的，是“映射出来”的

案例包里恒压供水、温度控制这类程序必然带模拟量处理。PLC 的 AD 模块把 4-20mA 或 0-10V 信号转换成整型原始值，西门子 S7-1200/1500 的单极性原始值范围是 0 到 27648，不是 0 到 65535。很多人把 27648 当成 65536 直接除，导致工程量永远偏小。

// 将 0-27648 原始值映射到 0.0 - 100.0 工程量 "pv_real" := "pv_raw" * 100.0 / 27648.0;

27648 这个数字来自西门子模拟量模块的 15 位精度加符号位，16 位整数的有效范围是 0 到 27648。三菱 FX 系列则不同，常见的是 0 到 4000 原始值。这就是跨品牌抄程序最容易翻车的地方。

案例包里常见的 FC105 (SCALE) 调用本质上就是这个公式，只是它内部还做了上下限钳位。自己写映射公式时别忘了做限幅，否则输入线断掉时原始值可能跳到 32767，算出来的工程量会大到荒谬，控制器会出现错误的超限报警。

3.4 顺序控制的状态机骨架

案例包里“全自动车床”“立体车库”“分选线”这类程序，表面看很复杂，拆开就是一组步进状态。老式程序用 M 继电器的置位复位实现步进，可读性差。更清晰的写法是用一个整型变量做当前步号，配合 CASE 语句：

// 三步循环：夹紧 -> 进给 -> 退回 CASE "step_no" OF 0: // 待机 IF "start_cmd" THEN "step_no" := 10; END_IF; 10: // 夹紧 "clamp" := TRUE; IF "clamp_done" THEN "step_no" := 20; END_IF; 20: // 进给 "feed" := TRUE; IF "feed_pos_ok" THEN "step_no" := 30; END_IF; 30: // 退回 "feed" := FALSE; IF "home_pos" THEN "step_no" := 0; "clamp" := FALSE; END_IF; END_CASE;

步号用 10、20、30 而不是 1、2、3，是刻意留白。设备调试到一半要在“夹紧”和“进给”之间增加一道“检测”工序，步号 15 直接插进去就行。用 1、2、3 连续编号，插入一步意味着后面所有步号重排，这种教训在案例包的注释里经常能看到“预留步号”的说法。所有步进处理的退出条件必须互斥：clamp_done和feed_pos_ok不能同时为 TRUE，否则状态跳转会混乱。案例包里这一步通常由外部传感器保证，但作为抄程序的人，最好在逻辑里再互锁一次。

4. 把案例还原成能跑的最小工程：从RAR到仿真闭环

4.1 虚拟机里打开老案例的软件组合

老案例包里的.gxw和.cxp工程常见于三菱 GX Works2 和欧姆龙 CX-One，这些软件在 Windows 10/11 新版系统上安装困难，常见方案是装一台 Windows 7 x86 虚拟机。虚拟机网络模式的选择影响 PLC 仿真的通信，特别是用 TIA Portal 连 PLCSIM 时：

用 VMware 跑 TIA Portal 时，连接 PLCSIM 的虚拟网卡 IP 必须与 PLCSIM 实例在同一子网。网卡选错会造成仿真器里看不到设备，问题不在程序而在网络模式。如果只做仿真，我一般直接用 Host-only 模式，把虚拟网卡 IP 固定成192.168.0.1，PLCSIM 实例设192.168.0.100，稳定且互不干扰。

4.2 电机启保停案例的最小还原步骤

以最常见的西门子 S7-1200 案例为例，从 rar 包中的源程序还原到本地仿真，按下面步骤走。注意这里的变量地址必须匹配案例源程序里的 I/O 映射，否则下载后强制表对不上：

第一步新建 TIA Portal 项目，选择与实际案例匹配的 CPU 型号。第二步在 PLC 变量表里建立上表变量，注意停止按钮的地址是%I0.1而不是%I0.2，案例源程序的注释和地址是一一对应的，改一个地址就要检查相关联的自保持回路。第三步在 OB1 里写启保停 ST 逻辑，第四步点击“仿真”按钮并下载到 PLCSIM，第五步打开监控表，强制start_btn为 TRUE，观察motor是否置位。

下载到 PLCSIM 时，最容易卡住的是“PG/PC 接口”选择。TIA Portal 的下载对话框里必须选 “PLCSIM” 而非实体网卡。选错后状态栏会一直提示“未找到设备”。还有一种常见情况：案例包里的程序用到了 S7-1200 固件 V4.0 的指令，但本地装的 PLCSIM 是 V3.0，下载时会报“模块不兼容”，这时需要修改项目里的 CPU 固件版本，而不是重装软件。

4.3 用强制表验证案例的边界条件

仿真不是“跑通了”就算完。案例包里的程序未必覆盖所有边界，最常见的隐患是停止按钮按下后再次启动需要等待的时序。在 PLCSIM 监控表里同时强制start_btn和stop_btn为 TRUE，观察输出必须是 FALSE 且不抖动。这个动作能验证程序里的停止优先级是否真的生效。

值的一提的是，用 PLCSIM 仿真模拟量案例时，原始值不是直接填 20.0，而是填 5530 之类的整型原始值。例如案例里要求模拟量输出对应 20% 的阀门开度，4-20mA 的 4mA 对应原始值 0，20mA 对应 27648，20% 开度对应原始值约 5529。在强制表里填错单位，PID 调节的积分项会一路饱和，画面表现是阀门全开全关来回震荡，案例程序本身没有错，错在仿真输入的口径不对。

5. 把RAR案例包用干净的三个文件层技巧

5.1 解压前先跑完整性校验，而不是等报错

下载站的案例包体积大、分卷多，传输损坏很常见。全量解压到一半报“CRC 失败”，浪费的时间足够重下两遍。我解压前固定两条命令：

sha256sum PLC程序常用100案例.rar unrar t PLC程序常用100案例.rar

sha256sum先算校验值，与下载页提供的哈希对比；页面没给哈希就跳过，直接跑unrar t。t是 test 参数，逐文件测试 CRC，输出“All OK”就说明压缩包物理完整。分卷包必须把所有分卷放在同一目录再测试，缺一卷时测试会直接报错，并指出缺哪个卷号。

5.2 跨平台解压时先切后台，避免误改封面图片和PDF

如果 rar 包里有触摸屏组态图片、PDF 手册这类资源文件，它们在 Linux 下解压出来同样有乱码问题。把全部文件重命名成 UTF-8 的脚本在 2.3 节提过，但整包跑这个脚本时要注意：info.filename里可能混入目录分隔符，需要用os.path.dirname和os.path.basename分开处理后再拼接。否则目录名修好了，文件名还是乱码，等于只修了一半。实际做法是直接对manifest.txt先做一次过滤，只处理工程后缀的文件，资源文件即使乱码也不影响程序导入。

5.3 关于rar密码和案例包再分发的边界

网上流传的案例包偶尔带密码保护。有人试图用十六进制编辑器查 RAR 文件头里的密码，这在 RAR5 格式下行不通——加密数据用的是 AES-256，包头不存在可读的密码校验位。看到.part1.rar后缀加密码的组合，直接回下载来源页找密码，或者放弃，比盲目跑字典更实际。

注意：带密码的案例包往往来自企业项目脱敏后的产物。解压后如发现包含真实设备 IP 段、工艺配方或人员工号，这属于敏感工程数据，不应再打包传播。把用不上的文件从解压目录里清掉，只保留工程本身，是保留案例知识又少惹麻烦的处理方式。这个习惯比任何压缩工具都值钱——你处理过的每一个 PLC 工程，都携带现场业务信息，压缩和解压只是表象，真正要管住的是数据流向。

本文还有配套的精品资源，点击获取