PLC与组态软件在停车场收费系统中的电气控制实战方案

发布时间:2026/9/9 14:23:52
PLC与组态软件在停车场收费系统中的电气控制实战方案 停车场这种系统听起来不像什么高科技但真正落到电气控制层面牵扯的东西比想象中要多。前两年我接手过一个小型商业体两进两出停车场的收费系统改造甲方既要稳、又要便宜还要求后期能扩展联网。我最终定的方案就是这套基于PLC和组态软件的智能停车场收费系统PLC负责所有现场设备的控制和信号采集组态软件负责收费操作界面、计费规则和数据记录整套系统从选型、接线、编程到组态调试前前后后我全部跟了一遍运行大半年基本没出过大的故障。这篇文章就以这类项目的电气控制为主线把我实际做项目踩过的坑、总结出的经验完整写出来给正在做类似集成项目的朋友一个可以参考的实操方案。1. 项目整体设计方案与需求拆解1.1 停车场场景要处理的信号远比想象多很多人第一反应是停车场收费就是“抬杆、落杆”那么简单真到现场你会发现一个普通入口车道至少要处理三类信号车辆检测信号、道闸状态信号、人机交互信号。先说车辆检测。入口车道的车主停车取卡或者触发车牌识别靠的是埋在地面下的地感线圈车辆驶过线圈上方时检测器输出一个开关量信号给PLC这是最可靠也最经济的车辆存在检测方式。出口车道类似但会多加一个防砸线圈或者红外光栅防止车还没完全离开时道闸就落下砸车。这些检测信号都是数字量输入直接进PLC的输入端。然后是道闸状态信号。道闸内部一般有开到位限位和关到位限位两个行程开关PLC必须知道当前道闸到底是在完全打开状态、完全关闭状态还是正在运动中间状态否则逻辑判断就无从谈起。中间状态如果长时间不结束基本就能判定道闸机械故障或者电机堵转必须触发报警。再就是人机交互。收费员在出口收费时需要一个操作界面通过界面确认车牌、收费金额、点击“开闸”按钮这个操作信号通过组态软件下发到PLC。入口处如果是取卡模式还要有取卡按钮和发卡机如果是纯车牌识别模式则需要识别相机给出一个“识别完成”的干接点信号或者网络信号给PLC作为开闸条件。把这些信号放到一起看一个标准出入口的I/O清单就出来了信号类型信号名称说明输入触发地感车进入入口/出口时的第一道检测输入防砸地感道闸下方的车辆存在检测有车严禁落杆输入开到位限位道闸升到位反馈输入关到位限位道闸降到位反馈输入手动开闸按钮收费员或保安应急使用输入急停按钮现场安全回路专用输出道闸升驱动道闸电机上升输出道闸降驱动道闸电机下降或解除保持输出警示灯/蜂鸣器道闸动作期间的声光提示两个入口加两个出口再加上一点冗余I/O点大概就是二十几个输入、十几个输出。这个规模很小但麻雀虽小五脏俱全电气设计上一样都不能落下。1.2 为什么是“PLC做控制、组态做交互”这套组合这套方案的核心分工就是PLC管现场、组态管交互。先说为什么不用传统的中间继电器控制柜。停车场如果只有单进单出纯继电器也能做几个中间继电器加时间继电器就能实现抬杆延时落杆。但到了两进两出、一个管理室集中控制、还要区分月卡车和临时车、统计车位数继电器柜的逻辑就复杂到没法维护了。PLC用梯形图写逻辑逻辑变化只需改程序完全不用动柜内接线这是第一层优势。为什么不能干脆用一个PC配IO采集卡来做成本和稳定性都过不了关。停车场出入口设备都在户外环境电磁干扰大雷雨天感应浪涌是常事PC主板和USB采集卡扛不住这种折腾。PLC是按工业环境设计的电源抗干扰能力、端口防护等级都远超普通板卡而且一旦程序写好后运行非常稳定不担心死机重启。这一点在项目交付后的运维阶段会变得格外明显。组态软件则解决了交互层的效率问题。收费员要看的不是一堆PLC指示灯而是直观的窗口界面当前车在哪个车道、车牌是什么、停车多久了、该收多少钱。如果全部用代码写上位机开发周期长后期甲方要求改个界面样式也很麻烦。组态软件的优势是图形化拖拽、支持主流PLC通信驱动、内置报警记录和历史数据存储几天就能搭出一个像模像样的收费管理界面。这套组合的额外好处是可扩展性好。后期如果甲方想接入云平台组态软件可以直接提供数据库接口或者OPC接口PLC不需要改动只在组态层加功能就行。总之这套方案从一开始我就坚守两个原则控制层全部下沉到PLC不依赖上位机存活交互层用组态软件完成开发快、改起来快、维护成本低。2. 硬件选型与电气接线要点2.1 PLC选型先算I/O点再定具体型号很多初学者容易犯的错误是一上来就问“用什么牌子什么型号”其实选型第一步永远是算I/O点I/O点数决定PLC本体规模和扩展方式。以两进两出停车场为例每个入口车道我按6个输入、3个输出估算触发地感、防砸地感、开到位、关到位、手动开闸按钮、急停按钮输出是道闸升、道闸降、警示灯。每个出口车道情况类似也是6个输入左右只是输出可能多一个收费完成提示灯。那么总计输入约24点、输出约12点。再加上备用点我一般直接乘以1.2左右的系数输入30点、输出16点是比较舒服的配置。这个量级下两台PLC分开控制或者一台PLC集中控制都可行。我个人的习惯是单台PLC做整站控制简单、成本低、联动方便。具体选型上国产台达DVP系列是性价比很高的选择本身自带RS485口支持Modbus RTU从站协议和组态软件通信非常方便这也是很多人搜“台达PLC 485从站”的原因。西门子S7-200 SMART也常用CPU本体带网口和组态软件走以太网通信更顺手。如果后续要接车牌识别相机做协议联动网口版PLC优势更大。PLC的继电器输出和晶体管输出也要想清楚。道闸电机和警示灯这种负载我偏向选用继电器输出型PLC触点可以直接切换中间继电器或小接触器隔离性好不用像晶体管输出那样外接固态继电器。缺点是继电器触点寿命有上限但停车场道闸一天动作几百次几年算下来也远没到寿命极限。通道扩展也要提前预留。如果在现有方案基础上还要增加车位引导屏、剩余车位显示或者更多车道的门禁控制小型PLC的扩展模块或者CPU本体的I/O余量必须够用不然就得换主机整个程序迁移成本很高。2.2 外围设备清单与控制柜接线细节整套系统的外围设备包括道闸栏杆机、地感线圈车辆检测器、数字显示屏、车牌识别相机、读卡器或者扫码器、急停开关、手动按钮、声光报警器以及为PLC和传感器供电的24V开关电源。接线中最重要的一个原则是强电和弱电分离。道闸电机一般用AC220V而PLC的输入信号是DC24V信号线和动力线在同一个线槽里平行走线大概率会出现干扰。我现场布线时动力电缆和信号电缆各自走独立的线槽或穿管间距至少保持20厘米以上实在避不开就十字交叉严禁平行长距离捆在一起。PLC输出端不能直接驱动大功率设备。道闸电机虽然功率不大但启动瞬间电流不小而且电机是感性负载断开瞬间会产生反向电动势。我在每个PLC输出点后面串接一个中间继电器再由中间继电器的触点去控制道闸电机或接触器同时在继电器线圈两端反向并联续流二极管。这样做既保护了PLC输出触点也让控制柜整体维护起来更安全——坏了换中间继电器就行不用拆PLC。接地是另一件容易被忽视但极其重要的事。PLC的电源地、传感器的屏蔽接地、柜体接地要合理规划。地感线圈的引出线必须用双绞线而且尽量远离动力线。线圈本身在路面切割的深度和匝数也要按检测器说明书来一般车辆检测器要求线圈周长2米左右匝数根据周长不同从2匝到5匝不等切槽深度约4到5厘米。线圈处理不好最常见的故障就是“有车不检测”或“无车乱检测”后面排查相当费劲。提示整套电气控制柜建议单独配一个总电源开关和急停回路。急停按钮不经过PLC直接串在道闸电机的控制回路里按下后无论PLC程序什么状态道闸电机都必须断电停止。这条安全回路是我做任何项目都不妥协的底线。3. PLC核心控制逻辑与程序编写3.1 入口控制逻辑从检测到落杆的完整动作链入口控制的目标是车来了抬杆车走了落杆且在这期间不能出现砸车、误抬杆的情况。我用状态法来写逻辑程序整个入口控制就是一个有限状态机比用一堆互锁触点去堆逻辑要清晰得多。默认状态是“待车进入”。触发地感检测到车辆输入端X0置ONPLC开始执行计时等待给组态软件一个“车辆到达”信号组态软件控制车牌识别相机抓拍识别识别成功后向PLC对应寄存器写入“识别完成”位。如果是取卡模式则是车主按下取卡按钮发卡机出卡并返回一个出卡完成信号。当PLC收到识别完成信号或者出卡完成信号输出Q0置ON驱动道闸上升。开到位限位X1导通后PLC记录道闸处于“完全打开”状态此时输出Q0可断开。道闸保持在打开状态等待车辆通过。车辆继续前进压到道闸下方的防砸地感X2然后驶离防砸地感。当防砸地感从ON变成OFF说明车辆已经通过道闸区域PLC启动落杆延时比如延时2秒让车尾能有安全距离然后输出Q1置ON驱动道闸下降。关到位限位X3导通后整个入口流程复位回到待车状态。如果防砸地感检测到有车还在道闸下方那么无论程序运行到什么步骤落杆动作都会被禁止同时PLC应该输出一个声光提示告知现场管理员“杆下有车”。这段互锁逻辑必须单独处理不能省。程序设计时我习惯把所有输入信号在程序开头做一个“中间映像”例如把X0到X7统一移动到M0到M7里这样后续逻辑全部使用M变量而不是直接用输入点方便后期改线换点也方便组态软件做监控。3.2 出口收费控制逻辑永远要把“人工确认”放中间出口车道的控制逻辑比入口复杂核心区别在于出口多了一个“收费确认”环节。临时车辆到了出口必须等收费员在组态界面上确认收费完成或月卡验证通过道闸才能打开。出场的流程是这样车辆压到出口触发地感PLC通知组态软件有车辆出场组态软件根据入场记录计算出停车费用收费员查看车牌、确认收费收费员点击“确认放行”按钮后组态软件向PLC发送一个开闸允许信号。PLC只有在收到这个开闸允许信号并且出口触发地感仍然处于有车状态的前提下才执行抬杆动作。这个“有车才抬杆”的条件很关键。如果现场系统还没识别到车收费员提前点了开闸道闸不应该动作避免出现道闸空开又直接落下的无效动作。车辆驶过防砸地感后防砸地感从ON变为OFFPLC启动落杆延时落杆复位。月卡车和免费车要单独处理。月卡车出场时组态软件可以设置为识别到月卡车牌后自动发送开闸允许信号不经过人工确认。但为了现场安全和管理可追溯我通常会在组态界面加一个“自动放行记录”每次自动开闸都生成一条流水记录包含时间、车牌和触发方式方便后期对账。出口控制还有一个容易踩的坑就是出入口共用一个管理室但通道距离较远时不同车道的状态会互相影响。我的做法是每一路车道建立独立的状态字寄存器入口2的状态不会覆盖入口1的状态整个程序里所有标志位都带车道号后缀。这样做虽然有重复代码但可读性、稳定性都会好很多。3.3 防砸车与异常保护这是现场口碑的分水岭停车场系统客户抱怨最多的不是收费不准而是道闸砸车。防砸功能做得好不好直接决定这个项目交付后是省心还是不断被投诉。防砸逻辑我认为至少要有三层保护。第一层是防砸地感检测。道闸正下方的防砸地感一旦检测到车辆存在PLC任何情况下都禁止落杆。更稳妥的做法是如果防砸地感在落杆过程中突然触发PLC不仅立即停止下降还应该自动重新抬杆给车辆留出安全空间。有些道闸控制器自身也带防砸功能但PLC这层必须自己做双保险。第二层是限位和时间双重保护。道闸如果出现机构卡住、限位开关损坏电机一直在运行却永远到不了位这种情况不能等人工发现因为电机很快会烧毁。我写的道闸控制逻辑中每次开闸或关闸动作都会启动一个计时器例如开闸计时8秒、关闸计时8秒如果计时到限位还未触发PLC强制断开输出并报警提示值班人员“道闸异常需现场检查”。第三层是急停回路。这个我在电气接线部分强调过急停按钮直接串在道闸电机控制回路中不依赖PLC程序。即使PLC死机或程序出错现场人员拍下急停按钮道闸电机也一定会断电。三层保护叠加才能谈得上有安全保证。4. 组态软件界面搭建与通信配置4.1 组态软件选择如果是我会怎么定组态软件是停车场收费系统面向操作人员的第一当面选型时主要考虑三点通信驱动全不全、画面开发快不快、授权费用合不合理。我用得最多的国产组态软件是MCGS也就是昆仑通态。MCGS在项目中的优势很明显设备驱动库覆盖国内主流PLC品牌西门子、三菱、台达、汇川都能直接选驱动不用自己写通信协议画界面是拖拽式的按钮、指示灯、文本框、仪表盘都能直接绑定变量脚本语言也足够灵活计费计算、时间转换、数据库写入这些都能搞定。而且MCGS有嵌入版、通用版、网络版单机项目用嵌入版就能满足授权费也控制在可以接受的范围。如果项目预算紧张或者希望整体更“轻”可以考虑FUXA这类开源Web组态软件。FUXA基于Node.js支持Modbus TCP和Modbus RTU前端界面比较现代适合做远程网页监控。但它的问题在于驱动生态不如商业组态软件完善和某些PLC的私有协议配合时比较费劲而且技术文档、中文案例都相对少现场实施对工程师要求更高。我的经验是常规停车场项目用MCGS研发项目或者要交付给用户做二次开发的才考虑FUXA。还有一点很实际就是后续维护人员的熟悉程度。很多停车场设备的维护电工接触最多的就是MCGS或者组态王这一类的国产软件。交付一套他们熟悉的软件以后甲方自己改界面、查记录都方面得多对我们的售后压力也小很多。4.2 PLC与组态的通信打通90%的坑都在这PLC和组态软件之间的通信是这类项目里出现频率最高的故障点。通信方式基本可以分成两种串口RS485通信和以太网通信。先说RS485串口通信。台达DVP系列PLC做从站组态软件做主站这是最经典也最便宜的配置。连接上PLC的RS485端子D和D-分别接到组态软件所在电脑串口卡或者USB转485模块的对应端子上。参数上PLC侧要设置好从站地址、波特率、数据位、校验位、停止位组态软件侧在设备窗口新建设备时选择对应驱动并填上完全一致的参数任何一位对不上都通信不成功。常见参数组合是9600波特率、8位数据、无校验、1位停止位站号从1开始。Modbus寄存器映射是另一个高频踩坑点。台达PLC的M区对应Modbus的0区D区对应4区但Modbus协议里的地址偏移和PLC软元件编号之间经常不是一一对应组态软件里建立变量时如果地址填错一位读到的数据就完全不对。我的习惯是先在PLC程序里专门定义一张“通信变量表”把组态需要交互的数据集中放到连续的D区或M区保证程序内部变量和通信变量分离再点对点做好映射。实际应用中比如PLC的M100代表入口道闸开到位组态软件设备变量就填M100对应Modbus地址D100代表当前收费金额组态变量就绑定到对应寄存器。调试阶段必须反复核对这些地址。再聊以太网通信。西门子S7-200 SMART直接走网口连接MCGS非常简单MCGS的驱动里选“西门子S7-200 SMART”填PLC的IP地址即可变量按I、Q、V区直接映射。如果需要走Modbus TCP则要在PLC里调用MB_SERVER指令块配置好服务器连接和寄存器缓冲区。以太网方式的好处是布线简单、抗干扰能力强、通信速度快而且还能同时接多台上位机。如今组态软件、视频监控、停车场管理平台可能都需要访问PLC数据网口的扩展性显然更好。4.3 收费界面和计费逻辑的几个关键实现组态软件的界面布局我认为至少要分成三个区域总览区、操作区、告警区。总览区显示整个停车场的实时状态包括每个车道当前是否有车、道闸状态、车位剩余数量。操作区是收费员日常操作的集中区域显示当前车辆的车牌、入场时间、停车时长、应收金额并提供“确认收费”“直接放行”等按钮。告警区用于实时提示异常状态比如道闸故障、通信断开、检测器故障等有告警时界面上要有明显的颜色变化和声音提示。计费逻辑的实现是组态软件里的重头戏。我用MCGS开发时入场时刻由组态软件记录到本地数据库或临时变量中车辆出场时组态软件用脚本计算当前时间与入场时间的时间差再按费率规则计算费用。费率规则建议做成可配置项而不是硬编码在脚本里。我一般会在组态画面里设一个“费率设置”页面包含首小时费用、续时费用、单日封顶费用等参数这些参数保存到独立的数据区或数据库字段里。这样一来甲方想调价的时候自己就能在界面上改不用找技术人员重新改程序。计费完成后的数据记录也很重要。收费流水至少要包含车牌、入场时间、出场时间、停车时长、应收金额、实收金额、收费员账号。这些数据建议通过组态软件的数据库功能写入SQLite或MySQL/MSSQL数据库文件方便后期按天、按月对账。我见过不少项目因为只把记录写在组态临时表格里电脑一重启数据全没了到月底对账完全对不上这是必须避免的。5. 调试、排查与项目现场的实战心得5.1 通信不上先按这个顺序查通信问题是这类项目现场最常见的问题没有之一。我自己总结了排查顺序按这个步骤走能省很多时间。先看物理层。RS485的A、B信号线是不是接反了屏蔽层是不是单端接地了接口螺丝是不是拧紧了USB转485模块的驱动装了吗。这些基础项用万用表量一下线路通断就能确认。其次看通信参数。组态软件里的参数和PLC侧设置必须完全一致波特率、数据位、停止位、校验位尤其是校验位和停止位很多PLC默认2位停止位组态软件默认1位对不上就白忙活。然后是站号。一台PLC一个站号站号必须和组态软件设备配置里填的完全一致。如果现场是多台PLC组网站号冲突会让整个网络通信都不稳定。物理和参数都查完了可以用Modbus调试工具直接读取PLC的寄存器比如Modbus Poll这类软件自己当主站去读PLC的地址看有没有数据返回。如果调试工具能读到组态软件读不到问题基本出在组态软件的设备变量绑定上如果调试工具也读不到那就回到物理层和参数层继续排查。通信恢复后建议再用组态软件的历史曲线或者数据报表功能观察一段时间确认数据不跳变、不偶发断线才算真正稳定。5.2 现场干扰与电气故障处理经验停车场设备和配电柜经常挨得很近干扰问题特别典型。我遇到过的最顽固故障是道闸动作瞬间PLC偶发复位换了PLC电源模块、加装滤波器最后排查发现是道闸电机的动力线与PLC的24V电源线在同一个线槽并行走了十几米电机启动时的电磁干扰直接串入了PLC电源。最后把动力线和信号线彻底分开故障再也没出现。这个案例能说明一个道理PLC软件再牛也扛不住硬件层面的干扰。凡是涉及感性负载的场合电机触点两端必须加吸收回路凡是信号线穿过干扰源区域屏蔽层必须按规定接地凡是柜内空间允许动力器件尽量和控制器分区域布置。还有一类问题是接地不良。有些现场把PLC的GND和柜体地混在一起而柜体接地不良导致整个系统成了天线的接收器。我处理这类问题时会单独测量PLC模拟地、数字地、保护地之间的电位差要求各种地之间的压差控制在安全范围内必要时用单独的地桩重新接地。地感线圈的检测故障也值得一提。车辆检测器对线圈的要求很严格如果路基里有钢筋网线圈的感应面积和参数会变得不稳定容易出现漏检。这种情况可以把线圈做成“8”字形或者改进切割方式但最稳妥的办法还是选灵敏度可调的检测器现场边调边测试找到最合适的档位。5.3 交付时容易被忽略但印象分极高的东西项目交付不是程序能跑就算完成我对交付的标准是“甲方能独立运维”。所以每次项目我都坚持交付三样附加东西I/O分配表、通信参数表、运维操作说明。I/O分配表详细列出每个PLC输入输出点接的设备名称、线号、所在端子位置。通信参数表则包含PLC站号、波特率、组态软件设备配置截图、关键寄存器地址含义。运维操作说明针对值班人员写清楚急停按钮怎么用、手动开闸在什么情况下可以操作、报警时第一步看什么。这些文档不需要多厚但一定得有因为项目运行半年以后连我自己都可能记不住当初某个中间继电器的编号。还有一个小技巧可以在组态软件的画面里加一页“诊断页面”把PLC运行状态、通信状态、主要输入输出点的实时值全部显示在一个屏幕上。现场出问题时让甲方把这一页截图发过来远程就能初步判断故障方向免去反复跑现场的麻烦。这个页面对后续售后支持帮助极大强烈建议做进去。整套系统做下来我最深的体会是停车场项目虽然不算复杂但它非常考验电气工程师的综合能力——既要懂PLC编程又要懂现场接线和抗干扰还要能搞定组态软件的通信。技术方案选型只是开始真正拉开项目成败差距的是细节处理和现场经验。如果你正准备做类似的设备希望这些内容能帮你少踩几个坑。

相关新闻