1. 为什么停车场收费这种“小系统”要上PLC和组态软件
先说一个最常见的质疑：一个停车场出入口，无非就是地感线圈检测车辆、道闸抬杆落杆、读卡器扣费、LED屏显示剩余车位，听起来单片机甚至继电器电路都能做，为什么非要绕一圈上PLC加组态软件？我最早也有这个疑问，直到真正接手了一个要求联网管理、带数据追溯、还要跟后续监控平台对接的项目，才彻底想明白。
单片机能做控制，但它的强项是逻辑运算和通信协议处理，弱项恰恰是电气控制层需要的可靠性和抗干扰能力。停车场道闸电机、卷帘门、风机、照明这些负载，启动瞬间的电流冲击和现场电磁干扰是实打实的，单片机方案在实验室跑得再欢，现场一接电机就死机重启的例子我见过太多。继电器电路倒是皮实，可一旦收费规则变化，比如从“按次收费”改成“按时段收费”，改线改到怀疑人生，更别提统计报表这种需求，纯继电器电路根本做不了。
PLC恰好卡在中间：它本质就是工业级的专用计算机，梯形图编程天然贴近电气逻辑，数字量输入输出直接驱动接触器和传感器，Modbus、Profinet这类通信协议又是老本行。针对停车场这种场景，PLC负责底线安全——抬杆、落杆、防砸车、防重复扣费这些必须毫秒级响应的控制逻辑，全部由PLC本地搞定，不依赖上位机。而组态软件负责非实时部分——收费金额计算、车牌显示、剩余车位统计、时段费率下发、操作日志记录。控制归控制，管理归管理，两边各干各擅长的活，系统才稳得住。
这也就回答了标题里的“电气控制”到底指什么：它不是单纯的梯形图编程，而是从传感器选型、I/O分配、电气图纸设计、主回路与控制回路规划，到PLC程序逻辑、组态软件交互、通信参数整定的一整套系统工程。下面我按一个真实项目的搭建过程，把每个环节的关键决策和踩过的坑摊开讲。
2. 系统整体架构与硬件选型：先把“谁指挥谁”理顺
2.1 三层架构划分
先看整体框架，我习惯把停车场收费系统拆成三层：
- 设备层：地感线圈车辆检测器、读卡器/车牌识别一体机、道闸、LED显示屏、语音播报模块、报警灯。
- 控制层：PLC本体加扩展模块，负责所有数字量输入输出的采集与输出，同时通过串口或以太网和上层设备通信。
- 管理层：组态软件运行的工控机，提供人机交互界面，负责费率计算、数据存储和远程监控。
这里最容易犯的错误是试图让PLC直接处理车牌识别、图片存储这些高数据量任务。PLC不是不能做，但存储空间、运算速度都有限，而且杀鸡用牛刀。车牌识别交给一体机，识别结果通过RS485或者网口发给PLC，PLC只需要得到一个“车牌号字符串”和“识别成功”的开关量信号，这样逻辑最干净。
2.2 PLC选型的关键考量
选PLC不是越贵越好，而是看I/O点数和通信接口够不够。我以西门子S7-1200为例，停车场进出口各一个控制箱的典型配置：
- 数字量输入：入口地感1路、出口地感1路、道闸限位开/关到位各2路、读卡器/识别一体机开闸信号2路、手动按钮若干，加起来约10到12路。
- 数字量输出：抬杆继电器2路、落杆继电器2路、报警输出1路、道闸指示灯2路，约8到10路。
- 通信接口：至少1个RS485口用于连接读卡器或车牌识别一体机，1个以太网口用于连接上位机组态软件。
S7-1200的CPU 1214C自带14路DI和10路DO，基本是踩着可用线选的，余量不大，建议要么选1215C，要么加一个SM 1223数字量扩展模块，给调试留余地。没有余量的后果我们后面联调时会讲到，临时要加一个限位开关都得上导轨拆装模块，现场很狼狈。
2.3 组态软件的选型对比
组态软件这块，市面上常用的是WinCC、组态王、力控、杰控等。我个人的观点是：如果PLC选西门子，优先考虑WinCC，哪怕是最基础的WinCC Runtime，变量关联的原生性、驱动稳定性都远好于第三方组态。但如果项目预算卡得紧，组态王或者力控也完全够用，它们在Modbus通信上做得相当成熟，学习成本也低一些，网上资料多，遇到问题好搜。
选型时还有一点容易忽略：组态软件运行的操作系统版本。WinCC 7.x对Windows版本要求很敏感，装错版本可能全是坑，建议在项目一开始就确认工控机的操作系统，免得软件装一半卡在兼容性上。我见过有人拿着WinCC 7.3的安装包往Win10家庭版上装，折腾了整整两天最后乖乖换系统重装。
2.4 关键执行部件选型要点
道闸电机最好选带限位开关和遇阻反弹功能的型号。限位开关的接线方式要提前确认好，是常开还是常闭，是共用零线还是独立触点，这些直接决定PLC输入侧的接线方式。地感线圈车辆检测器要选灵敏度可调的，并且输出信号要确认是脉冲还是电平，大多数检测器可以在“车到输出”和“车走输出”两种模式间切换，我们要的是“车到”信号。读卡器或车牌识别一体机的开闸信号，如果自带继电器输出，就按干接点接入PLC输入；如果是电平输出，一定要注意电平逻辑是NPN还是PNP，接错直接烧输入点。
3. 电气图纸设计与I/O分配：细节决定一把火烧不烧
3.1 电源拓扑规划
电气控制柜内部电源规划是第一步，也是很多人马虎的地方。停车场控制柜一般有三组电源：
- 220V交流主电源，给PLC电源模块、道闸电机、照明和风扇供电。
- 24V直流开关电源，给PLC输入输出模块、传感器、继电器线圈供电。
- 12V或5V直流电源，给读卡器、车牌识别一体机等设备供电。
这里有一条重要原则：不同电压等级的信号线和动力线必须分开走线。24V信号线和220V动力线如果扎在同一个线槽里，电机启停瞬间的电磁干扰会直接窜进PLC输入信号，轻则信号误触发，重则损坏输入模块。我见过一个现场，道闸一动作，读卡器就死机，最后查出来就是220V线和RS485通信线走了一个线管，间距太近，把通信线重新单独走管后问题消失。
3.2 I/O点分配表
画接线图之前，先把I/O表列清楚。以下是我习惯用的一个出入口I/O分配模板，供参考：
| PLC地址 | 信号名称 | 信号类型 | 说明 |
|---|---|---|---|
| I0.0 | 入口地感A | DI | 车道入口处地感，车到置1 |
| I0.1 | 出口地感A | DI | 车道出口处地感，车到置1 |
| I0.2 | 道闸开到位反馈 | DI | 闸杆完全抬起，常开触头闭合 |
| I0.3 | 道闸关到位反馈 | DI | 闸杆完全落下，常开触头闭合 |
| I0.4 | 道闸防砸触发 | DI | 落杆过程中检测到障碍物 |
| I0.5 | 读卡器开闸请求 | DI | 读卡/识别OK后由一体机输出脉冲 |
| Q0.0 | 抬杆继电器 | DO | 驱动道闸电机正转 |
| Q0.1 | 落杆继电器 | DO | 驱动道闸电机反转 |
| Q0.2 | 报警输出 | DO | 非法闯入/故障时驱动声光报警器 |
| Q0.3 | 通行指示灯绿 | DO | 允许通行时点亮 |
| Q0.4 | 通行指示灯红 | DO | 禁止通行时点亮 |
注意，道闸电机的正反转控制，如果电机自带控制盒，PLC的输出点只控制控制盒的“开”和“关”信号，不直接驱动接触器，那Q0.0和Q0.1就是开关量输出到控制盒。如果直接控制接触器，必须在输出端并联RC吸收回路，防止感性负载断电瞬间的反向电动势打坏PLC输出点。
3.3 安全回路设计
电气控制中安全永远是第一位，停车场道闸这种户外设备尤其要重视。我的做法是增加三级防护：
- 硬件急停按钮，串接在道闸电机主回路接触器线圈之前，直接切断电机电源，不经过PLC逻辑。
- 道闸限位开关硬互锁，抬杆和落杆两个接触器的线圈电路互相串联对方的常闭触点，即使PLC程序跑飞也不可能两个接触器同时吸合。
- 程序互锁，在梯形图中进行软互锁，防止误输出。
这三重防护是“电气控制”的核心意义所在。纯粹从功能上可以复制的逻辑很多，但安全设计不能省。
3.4 接地与防雷
停车场控制箱通常装在户外岗亭或者立柱上，防雷接地不能省。我的建议是：控制箱外壳单独做保护接地，PLC、开关电源的直流负端在系统中单点接地；电源输入端加装防浪涌保护器，信号线和对外的通信线如果超过20米，建议加信号防雷器。接地原则是“单点接地”，避免形成地环路，地环路是通信干扰和偶发故障的头号来源。组态软件和PLC之间走以太网时，如果通信偶尔中断又自动恢复，十有八九是接地问题。
4. PLC程序核心逻辑：把收费流程写成状态机
4.1 停车收费流程的状态划分
停车场收费流程看起来简单，但直接写梯形图很容易绕晕，所以我一般先在纸上把状态机画出来。一个出口的典型状态如下：
- S0 空闲：道闸处于关闭状态，绿灯熄灭，红灯常亮。
- S1 检测到车：出口地感有信号，程序启动稳定延时，确认车辆停稳在读卡区。
- S2 读卡/识别：向读卡器发送读卡指令，或接收车牌识别一体机的识别结果。
- S3 校验与计费：根据入场时间和当前时间计算费用（此部分由组态软件完成），费用结清后由一体机发送开闸信号。
- S4 抬杆放行：PLC输出抬杆信号，闸杆抬起。
- S5 车辆通过检测：出口地感信号消失，说明车辆已通过闸杆位置。
- S6 落杆复位：闸杆落下，回到S0。
组态软件在上位机参与的这个过程里，实时性最高的部分是S4到S6的抬落杆控制，这部分必须由PLC独立完成；S2到S3涉及数据库查询和费用计算，响应时间在百毫秒级，交给组态软件反而更稳。
4.2 防重复扣费的防护逻辑
这是整个程序里最容易出bug也最容易引起客户投诉的地方。典型场景：车辆卡在闸杆下，倒车又重新前进，地感信号断断续续，读卡器可能会在短时间内发送多次开闸请求，如果程序不做处理，第一辆车还没过去，第二笔费用已经扣了，用户必然投诉。
我的方案是采用**“开闸请求锁存+通道占用标志”**机制。用一个内部位M0.0表示“当前通道是否有车正在过闸”，车辆触发地感后，M0.0置1，此时即使读卡器再次发送开闸请求，PLC也只认为是重复信号，不会重复触发计费。必须等到车辆通过（出口地感消失并延时确认）且道闸落杆到位，M0.0才清除。
这里有一个坑：如果读卡器发送的开闸信号是电平信号而不是脉冲，程序里需要做上升沿检测，否则在通道占用期间，电平一直为1，会导致释放M0.0后立刻再次误触发。必须在梯形图中使用上升沿指令处理外部开闸信号。
4.3 防砸车逻辑的两种实现
防砸雷达或者红外对射是现代停车场标配。当道闸落杆过程中，如果防砸信号突然变1，说明闸杆下方有障碍物，程序必须立即执行“抬起”动作，并且落杆指令要置零。
常见梯形图思路如下：
// 防砸触发时强制抬起 IF 道闸正在下降 AND 防砸信号 = 1 THEN 落杆继电器 := 0; 抬杆继电器 := 1; 防砸报警标志 := 1; END_IF这里要注意的是，在ST中如此简单，在梯形图里要画成交互密切的“落杆中”辅助点串联防砸输入点，输出到“抬杆”线圈。同时，每次防砸触发后，程序要记一个“防砸发生次数”，超过三次连续触发就要输出报警，并停止自动落杆，让人工介入。如果不加这个逻辑，道闸就会反复抬落，电机频繁正反转，减速箱磨损极其严重。
4.4 地感信号滤波防抖
地感线圈检测器输出信号在车辆经过时会出现抖动，直接读取会导致状态跳变。处理方式就是软件滤波：信号变为有效后，启动一个10到20毫秒的延时定时器，定时时间到后再次确认信号仍有效，才认为稳定。S7-1200可以用TON延时接通定时器来实现，代码片段大致如下：
#地感滤波TON( IN := #地感硬信号, PT := T#20MS, Q => #地感有效信号 );不要小看这个20毫秒，没有它，道闸的动作会时好时坏，特别是雷雨天或旁边有大功率设备启动时，抖动更明显。
4.5 计数与数据通信
出入口各装一个地感，每通过一辆车，相关的车道计数就加一，这个计数要同时同步给组态软件。PLC侧用变量保持，组态软件侧通过Modbus或S7通信协议周期性读取。注意，PLC内的计数器断电要保持，所以要用保持性变量（S7-1200里设置保持属性），避免断电后重新上电计数清零，导致收费记录对不上。这个细节是验收时经常被审计提出来的点。
5. 组态软件画面设计与变量关联：把控制逻辑翻译成人能看懂的界面
5.1 画面布局的核心原则
组态软件在系统里承担“交给人来看和操作”的角色，画面设计直接决定现场保安和值班员用起来顺不顺手。我的布局原则是：一张主监控画面看全局，三块功能区清晰分离。
一是车道状态区，以俯视图的方式画出入口车道的道闸、地感位置，用颜色切换表示状态：道闸关闭红色、道闸打开绿色、有车占用黄色。注意颜色切换的动画连接要绑定到PLC的I点或Q点，而不是绑定到组态软件内部变量，否则PLC断电重启后画面状态和现场实际状态对不上，这个界面就会骗人。
二是收费信息区，显示最近一条通行记录的入场时间、出场时间、应收金额、实收金额、车牌号。这些数据来自组态软件内部数据库，通过脚本从读卡器获取，再结合PLC的车辆到位信号触发刷新。
三是控制与报警区，放手动/自动切换按钮、道闸手动抬落按钮、紧急停止按钮、当前报警列表。手动按钮的权限要设好，不能让无关人员乱按，组态软件里用用户权限管理实现，操作员级只能看和操作基本按钮，管理员级才能修改费率参数。
5.2 组态与PLC的变量关联细节
以WinCC和S7-1200为例，变量关联的坑主要在以下几点：
通信建立：在WinCC里添加S7-1200驱动时，连接参数要填PLC的IP地址，并且注意WinCC所在电脑和PLC的IP要在同一网段。更关键的是，如果PLC侧没有勾选“允许来自远程对象的PUT/GET通信访问”，WinCC是连不上PLC的。S7-1200默认禁止外部读写，必须在硬件组态里把“防护与安全”里的连接机制打开。
变量类型匹配：PLC里的Bool、Int、Real对应WinCC里的二进制变量、有符号16位数、32位浮点数。最容易错的是PLC的Int类型在WinCC里选成了无符号，导致负数显示成65535这种诡异数值。计费金额用Real，但注意WinCC显示时设置小数位数。
数据块变量访问：S7-1200的数据块变量默认有优化属性，WinCC无法直接访问优化数据块，要么在数据块属性里取消优化，要么使用绝对地址访问。组态软件关联不上变量时，先查这个。
通信周期的平衡：组态软件刷新率设置太密集会导致PLC通信负载过高，影响PLC程序扫描周期。比如收费金额这种变化不频繁的变量，设1秒刷新足够；道闸状态这种实时性要求高的，也只需要200毫秒。不需要把所有变量都设成100毫秒，通信负载上去后整个系统都会有迟滞感。
5.3 组态软件里的计费逻辑怎么和PLC配合
我习惯把费用计算完全放在组态软件里，通过SQL数据库记录车辆入场时间戳，出场时读卡器识别到入场记录后，用当前时间减去入场时间计算停车时长，再按费率表计算金额。组态软件通过脚本（VBS或C脚本）周期执行这个查询和处理。
这里有个重要的配合细节：组态软件计算出应收金额并且完成扣费后，要置位一个“扣费完成”的变量，然后由PLC程序去判断这个变量而决定是否允许抬杆。而不是由组态软件直接通过脚本写PLC的Q点。为什么？因为组态软件的运行环境没有PLC那么实时和可靠，如果组态软件在扣费后直接发抬杆指令，万一上位机卡死或通信中断，道闸会失去控制。正确的分工是：**组态软件只负责“通知”PLC，抬不抬由PLC程序根据状态机逻辑自己决定。**这也是“电气控制”系统和普通PC软件管理系统的本质区别——控制权的最后一公里必须握在PLC手里。
5.4 数据记录与报表
组态软件的另一个核心价值就是数据回溯能力。我的做法是：每次车辆通行完成后，组态软件自动在数据库里插入一条记录，包括车牌、入场时间、出场时间、停车时长、现金或电子支付金额、通道编号、收费员编号。这些记录在月底对账时一键导出Excel。
这个模块看起来简单，但有一个很实际的细节：收费员的交接班记录也要让组态软件管起来，因为交接班需要打印当班收费总额和车辆总数，如果只在本地Excel里手工记录，月底审计时极易扯皮。组态软件里的交接班报表功能，能直接从数据库按时间范围聚合查询，这个功能虽然不起眼，却是客户最满意的功能之一。
6. 现场联调排错经验：通信、干扰、时序三大坑
6.1 通信连不上的排查链路
组态软件连不上PLC是联调阶段最高频的问题，比程序bug还多。我总结了一套排查链路，按顺序走，基本都能定位：
- 物理层：确认网线两端指示灯是否亮起，用ping命令测试工控机到PLC的连通性。ping不通就看IP和子网掩码是否一致，以及PLC是不是处于STOP状态（STOP状态下有些型号网口不响应）。
- 协议层：S7-1200需要在硬件组态里允许PUT/GET访问，这个我在前面提过，默认是关闭的，第一次配置最容易忘。
- 变量层：确认组态软件里的变量，与PLC里的变量名称、数据类型、地址一致。数据块变量如果是优化块，组态软件直接找不到。
整个链路里我最想强调的是：**先会在PLC侧用自带的小面板或编程软件监控变量值，再谈组态软件连接。**如果PLC侧变量就根本没有值，组态软件那边连死都白搭。我见过不少工程师，组态软件里变量显示维修状态就着急改IP改参数，最后发现是PLC程序根本没下载进去，连线上通没通都没验证。
6.2 道闸动作异常：干扰还是逻辑错误
道闸自动抬杆、落杆位置不准确、防砸失灵，这类问题的排查要分两步。先排除机械和电气干扰，再看PLC程序逻辑。
如果是落杆不彻底，先用手动控制盒测试道闸本身是否正常，比如限位开关是否松动。如果手动正常，自动不正常，重点查PLC输出信号到控制盒之间的中间继电器触点是否有拉弧烧蚀，以及接线端子是否松动。道闸电机启停瞬间的电流冲击很容易让相邻的数字量输出产生误动作，我建议所有的输出继电器线圈都并联续流二极管，如果是交流线圈就并RC吸收回路。
如果是验收阶段才出现的偶发误动作，优先怀疑是供电不稳或者干扰，措施是加隔离变压器或者在PLC电源前端加滤波器，同时把通信线换屏蔽双绞线并单端接地。这个排错过程需要耐心，但收获也是长期的，处理完以后这套系统会稳定很多。
6.3 地感信号丢失的高发时段
地感线圈在雨天和温差大的季节容易“飘”，表现为车辆过车但地感信号时有时无。原因通常是地感线圈的绝缘性能下降，或检测器灵敏度过高。处理方案分两步：一是检查线圈到检测器的引线，不能有接头，如果有接头要重新做防水处理；二是检测器的灵敏度等级，不是灵敏度越高越好，过高会把路面金属和地下钢筋当车辆触发，过低又检测不到地盘较高的SUV，需要现场反复调试。
我在一个项目里试过最有效的办法是将灵敏度因子设置为中间档，并且将检测器的输出延时设在100到200毫秒之间，这样既不会漏检也不会因抖动误触发。这些参数在现场不太起眼，但决定了“车辆通过成功率”这个关键体验指标。
6.4 调试顺序建议
很多新手喜欢先把所有I/O点都接好，然后同时调试程序和画面，结果出了问题根本不知道从哪查起。我的做法是分五步走，每一步验证通过再进行下一步：
- 先只给PLC和扩展模块通电，用编程软件监控I/O点的原始状态，把所有开关量输入一个个短接测试，确认I/O地址和实物对应无误。
- 暂时断开执行器输出，只写一个简单的输出测试程序，让每个Q点轮流置1，用万用表量输出侧的电压变化，确认输出口接线正确。
- 接入执行器，测试道闸手动模式下的抬杆、落杆和限位反馈，这时先不跑自动流程。
- 把完整PLC程序下载进去，用编程软件里的变量监控表，模拟地感和开闸请求信号，观察状态机的状态切换是否符合预期。
- 最后才把组态软件连上来，做上位机和下位机联动调试。如果画面上的数据不对，至少可以确认PLC程序本身没问题，问题必然出在组态软件的变量关联或脚本逻辑上。
这个顺序帮我节省了大量排查时间，每次都能在最短时间内把问题定位到具体环节。现场调试最忌讳“上来就全通”，因为系统耦合在一起后，故障的边界是模糊的，逐步解耦才能让问题显形。
6.5 长时间运行下的保养要点
项目交付并不意味着工作结束。PLC电池要定期更换，否则断电后程序和数据可能丢失；控制柜内的散热风扇要定期清理灰尘，否则夏天连续高温宕机的风险很高；地感线圈的切割缝要定期检查，沥青老化或灌封胶开裂都会影响检测可靠性。这些不是设备故障，但都是系统性隐患。我见过不少停车场用了一年多之后开始频繁出小毛病，基本都是日常维护没跟上导致的。
组态软件侧的数据库也要定期备份，因为收费记录文件如果损坏，对账就极其痛苦。可以在组态软件里设置自动备份任务，每天凌晨将数据库文件复制到另一台机器或移动硬盘上，这个习惯虽然简单，但真到了需要查三个月前的某笔记录时，你会感谢当初动了这几下手指。
7. 这套方案以后还能往哪走
停车场收费系统是一个很小的应用场景，但它几乎涵盖了工业自动化的所有核心要素：传感器采集、逻辑控制、执行器驱动、上位机通信、数据管理。把这套思路吃透了，往智能楼宇的车辆管理、园区门禁、充电桩联动方向迁移，原理完全一致。
我目前正在做的扩展方向是充电桩联动。停车场里加装充电桩之后，地感信号可以同时联动充电桩的占用状态，PLC在检测到新能源车停入充电位后，通过Modbus TCP向充电桩下发启动指令，充满自动停止，费用统一通过组态软件结算。整个系统的骨架和收费系统没有本质区别，只是在I/O点数和通信协议上做了扩展。
另一个方向是云平台对接。组态软件本地运行之外，通过MQTT协议把停车数据和道闸状态上报到云端平台，管理人员在手机上就能实时查看车场运营状况，还能远程下发应急处理指令。PLC这边只需要在程序中增加一个通信功能块，把几个关键状态变量映射到MQTT网关。
回到标题本身，“电气控制”四个字是这套系统的灵魂。组态软件可以换、通信协议可以换、甚至PLC品牌都可以换，但电气控制的安全逻辑、状态机思路、分层架构原则是通用的。把这些吃透，换什么平台都是熟门熟路。
