企业官网建设流程全解析

前两年接手了一个隧道照明改造项目，业主要求很明确：把隧道里那段24小时全天候亮着的灯，改成能自动调光的智能照明控制系统，车来全亮、车走半亮、白天关闭入口段加强照明，还要在值班室用触摸屏看到整套系统的运行状态。项目本身不算大，但因为同时涉及西门子S7-200 PLC和MCGS组态软件，要输出完整的梯形图程序、接线图设计方案和上位机组态画面，中间踩了不少坑。这篇文章就把这套系统的完整设计过程写出来，从控制策略到I/O分配，从梯形图到组态画面，再到现场调试遇到的实际问题，适合正在做PLC毕业设计、或者手头接到类似中小型照明改造项目需要快速上手的工程师参考。

1. 为什么用"PLC+组态"这套路线来做隧道照明

1.1 隧道照明的控制难点：不是简单的天亮关灯、天黑开灯

隧道照明跟普通道路照明不一样，它有很明显的"黑洞效应"和"白洞效应"。白天车辆刚进隧道时，人眼从亮处突然进入暗处需要适应时间，所以隧道入口段必须加强照明；深夜隧道里没什么车，如果整条隧道还保持全亮度运行，电费浪费非常严重。再加上隧道中间段和出口段的亮度需求也不同，这就决定了隧道照明不能只靠一个光控开关解决，最少也要分成"入口加强照明""基本照明""应急照明"几个回路来分别控制。

目前大部分隧道改造项目的需求都集中在这几点：能自动检测隧道内外光照度、能联动车辆检测信号、能分时段调光，还要能实时看到每个照明回路的工作状态。这种需求用纯继电器回路也能做出来一部分，但方案改动一次就要重新接线，而且"白天/夜间/来车/无车"这种多条件组合逻辑，用硬逻辑实现起来非常痛苦。PLC天生就是干这个的——输入条件多、输出逻辑可编程、扩展方便，改控制逻辑不用动一根线。MCGS组态负责把PLC内部的位和字变量变成值班人员看得懂的图形界面，这就是整套系统的核心价值。

1.2 S7-200都停产了，为什么还选它

说句实话，西门子S7-200从2013年就停产了，但市场上现存的隧道、泵站、水处理、小型产线里，它仍然大量在运行。我选它有两个现实原因：

• 这条隧道原本就有PLC控制柜，里面装的正好是S7-200 CPU224，改造时可以继续用，只需要增加模拟量处理和相关模块。
• S7-200的指令系统足够简单，市面上教材和案例多，业主后续维护时找人接手成本低，备件也不难找。

如果你是拿这个题目做毕业设计，选S7-200还有一个额外好处：MCGS官方驱动里有专门的"S7-200 PPI"驱动，组态连线上非常顺，网上参考案例一抓一大把，比直接用S7-1200配MCGS少踩很多驱动兼容性的坑。

1.3 MCGS组态在中小型项目里的性价比优势

MCGS组态软件分为嵌入版和通用版，在中小型自控项目里普及度极高。正版授权费用比WinCC、iFIX这些低不少，运行硬件也灵活——可以用MCGS自家的TPC系列触摸屏，也可以装在普通工控机上跑。它支持通过串口PPI协议读写S7-200，也支持以太网方式连接S7-200 SMART。

隧道照明这种项目，I/O点数几十个，画面要求直观、报警要求简单，MCGS完全够用，而且本地化技术服务资料多，遇到问题很容易搜到解决方案。

2. 系统硬件选型与I/O分配，从"照度检测"到"回路控制"

2.1 系统架构和核心设备清单

系统整体分为三层。最上层是MCGS触摸屏，通过RS485连接S7-200 PLC；中间层是PLC处理光照模拟量、车辆检测开关量、运行模式切换，输出控制接触器；底层是照明回路，包括入口加强照明、基本照明和应急照明。

这是我的设备清单，大部分都是市面上常见、好采购的型号：

用户在做这类项目时要注意，S7-200 CPU224XP自带2路模拟量输入，电压型的，0-10V范围。如果用的是4-20mA变送器，就要在模拟量输入端子处并联一只250欧姆精密电阻，把电流信号转成1-5V电压信号再进PLC，这也是工程上最常用的做法。新手容易漏掉这个电阻，直接接上去后数值要么满量程要么乱跳，这不是程序问题，是信号没有完成转换。

2.2 I/O地址分配表：提前规划能省一半调试时间

I/O分配是整套系统的"地图"，必须在写程序之前确定，而且每个点要有明确含义。我的分配表如下：

这里要重点解释一下"基本照明A组/B组"的设计思路。隧道基本照明灯具数量多，要降低亮度时不可能把整条隧道的灯全关掉，那样太危险。实务中把基本照明的灯具按奇偶分成两路，A组和B组。全亮时Q0.1和Q0.2同时吸合；半亮时只吸合A组、断开B组；深夜无车时基本照明全部关闭，只留应急照明。这个"分组调光"方案比用0-10V调光驱动器成本低得多，控制逻辑也简单，在中小型隧道改造项目中非常实用。

2.3 接线图设计里最容易出问题的几个地方

接线图是整个项目的"硬件骨架"，我画过几次以后总结出几个容易踩坑的点：

1. 输入回路的公共端接法。S7-200的开关量输入端子既可以接源型也可以接漏型，取决于1M、2M公共端接DC24V正极还是0V。我一般习惯采用源型接法：公共端接DC24V正极，传感器、旋钮的触点接到对应输入点。接反了也不会烧设备，但信号检测会失效。

2. 模拟量输入的量程设置。如果用了EM231扩展模块，模块顶部的DIP开关必须按变送器量程拨码。EM231出厂默认是0-5V量程，如果接的是4-20mA变送器，需要先在外围并联250欧姆电阻，再把DIP开关拨到对应档位。这个问题说明书写得不太显眼，很多现场"AIW0读数永远最大或为零"基本都是这个原因。

3. PLC输出触点的保护。S7-200继电器输出触点容量一般是2A，直接控制接触器线圈虽然能吸合，但感性负载的拉弧会明显缩短触点寿命。标准做法是PLC输出先驱动DC24V中间继电器，中间继电器触点再控制AC220V接触器线圈。同时，接触器线圈两端要并接RC吸收回路或压敏电阻。中间继电器线圈是直流的，还要反向并联续流二极管。

4. RS485通信线的压接。MCGS触摸屏COM口和S7-200的PORT0口都是DB9接口，PPI通信只用3脚和8脚。用屏蔽双绞线做通信线时，屏蔽层要在PLC端单点接地。通信线接反（3对8）会导致通讯时好时坏，这是现场排查时最先要确认的。

3. 梯形图程序设计的核心：三段式调光与车检联动

3.1 先把控制策略画成状态表再写程序

写梯形图之前，我习惯先把控制逻辑整理成一张状态表，把每种工况下各个输出该是什么状态定义清楚。这套项目的状态表如下：

这个策略的来源是《公路隧道照明设计细则》对入口段、中间段和过渡段亮度的基本要求。工程项目里不可能做到每个区段精确调光，但把隧道分成"加强、全亮、半亮、应急"四个亮度档位，配合车检联动，已经能满足大多数改造项目的验收要求。

3.2 关键网络段的指令表写法

梯形图程序我按"主程序+子程序"结构组织。主程序处理模式判断和手自动切换，子程序分为光强采集换算、车检信号防抖延时、照明回路输出、报警四块。下面给出几个关键网络段的写法，用STL指令表展示，方便理解梯形图背后的逻辑流。

模拟量采集和线性换算。配合CPU224XP的AIW0通道，把1-5V对应的AIW数值转换为光照度的工程值。S7-200模拟量输入4-20mA对应0-32000，但电压输入1-5V对应的数值是6400-32000，所以换算公式是：Lux = (AIW0 - 6400) × 2000 / (32000 - 6400)，即 (AIW0-6400) × 1000 / 12800。

Network 1 模拟量采集与线性换算 LD SM0.0 MOVW AIW0, VW100 MOVW VW100, VW102 -I +6400, VW102 *I +1000, VW102 /I +12800, VW102

注意S7-200的整数乘法容易溢出，所以我在程序里把换算系数控制在1000，测量值7000左右时结果在合理范围内。如果需要更高精度，建议用双整数运算，把AIW0先转成VD区再计算。

车辆检测信号的上升沿捕捉。车检器给出的是一个电平信号，车辆进入检测区时触点闭合。如果直接用常开触点驱动全亮逻辑，车辆一直停在检测区时全亮状态会一直保持，逻辑上是错的。正确做法是用上升沿指令EU，只在触点闭合的瞬间置位一个内部中间继电器M0.1，然后用M0.1启动T37延时定时器，30秒后自动复位。

Network 2 车检信号上升沿捕捉与30秒延时 LD I0.1 EU S M0.1, 1 LD M0.1 TON T37, 300 LD M0.1 AN T37 = Q0.1 = Q0.2 LD T37 R M0.1, 1

这段逻辑里T37是100ms定时器，设定值300就是30秒。车辆经过后，Q0.1和Q0.2同时吸合，全亮30秒；30秒后T37动作，M0.1复位，Q0.1/Q0.2释放，系统自动回到半亮状态。这里有个工程细节：夜间无车时基本照明A组保持半亮，所以车来全亮结束以后恢复的其实是"半亮"而不是全灭，复位逻辑要避免把Q0.1也断开。

夜间半亮逻辑。光照度低于200Lux且没有车检信号时，基本照明A组保持吸合，B组断开。用比较指令实现：

Network 3 夜间基本照明半亮 LDW< VW102, +200 AN M0.1 AN T37 AN I0.0 = Q0.1

这里要注意，VW102里存的是换算后的光照度工程值，所以比较指令用的是VW102而不是AIW0直接比较。AN I0.0是自动模式的限定条件，手动模式下跳过自动逻辑。

3.3 手自动切换与安全互锁的实现

手动模式下的控制权在触摸屏。我在PLC里定义了一组V区位变量，触摸屏上的操作按钮写入这些V区，例如V0.2对应加强照明手动开启、V0.3对应基本照明A组手动开启。手动逻辑和自动逻辑通过I0.0互锁：

Network 4 手动模式加强照明控制 LD I0.0 AN I0.4 = Q0.0

这里把I0.4（回路故障反馈）串进回路作为互锁保护，手动或者自动模式下，只要接触器反馈异常，输出都会被切断。很多事故都是因为把互锁做在组态软件脚本里，而不是做在PLC梯形图里。一旦触摸屏和PLC通信断开，组态里的互锁就失效了，PLC侧必须自己保证安全。

应急照明回路Q0.3不参与任何调光逻辑，PLC上电即输出。同时从硬件层面做冗余：即使PLC处于停止状态，应急照明也可以通过控制柜内单独的断路器回路保持供电，这在隧道运维中是硬性要求，灯可以少亮但不能全灭。

4. MCGS组态画面设计：设备窗口怎么配，画面怎么画

4.1 设备窗口添加S7-200驱动

我用的是MCGS嵌入版组态环境，触摸屏型号TPC7062K。新建工程后第一步配置设备窗口。双击"设备窗口"，在工具箱里找到"通用串口父设备"，先把父设备添加到窗口，然后在其下挂"西门子S7-200/PPI"子设备。

这里有个新手特别容易犯的错：只添加子设备不添加父设备，或者反过来，结果通讯一直失败。MCGS的设备窗口结构必须是"父设备下面挂子设备"，这是它的规定，跟PLC里子程序的嵌套逻辑类似。

串口参数设置如下，需要和PLC侧的PPI配置保持一致：

S7-200的PPI通信口默认波特率是9600，地址是2。如果你的PLC地址被改过，或者波特率被Micro/WIN软件改过，触摸屏这边一定要跟着改，否则设备窗口会一直显示"通讯失败"。

4.2 变量连接与寄存器映射：统一走V区最省事

MCGS里有两层变量，一层是"实时数据库变量"，另一层是"设备变量"，二者通过"设备通道连接"绑定在一起。和很多组态软件不同，MCGS的画面元件不能直接引用设备变量，必须通过实时数据库变量中转，这是它跟WinCC不太一样的地方。

我习惯让PLC程序把所有需要监控的状态都集中放到V区，组态侧只读写V区，避免一会读I点一会读Q点，来回切换地址格式容易出错。具体映射如下：

PLC程序里要做一段数据传送，把I0.0、I0.1、Q0.0、Q0.1这些实际开关状态搬到V区。虽然PPI驱动理论上可以直接读写I/Q/M区，但统一走V区有一个实际好处：调试时在触摸屏端看到的数据列表和PLC程序里的监视表完全对应，哪个点有问题一目了然。

4.3 用户窗口的布局思路与动画连接

画面布局我采用"总览式"设计：一张隧道剖面图，左右是洞口，中间是隧道段。每个照明回路用图形元件表示灯的位置，亮灯显示绿色，灭灯显示灰色。顶部放几个关键数字：当前光照度、运行模式（白天/夜间/来车）、报警状态。操作区放在画面右侧，布置"自动/手动切换""加强照明强制开启""基本照明强制开启"等按钮。

动画连接方面，灯元件不需要用复杂图库，用MCGS自带的"图元"画一个圆或灯形，加上"动画显示"的"可见度"属性即可：变量值为1时显示亮色图层，变量值为0时显示灰色图层或隐藏。这种方式对新手最友好，后续维护时改颜色也方便。

操作按钮要加权限管理。维护人员现场检修时需要强制点亮某一回路，但不能让普通值班人员随意操作。MCGS的用户权限管理里，把操作按钮设置的"操作权限"指向维护组账号，默认登录的用户只有查看权限，这样多了一层安全防护。

4.4 运行策略里做报警、趋势曲线和存盘

MCGS的"运行策略"相当于轻量级脚本环境，可以定时执行一段类似BASIC的脚本。我在这里做了三件事：

第一，每500毫秒把光照度值赋给趋势曲线的数据源，生成实时趋势图，值班人员能看到一天内的光照度变化；第二，定时扫描PLC的报警位V0.4，为1时弹出报警窗口并在报警数据库中记录时间和内容；第三，整点统计照明回路累计运行时长，存入本地数据库，可查询日报表。

脚本写法比较简单，例如报警判断大致是：

IF 设备变量_报警位 = 1 THEN !ALARM("照明回路故障", 1) ENDIF

实际脚本中设备变量的名称是在设备通道连接时确定的，这里不展开写具体界面路径。需要提醒的是，MCGS默认的报警记录存在内存中，掉电会丢。要做历史报警存盘，必须在运行策略里添加"存盘"设置，把报警数据写入本地数据库文件。这个配置藏得比较深，很多新手做完画面以为报警记录了，断电后才发现什么都没留下。

5. 现场调试踩过的坑和一点改进方向

5.1 通讯一直报错：排查链路分享

第一次现场上电时，MCGS设备窗口一直显示"通讯失败"，我按下面几步排查的，这条链路对类似问题通用：

1. 先确认串口号。触摸屏上用COM1问题不大，但如果在电脑上用USB转串口线连接PLC，要打开设备管理器确认是COM5而不是COM3。我遇到过到底哪个COM口才是正确端口的尴尬情况。
2. 再查接线。PPI是RS485半双工通信，A/B对应DB9的第3脚和第8脚，不能接反。屏蔽层在PLC端单端接地。那次最终发现的问题就是通信线用的是普通USB转TTL线，电平不匹配，换成带隔离的USB转RS485模块后马上恢复。
3. 最后查地址。S7-200的PPI地址可能是2，也可能被Micro/WIN软件改成其他值，用原厂编程电缆查看CPU通信地址，确保与MCGS设备地址一致。

排查顺序遵循"从物理层到协议层再到应用层"的顺序，不要一上来就怀疑是程序问题。通讯类故障九成在物理层。

5.2 模拟量漂移和红外误触发的处理

光照模拟量在隧道现场很容易受车灯、路灯叠加影响，数值跳变很大。我在程序里加了数字滤波，连续采集5次求平均。S7-200做平均时要注意累加结果的溢出问题，或者用移位寄存器的方式保存最近5次采样值，每来一个新值就替换最旧的。代码结构不过多展开，核心思路就是滑动平均。

红外车检器误触发是另一个高频问题。隧道内壁潮湿，红外反射面脏了会造成误报；安装角度如果正对洞口阳光方向，午后也容易误触。我的做法是调整安装位置，避免正对光源，同时在程序里给车检信号加防抖延时，持续低电平超过5秒才认为是一次有效车检。用T38做5秒延时，延时时间到后取上升沿置位M0.1，这样大部分干扰脉冲都会被过滤掉。

5.3 光照度分区与加强照明的补充控制

在完整项目中，光照控制会更精细。隧道的入口段、过渡段、中间段、出口段照度需求不同，我还会在程序里增加分区阈值：超过2000Lux判断为白天，关闭入口加强照明；200到2000Lux之间判断为过渡状态，入口加强照明保持低亮度；低于200Lux判断为夜间，入口加强照明常亮。这个三段阈值用比较指令实现，程序结构和前面写的类似，只是比较的目标从VW102换成不同的光照度变量。

需要补充的是，隧道口光照变送器的安装位置很有讲究。不能正对洞口朝里面装，那样会直接照射到洞内灯具的反光，数值失真严重。应该装在隧道口外侧靠近洞顶的位置，探头朝上偏外，采集环境漫射光，这样才能反映驾驶员接近隧道时真实的人眼适应亮度。

5.4 S7-200停产后的替代与升级思路

虽然S7-200存量还很多，但新项目我一般建议直接用S7-200 SMART或S7-1200。S7-200 SMART的通信口支持以太网和RS485，MCGS新版驱动也支持S7-200 SMART，程序结构基本可以平移，成本并没有高多少。比较明显的区别是模拟量扩展不再需要拨码开关，直接在STEP 7-MicroWIN SMART软件的系统块里组态量程，反而更不容易出错。

如果你拿这个题目做毕业设计，也可以把整套控制逻辑移植到S7-200 SMART上，组态用MCGS嵌入版或通用版，画面设计逻辑完全一致。唯一要注意的是驱动选择：MCGS对应S7-200 SMART的驱动名称和S7-200 PPI驱动不一样，串口参数中PLC地址、波特率设置界面也有差异，但整体设计流程是通用的。

最后说一点个人体会：整套系统调试下来，控制逻辑本身并不复杂，真正耗时间的往往是现场那根通信线、那个拨码开关、那个PLC地址。S7-200加MCGS这套组合虽然技术上不算新，但对中小型隧道照明改造项目来说，性价比和稳定性的平衡做得相当好。如果你正在做类似的照明或小型控制系统，建议开工前先把控制策略画成状态表，再把组态变量和PLC地址做一张映射表，调试阶段能少走一半弯路。