做停车场收费系统很多人第一反应就是“不就是入口抬杆、出口收费嘛”。但等你真正用PLC和组态软件把这套东西落地之后才发现表面越简单的事背后的信号链路越容易被低估。我自己做完这个基于PLC和组态软件的智能停车场收费系统之后最大的感受就是控制逻辑、通信配置、收费联动、异常处理任何一环没想清楚现场调试都能把你磨到怀疑人生。这篇文章我打算把整个项目的来龙去脉摊开讲一遍包括系统架构怎么搭、硬件怎么选、组态软件里收费逻辑怎么写、PLC和上位机之间通信怎么调通、还有那些我踩过的坑。适合正在做PLC相关项目、准备做毕业设计、或者准备接手停车场类自动化项目的朋友参考。1. 项目整体设计与方案选择1.1 需求拆解从业内视角重新定义“智能停车场”普通车主看到的停车场只有三步进场抬杆、扫码付费、出场放行。但站在做系统的人角度这背后其实是好几条独立的信号链。入场时地感线圈检测到车辆触发车辆检测器给出一个电平信号PLC收到这个信号之后要判断是否抬杆同时要联动车牌识别摄像机抓拍车牌。如果车牌在系统里命中月卡白名单道闸直接抬起如果没命中也要正常抬杆放行但要把入场记录和车牌图片传给收费系统。出场时系统要核对车辆入场时间和当前时间根据计费规则算出金额支持扫码支付、现金支付、月卡核销等不同模式。支付成功之后收费系统再通过通信接口通知PLC抬杆。这套流程如果全用PC控制也不是不行但真正运行起来就会遇到问题比如PC死机、断电重启后道闸状态丢失、通信卡住导致道闸不抬杆。所以我们要做的就是把“控制”和“业务”分开。PLC负责所有和设备直接相关的动作——地感信号采集、道闸电机控制、防砸车逻辑、手动/自动切换保证即使PC挂了现场车辆也能靠人工或半自动模式进出。组态软件负责业务部分——车牌识别数据对接、计费逻辑、支付结果核验、报表记录。这样拆开之后每个环节都变得清晰后续排查也好定位问题。1.2 为什么核心调度必须交给PLC而不是上位机直控有朋友问过既然组态软件功能这么强干嘛还要PLC甚至有人直接拿继电器自己搭一个控制柜成本还更便宜。我的看法是停车场道闸是高频率、低容错设备一小时进出一百多辆车每次抬杆落杆都要精准如果控制回路只是一堆散装继电器一旦某个接触不良整个道闸就趴窝了。PLC的核心优势在于程序跑在专用硬件上循环扫描周期短IO响应基本在毫秒级别。而组态软件运行在Windows上即使电脑配置不低也可能因为杀毒软件扫描、系统更新、后台服务占用CPU导致画面卡顿或者指令延迟。你可以接受充电桩屏幕偶尔卡一下但无法接受道闸收到抬杆指令后延迟两秒再动作。另外一点是断电保持和状态恢复。PLC的CPU带掉电保持区道闸当前是开还是关、某个抬杆命令有没有执行完这些状态都可以记录下来。重新上电之后PLC能把系统恢复到掉电前的状态不会出现“明明车还在道闸底下却因为上位机没启动而不让抬杆”的尴尬场景。组态软件则主要负责给人看、给人操作把复杂的逻辑下放到PLC才能既稳定又灵活。2. 硬件选型与关键设备配置2.1 PLC的选型思路与扩展能力这套系统里我用的PLC是西门子S7-200 SMART系列。说实话这个系列在大型自动化项目里不算高端但在停车场这种中小型设备控制场景里非常合适。CPU自带以太网口可以直接和组态软件通过Modbus TCP或者S7协议通信省掉了串口转接模块。IO点数要求也不高道闸控制和地感检测用十几个点就够如果以后要扩展车位引导屏、剩余车位计数还可以加数字量扩展模块或者以太网远程IO。选型时一定要注意CPU型号的具体规格。以S7-200 SMART为例ST20和SR20的IO点数一样但一个是晶体管输出一个是继电器输出。道闸线圈和指示灯这类负载用继电器输出更省事不容易烧输出点。晶体管输出响应更快但带载能力弱如果需要直接驱动电磁阀或者高速脉冲输出就必须选晶体管型。这个细节我在项目初期差点忽略后来和电气工程师核对负载类型时才改的配置。还需要考虑的是通信口的数量。有些PLC只有一个串口既要接触摸屏又要接上位机就只能通过扩展模块或者加交换机来解决。S7-200 SMART好一点CPU自带以太网口有多个上位机设备还能组成一个小的局域网调试起来也方便。另外一个经验是无论选什么品牌都要先把手册里关于通信口、地址范围、寄存器分配的定义下载下来后面写程序和配置组态时翻得频率很高。2.2 地感线圈、车辆检测器与道闸执行机构地下线圈是停车场最常见的车辆检测方式。原理就是在地面切槽埋一圈感应线车辆的铁磁物体经过时会让线圈电感量发生变化通过车辆检测器把这种变化转换成开关量信号送给PLC。在实际施工时线圈的形状和匝数都有讲究埋线的槽不能太深线径要选合适的线圈到检测器的距离尽量不要超过20米否则灵敏度会下降。道闸这边的执行机构一般是交流电机加涡轮蜗杆减速箱通过限位开关或者编码器判断抬杆到顶和落杆到底的位置。典型的控制方式是PLC输出两个DO点一个给“抬杆继电器”一个给“落杆继电器”通过中间继电器去控制交流接触器电机正转抬杆、反转落杆。道闸臂带防砸功能的话需要接入地感线圈的第二次触发信号或者红外对射传感器的输出。当落杆过程中检测到下方有车或人PLC必须立即停止落杆并转为抬杆这个逻辑在梯形图里要作为最高优先级处理。执行机构这块我的建议是不要省继电器。PLC的输出端子直接接交流接触器线圈虽然短时间内能用但长期现场震动、端子和线缆老化很容易出问题。在控制柜里加上中间继电器做一层隔离虽然多几个元件但是维修时可以直接更换不会伤到PLC本体。3. 组态软件层画面、数据、收费逻辑怎么设计3.1 组态画面的几个设计原则组态软件选的是国产组态软件兼容性和上手速度都不错和西门子的WinCC相比门槛低一些。组态画面设计不要一味追求花哨停车场收费系统面向的是收费员和运维人员他们要的是一眼能看到当前状态。我习惯把整个画面分成三个区域最上面是停车场总览包括总车位、剩余车位、入口状态、出口状态、道闸开关状态中间是当前正在处理的车辆信息包括车牌号、入场时间、应收金额、支付状态最下面是报警信息栏把通信中断、道闸故障、地感检测器异常这些重要状态滚动显示。组态软件里的变量要和PLC地址一一对应比如PLC的Q0.0对应入口道闸抬杆输出组态变量就要用同一个地址来读取状态。逻辑上不要跨PLC去读地址尽量保持“一个画面只关心一个PLC”的原则。如果需要显示两个道闸状态就增加变量但不要试图在脚本里做大量地址换算那个维护成本太高。3.2 收费逻辑如何和车牌识别联动车牌识别是停车场系统的关键数据来源。目前常用的方式是在入口和出口部署高清识别摄像机摄像机内置识别算法识别完成后通过HTTP或者TCP协议把车牌号、抓拍时间、图片地址发给组态软件所在的服务器。组态软件通过脚本或者内置的数据库接口来处理这些数据。比如进场时车辆触发地感后PLC会给出一个“车辆入场信号”组态软件监听到这个信号变化后从摄像头取回识别结果把车牌号写入数据库同时记录入场时间。出场时同样是先由PLC检测到车辆到位组态软件再调取摄像头识别结果根据车牌号查询入场记录计算停车时长和费用。计费规则这块要注意时段的区别比如白天和夜间收费不同首小时和后续小时收费不同还有免费时长。我建议把计费参数做成独立的数据库表或者配置文件而不是写死在组态脚本里。这样遇到节假日调整、出租率策略变更管理人员直接改参数就行不用重新编译画面。对于月卡车还要支持白名单导入命中白名单的车辆出场时直接放行组态软件只记录不收费同时在界面上弹出一个提示“月卡车辆”。支付对接上常用的做法是组态软件调用支付接口生成二维码车主扫码后支付平台通过回调通知组态软件支付结果再通知PLC抬杆。这里最容易踩的坑是回调超时也就是车主已经付完钱了但因为网络或者端口问题组态软件没收到支付成功消息导致不抬杆。我后来在处理上加了两个兜底一是定期主动向支付平台查询订单状态二是提供了一个“手工确认放行”按钮收费员在界面上确认识别到支付成功后可以直接触发PLC抬杆。4. 打通上下位机Modbus TCP与OPC UA通信实战4.1 我为什么优先用Modbus TCP而不是串口停车场控制系统里PLC和组态软件的通信是整个项目的中枢神经。如果通信不稳定前面所有的逻辑设计都白搭。我在这套系统里优先选Modbus TCP而不是传统Modbus RTU串口原因有三个。第一S7-200 SMART自带网口Modbus TCP可以直接跑在以太网上不需要额外的串口服务器或者USB转485模块硬件成本低。第二调试方便网线一插就能通过电脑上的Modbus调试工具直接读PLC寄存器排查问题比串口清晰。第三传输距离和抗干扰能力比RS485强停车场控制柜到岗亭往往有二三十米如果用RS485线材质量和接地处理不好通信很容易时好时坏。给PLC写Modbus通信程序时要注意寄存器映射。S7-200 SMART的Modbus库使用V区作为数据缓冲区需要预留一段V存储区作为通信请求和响应缓冲区。组态软件里配置设备地址、起始寄存器时要和PLC程序里定义的一致。常见错误是组态软件里读的是保持寄存器地址但PLC程序里用的是输入寄存器或者线圈地址两边对不上导致读到全是0或者直接报错。4.2 OPC UA适合什么样的连接场景这个项目里其实还用到了OPC UA用的是组态软件自带的OPC UA服务器功能。很多人分不清Modbus和OPC UA的区别简单说Modbus是设备层面的协议传输效率高但数据语义简单适合PLC和仪表之间的实时数据交换OPC UA应用层更强大支持统一的地址空间还带安全和数据模型适合不同品牌设备之间、SCADA级别系统之间相互整合。如果你用的是西门子S7-1200/1500系列本身就是原生支持OPC UA的直接用OPC UA和组态软件连接会更方便不需要每个地址都手动映射。如果是S7-200 SMART这种入门级设备主要还是靠Modbus TCPOPC UA更多是用来给上层MES系统提供数据接口。比如我用OPC UA把停车场系统的车位占用率、道闸状态、入场车辆数这些信息共享给了本地的数字孪生展示系统这样展示平台不用直接去读PLC也能拿到实时运行数据。4.3 通信调试的通用套路和注意点通信这块我踩过的坑非常多总结下来排查思路无非三步。第一步先用调试工具确认链路通不通比如直接用Modscan或者Modbus Poll工具去读PLC设备。第二步把工具能读到数据和组态软件里的配置做对比看是地址范围、数据格式还是设备地址不一致。第三步如果都一致还不行换个通信方式试比如先用串口连一把确认不是网口冲突或者防火墙拦截。还有一点容易被忽略就是组态软件和PLC的通信参数要匹配包括功能码、寄存器类型、数据长度。有些组态软件默认按照Modbus地址规则自动偏移比如地址40001对应保持寄存器起始位置但PLC侧缓冲区里数据的偏移量是按1开始的还是按0开始的不同软件或库的处理方式不同实际上差一位就会全部错乱。实在排查不出的时候就手动把读回来的第一个数值和PLC里固定写入的测试数值对比是最快的定位方式。5. PLC程序开发与整体联调5.1 梯形图分区和逻辑设计PLC程序不要写成一坨大锅乱炖。我写这套停车场程序时按照功能块分了几个区域系统初始化、地感信号处理、道闸动作控制、手自动切换逻辑、状态输出。每个区域用对应的程序段来组织并用注释标明变量含义。道闸控制的核心是顺序逻辑。举个简单例子入场道闸在自检完成后默认处于关闭状态。当地感检测到车辆PLC判断道闸当前是否在“已开”状态如果不在就置位抬杆输出。抬杆到顶后限位开关信号反馈PLC延时判断车辆是否安全通过。车辆通过后再次触发出口地感PLC再执行落杆动作。这就是典型的顺序启动、逆序停止的控制思路和那些基础练习题里的电机顺启逆停、加定时器延时逻辑一个套路只是把这些基本逻辑拼装成了更完整的流程。在实际编码时我习惯把“手动模式”和“自动模式”分开。手动模式下现场人员通过控制柜面板上的开关直接控制道闸PLC不做任何自动判断方便检修设备。自动模式下才接入地感、防砸雷达、收费系统放行信号。切换开关放在控制柜门外维护时不用打开柜门就能操作。这样的程序结构也不复杂但现场维护会省心很多。5.2 现场联调的顺序和方法联调阶段我建议按“先IO、再逻辑、后通信、最后业务”的顺序来这个顺序能最大程度减少调试混乱。第一步是把每个输入输出点都点一遍。例如地感触发一下信号看PLC对应输入指示灯亮不亮点动输出看道闸电机正转反转是否对应。这个阶段就需要把PLC程序里所有软元件和实物对应起来最烧时间但最值得做。第二步是逻辑验证。在电脑上用PLC编程软件的仿真功能先把道闸逻辑模拟一遍比如手动置位地感信号观察输出状态是否正确抬杆限位信号给上之后落杆指令是否被阻止。这个过程能暴露很多编程时的疏漏而且不用去现场反复跑设备确认。第三步是通信联调。把组态软件运行起来看PLC变量是否和画面上的变量对应。我会故意在PLC里写一个测试数据比如把固定值写到某个寄存器再到组态界面上看它显示是否正确如果显示和预期不一致说明地址映射有问题。最后是业务端到端联调。用一辆真实的车反复进出模拟月卡扣费、临时车扫码支付、无牌车人工放行等不同的场景整个链路从地感触发到PLC抬杆、组态软件计费、支付结果回调、再到道闸抬杆每一环都要看到预期结果。这个阶段务必多测几轮异常场景比如车主在道闸下停留时间过长、信号抖动、支付超时等因为真正常出问题的都是这些边界情况。6. 常见问题排查与避坑速查6.1 用MODSCAN能读到串口数据组态软件却读不到这个现象在串口通信时特别常见我也遇到过很多次。用MODSCAN读串口设备数据完全正常但组态软件里的变量就是死活刷新不出来这时候很多人会怀疑是组态软件坏了或者破解不完整。实际上用MODSCAN能读、组态软件不能读多半是通信模式冲突。MODSCAN工具是独占串口的如果组态软件里面还配置了同一个串口设备并且软件里面已经启动通信那么MODSCAN或者组态软件就会有一个占用失败。有些组态软件默认开启实时刷新一直在监听串口你用MODSCAN再去连接同一个串口肯定是读取正常但软件界面数据不动。解决的办法是先在组态软件里把对应设备禁用或者停止通信再用MODSCAN测试。测试完关闭MODSCAN重新使能组态软件通信。另外还要确认组态软件的设备地址、波特率、校验位和PLC侧完全一致很多组态软件默认的设备地址是1但有些设备地址是从站设置的可能设成2或者3两边对不上也读不到数。6.2 西门子Smart PLC搜索不到CPU手动加IP却能连上这个属于S7-200 SMART设备调试时的经典问题。正常用Micro/WIN SMART软件搜索CPU结果扫描半天没有响应但通过“添加CPU”手动输入IP地址之后又能连上并下载程序。原因大体有两种。一种是电脑和PLC不在同一个网段或者路由器隔离了广播包自动搜索依赖的是局域网广播广播被隔离或网段不符时自然搜不到但通过IP直接访问可以绕过广播问题。另一种是Micro/WIN SMART的版本和PLC固件不匹配低版本软件连接新版本固件的CPU某些功能会有兼容问题。我的建议是搜索之前先确认电脑网卡IP和PLC在同一个网段然后再用Ping命令测试连通性。能Ping通就去“添加CPU”直接输IP连接这个方法最省事。如果在项目上PLC数量很多建议用交换机统一接入不要一台台插着网线去配置那样容易遇到网线接触不良的问题。6.3 三菱FX3U的普通寄存器断电不保持三菱FX3U的D0到D8属于普通寄存器默认设定是断电不保持。也就是说一旦系统掉电这些寄存器里的值就会回到零。而D200以上的一部分寄存器默认为锁存区域掉电后数据仍能保留。但这个“默认”是可以改的在PLC参数里重新设定软元件锁存范围就能把D0到D8改成断电保持。在停车场的收费逻辑上这个问题特别重要。比如某辆车正在支付中现场突然停电如果入场时间、车牌信息放在不保持的寄存器里恢复供电后这些信息可能已经清零系统就无法正确计算停车费。所以我建议凡是涉及收费状态、车辆计数、抬杆标志等关键运行数据要么放在锁存区域要么在断电时通过组态软件数据库保存在PLC上电后进行恢复。不能只依赖组态软件因为组态软件所在的电脑也可能被切断电源。6.4 一台PLC到底能不能接两个触摸屏经常有同行问这个问题一台PLC能不能用两个触摸屏同时监控、同时操作。答案是完全可以但要注意通信方式和数据负载。如果PLC自带以太网口两个触摸屏可以通过交换机访问同一个PLC地址同时读取数据互不干扰这是最推荐的方式。如果用的是西门子Smart系列这种支持S7以太网协议的设备多个HMI连接在同一条总线上没有大问题。如果是老的串口型PLC只有一个COM口接到了触摸屏上又想再增加一个显示终端那就必须通过RS485总线把两组触摸屏挂在一起从站地址要区分开。需要注意的是多终端同时操作时有可能导致数据写入冲突。比如两个触摸屏都修改同一个参数不一定谁后写谁就会覆盖谁。一般HMI会有写入权限控制但实际中还是建议把参数设置页面集中在“管理端”这一个屏上现场显示端只做监控和简单操作。这样既满足现场需求也避免维护混乱。7. 落地之后的复盘与建议7.1 五个值得保留的现场经验这套智能停车场收费系统从设计到落地我最深的体会有五个也分享给准备做类似项目的朋友。第一个是预留接口。控制柜里至少预留20%的备用IO点通信上尽量选择带网口的设备因为后续一旦要加车位引导屏、自助缴费机、ETC识别盒这些设备大多数都跑以太网预留好了就不用重新规划结构。第二个是重视防水防尘。道闸控制器和地感检测器都装在户外哪怕放到岗亭里也会面临灰尘大、湿气重的问题。接线端子最好选用带压线螺丝的型号线头要压冷压端子不能直接缠绕挂上去。我在现场修过的故障有三分之一是端子松动和接线氧化导致的。第三个是安全逻辑永远最高优先级。防砸车不只是道闸本身的功能而是整个系统要遵守的原则。地感检测、红外对射、触摸式安全边缘传感器这些信号在PLC程序里一定要用常闭逻辑去接线断线了要报故障而不能简单地通过断开信号来屏蔽保护。第四个是记录要全。停车场收费涉及钱款所有车辆进出记录、支付记录、人工操作记录都应该在组态软件里留下日志。后续对账时如果发现某辆车没记录至少能通过日志回放确认当时是哪个环节出了问题。别怕数据量大数据库定期归档就行就怕到时候没有日志可查。第五个是调试要稳不要图省事。通信调试、联调验证一步一步来最靠谱。有时候看起来像是软件操作不熟练的问题查到最后是网线水晶头质量问题这种隐蔽问题通过固定设备加固定网线逐段替换才最容易找到根因。现在做这类系统的人越来越多但每个项目现场都不一样最终考验的还是对整个信号链路的理解。把PLC和组态软件之间的分工理清楚把每个I/O点背后的物理意义搞明白把通信过程里的每一步都验证过这套系统才能真正稳定跑下去。如果你也正准备动手做类似项目希望这篇分享能帮你少走几个弯路。