拓冰网站定制 
1. 项目概述1.1 核心需求解析停车收费这件事听起来简单真正做起来却有不少讲究。我做了这么多年自动化项目接触过不少停车场的需求方他们往往一开始的说法都很统一就是入口发卡、出口收费抬杆。可真到现场勘察完你会发现事情完全不是这么简单——车流量统计、车位余量显示、防砸车保护、断电续行、对账查询、高峰期双通道调度每一项都是刚需。这套基于PLC和组态软件的智能停车场收费系统解决的正是这些看似简单、实则琐碎的现场问题。它的核心思路是用PLC做底层逻辑控制和设备联动用组态软件做人机交互和数据管理两者通过工业通信协议如Modbus、OPC UA实现数据交互。相比市面上常见的纯单片机或工控机方案PLC组态的组合在稳定性和抗干扰能力上有天然优势特别适合停车场这种环境复杂、24小时不间断运行的场景。这篇内容是我自己实际做过的一个项目总结从架构搭建、PLC程序编写到组态画面设计再到联合调试中的各种坑完整走了一遍。适合正在做PLC毕业设计的学生、准备接非标自动化项目的一线工程师以及想了解停车场系统内部逻辑的运维人员参考。1.2 为什么选PLC组态软件而非其他方案在做方案选型的时候我们其实对比过三种常见路径第一种是纯单片机方案成本低但扩展性差后期加功能几乎等于重做第二种工控机高级语言开发灵活性强但开发周期长、对现场运维人员的要求高而且死机问题在恶劣环境下很难根治第三种就是PLC组态软件也是我们最终选择的方案。选它的核心理由有三个第一稳定。PLC本身就是为工业环境设计的电源波动、温湿度变化、电磁干扰这些停车场常见的恶劣条件对PLC来说都是小场面。第二开发效率高。组态软件的画面开发是拖拽式的不需要写太多代码逻辑修改也快不像高级语言那样动不动就要重新编译。第三后期好维护。设备出了问题现场电工基本都能上手排查不会像工控机那样黑屏了只能等厂家。当然这套方案也不是没有缺点——它不是一个开箱即用的产品需要针对具体项目做定制开发。但如果你想做一套真正贴合自己需求、不被第三方厂商绑架的系统这条路是值得走的。2. 系统整体建设与设计思路2.1 停车场收费系统的组成架构整套系统的物理架构可以拆成三个层面设备层、控制层和管理层。设备层就是停车场现场那些看得见摸得着的东西入口地感线圈、出口地感线圈、道闸电动栏杆机、车牌识别相机本项目中预留了RS485接口后续可扩展、LED余位显示屏、红绿指示灯、语音播报模块还有最重要的——收费岗亭里的读卡器和管理电脑。这些设备加起来构成了系统最底层的感官和手脚。控制层是整个系统的核心也就是PLC。它负责采集所有传感器的信号、判断车辆状态、控制道闸起落、管理车位计数逻辑。我这里用的是西门子S7-200 SMART系列原因很简单性价比高、资料多、梯形图编程上手快而且它自带的以太网口和RS485口做通信非常方便。如果你用三菱FX3U或者汇川的AM系列整套逻辑同样是适用的只是通信指令写法上需要调整。管理层就是组态软件跑在一台管理电脑上负责车位数据实时监控、收费金额计算、历史记录查询、报表导出等。我们用的是组态王KingView——它在国内停车场项目里用得非常多驱动丰富和S7-200 SMART的通信配置也有现成模板可以参考。如果你熟悉西门子的WINCC同样是可行的只是WINCC的授权和部署成本会高不少。2.2 PLC组态各自的职责边界很多第一次做这类项目的人容易陷入一个误区想把所有逻辑都写在组态软件里让PLC只当一个信号中转站。这是一个非常危险的倾向。我的原则很简单凡是需要实时响应、涉及安全的逻辑必须放在PLC里。比如道闸的防砸控制——地感线圈检测到车底有障碍物时道闸必须立刻停止下降甚至抬升这个响应时间要在毫秒级。如果走组态软件数据要经过通信链路往返一旦通信出现延迟或者断线事故就不可避免。再比如车位计数PLC通过地感信号判断车辆进出这个计数是在PLC内部完成的组态软件只是读这个数值来显示。反过来组态软件负责的是非实时部分收费金额的计算与记录、操作员的登录管理、报表生成、画面切换、报警记录。这些功能对实时性要求不高但逻辑复杂、界面交互频繁用组态软件来做开发效率极高。一句话总结PLC管设备和安全组态管数据和交互。把这条边界划清楚了后面写程序和调画面的时候会顺畅很多。2.3 核心数据流与工作流程整套系统的运转流程是这样的车辆驶入入口道闸前的地感线圈线圈感应到车后PLC收到信号输出指令让入口摄像机进行抓拍识别同时PLC控制道闸抬杆放行。车辆通过道闸下方的第二个地感线圈后PLC判断车辆已完全驶入控制道闸落杆同时车位计数加一这个加一后的数值通过通信实时刷新到组态软件的画面和LED余位显示屏上。出口的逻辑正好相反车辆压到出口地感线圈PLC通知组态软件开始计费如果做的是按时收费收费员在组态画面上操作收费完成后点击放行PLC收到放行指令抬起道闸车辆通过后落杆、计数减一。在内部通信层面PLC的输入映像区有一组地址专门用于和组态软件交换数据我们定义了I区标志位代表出口地感触发、道闸上升到位、道闸下降到位等状态组态软件侧通过Modbus TCP协议周期性读取这些地址同理组态软件向PLC写入放行指令和复位指令时也是通过Q区或者V区地址。这套地址映射表是整个系统联调的通信协议在项目一开始就必须确定好不然后期改起来非常痛苦。3. PLC程序的关键逻辑实现3.1 出入口道闸联动控制道闸控制是整个PLC程序里最核心的逻辑。很多人以为道闸控制就是给信号就抬、再给信号就落实际上完全没有这么简单。安全逻辑在这里占了很大的比重。我做的第一版程序里抬杆逻辑是这样的入口地感线圈动作且收费状态正常组态给了放行信号→ 道闸上升输出置位。道闸上升到位后上升输出复位。这个逻辑看似没问题但实际测试时发现一个坑如果车在道闸正下方停了很久入口地感会一直保持动作状态PLC就一直接到有车的指令。这时候如果操作员手动抬杆道闸抬起来之后又立刻执行落杆——因为地感持续检测到车辆程序误判车还在应该落杆结果就是道闸砸在车顶上。解决这个问题我把控制流程改成了脉冲触发、状态保持模式地感信号只是触发抬杆动作抬杆之后的保持逻辑由中间继电器M来实现地感的持续信号不再参与道闸的保持判断。只有当道闸上升到位信号到达或者落杆指令发出时保持状态才被复位。这套改动之后再没出现过误落杆的情况。3.2 车位计数防重与防漏策略车位计数的准确性是停车场系统最容易被人诟病的地方。你想想车库明明还有空位显示屏显示已满结果外面的车进不来车主投诉或者屏上显示还有几十个空位进去转一圈一个都没有客户直接质疑系统瞎报。这两种情况都严重影响系统口碑。计数逻辑的原理很简单入口地感一个完整脉冲有车→无车就加一出口一个完整脉冲就减一。真正难处理的是防重和防漏。防重一辆车在入口倒车再进轮胎反复碾压地感产生多次脉冲。我的解决办法是加延时确认——地感信号持续动作超过1.5秒才算作一次有效车辆通行并且在同一辆车通过期间从触发到道闸落杆只允许计数一次用置位M寄存器来锁存通行状态直到落杆完成才复位。防漏两辆车紧贴着进出地感信号没有完全断开过第二个脉冲丢失。这个纯靠地感很难完美解决需要在现场把地感灵敏度调低一点、让检测范围覆盖整个车道。如果条件允许加上红外对射或者雷达检测做辅助准确率能提升不少。3.3 道闸防砸保护编程防砸逻辑是停车场系统里最不能省钱、也最不能出bug的部分。道闸砸到车轻则赔钱道歉重则安全事故。常用的防砸手段有三种地感防砸、红外防砸和压力波防砸。我在项目里用地感防砸为主、红外对射为辅。PLC程序里实现这样一个保护逻辑道闸处于下降过程中如果地感线圈被触发说明道闸下方有车或人立即停止下降输出——更准确地说是立即切换到上升输出让道闸抬起来。这里有一个关键细节道闸电机在下降过程中被强行反向驱动对电机和减速箱的冲击很大。所以程序中必须加延时保护——切换方向之前先停顿0.3秒让电机完全停止后再反向启动。这个细节如果不注意用不了几个月电机就会过热甚至烧毁。另外道闸的限位信号也要认真对待。上升限位和下降限位必须接入PLC的输入点如果这两个信号在3秒内同时为ON或者长时间没有变化说明限位开关出了问题PLC应该立即停止道闸控制输出并发出报警。这个逻辑我用了一个定时器和几个比较指令就实现了但它的价值在长时间运行里体现得非常明显。3.4 报警信息采集与处理停车场设备长期在室外运行风吹日晒故障率不低。PLC除了做控制更重要的职责是感知异常并及时上报。我给系统定义了几路报警输入道闸故障、地感线圈断路、通信超时、UPS供电异常。PLC在扫描周期的末尾做一个统一的报警汇总——任何一种异常状态被触发都置位相应的报警寄存器并通过通信写入组态软件组态画面会弹出报警窗口同时伴有声音提示。这里有个经验要分享报警信号不能做成上升沿触发、立即消失必须做成状态保持、手动复位的形式。因为现场运维人员到岗处理是需要时间的如果报警状态自动消失人还没走到现场可能就看不出问题所在了。程序里我特意加了一个延时——报警状态保持至少30秒同时操作员在组态画面手动复位如果30秒内报警源还在状态继续保持。这套机制在实际使用中帮了不少忙。4. 组态软件监控界面与通信配置4.1 组态画面的布局与核心控件组态软件的界面设计直接决定了收费员和运维人员愿不愿意用这套系统。做得好人家觉得方便、清爽做得不好再先进的技术也会被吐槽不如用本子记。我的画面布局分成三个区域顶部是系统状态栏显示当前时间、PLC连接状态、车位余量、操作员姓名。中间是停车场模拟图——用简单的矩形代表车位区域每个区域用不同颜色表示占用或空闲收费员一眼就能看出整个停车场的负载情况。底部是操作区放的是常用按钮手动抬杆、手动落杆、收费确认、报警复位、报表查询。组态软件里最核心的控件是变量动画连接。以车位余量显示为例PLC里VW100地址存的是当前剩余车位数在组态里新建一个IO变量绑定VW100然后在画面上放一个文本显示控件把它的数值输出属性关联到这个变量刷新周期设为500毫秒。这个500毫秒的设置是有讲究的——太快了通信负载大太慢了显示延迟明显实测下来500毫秒是平衡点。4.2 Modbus TCP通信配置与地址映射我用的组态王和S7-200 SMART通信走的是Modbus TCP协议。PLC侧要做两件事一是在S7-200 SMART的编程软件里启用Modbus TCP通信功能块二是把要交换的数据映射到通信区域。这里有个常见坑S7-200 SMART的Modbus TCP库最多支持8个连接每个连接最小通信间隔建议设在10ms以上。如果通信间隔设得太短PLC的扫描周期会被通信任务拖累导致道闸控制逻辑的响应变慢。组态侧新建IO设备时设备地址填PLC的IP通信端口默认502采集频率设置100ms一个周期。数据项按地址映射表逐个添加VW100对应余位数M10.0对应入口抬杆触发M10.1对应出口抬杆触发M20.0对应地感故障报警……总共也就十几个变量配置半小时就能完成。配置完成后在组态软件里做一次设备测试状态显示通讯成功就说明地址映射表没有问题。这里必须强调一个细节Modbus地址的偏移计算。S7-200 SMART的V区地址在Modbus映射里是40001开始的保持寄存器区。比如VW100对应的是40051100/2151如果你的组态软件里填的地址不对读出来的数据永远不对。这个坑我见过太多人踩了而且是在现场调试的时候才暴露出来非常浪费时间。4.3 OPC UA方案的替代路径如果你的项目用的PLC不是S7-200 SMART而是汇川AM系列、倍福Twincat这类支持Codesys平台的设备或者你想让组态软件直接对接传感器、数控机床这些更多种类的设备那Modbus TCP可能就不够用了。这时候OPC UA协议是更好的选择。我后来在另一个项目里就用OPC UA把一台汇川PLC的数据接到了组态软件——OPC UA的优势在于它支持复杂的数据结构安全性更强有证书验证而且自带信息模型设备的数据语义更丰富。组态王本身支持OPC UA客户端功能配置方式是在OPC服务器里新建一个客户端连接指向PLC的OPC UA服务器地址然后浏览节点树把需要的节点一一拖到变量表里即可。如果你的组态画面是多个设备的数据汇总OPC UA这套方案会清爽很多。它不需要你像Modbus那样手工查地址偏移直接浏览节点就能找到想要的变量。当然代价是需要额外部署一个OPC UA服务器而且第一次配置证书环节稍繁琐。5. 实操环节从硬件接线到联合调试5.1 硬件选型与接线要点这里我把整个系统的硬件清单列一下方便你照着做PLC控制器西门子S7-200 SMART SR4024DI/16DO继电器输出这个型号的I/O点数对中小型停车场足够用了通信扩展S7-200 SMART自带以太网口无需额外扩展RS485口可用于接LED显示屏道闸选用380V或220V单相电机道闸带上升限位和下降限位输出接口地感线圈车辆检测器地感处理器输出继电器信号接到PLC输入端组态软件运行电脑普通商用机即可Win10系统4GB内存以上接线时最需要注意的PLC的输入信号线一定要采用屏蔽双绞线屏蔽层单端接地。停车场现场电缆多、干扰源多如果不做屏蔽地感信号和限位信号很容易误动作那种道闸自己抬起来又自己落下去的诡异问题多半不是程序bug而是信号干扰。道闸电机控制我建议用继电器中转——PLC的继电器输出直接驱动道闸电机容易过流烧触点通过一个中间继电器线圈DC24V转接一下既保护了PLC的输出点又方便后期更换。中间继电器选带底座的现场更换时拔插最方便。地感线圈的铺设也有讲究切槽深度4cm左右线圈绕3~4圈线圈到检测器的双绞线长度尽量短不要超过50米。现场很多安装工不懂这个把双绞线走了100多米结果检测器怎么调都不稳定。5.2 通信异常排查实录Modscan能读、组态不能读这个问题的排查过程很有代表性。现场反馈的情况是用ModscanModbus调试助手能正常读到PLC的保持寄存器数据但在西门子组态软件比如WINCC或者相关测试工具里读不到连接状态一直是通信失败。我第一反应是组态软件的通信参数没配对。因为Modscan能读到数据说明PLC侧的Modbus TCP服务器是正常的问题大概率出在客户端侧。排查过程对比Modscan的连接参数和组态软件的参数IP、端口号都一致检查组态软件的采集周期发现设置的是10ms——这太快了PLC的通信功能块处理不过来导致部分请求超时。Modscan默认的轮询间隔是1000ms所以Modscan没事组态软件却超时断连把采集周期改成200ms重新测试连接恢复正常后来我又想了一下这种第三方工具能读、组态软件不能读的问题还有一种原因是组态软件对通信应答时间的容忍度比调试工具严。Modscan发一个请求300ms没收到响应也不会报错只是继续发下一条而组态软件如果200ms没收到响应就直接判定设备离线。所以如果PLC的程序扫描周期很长比如有大段循环处理通信响应会被拖慢这时候组态软件就会误判。解决办法把PLC的通信中断优先级调高或者精简主程序里的大循环逻辑。5.3 地感信号误触发的排查思路地感误触发在停车场系统里太常见了。表现是没有车经过道闸自己抬杆或者车位计数莫名其妙地跳动。排查顺序建议从易到难先看地感检测器的灵敏度设置。检测器面板上一般有灵敏度旋钮或拨码调太高了会把路面上其他金属物体比如铁井盖、拉链、手机放在口袋里的行人都检测到。我们实践下来灵敏度调在中间偏低的档位就够用了再看线圈的铺设。线圈如果有接头接头必须焊接牢固且做好防水绝缘否则下雨天受潮信号会漂移最后查接线。地感检测器输出的是继电器干接点信号如果这段线和动力电缆走在同一个线槽里感应电压就可能让PLC误读到ON状态。把信号线挪远一点或者加中间继电器做电气隔离我们项目里出现过一次很诡异的误触发每天早上8点准时自动抬一次杆后来排查发现是旁边的饮水机加热和道闸共用了一个电源回路加热启动瞬间电压跌落导致PLC的24V电源输出瞬间掉电又恢复——PLC一上电程序初始化道闸输出点有一个短暂的输出脉冲。这个案例当时排查了很久最终锁定在电源上。从那以后我所有项目的PLC电源都单独走一路开关电源绝不敢和电机类负载共用一个电源算是拿教训换来的经验。5.4 联合调试的步骤与验收清单系统组装完成后联合调试千万别带着设备一把梭直接跑那样出了问题根本定位不到。我的调试流程分五步**第一步单设备测试。**PLC单独通电用编程软件的监视模式看输入点能不能正确反映地感和限位信号的变化。这一步确认了硬件接线的正确性。**第二步PLC逻辑纯手动测试。**在组态软件还没接上之前用编程软件里的强制功能模拟输入信号验证道闸控制、计数逻辑是否按预期跑。比如强制地感信号为ON观察道闸输出点是否置位。**第三步通信联调。**启动组态软件新建设备、配置地址、测试连接。这一步看组态和PLC之间的数据是否读写正常重点查地址映射表有没有错位。**第四步组态逻辑联动测试。**在组态画面上操作按钮看PLC侧对应的变量有没有变化同时在PLC侧强制改变状态看组态画面是否刷新。这一步验证的是双方的协议是否一致。**第五步现场端到端模拟。**用实际车辆模拟进出场的完整流程从地感触发到道闸抬杆、计数变化、组态记录生成逐项核对是否符合预期。这一步也是耗时最长的建议把验收清单做成表格一项一项过。验收清单我常用的核心项目包括入口抬杆响应时间从地感触发到道闸启动要求小于1秒、车辆通过后落杆是否平稳、满位后入口是否禁止抬杆、出口收费后是否正常放行、断电再上电后车位计数是否保留了掉电前的状态、连续跑24小时通信是否稳定。6. 常见故障与排查方法速查我在多个停车场项目上积累了不少故障案例整理成下面这个表格方便现场遇到问题时快速定位。这里的处理思路都是实测有效的但每个项目现场环境不同需要结合具体情况做一些调整。故障现象可能原因排查顺序与处理方法组态软件通信超时采集周期太短、PLC扫描周期过长先在组态软件里把采集周期调到200ms以上再检查PLC主程序里是否有大循环、定时中断是否被占用道闸自动起落地感误触发、PLC电源不稳、接线感应电压先调低地感灵敏度再看信号线是否和动力电缆共用线槽最后用万用表监测PLC 24V电源波形车位计数越跑越乱车辆倒车多次触发、地感间隔太近检查计数程序里是否加了1.5秒确认延时和单次锁存逻辑现场检查地感线圈间距是否足够组态画面数据不刷新变量地址映射错误、Modbus地址偏移算错用Modbus调试工具确认实际数据位置重新核对地址转换关系VW地址和Modbus寄存器号不能直接相等道闸落杆后不计数减一出口地感位置摆放不当、车辆没完全驶离检查出口地感线圈是否在道闸后方足够远的位置避免车辆停在道闸下方导致逻辑无法完成完整脉冲报警一直闪烁无法复位报警源未消失、复位逻辑依赖上升沿检查实际报警输入点是否正常确认PLC程序里复位采用的是状态复位而不是边沿复位这个表我在现场打印了几份贴在每个岗亭里。运维人员遇到问题先查表解决不了的再给我打电话大大降低了沟通成本。另外还有一个常见问题很多新手容易忽略PLC断电再上电之后程序是从头开始跑的计数寄存器如果用的普通寄存器数据会清零。我踩过这个坑之后把车位计数寄存器改成了断电保持寄存器S7-200 SMART里是V区的前一部分或者用保持型M寄存器再配合电池或者超级电容断电后数小时内数据不丢失恢复供电后系统能直接续上之前的计数状态不用人工重新校正。如果你用的是三菱FX3UD0D8是普通寄存器默认断电不保持但可以通过PLC参数设置改成断电保持区域——这个细节在项目验收时一定要测试到不然系统断电一次车位数据就乱了回头客户会来找你麻烦。7. 给新手工程师的几条实操建议如果你看了前面这些内容准备动手做类似项目或者正在准备PLC相关的毕业设计、非标项目竞标下面这几条建议估计能帮你省下不少冤枉时间。第一条方案阶段就要把地址映射表定下来。很多项目失败或者延期根子都在双方约定的接口不清楚。PLC工程师觉得自己写好了就行组态工程师不知道PLC的哪些地址能用、哪些地址有什么含义结果联调的时候鸡同鸭讲。正确做法项目启动时PLC侧先整理好一张完整的数据交换表包含变量名、PLC地址、Modbus寄存器地址、数据类型、读写权限、刷新周期、备注说明组态工程师拿到这张表才能开工。这相当于两个系统之间的接口文档哪怕中途有人换岗新接手的工程师也能快速上手。第二条程序里不要用太多的特殊技巧。我看过一些项目PLC程序写得花里胡哨各种间接寻址、指针操作、复杂的浮点运算看着很炫但一到现场就出问题。停车场这种系统需求本身不复杂程序的可读性和可维护性比炫技重要得多。我用的是最朴素的梯形图一个网段干一件事注释写清楚变量命名规范。半年后有同事接手维护他也能够不看原设计文档就改程序。这一点在非标自动化项目里特别重要因为很多项目交付后需要长期维护而你不可能永远守在现场。第三条调试阶段的测试用例要提前想好。不是你写完程序、通电跑一遍没问题就完事了。正逻辑要测反逻辑也要测——比如入口地感触发后模拟道闸上升到位信号丢失系统应该怎么办应不应该超时报警很多故障只有在设备状态异常时才会暴露程序逻辑的缺陷。所以你现在就盯紧这些边界情况信号长时间不变化、多个输入点同时动作、通信中断再恢复……把测试用例列成表调试时逐个过心里才有底。8. 项目复盘与后续扩展思路这个项目做完交付之后其实还有很多可以二次开发的空间。比如现在我正在尝试的方向是把数字孪生的概念引进来——PLC控制逻辑跑在实际设备上组态软件做的是数据展示如果再加上一套三维模拟场景用OPC UA把PLC的数据实时同步到数字孪生平台里就能在监控室里看到整个停车场的三维车辆状态、设备运行状态。这套玩法现在在智慧园区、智能楼宇项目里很受欢迎报价也能上一个台阶。还有AI方向。现在很多PLC产品开始支持AI代码生成用自然语言描述控制逻辑工具自动生成梯形图或者结构化文本。我试过一些对简单逻辑确实能用但涉及到防砸保护这种安全逻辑还是得人工仔细审核。我觉得AI将来能帮助解决的是逻辑模板复用的问题把标准功能做成一键生成、一键验证工程师把更多精力花在现场的疑难杂症上。另外一个很实在的扩展方向如果同一个车场有多个出入口或者一个集团有好几个停车场数据要汇总那就要在上位管理平台做统一调度——组态软件本身做不了多站点数据聚合但可以通过OPC UA把数据传到云端或总部的数据平台上做集团级的车位统计和财务对账。这个方向对做方案预算的人来说特别有价值因为属于一键升级就能多做一单生意的功能点。我个人在这些项目里最深的体会是自动化项目没有真正意义上的做完交付只是开始设备在运行中暴露出来的问题、客户在使用中冒出来的新需求才是你技术积累的真正来源。每次去现场处理一个故障、在组态画面上多优化一个交互细节都是在给下一个项目积累经验。希望这篇分享能让你在遇到类似项目时少走几个来回折腾的弯路。如果你做的停车场项目和我的方案不太一样欢迎按照自己的需求调整——毕竟现场情况千差万别最懂你的项目的永远是你自己。 基于PLC和组态软件的智能停车场收费系统设计与实现
1. 项目概述1.1 核心需求解析停车收费这件事听起来简单真正做起来却有不少讲究。我做了这么多年自动化项目接触过不少停车场的需求方他们往往一开始的说法都很统一就是入口发卡、出口收费抬杆。可真到现场勘察完你会发现事情完全不是这么简单——车流量统计、车位余量显示、防砸车保护、断电续行、对账查询、高峰期双通道调度每一项都是刚需。这套基于PLC和组态软件的智能停车场收费系统解决的正是这些看似简单、实则琐碎的现场问题。它的核心思路是用PLC做底层逻辑控制和设备联动用组态软件做人机交互和数据管理两者通过工业通信协议如Modbus、OPC UA实现数据交互。相比市面上常见的纯单片机或工控机方案PLC组态的组合在稳定性和抗干扰能力上有天然优势特别适合停车场这种环境复杂、24小时不间断运行的场景。这篇内容是我自己实际做过的一个项目总结从架构搭建、PLC程序编写到组态画面设计再到联合调试中的各种坑完整走了一遍。适合正在做PLC毕业设计的学生、准备接非标自动化项目的一线工程师以及想了解停车场系统内部逻辑的运维人员参考。1.2 为什么选PLC组态软件而非其他方案在做方案选型的时候我们其实对比过三种常见路径第一种是纯单片机方案成本低但扩展性差后期加功能几乎等于重做第二种工控机高级语言开发灵活性强但开发周期长、对现场运维人员的要求高而且死机问题在恶劣环境下很难根治第三种就是PLC组态软件也是我们最终选择的方案。选它的核心理由有三个第一稳定。PLC本身就是为工业环境设计的电源波动、温湿度变化、电磁干扰这些停车场常见的恶劣条件对PLC来说都是小场面。第二开发效率高。组态软件的画面开发是拖拽式的不需要写太多代码逻辑修改也快不像高级语言那样动不动就要重新编译。第三后期好维护。设备出了问题现场电工基本都能上手排查不会像工控机那样黑屏了只能等厂家。当然这套方案也不是没有缺点——它不是一个开箱即用的产品需要针对具体项目做定制开发。但如果你想做一套真正贴合自己需求、不被第三方厂商绑架的系统这条路是值得走的。2. 系统整体建设与设计思路2.1 停车场收费系统的组成架构整套系统的物理架构可以拆成三个层面设备层、控制层和管理层。设备层就是停车场现场那些看得见摸得着的东西入口地感线圈、出口地感线圈、道闸电动栏杆机、车牌识别相机本项目中预留了RS485接口后续可扩展、LED余位显示屏、红绿指示灯、语音播报模块还有最重要的——收费岗亭里的读卡器和管理电脑。这些设备加起来构成了系统最底层的感官和手脚。控制层是整个系统的核心也就是PLC。它负责采集所有传感器的信号、判断车辆状态、控制道闸起落、管理车位计数逻辑。我这里用的是西门子S7-200 SMART系列原因很简单性价比高、资料多、梯形图编程上手快而且它自带的以太网口和RS485口做通信非常方便。如果你用三菱FX3U或者汇川的AM系列整套逻辑同样是适用的只是通信指令写法上需要调整。管理层就是组态软件跑在一台管理电脑上负责车位数据实时监控、收费金额计算、历史记录查询、报表导出等。我们用的是组态王KingView——它在国内停车场项目里用得非常多驱动丰富和S7-200 SMART的通信配置也有现成模板可以参考。如果你熟悉西门子的WINCC同样是可行的只是WINCC的授权和部署成本会高不少。2.2 PLC组态各自的职责边界很多第一次做这类项目的人容易陷入一个误区想把所有逻辑都写在组态软件里让PLC只当一个信号中转站。这是一个非常危险的倾向。我的原则很简单凡是需要实时响应、涉及安全的逻辑必须放在PLC里。比如道闸的防砸控制——地感线圈检测到车底有障碍物时道闸必须立刻停止下降甚至抬升这个响应时间要在毫秒级。如果走组态软件数据要经过通信链路往返一旦通信出现延迟或者断线事故就不可避免。再比如车位计数PLC通过地感信号判断车辆进出这个计数是在PLC内部完成的组态软件只是读这个数值来显示。反过来组态软件负责的是非实时部分收费金额的计算与记录、操作员的登录管理、报表生成、画面切换、报警记录。这些功能对实时性要求不高但逻辑复杂、界面交互频繁用组态软件来做开发效率极高。一句话总结PLC管设备和安全组态管数据和交互。把这条边界划清楚了后面写程序和调画面的时候会顺畅很多。2.3 核心数据流与工作流程整套系统的运转流程是这样的车辆驶入入口道闸前的地感线圈线圈感应到车后PLC收到信号输出指令让入口摄像机进行抓拍识别同时PLC控制道闸抬杆放行。车辆通过道闸下方的第二个地感线圈后PLC判断车辆已完全驶入控制道闸落杆同时车位计数加一这个加一后的数值通过通信实时刷新到组态软件的画面和LED余位显示屏上。出口的逻辑正好相反车辆压到出口地感线圈PLC通知组态软件开始计费如果做的是按时收费收费员在组态画面上操作收费完成后点击放行PLC收到放行指令抬起道闸车辆通过后落杆、计数减一。在内部通信层面PLC的输入映像区有一组地址专门用于和组态软件交换数据我们定义了I区标志位代表出口地感触发、道闸上升到位、道闸下降到位等状态组态软件侧通过Modbus TCP协议周期性读取这些地址同理组态软件向PLC写入放行指令和复位指令时也是通过Q区或者V区地址。这套地址映射表是整个系统联调的通信协议在项目一开始就必须确定好不然后期改起来非常痛苦。3. PLC程序的关键逻辑实现3.1 出入口道闸联动控制道闸控制是整个PLC程序里最核心的逻辑。很多人以为道闸控制就是给信号就抬、再给信号就落实际上完全没有这么简单。安全逻辑在这里占了很大的比重。我做的第一版程序里抬杆逻辑是这样的入口地感线圈动作且收费状态正常组态给了放行信号→ 道闸上升输出置位。道闸上升到位后上升输出复位。这个逻辑看似没问题但实际测试时发现一个坑如果车在道闸正下方停了很久入口地感会一直保持动作状态PLC就一直接到有车的指令。这时候如果操作员手动抬杆道闸抬起来之后又立刻执行落杆——因为地感持续检测到车辆程序误判车还在应该落杆结果就是道闸砸在车顶上。解决这个问题我把控制流程改成了脉冲触发、状态保持模式地感信号只是触发抬杆动作抬杆之后的保持逻辑由中间继电器M来实现地感的持续信号不再参与道闸的保持判断。只有当道闸上升到位信号到达或者落杆指令发出时保持状态才被复位。这套改动之后再没出现过误落杆的情况。3.2 车位计数防重与防漏策略车位计数的准确性是停车场系统最容易被人诟病的地方。你想想车库明明还有空位显示屏显示已满结果外面的车进不来车主投诉或者屏上显示还有几十个空位进去转一圈一个都没有客户直接质疑系统瞎报。这两种情况都严重影响系统口碑。计数逻辑的原理很简单入口地感一个完整脉冲有车→无车就加一出口一个完整脉冲就减一。真正难处理的是防重和防漏。防重一辆车在入口倒车再进轮胎反复碾压地感产生多次脉冲。我的解决办法是加延时确认——地感信号持续动作超过1.5秒才算作一次有效车辆通行并且在同一辆车通过期间从触发到道闸落杆只允许计数一次用置位M寄存器来锁存通行状态直到落杆完成才复位。防漏两辆车紧贴着进出地感信号没有完全断开过第二个脉冲丢失。这个纯靠地感很难完美解决需要在现场把地感灵敏度调低一点、让检测范围覆盖整个车道。如果条件允许加上红外对射或者雷达检测做辅助准确率能提升不少。3.3 道闸防砸保护编程防砸逻辑是停车场系统里最不能省钱、也最不能出bug的部分。道闸砸到车轻则赔钱道歉重则安全事故。常用的防砸手段有三种地感防砸、红外防砸和压力波防砸。我在项目里用地感防砸为主、红外对射为辅。PLC程序里实现这样一个保护逻辑道闸处于下降过程中如果地感线圈被触发说明道闸下方有车或人立即停止下降输出——更准确地说是立即切换到上升输出让道闸抬起来。这里有一个关键细节道闸电机在下降过程中被强行反向驱动对电机和减速箱的冲击很大。所以程序中必须加延时保护——切换方向之前先停顿0.3秒让电机完全停止后再反向启动。这个细节如果不注意用不了几个月电机就会过热甚至烧毁。另外道闸的限位信号也要认真对待。上升限位和下降限位必须接入PLC的输入点如果这两个信号在3秒内同时为ON或者长时间没有变化说明限位开关出了问题PLC应该立即停止道闸控制输出并发出报警。这个逻辑我用了一个定时器和几个比较指令就实现了但它的价值在长时间运行里体现得非常明显。3.4 报警信息采集与处理停车场设备长期在室外运行风吹日晒故障率不低。PLC除了做控制更重要的职责是感知异常并及时上报。我给系统定义了几路报警输入道闸故障、地感线圈断路、通信超时、UPS供电异常。PLC在扫描周期的末尾做一个统一的报警汇总——任何一种异常状态被触发都置位相应的报警寄存器并通过通信写入组态软件组态画面会弹出报警窗口同时伴有声音提示。这里有个经验要分享报警信号不能做成上升沿触发、立即消失必须做成状态保持、手动复位的形式。因为现场运维人员到岗处理是需要时间的如果报警状态自动消失人还没走到现场可能就看不出问题所在了。程序里我特意加了一个延时——报警状态保持至少30秒同时操作员在组态画面手动复位如果30秒内报警源还在状态继续保持。这套机制在实际使用中帮了不少忙。4. 组态软件监控界面与通信配置4.1 组态画面的布局与核心控件组态软件的界面设计直接决定了收费员和运维人员愿不愿意用这套系统。做得好人家觉得方便、清爽做得不好再先进的技术也会被吐槽不如用本子记。我的画面布局分成三个区域顶部是系统状态栏显示当前时间、PLC连接状态、车位余量、操作员姓名。中间是停车场模拟图——用简单的矩形代表车位区域每个区域用不同颜色表示占用或空闲收费员一眼就能看出整个停车场的负载情况。底部是操作区放的是常用按钮手动抬杆、手动落杆、收费确认、报警复位、报表查询。组态软件里最核心的控件是变量动画连接。以车位余量显示为例PLC里VW100地址存的是当前剩余车位数在组态里新建一个IO变量绑定VW100然后在画面上放一个文本显示控件把它的数值输出属性关联到这个变量刷新周期设为500毫秒。这个500毫秒的设置是有讲究的——太快了通信负载大太慢了显示延迟明显实测下来500毫秒是平衡点。4.2 Modbus TCP通信配置与地址映射我用的组态王和S7-200 SMART通信走的是Modbus TCP协议。PLC侧要做两件事一是在S7-200 SMART的编程软件里启用Modbus TCP通信功能块二是把要交换的数据映射到通信区域。这里有个常见坑S7-200 SMART的Modbus TCP库最多支持8个连接每个连接最小通信间隔建议设在10ms以上。如果通信间隔设得太短PLC的扫描周期会被通信任务拖累导致道闸控制逻辑的响应变慢。组态侧新建IO设备时设备地址填PLC的IP通信端口默认502采集频率设置100ms一个周期。数据项按地址映射表逐个添加VW100对应余位数M10.0对应入口抬杆触发M10.1对应出口抬杆触发M20.0对应地感故障报警……总共也就十几个变量配置半小时就能完成。配置完成后在组态软件里做一次设备测试状态显示通讯成功就说明地址映射表没有问题。这里必须强调一个细节Modbus地址的偏移计算。S7-200 SMART的V区地址在Modbus映射里是40001开始的保持寄存器区。比如VW100对应的是40051100/2151如果你的组态软件里填的地址不对读出来的数据永远不对。这个坑我见过太多人踩了而且是在现场调试的时候才暴露出来非常浪费时间。4.3 OPC UA方案的替代路径如果你的项目用的PLC不是S7-200 SMART而是汇川AM系列、倍福Twincat这类支持Codesys平台的设备或者你想让组态软件直接对接传感器、数控机床这些更多种类的设备那Modbus TCP可能就不够用了。这时候OPC UA协议是更好的选择。我后来在另一个项目里就用OPC UA把一台汇川PLC的数据接到了组态软件——OPC UA的优势在于它支持复杂的数据结构安全性更强有证书验证而且自带信息模型设备的数据语义更丰富。组态王本身支持OPC UA客户端功能配置方式是在OPC服务器里新建一个客户端连接指向PLC的OPC UA服务器地址然后浏览节点树把需要的节点一一拖到变量表里即可。如果你的组态画面是多个设备的数据汇总OPC UA这套方案会清爽很多。它不需要你像Modbus那样手工查地址偏移直接浏览节点就能找到想要的变量。当然代价是需要额外部署一个OPC UA服务器而且第一次配置证书环节稍繁琐。5. 实操环节从硬件接线到联合调试5.1 硬件选型与接线要点这里我把整个系统的硬件清单列一下方便你照着做PLC控制器西门子S7-200 SMART SR4024DI/16DO继电器输出这个型号的I/O点数对中小型停车场足够用了通信扩展S7-200 SMART自带以太网口无需额外扩展RS485口可用于接LED显示屏道闸选用380V或220V单相电机道闸带上升限位和下降限位输出接口地感线圈车辆检测器地感处理器输出继电器信号接到PLC输入端组态软件运行电脑普通商用机即可Win10系统4GB内存以上接线时最需要注意的PLC的输入信号线一定要采用屏蔽双绞线屏蔽层单端接地。停车场现场电缆多、干扰源多如果不做屏蔽地感信号和限位信号很容易误动作那种道闸自己抬起来又自己落下去的诡异问题多半不是程序bug而是信号干扰。道闸电机控制我建议用继电器中转——PLC的继电器输出直接驱动道闸电机容易过流烧触点通过一个中间继电器线圈DC24V转接一下既保护了PLC的输出点又方便后期更换。中间继电器选带底座的现场更换时拔插最方便。地感线圈的铺设也有讲究切槽深度4cm左右线圈绕3~4圈线圈到检测器的双绞线长度尽量短不要超过50米。现场很多安装工不懂这个把双绞线走了100多米结果检测器怎么调都不稳定。5.2 通信异常排查实录Modscan能读、组态不能读这个问题的排查过程很有代表性。现场反馈的情况是用ModscanModbus调试助手能正常读到PLC的保持寄存器数据但在西门子组态软件比如WINCC或者相关测试工具里读不到连接状态一直是通信失败。我第一反应是组态软件的通信参数没配对。因为Modscan能读到数据说明PLC侧的Modbus TCP服务器是正常的问题大概率出在客户端侧。排查过程对比Modscan的连接参数和组态软件的参数IP、端口号都一致检查组态软件的采集周期发现设置的是10ms——这太快了PLC的通信功能块处理不过来导致部分请求超时。Modscan默认的轮询间隔是1000ms所以Modscan没事组态软件却超时断连把采集周期改成200ms重新测试连接恢复正常后来我又想了一下这种第三方工具能读、组态软件不能读的问题还有一种原因是组态软件对通信应答时间的容忍度比调试工具严。Modscan发一个请求300ms没收到响应也不会报错只是继续发下一条而组态软件如果200ms没收到响应就直接判定设备离线。所以如果PLC的程序扫描周期很长比如有大段循环处理通信响应会被拖慢这时候组态软件就会误判。解决办法把PLC的通信中断优先级调高或者精简主程序里的大循环逻辑。5.3 地感信号误触发的排查思路地感误触发在停车场系统里太常见了。表现是没有车经过道闸自己抬杆或者车位计数莫名其妙地跳动。排查顺序建议从易到难先看地感检测器的灵敏度设置。检测器面板上一般有灵敏度旋钮或拨码调太高了会把路面上其他金属物体比如铁井盖、拉链、手机放在口袋里的行人都检测到。我们实践下来灵敏度调在中间偏低的档位就够用了再看线圈的铺设。线圈如果有接头接头必须焊接牢固且做好防水绝缘否则下雨天受潮信号会漂移最后查接线。地感检测器输出的是继电器干接点信号如果这段线和动力电缆走在同一个线槽里感应电压就可能让PLC误读到ON状态。把信号线挪远一点或者加中间继电器做电气隔离我们项目里出现过一次很诡异的误触发每天早上8点准时自动抬一次杆后来排查发现是旁边的饮水机加热和道闸共用了一个电源回路加热启动瞬间电压跌落导致PLC的24V电源输出瞬间掉电又恢复——PLC一上电程序初始化道闸输出点有一个短暂的输出脉冲。这个案例当时排查了很久最终锁定在电源上。从那以后我所有项目的PLC电源都单独走一路开关电源绝不敢和电机类负载共用一个电源算是拿教训换来的经验。5.4 联合调试的步骤与验收清单系统组装完成后联合调试千万别带着设备一把梭直接跑那样出了问题根本定位不到。我的调试流程分五步**第一步单设备测试。**PLC单独通电用编程软件的监视模式看输入点能不能正确反映地感和限位信号的变化。这一步确认了硬件接线的正确性。**第二步PLC逻辑纯手动测试。**在组态软件还没接上之前用编程软件里的强制功能模拟输入信号验证道闸控制、计数逻辑是否按预期跑。比如强制地感信号为ON观察道闸输出点是否置位。**第三步通信联调。**启动组态软件新建设备、配置地址、测试连接。这一步看组态和PLC之间的数据是否读写正常重点查地址映射表有没有错位。**第四步组态逻辑联动测试。**在组态画面上操作按钮看PLC侧对应的变量有没有变化同时在PLC侧强制改变状态看组态画面是否刷新。这一步验证的是双方的协议是否一致。**第五步现场端到端模拟。**用实际车辆模拟进出场的完整流程从地感触发到道闸抬杆、计数变化、组态记录生成逐项核对是否符合预期。这一步也是耗时最长的建议把验收清单做成表格一项一项过。验收清单我常用的核心项目包括入口抬杆响应时间从地感触发到道闸启动要求小于1秒、车辆通过后落杆是否平稳、满位后入口是否禁止抬杆、出口收费后是否正常放行、断电再上电后车位计数是否保留了掉电前的状态、连续跑24小时通信是否稳定。6. 常见故障与排查方法速查我在多个停车场项目上积累了不少故障案例整理成下面这个表格方便现场遇到问题时快速定位。这里的处理思路都是实测有效的但每个项目现场环境不同需要结合具体情况做一些调整。故障现象可能原因排查顺序与处理方法组态软件通信超时采集周期太短、PLC扫描周期过长先在组态软件里把采集周期调到200ms以上再检查PLC主程序里是否有大循环、定时中断是否被占用道闸自动起落地感误触发、PLC电源不稳、接线感应电压先调低地感灵敏度再看信号线是否和动力电缆共用线槽最后用万用表监测PLC 24V电源波形车位计数越跑越乱车辆倒车多次触发、地感间隔太近检查计数程序里是否加了1.5秒确认延时和单次锁存逻辑现场检查地感线圈间距是否足够组态画面数据不刷新变量地址映射错误、Modbus地址偏移算错用Modbus调试工具确认实际数据位置重新核对地址转换关系VW地址和Modbus寄存器号不能直接相等道闸落杆后不计数减一出口地感位置摆放不当、车辆没完全驶离检查出口地感线圈是否在道闸后方足够远的位置避免车辆停在道闸下方导致逻辑无法完成完整脉冲报警一直闪烁无法复位报警源未消失、复位逻辑依赖上升沿检查实际报警输入点是否正常确认PLC程序里复位采用的是状态复位而不是边沿复位这个表我在现场打印了几份贴在每个岗亭里。运维人员遇到问题先查表解决不了的再给我打电话大大降低了沟通成本。另外还有一个常见问题很多新手容易忽略PLC断电再上电之后程序是从头开始跑的计数寄存器如果用的普通寄存器数据会清零。我踩过这个坑之后把车位计数寄存器改成了断电保持寄存器S7-200 SMART里是V区的前一部分或者用保持型M寄存器再配合电池或者超级电容断电后数小时内数据不丢失恢复供电后系统能直接续上之前的计数状态不用人工重新校正。如果你用的是三菱FX3UD0D8是普通寄存器默认断电不保持但可以通过PLC参数设置改成断电保持区域——这个细节在项目验收时一定要测试到不然系统断电一次车位数据就乱了回头客户会来找你麻烦。7. 给新手工程师的几条实操建议如果你看了前面这些内容准备动手做类似项目或者正在准备PLC相关的毕业设计、非标项目竞标下面这几条建议估计能帮你省下不少冤枉时间。第一条方案阶段就要把地址映射表定下来。很多项目失败或者延期根子都在双方约定的接口不清楚。PLC工程师觉得自己写好了就行组态工程师不知道PLC的哪些地址能用、哪些地址有什么含义结果联调的时候鸡同鸭讲。正确做法项目启动时PLC侧先整理好一张完整的数据交换表包含变量名、PLC地址、Modbus寄存器地址、数据类型、读写权限、刷新周期、备注说明组态工程师拿到这张表才能开工。这相当于两个系统之间的接口文档哪怕中途有人换岗新接手的工程师也能快速上手。第二条程序里不要用太多的特殊技巧。我看过一些项目PLC程序写得花里胡哨各种间接寻址、指针操作、复杂的浮点运算看着很炫但一到现场就出问题。停车场这种系统需求本身不复杂程序的可读性和可维护性比炫技重要得多。我用的是最朴素的梯形图一个网段干一件事注释写清楚变量命名规范。半年后有同事接手维护他也能够不看原设计文档就改程序。这一点在非标自动化项目里特别重要因为很多项目交付后需要长期维护而你不可能永远守在现场。第三条调试阶段的测试用例要提前想好。不是你写完程序、通电跑一遍没问题就完事了。正逻辑要测反逻辑也要测——比如入口地感触发后模拟道闸上升到位信号丢失系统应该怎么办应不应该超时报警很多故障只有在设备状态异常时才会暴露程序逻辑的缺陷。所以你现在就盯紧这些边界情况信号长时间不变化、多个输入点同时动作、通信中断再恢复……把测试用例列成表调试时逐个过心里才有底。8. 项目复盘与后续扩展思路这个项目做完交付之后其实还有很多可以二次开发的空间。比如现在我正在尝试的方向是把数字孪生的概念引进来——PLC控制逻辑跑在实际设备上组态软件做的是数据展示如果再加上一套三维模拟场景用OPC UA把PLC的数据实时同步到数字孪生平台里就能在监控室里看到整个停车场的三维车辆状态、设备运行状态。这套玩法现在在智慧园区、智能楼宇项目里很受欢迎报价也能上一个台阶。还有AI方向。现在很多PLC产品开始支持AI代码生成用自然语言描述控制逻辑工具自动生成梯形图或者结构化文本。我试过一些对简单逻辑确实能用但涉及到防砸保护这种安全逻辑还是得人工仔细审核。我觉得AI将来能帮助解决的是逻辑模板复用的问题把标准功能做成一键生成、一键验证工程师把更多精力花在现场的疑难杂症上。另外一个很实在的扩展方向如果同一个车场有多个出入口或者一个集团有好几个停车场数据要汇总那就要在上位管理平台做统一调度——组态软件本身做不了多站点数据聚合但可以通过OPC UA把数据传到云端或总部的数据平台上做集团级的车位统计和财务对账。这个方向对做方案预算的人来说特别有价值因为属于一键升级就能多做一单生意的功能点。我个人在这些项目里最深的体会是自动化项目没有真正意义上的做完交付只是开始设备在运行中暴露出来的问题、客户在使用中冒出来的新需求才是你技术积累的真正来源。每次去现场处理一个故障、在组态画面上多优化一个交互细节都是在给下一个项目积累经验。希望这篇分享能让你在遇到类似项目时少走几个来回折腾的弯路。如果你做的停车场项目和我的方案不太一样欢迎按照自己的需求调整——毕竟现场情况千差万别最懂你的项目的永远是你自己。