1. 为什么用S7-1200做停车场控制项目立项时的真实考量接手这个智能停车场车位控制系统的项目时甲方最开始的需求其实并不复杂——某个产业园区的地下停车场有120个车位希望实现三个功能实时显示剩余车位数、入口道闸自动抬杆、车位引导屏提示空位方向。就这么点需求市面上随便一个车牌识别一体机方案商都能报出价格为什么最终决定用西门子S7-1200 PLC来做这得从项目现场的几个硬性条件说起。首先是现有设备的兼容性。这个停车场不是新建的道闸、地感线圈、红外对射这些基础设备已经存在而且运行了好几年。甲方不想把这些老设备全部推倒重来而是希望有一套控制系统能把它们统一管理起来。道闸的控制是标准的开关量信号地感线圈输出的是继电器干接点信号红外对射同样如此——这些东西天然就是数字量输入输出和PLC的DI/DO通道完美对接。如果用嵌入式方案或者单片机方案反而需要额外设计信号转换电路增加了故障点。其次是可靠性和稳定性要求。停车场设备在室外和地下环境常年运行温度范围宽、湿度大、还会遇到雷击浪涌。甲方明确要求系统平均无故障时间不低于一年而且一旦停电恢复后要能自动回到正确运行状态。这正好是PLC的看家本领——工业级设计、宽温运行、看门狗自恢复这些特性在工业现场已经被验证了无数年拿来应付停车场这种相对温和的环境完全是降维打击。第三点是后期维护的便利性。园区本身有电工和弱电维护人员他们对PLC普遍有基础认知。用S7-1200做控制核心万一日后要改逻辑、调参数维护人员通过博途TIA Portal软件就能在线修改监控不需要厂家到场。这一点在后来的实际运行中证明极其重要——甲方在系统交付后提了两次小需求变更调整高峰期道闸延时时间、增加夜间降噪模式都是他们自己的电工看了我写的注释后动手改的。选型时我其实纠结了一下S7-1200和S7-200 SMART。200 SMART价格更便宜而且同样是以太网接口。但对比下来最终还是选了1200核心原因有三个第一S7-1200的PID和模拟量处理能力更强虽然当前停车场项目没有模拟量输入但考虑到后续可能扩展地磁传感器或者超声波模拟量探头1200的平台更从容第二1200在博途环境下编程和后续上位机通信、HMI组态的配合更顺畅第三1200的程序存储空间更大可以留出充足余量给日后的功能扩展。顺带说一句硬件选型的具体配置给打算抄作业的朋友做个参考CPUS7-1200 1214C DC/DC/DC14路数字量输入、10路数字量输出集成2路模拟量输入扩展模块SM 1223 DI16/DQ16增加16路数字量输入和16路数字量输出预留余量通信模块CPU本体集成PROFINET接口通过以太网与上位机和交换机通信人机界面KTP700 Basic PN现场触摸屏显示车位信息和手动控制界面上位机软件Visual Studio 2019 C# WinForm数据看板和报表这套配置下来硬件成本大约在8000元上下比车牌识别一体机方案报价通常2万起步便宜不少而且功能更加灵活可控这也是甲方最终拍板的重要原因。2. 硬件拓扑与信号分配停车场设备如何与PLC建立连接方案定了PLC之后接下来要解决的是物理世界怎么接进来的问题。停车场里的设备五花八门有出入口道闸、入口地感、出口地感、车位检测传感器我最终选的是超声波车位探测器、LED剩余车位显示屏、红绿状态指示灯、语音播报模块。这些设备怎么和S7-1200建立起可靠的连接我在设计时对信号类型做了仔细梳理。2.1 车位检测层的信号采集方案车位检测是整个系统的信息来源这部分如果数据不可靠后面所有逻辑都是空中楼阁。我调研了市面上几种车位检测方案地感线圈、红外对射、超声波探测器、地磁传感器。地感线圈对车辆底盘高度的敏感性不错但需要在车位上开槽布线施工破坏性大后期维护麻烦红外对射便宜但极易受灰尘和光线干扰地磁传感器无线方案成本高电池维护也是长期负担。最终选了超声波车位探测器挂在车位正上方的天花板上每个探测器内置一个超声波探头和一个LED指示灯红色表示占用绿色表示空闲输出方式是继电器无源干接点信号——有车时继电器吸合无车时释放。这个信号直接接入PLC的数字量输入通道每个车位占用一路DI。这里有个细节值得注意S7-1200的数字量输入回路是漏型/源型兼容的但24V DC供电方向有讲究。超声波探测器是NPN输出的信号线输出低电平有效所以PLC公共端M端要接入24V信号接入DI通道当探测器继电器吸合时DI通道被拉低PLC读到的就是0。这和很多人习惯的高电平有效相反接线时必须看仔细说明书我第一次做类似项目时就在这个细节上吃过亏当时是怎么查都查不出为什么输入信号不来最后万用表一量才发现是公共端电源接反了。2.2 执行层的输出通道规划控制输出这一侧相对简单直接。道闸控制有三路信号开闸上升沿有效、关闸上升沿有效、状态反馈道闸是否到位。这里有个经验值得分享——很多道闸控制板提供的是开/停/关三线控制方式即两根信号线分别为开和关按下时给脉冲松手停止。但道闸一旦启动到限位位置会自动停止所以PLC这边只需要给一个短脉冲300ms~500ms触发开/关动作即可不需要持续保持电平。LED剩余车位显示屏则是标准的RS485通信在PLC侧加了一个RS485通信模块CB1241。屏上有4位数码管支持Modbus RTU协议PLC作为Modbus主站向屏写入显示数据。之所以不用DO点直接驱动数码管是因为剩余车位数是从0到120的两百多种变化状态用开关量控制会导致逻辑复杂到无法维护用通信方式一帧数据就搞定了。红绿指示灯的状态指示逻辑是入口处绿灯常亮表示有车位、红灯亮起表示车库已满每个车位上的超声波探测器自带LED指示这部分就不占用PLC输出了。2.3 供电设计与抗干扰处理S7-1200用的24V直流电源取自开关电源明纬DR-120-24但从现场经验看停车场设备的电磁干扰是个很容易被低估的问题——特别是道闸电机启停瞬间的电流冲击还有地下车库照明回路上的感性和容性负载切换都会在24V母线上制造毛刺。因此我给PLC供电回路做了三级处理开关电源输出端并联一个大容量电解电容1000μF/35V吸收低频纹波PLC电源入口串联一个EMI滤波器即电磁干扰滤波器选用TDK的通用品所有DI/DO信号线使用带屏蔽层的多芯电缆屏蔽层单端接地在PLC控制柜内接地排同时把PLC控制柜放在入口岗亭内部和室外设备之间通过屏蔽电缆连接线缆长度控制在50米以内这些措施保证了系统在运行中几乎没有因为干扰导致误动作的情况。I/O地址分配表我整理过一次发在项目文档里大致结构是这样的信号类型地址范围用途DII0.0 - I0.3入口地感、出口地感、道闸开到位、道闸关到位DII0.4 - I0.7备用、急停、手自动切换、语音播报反馈DII1.0 - I1.7车位探测器 1# - 8#分布式扩展按块划分DII2.0 - I2.7车位探测器 9# - 16#DII8.0 - I8.7通过SM1223扩展的DI通道车位探测器继续往后排DQQ0.0 - Q0.3入口道闸开、关出口道闸开、关DQQ0.4 - Q0.7LED屏电源、语音播报触发、指示灯、备用DQQ4.0 - Q4.7通过SM1223扩展的DQ通道冗余备用3. 博途里的核心逻辑设计车位状态机与防抖处理硬件接线完成之后工作重心转移到TIA Portal V15里面的程序开发。整个PLC程序我拆解成三个功能块现场信号采集与处理FC1、车位状态管理与剩余车位计数FC2、输出控制逻辑FC3外加一个主程序OB1进行总调度。这里重点聊聊软件的架构设计思路和几个关键逻辑细节。3.1 为什么不用继电器电路而用PLC程序多说一句背景。传统停车场的控制都是用中间继电器搭建的逻辑电路——入口地感检测到车、继电器吸合给道闸发开闸信号车走后延时继电器再触发关闸。这套电路在简单的单入口单出口场景下确实够用但只要加上剩余车位计数满位自动切换多出入口协调这些逻辑继电器电路就会爆炸式复杂——触点和线圈的数量呈指数级增长接线图施工难度和维护成本都不可控。PLC程序从根本上解决了这个问题。逻辑用梯形图或者SCL语言描述改动逻辑不需要拆线重接只需要修改程序下载进去。这次项目的逻辑规模大概用了300多行SCL代码和一段梯形图配合如果全部用继电器实现估计得两个控制柜的继电器才能塞下。3.2 车位状态机的四态模型每个车位我有四个状态空闲IDLE、占用OCCUPIED、进入中ENTERING、离开中LEAVING。这个状态机是设计中最有价值的部分解决了超声波探测器信号在临界状态的抖动问题。现实场景有这样的问题一辆车从车位上方缓缓经过或者在车位边缘停了一下又开走超声波探头检测到的信号就会在有车和无车之间跳变。如果程序只根据当前探头状态直接判断占用或空闲那么剩余车位数的统计很快就会错乱。我最初的设计就是吃了这个亏——上线第一天剩余车位数字就开始不正常一会儿多一会儿少甲方差点以为这套系统根本不能用。后来改成四态模型探测器的原始信号进入状态机之后必须先在一个状态保持稳定超过2秒状态才允许切换。比如当前车位是空闲探测器变为了有车状态先切到进入中如果这个有车状态稳定保持超过2秒则正式切到占用如果期间信号又变回无车则回到空闲。这样做的本质是把原始信号做了时间窗口的滤波消除毛刺和临界抖动的影响。用SCL实现这个状态机的核心逻辑大致是// 状态机定义 CASE car_status OF 0: // IDLE 空闲 IF raw_signal TRUE THEN timer_start; // 开始计时 car_status : 1; // 进入中 END_IF; 1: // ENTERING 进入中 IF raw_signal TRUE THEN IF timer_elapsed 2000 THEN car_status : 2; // 占用 occupied_count : occupied_count 1; END_IF; ELSE car_status : 0; // 回到空闲 END_IF; 2: // OCCUPIED 占用 IF raw_signal FALSE THEN timer_start; // 重新计时 car_status : 3; // 离开中 END_IF; 3: // LEAVING 离开中 IF raw_signal FALSE THEN IF timer_elapsed 2000 THEN car_status : 0; // 空闲 occupied_count : occupied_count - 1; END_IF; ELSE car_status : 2; // 回到占用 END_IF; END_CASE;这段代码里还隐含了一个保护逻辑如果超声波探测器故障导致信号异常长期不变或者车辆长时间停在车位边缘导致信号反复跳变状态机最终会在进入中和离开中两个状态之间来回而不会错误地增减计数——因为只有在稳定切换时才更新计数。3.3 剩余车位计的防重入保护剩余车位数的准确性是整个系统的命脉入口大屏上显示的数字如果错了驾驶员的信任感瞬间崩溃。除了状态机处理单车位信号之外我还在全局计数上加了几个保险第一总余位数采用物理上界限幅。剩余车位总数 总车位数 - 占用数范围必须锁定在0到总车位数之间。如果计算出来的结果小于0或者大于总车位数直接判定为数据异常PLC会触发一个报警位通知维护人员同时大屏上显示--而不是一个错误的数字。第二每个车位对应的占用状态记忆采用断电保持Retentive Memory。S7-1200里需要将存储车位状态和剩余车位数的DB块变量设置为保持属性。这个设计很关键——停车场会发生意外断电如果PLC重新上电后所有车位都变成空闲而实际停车场里停了半场车那剩余位数就会虚高入口车辆涌入后发现没位置体验极其糟糕。设置为保持属性的变量在PLC重启后保存断电时的值系统恢复供电后状态自动延续。第三入口与出口的计数逻辑采用双向校验。停车场设计中还有一个隐藏逻辑入口道闸的开闸信号触发行入计数出口道闸的开闸信号触发行出计数系统预期的场内车数 累加行入 - 累计行出。这套累计值可以和车位探测器统计的占用数做交叉比对——如果偏差超过5辆系统触发报警提示检测系统可能存在车位探测失效请排查。虽然基于道闸的逻辑在没有车牌识别的情况下无法做到百分百准确但作为粗粒度的健康监测已经足够了。3.4 道闸控制的互锁与延时策略道闸控制这块PLC程序里做了开闸优先、关闸延时的策略。入口地感1检测到车辆到达时PLC立即输出开闸脉冲同时启动一个定时器默认3秒定时器到时间后自动输出关闸脉冲。但这里有个防夹车的保护逻辑如果车辆在前一辆车还没完全通过闸机时就已经到达比如连续两辆车跟得很近地感2门槛内侧的检测线圈一旦检测到还有车在闸机下方关闸脉冲就不发送。这是用梯形图实现互锁和延时最直观的地方// 入口开闸触发地感1有车且道闸不在打开状态 Network 1: // I0.0是入口地感Q0.0是开闸输出Q0.1是关闸输出 I_入口地感 Q_开闸输出 Q_开闸输出 ----[ ]----------[/]----------------------( ) | | | I_开到位限位 | ----[ ]-----------------------------------( ) // 保持信号直到开到位 Network 2: // 3秒延时后自动关闸但门槛检测有车则禁止 Q_开闸输出 T_延时关闸 T_延时关闸 ----[ ]------------(TON)-------------------( ) // 实际关闸输出定时器到点 且 门槛内无车 且 手动模式下允许 Network 3: T_延时关闸.Q I_门内无车 Q_关闸输出 ----[ ]------------[ ]----------------------( )这部分的细节全在时序上。实际调试中发现如果开闸信号保持过长时间道闸电机会持续堵转发热长时间运行容易损坏电机。所以开闸输出在道闸到位反馈I0.2到达后必须立即断开。另外延时关闸时间要配合车辆的通过速度调整——设得太短容易在车辆还没完全通过时闸机落下砸车设得太长又会让后面的车误以为道闸坏了。我在现场测了几十辆车最终把3秒调整到了4.5秒才在效率和安全性上找到平衡点。4. C#上位机与S7-1200的通信实战从S7协议到数据看板在停车场控制项目里PLC解决了现场控制的可靠性问题但管理者和运维人员还需要一个直观的操作界面——实时看到剩余车位数、车流量统计、历史记录、手动遥控道闸。这个需求就是上位机软件的职责了。我在调研后选择了C# Windows Forms的方案主要通过以太网和S7-1200的PROFINET接口通信。这一节重点聊通信实现的技术细节。4.1 通信方式选型为什么放弃S7.NET选择Sharp7S7-1200对外通信常用的方式是S7协议TCP端口102。C#环境里访问这个协议最流行的库有S7.NET基于.NET Standard和Sharp7原生C实现的封装库另外还有Siemens官方提供的S7-1200/1500开放式开发库比如Siemens.Simatic.S7.Communication。我最终选择了Sharp7原因是它稳定、轻量、文档全社区用户多遇到问题容易找到解决方案。对比一下这几个库的实际体验——S7.NET的API设计更面向对象读数据直接返回强类型对象写起来确实舒服但在连续高频率轮询时偶发掉线需要自己实现重连机制Sharp7的API相对偏底层读数据要先读成字节数组再自己解析稍微麻烦一些但正因为更底层连接稳定性更好可控性更强。Siemens官方库虽然最正规但授权复杂用起来重量级对于这样一个小项目属于杀鸡用牛刀。4.2 连接配置与读写核心代码PLC和上位机之间的数据交换点是一块专门的通信DB块DB10我在PLC程序里把需要上位机读取的数据全部集中在这块DB里// PLC侧数据交换DB块定义 DATA_BLOCK HMI_Data { S7_Optimized_Access : TRUE } // 注意这里后面会讲坑 VERSION : 0.1 STRUCT RemainingSpaces : Int; // 剩余车位数 OccupiedCount : Int; // 已占用车位数 TotalSpaces : Int; // 总车位数 CarInTotal : DInt; // 累计驶入车辆数 CarOutTotal : DInt; // 累计驶出车辆数 AlarmCode : Word; // 报警代码 LightStatus : Bool; // 指示灯状态 ManualMode : Bool; // 手动/自动模式 EntryGateOpen : Bool; // 入口道闸开信号 EntryGateClose : Bool; // 入口道闸关信号 ExitGateOpen : Bool; // 出口道闸开信号 ExitGateClose : Bool; // 出口道闸关信号 END_STRUCTC#这边用Sharp7读这个DB块的核心代码如下using Sharp7; // 初始化连接注意IP就是PLC的IP机架0槽1是S7-1200的标准设置 S7Client client new S7Client(); int result client.Connect(192.168.0.1, 0, 1); if (result ! 0) { // 连接失败处理 tbStatus.Text 连接失败 client.ErrorText(result); return; } // 从DB10读取数据长度是DB块总字节数 byte[] buffer new byte[64]; int readResult client.ReadArea(S7Area.DB, 10, 0, 64, buffer); if (readResult 0) { // 解析数据RemainingSpaces是Int位于偏移0和1 short remainingSpaces S7.GetShortAt(buffer, 0); short occupiedCount S7.GetShortAt(buffer, 2); short totalSpaces S7.GetShortAt(buffer, 4); int carInTotal S7.GetDIntAt(buffer, 6); int carOutTotal S7.GetDIntAt(buffer, 10); // 更新界面... } else { tbStatus.Text 读取失败 client.ErrorText(readResult); }写控制的逻辑类似向DB10里的Bool型控制字写入数值// 向DB10第28字节偏移处写入开闸控制位 // 注意S7协议里Bool的存取需要以字节为单位处理先读出当前字节再按位修改 byte[] buffer new byte[2]; // 假设只是修改一个字节中的某位 client.ReadArea(S7Area.DB, 10, 28, 1, buffer); S7.SetBitAt(ref buffer, 0, 2, true); // 将字节0的第2位设为1 client.WriteArea(S7Area.DB, 10, 28, 1, buffer); // 定时恢复为0模拟脉冲 Thread.Sleep(500); buffer[0] 0; client.WriteArea(S7Area.DB, 10, 28, 1, buffer);4.3 通信时序和异常处理的三个关键点在实际项目里上位机和PLC通信不是简单写几行示例代码就完事的有几个必须在设计阶段考虑的问题轮询频率要有节制。S7-1200的通信资源是有限的如果上位机用100ms的周期去疯狂读数据一方面会加重PLC的通信负载这在一个还要同时跑控制逻辑的CPU上不是好事情另一方面也会增加上位机的CPU占用。我最终的方案是PLC主动把数据包通过TSEND_C指令定时每200ms推送到上位机上位机被动接收上位机向PLC写入控制命令则使用事件驱动用户点击按钮时才写而不是周期轮询。这种方式大幅减少了无效通信流量也让系统通信更稳定。必须处理PLC停机/重启/拔网线的情况。S7连接非常脆弱一旦PLC侧程序停止、网线松动或者IP冲突上位机客户端立即进入异常状态。如果不做处理UI会一直卡在读取中的假死状态。我的做法是在界面定时器如500ms里检查client.Connected属性同时每5秒主动Ping一次PLC的IP地址一旦发现不可达自动断开重连并在状态栏明确显示通信中断正在重连。PLC程序里有一个不兼容的坑——优化访问机制。博途默认创建的DB块是优化访问S7_Optimized_Access : TRUE这种DB块不允许外部S7协议直接按偏移地址读取这在用Sharp7时会报区域长度错误之类的错。解决方案有两个一是创建DB块时取消勾选优化的块访问选项二是使用PLCSIM Advanced配合S7-1500/1200的PC访问点机制但对这种小项目来说最省事的还是直接关闭优化访问——这就是为什么上面的DB块声明里我把这个属性列出来就是为了提醒大家别在这里踩坑。4.4 数据看板的展示逻辑与体验设计上位机界面我设计了三个页面实时监控页、车流统计页、手动控制页。实时监控页用一个大数字控件显示剩余车位同时用一个DataGridView表格实时刷新所有车位的占用状态绿色/红色圆点。车流统计页展示按小时、按天聚合的驶入驶出数据和柱状图。手动控制页给运维人员提供了应急手段——如果自动控制逻辑出现异常可以在界面上手动开/关任意一道闸。值得一提的是为了让大屏看板有更好的实时视觉效果我还做了最近10分钟车流迷你趋势图数据源是上位机在后台累积的入场事件记录。这个功能虽然不涉及PLC逻辑但给客户留下了很好的印象因为他们能直观地看到系统在干活。5. 现场调试的疑难杂症与解决办法任何工控项目最花时间的一定不是写代码而是现场调试。这个项目前后去了五趟现场遇到了不少奇葩问题挑几个典型的分享出来——这些经验在教科书里是找不到的。5.1 超声波探测器在户外入口的幽灵触发第一批问题集中出现在车位探测器上。地下停车场里有几处车位居于消防通道旁边顶层天花板有通风管道气流对超声波探头产生了干扰——超声波信号被流动的空气折射探头误判反射时间导致无车变有车的幽灵触发。这个问题在一开始用固定阈值的判断方式下特别明显。解决办法做了两个层次的调整第一把探测器的方向稍微偏向车位中间区域避开通风管道正下方第二在PLC程序里把状态切换的确认时间从2秒延长到3秒同时对探测器输出信号增加了硬件滤波器RC低通时间常数约200ms。经过这两层处理后幽灵触发基本消失偶尔有误判也会被状态机的时间窗口吸收掉。5.2 道闸到位信号的选择困难症道闸的到位反馈信号是限位开关提供的输出24V高低电平。但实际调试时发现道闸开到位之后限位开关会有持续约500ms的机械抖动导致PLC读到的到位信号在不断跳变。这个过程如果正好有车在闸机下方PLC可能会误判为关到位而落下闸杆非常危险。解决思路是在PLC程序里对到位信号做稳定检测——信号必须在150ms内保持不变才认定为有效。原来的互锁逻辑里加上这个延时确认段同时把道闸输出脉冲宽度从300ms调整到500ms以覆盖限位开关的抖动区间。这个细节在验收测试中发挥了关键作用因为验收时专门测试了连续跟车场景。5.3 上位机连接莫名其妙的连接重置另一个费了不少周折的问题是上位机和PLC之间偶尔发生的连接重置——运行一段时间后Sharp7客户端连接会莫名断开重新连接又能恢复但过一段时间又断。排查过程分了几个方向PLC侧是否有异常重启看运行时间变量排除交换机端口是否有异常检查了网线和水晶头最终用Wireshark抓包分析发现是上位机和PLC之间存在大量的TCP Keep-Alive报文而某些时候这些报文没有收到响应导致连接被重置。根源找到了地下车库的交换机是一台旧的百兆工业交换机端口自动协商出了问题在某个运行阶段协商到了半双工模式从而产生大量冲突帧和数据错误。最后把上位机网卡的双工模式手动固定为100Mbps全双工PLC侧的PROFINET端口参数也强制设置为一样问题再未出现。5.4 LED显示屏数字跳变的误区剩余车位显示屏上显示的数字偶发跳变——不是计数逻辑错误而是LED显示屏支持的Modbus地址和数据格式与PLC发送的不一致。PLC以二进制数发送例如发送123表示剩余123位但LED屏内部以BCD码解析结果数字就变成了乱码。这个问题的坑在于即使通信正常、双方地址匹配数据格式不匹配也会得到错误结果。解决办法是修改PLC发送侧的编码方式由直接发送Int值改为将值拆分为个位、十位、百位逐位转换为BCD码再发送。具体做法剩余位数为RemainingSpaces则BCD_HUNDREDS (RemainingSpaces / 100) MOD 10BCD_TENS (RemainingSpaces / 10) MOD 10BCD_UNITS RemainingSpaces MOD 10拼接成16位数据高位为百位低位为个位以Holding Register的方式写入LED屏的对应寄存器地址。编码逻辑虽然麻烦一点但一劳永逸。5.5 断电重启后的计数恢复验证最后一个值得提的是断电恢复测试。由于我在PLC变量里设置了断电保持属性理论上PLC重新上电后车位状态和计数应该和断电前一致。但实际测试时发现一个隐藏问题超声波探测器在PLC重新上电后有大约10秒的初始化时间在此期间探测器的输出信号是不稳定的。因为PLC程序在启动时已经根据当前信号的有车/无车刷新了车位状态所以此时PLC记录的状态很可能和探测器初始化完成后的真实状态不一致。为了解决这个问题我在PLC的启动组织块OB100里增加了一段初始化逻辑程序刚启动时先将所有车位状态清为空闲同时开始一个120秒的系统稳定期。稳定期内PLC只采集探测器信号不更新车位占用状态稳定期结束后再根据当前探测器信号进行第一次批量状态刷新。这个处理完全规避了探测器上电初始化时间窗口带来的状态误判问题。6. 维护阶段的一些实用心得项目交付后跟踪运行了三个月剩余车位计数准确率在99%以上唯一的几次误差来自超声波探测器被装修尘土遮挡上位机通信稳定。甲方反馈日常维护压力不大基本是定期清理探测器探头和检查道闸机械部件。从整个项目下来有几个经验想特别分享给准备做类似项目的朋友第一PLC程序的注释一定要写得像给陌生人看的说明书。停车场项目的维护者往往不是最初的开发人员一个好的程序注释可以节省大量后期沟通成本。我在每个程序块的头部都写明了该块的功能、输入输出变量表、修改记录包括修改日期和修改人。这一点被甲方电工多次点赞。第二系统要预留手动优先的后门。停车场运营过程中免不了遇到特殊事件某某领导的车要停预留位、施工需要临时禁停某区如果有手动控制界面和手动模式运维人员就不用跑到控制柜里拨开关直接在触摸屏上点点点就能完成临时干预。第三和甲方保持沟通渠道畅通远比技术本身重要。项目实施中有个意外收获——因为我提供了以太网通信接口的详细文档甲方让他们的IT管理员把停车场的车位数据接入到了园区物业管理平台用来做员工停车补贴核算。虽然这超出项目合同范围但对甲方来说是实打实的增值后续有什么扩展需求也第一时间想到找我。再分享一个小技巧给最终交付时使用。我给上位机加了一个数据导出按钮可以把每天的车流统计和车位占用率自动导出为CSV文件放在固定目录里。这样甲方管理人员每天下班前扫一眼就知道当天停车高峰时段是几点、车位利用率有多高为将来增开车位或者调整收费标准提供了依据。这种超出预期一点点的小功能往往比完美的技术参数更能打动客户。 基于S7-1200 PLC的智能停车场车位控制系统设计与实现
1. 为什么用S7-1200做停车场控制项目立项时的真实考量接手这个智能停车场车位控制系统的项目时甲方最开始的需求其实并不复杂——某个产业园区的地下停车场有120个车位希望实现三个功能实时显示剩余车位数、入口道闸自动抬杆、车位引导屏提示空位方向。就这么点需求市面上随便一个车牌识别一体机方案商都能报出价格为什么最终决定用西门子S7-1200 PLC来做这得从项目现场的几个硬性条件说起。首先是现有设备的兼容性。这个停车场不是新建的道闸、地感线圈、红外对射这些基础设备已经存在而且运行了好几年。甲方不想把这些老设备全部推倒重来而是希望有一套控制系统能把它们统一管理起来。道闸的控制是标准的开关量信号地感线圈输出的是继电器干接点信号红外对射同样如此——这些东西天然就是数字量输入输出和PLC的DI/DO通道完美对接。如果用嵌入式方案或者单片机方案反而需要额外设计信号转换电路增加了故障点。其次是可靠性和稳定性要求。停车场设备在室外和地下环境常年运行温度范围宽、湿度大、还会遇到雷击浪涌。甲方明确要求系统平均无故障时间不低于一年而且一旦停电恢复后要能自动回到正确运行状态。这正好是PLC的看家本领——工业级设计、宽温运行、看门狗自恢复这些特性在工业现场已经被验证了无数年拿来应付停车场这种相对温和的环境完全是降维打击。第三点是后期维护的便利性。园区本身有电工和弱电维护人员他们对PLC普遍有基础认知。用S7-1200做控制核心万一日后要改逻辑、调参数维护人员通过博途TIA Portal软件就能在线修改监控不需要厂家到场。这一点在后来的实际运行中证明极其重要——甲方在系统交付后提了两次小需求变更调整高峰期道闸延时时间、增加夜间降噪模式都是他们自己的电工看了我写的注释后动手改的。选型时我其实纠结了一下S7-1200和S7-200 SMART。200 SMART价格更便宜而且同样是以太网接口。但对比下来最终还是选了1200核心原因有三个第一S7-1200的PID和模拟量处理能力更强虽然当前停车场项目没有模拟量输入但考虑到后续可能扩展地磁传感器或者超声波模拟量探头1200的平台更从容第二1200在博途环境下编程和后续上位机通信、HMI组态的配合更顺畅第三1200的程序存储空间更大可以留出充足余量给日后的功能扩展。顺带说一句硬件选型的具体配置给打算抄作业的朋友做个参考CPUS7-1200 1214C DC/DC/DC14路数字量输入、10路数字量输出集成2路模拟量输入扩展模块SM 1223 DI16/DQ16增加16路数字量输入和16路数字量输出预留余量通信模块CPU本体集成PROFINET接口通过以太网与上位机和交换机通信人机界面KTP700 Basic PN现场触摸屏显示车位信息和手动控制界面上位机软件Visual Studio 2019 C# WinForm数据看板和报表这套配置下来硬件成本大约在8000元上下比车牌识别一体机方案报价通常2万起步便宜不少而且功能更加灵活可控这也是甲方最终拍板的重要原因。2. 硬件拓扑与信号分配停车场设备如何与PLC建立连接方案定了PLC之后接下来要解决的是物理世界怎么接进来的问题。停车场里的设备五花八门有出入口道闸、入口地感、出口地感、车位检测传感器我最终选的是超声波车位探测器、LED剩余车位显示屏、红绿状态指示灯、语音播报模块。这些设备怎么和S7-1200建立起可靠的连接我在设计时对信号类型做了仔细梳理。2.1 车位检测层的信号采集方案车位检测是整个系统的信息来源这部分如果数据不可靠后面所有逻辑都是空中楼阁。我调研了市面上几种车位检测方案地感线圈、红外对射、超声波探测器、地磁传感器。地感线圈对车辆底盘高度的敏感性不错但需要在车位上开槽布线施工破坏性大后期维护麻烦红外对射便宜但极易受灰尘和光线干扰地磁传感器无线方案成本高电池维护也是长期负担。最终选了超声波车位探测器挂在车位正上方的天花板上每个探测器内置一个超声波探头和一个LED指示灯红色表示占用绿色表示空闲输出方式是继电器无源干接点信号——有车时继电器吸合无车时释放。这个信号直接接入PLC的数字量输入通道每个车位占用一路DI。这里有个细节值得注意S7-1200的数字量输入回路是漏型/源型兼容的但24V DC供电方向有讲究。超声波探测器是NPN输出的信号线输出低电平有效所以PLC公共端M端要接入24V信号接入DI通道当探测器继电器吸合时DI通道被拉低PLC读到的就是0。这和很多人习惯的高电平有效相反接线时必须看仔细说明书我第一次做类似项目时就在这个细节上吃过亏当时是怎么查都查不出为什么输入信号不来最后万用表一量才发现是公共端电源接反了。2.2 执行层的输出通道规划控制输出这一侧相对简单直接。道闸控制有三路信号开闸上升沿有效、关闸上升沿有效、状态反馈道闸是否到位。这里有个经验值得分享——很多道闸控制板提供的是开/停/关三线控制方式即两根信号线分别为开和关按下时给脉冲松手停止。但道闸一旦启动到限位位置会自动停止所以PLC这边只需要给一个短脉冲300ms~500ms触发开/关动作即可不需要持续保持电平。LED剩余车位显示屏则是标准的RS485通信在PLC侧加了一个RS485通信模块CB1241。屏上有4位数码管支持Modbus RTU协议PLC作为Modbus主站向屏写入显示数据。之所以不用DO点直接驱动数码管是因为剩余车位数是从0到120的两百多种变化状态用开关量控制会导致逻辑复杂到无法维护用通信方式一帧数据就搞定了。红绿指示灯的状态指示逻辑是入口处绿灯常亮表示有车位、红灯亮起表示车库已满每个车位上的超声波探测器自带LED指示这部分就不占用PLC输出了。2.3 供电设计与抗干扰处理S7-1200用的24V直流电源取自开关电源明纬DR-120-24但从现场经验看停车场设备的电磁干扰是个很容易被低估的问题——特别是道闸电机启停瞬间的电流冲击还有地下车库照明回路上的感性和容性负载切换都会在24V母线上制造毛刺。因此我给PLC供电回路做了三级处理开关电源输出端并联一个大容量电解电容1000μF/35V吸收低频纹波PLC电源入口串联一个EMI滤波器即电磁干扰滤波器选用TDK的通用品所有DI/DO信号线使用带屏蔽层的多芯电缆屏蔽层单端接地在PLC控制柜内接地排同时把PLC控制柜放在入口岗亭内部和室外设备之间通过屏蔽电缆连接线缆长度控制在50米以内这些措施保证了系统在运行中几乎没有因为干扰导致误动作的情况。I/O地址分配表我整理过一次发在项目文档里大致结构是这样的信号类型地址范围用途DII0.0 - I0.3入口地感、出口地感、道闸开到位、道闸关到位DII0.4 - I0.7备用、急停、手自动切换、语音播报反馈DII1.0 - I1.7车位探测器 1# - 8#分布式扩展按块划分DII2.0 - I2.7车位探测器 9# - 16#DII8.0 - I8.7通过SM1223扩展的DI通道车位探测器继续往后排DQQ0.0 - Q0.3入口道闸开、关出口道闸开、关DQQ0.4 - Q0.7LED屏电源、语音播报触发、指示灯、备用DQQ4.0 - Q4.7通过SM1223扩展的DQ通道冗余备用3. 博途里的核心逻辑设计车位状态机与防抖处理硬件接线完成之后工作重心转移到TIA Portal V15里面的程序开发。整个PLC程序我拆解成三个功能块现场信号采集与处理FC1、车位状态管理与剩余车位计数FC2、输出控制逻辑FC3外加一个主程序OB1进行总调度。这里重点聊聊软件的架构设计思路和几个关键逻辑细节。3.1 为什么不用继电器电路而用PLC程序多说一句背景。传统停车场的控制都是用中间继电器搭建的逻辑电路——入口地感检测到车、继电器吸合给道闸发开闸信号车走后延时继电器再触发关闸。这套电路在简单的单入口单出口场景下确实够用但只要加上剩余车位计数满位自动切换多出入口协调这些逻辑继电器电路就会爆炸式复杂——触点和线圈的数量呈指数级增长接线图施工难度和维护成本都不可控。PLC程序从根本上解决了这个问题。逻辑用梯形图或者SCL语言描述改动逻辑不需要拆线重接只需要修改程序下载进去。这次项目的逻辑规模大概用了300多行SCL代码和一段梯形图配合如果全部用继电器实现估计得两个控制柜的继电器才能塞下。3.2 车位状态机的四态模型每个车位我有四个状态空闲IDLE、占用OCCUPIED、进入中ENTERING、离开中LEAVING。这个状态机是设计中最有价值的部分解决了超声波探测器信号在临界状态的抖动问题。现实场景有这样的问题一辆车从车位上方缓缓经过或者在车位边缘停了一下又开走超声波探头检测到的信号就会在有车和无车之间跳变。如果程序只根据当前探头状态直接判断占用或空闲那么剩余车位数的统计很快就会错乱。我最初的设计就是吃了这个亏——上线第一天剩余车位数字就开始不正常一会儿多一会儿少甲方差点以为这套系统根本不能用。后来改成四态模型探测器的原始信号进入状态机之后必须先在一个状态保持稳定超过2秒状态才允许切换。比如当前车位是空闲探测器变为了有车状态先切到进入中如果这个有车状态稳定保持超过2秒则正式切到占用如果期间信号又变回无车则回到空闲。这样做的本质是把原始信号做了时间窗口的滤波消除毛刺和临界抖动的影响。用SCL实现这个状态机的核心逻辑大致是// 状态机定义 CASE car_status OF 0: // IDLE 空闲 IF raw_signal TRUE THEN timer_start; // 开始计时 car_status : 1; // 进入中 END_IF; 1: // ENTERING 进入中 IF raw_signal TRUE THEN IF timer_elapsed 2000 THEN car_status : 2; // 占用 occupied_count : occupied_count 1; END_IF; ELSE car_status : 0; // 回到空闲 END_IF; 2: // OCCUPIED 占用 IF raw_signal FALSE THEN timer_start; // 重新计时 car_status : 3; // 离开中 END_IF; 3: // LEAVING 离开中 IF raw_signal FALSE THEN IF timer_elapsed 2000 THEN car_status : 0; // 空闲 occupied_count : occupied_count - 1; END_IF; ELSE car_status : 2; // 回到占用 END_IF; END_CASE;这段代码里还隐含了一个保护逻辑如果超声波探测器故障导致信号异常长期不变或者车辆长时间停在车位边缘导致信号反复跳变状态机最终会在进入中和离开中两个状态之间来回而不会错误地增减计数——因为只有在稳定切换时才更新计数。3.3 剩余车位计的防重入保护剩余车位数的准确性是整个系统的命脉入口大屏上显示的数字如果错了驾驶员的信任感瞬间崩溃。除了状态机处理单车位信号之外我还在全局计数上加了几个保险第一总余位数采用物理上界限幅。剩余车位总数 总车位数 - 占用数范围必须锁定在0到总车位数之间。如果计算出来的结果小于0或者大于总车位数直接判定为数据异常PLC会触发一个报警位通知维护人员同时大屏上显示--而不是一个错误的数字。第二每个车位对应的占用状态记忆采用断电保持Retentive Memory。S7-1200里需要将存储车位状态和剩余车位数的DB块变量设置为保持属性。这个设计很关键——停车场会发生意外断电如果PLC重新上电后所有车位都变成空闲而实际停车场里停了半场车那剩余位数就会虚高入口车辆涌入后发现没位置体验极其糟糕。设置为保持属性的变量在PLC重启后保存断电时的值系统恢复供电后状态自动延续。第三入口与出口的计数逻辑采用双向校验。停车场设计中还有一个隐藏逻辑入口道闸的开闸信号触发行入计数出口道闸的开闸信号触发行出计数系统预期的场内车数 累加行入 - 累计行出。这套累计值可以和车位探测器统计的占用数做交叉比对——如果偏差超过5辆系统触发报警提示检测系统可能存在车位探测失效请排查。虽然基于道闸的逻辑在没有车牌识别的情况下无法做到百分百准确但作为粗粒度的健康监测已经足够了。3.4 道闸控制的互锁与延时策略道闸控制这块PLC程序里做了开闸优先、关闸延时的策略。入口地感1检测到车辆到达时PLC立即输出开闸脉冲同时启动一个定时器默认3秒定时器到时间后自动输出关闸脉冲。但这里有个防夹车的保护逻辑如果车辆在前一辆车还没完全通过闸机时就已经到达比如连续两辆车跟得很近地感2门槛内侧的检测线圈一旦检测到还有车在闸机下方关闸脉冲就不发送。这是用梯形图实现互锁和延时最直观的地方// 入口开闸触发地感1有车且道闸不在打开状态 Network 1: // I0.0是入口地感Q0.0是开闸输出Q0.1是关闸输出 I_入口地感 Q_开闸输出 Q_开闸输出 ----[ ]----------[/]----------------------( ) | | | I_开到位限位 | ----[ ]-----------------------------------( ) // 保持信号直到开到位 Network 2: // 3秒延时后自动关闸但门槛检测有车则禁止 Q_开闸输出 T_延时关闸 T_延时关闸 ----[ ]------------(TON)-------------------( ) // 实际关闸输出定时器到点 且 门槛内无车 且 手动模式下允许 Network 3: T_延时关闸.Q I_门内无车 Q_关闸输出 ----[ ]------------[ ]----------------------( )这部分的细节全在时序上。实际调试中发现如果开闸信号保持过长时间道闸电机会持续堵转发热长时间运行容易损坏电机。所以开闸输出在道闸到位反馈I0.2到达后必须立即断开。另外延时关闸时间要配合车辆的通过速度调整——设得太短容易在车辆还没完全通过时闸机落下砸车设得太长又会让后面的车误以为道闸坏了。我在现场测了几十辆车最终把3秒调整到了4.5秒才在效率和安全性上找到平衡点。4. C#上位机与S7-1200的通信实战从S7协议到数据看板在停车场控制项目里PLC解决了现场控制的可靠性问题但管理者和运维人员还需要一个直观的操作界面——实时看到剩余车位数、车流量统计、历史记录、手动遥控道闸。这个需求就是上位机软件的职责了。我在调研后选择了C# Windows Forms的方案主要通过以太网和S7-1200的PROFINET接口通信。这一节重点聊通信实现的技术细节。4.1 通信方式选型为什么放弃S7.NET选择Sharp7S7-1200对外通信常用的方式是S7协议TCP端口102。C#环境里访问这个协议最流行的库有S7.NET基于.NET Standard和Sharp7原生C实现的封装库另外还有Siemens官方提供的S7-1200/1500开放式开发库比如Siemens.Simatic.S7.Communication。我最终选择了Sharp7原因是它稳定、轻量、文档全社区用户多遇到问题容易找到解决方案。对比一下这几个库的实际体验——S7.NET的API设计更面向对象读数据直接返回强类型对象写起来确实舒服但在连续高频率轮询时偶发掉线需要自己实现重连机制Sharp7的API相对偏底层读数据要先读成字节数组再自己解析稍微麻烦一些但正因为更底层连接稳定性更好可控性更强。Siemens官方库虽然最正规但授权复杂用起来重量级对于这样一个小项目属于杀鸡用牛刀。4.2 连接配置与读写核心代码PLC和上位机之间的数据交换点是一块专门的通信DB块DB10我在PLC程序里把需要上位机读取的数据全部集中在这块DB里// PLC侧数据交换DB块定义 DATA_BLOCK HMI_Data { S7_Optimized_Access : TRUE } // 注意这里后面会讲坑 VERSION : 0.1 STRUCT RemainingSpaces : Int; // 剩余车位数 OccupiedCount : Int; // 已占用车位数 TotalSpaces : Int; // 总车位数 CarInTotal : DInt; // 累计驶入车辆数 CarOutTotal : DInt; // 累计驶出车辆数 AlarmCode : Word; // 报警代码 LightStatus : Bool; // 指示灯状态 ManualMode : Bool; // 手动/自动模式 EntryGateOpen : Bool; // 入口道闸开信号 EntryGateClose : Bool; // 入口道闸关信号 ExitGateOpen : Bool; // 出口道闸开信号 ExitGateClose : Bool; // 出口道闸关信号 END_STRUCTC#这边用Sharp7读这个DB块的核心代码如下using Sharp7; // 初始化连接注意IP就是PLC的IP机架0槽1是S7-1200的标准设置 S7Client client new S7Client(); int result client.Connect(192.168.0.1, 0, 1); if (result ! 0) { // 连接失败处理 tbStatus.Text 连接失败 client.ErrorText(result); return; } // 从DB10读取数据长度是DB块总字节数 byte[] buffer new byte[64]; int readResult client.ReadArea(S7Area.DB, 10, 0, 64, buffer); if (readResult 0) { // 解析数据RemainingSpaces是Int位于偏移0和1 short remainingSpaces S7.GetShortAt(buffer, 0); short occupiedCount S7.GetShortAt(buffer, 2); short totalSpaces S7.GetShortAt(buffer, 4); int carInTotal S7.GetDIntAt(buffer, 6); int carOutTotal S7.GetDIntAt(buffer, 10); // 更新界面... } else { tbStatus.Text 读取失败 client.ErrorText(readResult); }写控制的逻辑类似向DB10里的Bool型控制字写入数值// 向DB10第28字节偏移处写入开闸控制位 // 注意S7协议里Bool的存取需要以字节为单位处理先读出当前字节再按位修改 byte[] buffer new byte[2]; // 假设只是修改一个字节中的某位 client.ReadArea(S7Area.DB, 10, 28, 1, buffer); S7.SetBitAt(ref buffer, 0, 2, true); // 将字节0的第2位设为1 client.WriteArea(S7Area.DB, 10, 28, 1, buffer); // 定时恢复为0模拟脉冲 Thread.Sleep(500); buffer[0] 0; client.WriteArea(S7Area.DB, 10, 28, 1, buffer);4.3 通信时序和异常处理的三个关键点在实际项目里上位机和PLC通信不是简单写几行示例代码就完事的有几个必须在设计阶段考虑的问题轮询频率要有节制。S7-1200的通信资源是有限的如果上位机用100ms的周期去疯狂读数据一方面会加重PLC的通信负载这在一个还要同时跑控制逻辑的CPU上不是好事情另一方面也会增加上位机的CPU占用。我最终的方案是PLC主动把数据包通过TSEND_C指令定时每200ms推送到上位机上位机被动接收上位机向PLC写入控制命令则使用事件驱动用户点击按钮时才写而不是周期轮询。这种方式大幅减少了无效通信流量也让系统通信更稳定。必须处理PLC停机/重启/拔网线的情况。S7连接非常脆弱一旦PLC侧程序停止、网线松动或者IP冲突上位机客户端立即进入异常状态。如果不做处理UI会一直卡在读取中的假死状态。我的做法是在界面定时器如500ms里检查client.Connected属性同时每5秒主动Ping一次PLC的IP地址一旦发现不可达自动断开重连并在状态栏明确显示通信中断正在重连。PLC程序里有一个不兼容的坑——优化访问机制。博途默认创建的DB块是优化访问S7_Optimized_Access : TRUE这种DB块不允许外部S7协议直接按偏移地址读取这在用Sharp7时会报区域长度错误之类的错。解决方案有两个一是创建DB块时取消勾选优化的块访问选项二是使用PLCSIM Advanced配合S7-1500/1200的PC访问点机制但对这种小项目来说最省事的还是直接关闭优化访问——这就是为什么上面的DB块声明里我把这个属性列出来就是为了提醒大家别在这里踩坑。4.4 数据看板的展示逻辑与体验设计上位机界面我设计了三个页面实时监控页、车流统计页、手动控制页。实时监控页用一个大数字控件显示剩余车位同时用一个DataGridView表格实时刷新所有车位的占用状态绿色/红色圆点。车流统计页展示按小时、按天聚合的驶入驶出数据和柱状图。手动控制页给运维人员提供了应急手段——如果自动控制逻辑出现异常可以在界面上手动开/关任意一道闸。值得一提的是为了让大屏看板有更好的实时视觉效果我还做了最近10分钟车流迷你趋势图数据源是上位机在后台累积的入场事件记录。这个功能虽然不涉及PLC逻辑但给客户留下了很好的印象因为他们能直观地看到系统在干活。5. 现场调试的疑难杂症与解决办法任何工控项目最花时间的一定不是写代码而是现场调试。这个项目前后去了五趟现场遇到了不少奇葩问题挑几个典型的分享出来——这些经验在教科书里是找不到的。5.1 超声波探测器在户外入口的幽灵触发第一批问题集中出现在车位探测器上。地下停车场里有几处车位居于消防通道旁边顶层天花板有通风管道气流对超声波探头产生了干扰——超声波信号被流动的空气折射探头误判反射时间导致无车变有车的幽灵触发。这个问题在一开始用固定阈值的判断方式下特别明显。解决办法做了两个层次的调整第一把探测器的方向稍微偏向车位中间区域避开通风管道正下方第二在PLC程序里把状态切换的确认时间从2秒延长到3秒同时对探测器输出信号增加了硬件滤波器RC低通时间常数约200ms。经过这两层处理后幽灵触发基本消失偶尔有误判也会被状态机的时间窗口吸收掉。5.2 道闸到位信号的选择困难症道闸的到位反馈信号是限位开关提供的输出24V高低电平。但实际调试时发现道闸开到位之后限位开关会有持续约500ms的机械抖动导致PLC读到的到位信号在不断跳变。这个过程如果正好有车在闸机下方PLC可能会误判为关到位而落下闸杆非常危险。解决思路是在PLC程序里对到位信号做稳定检测——信号必须在150ms内保持不变才认定为有效。原来的互锁逻辑里加上这个延时确认段同时把道闸输出脉冲宽度从300ms调整到500ms以覆盖限位开关的抖动区间。这个细节在验收测试中发挥了关键作用因为验收时专门测试了连续跟车场景。5.3 上位机连接莫名其妙的连接重置另一个费了不少周折的问题是上位机和PLC之间偶尔发生的连接重置——运行一段时间后Sharp7客户端连接会莫名断开重新连接又能恢复但过一段时间又断。排查过程分了几个方向PLC侧是否有异常重启看运行时间变量排除交换机端口是否有异常检查了网线和水晶头最终用Wireshark抓包分析发现是上位机和PLC之间存在大量的TCP Keep-Alive报文而某些时候这些报文没有收到响应导致连接被重置。根源找到了地下车库的交换机是一台旧的百兆工业交换机端口自动协商出了问题在某个运行阶段协商到了半双工模式从而产生大量冲突帧和数据错误。最后把上位机网卡的双工模式手动固定为100Mbps全双工PLC侧的PROFINET端口参数也强制设置为一样问题再未出现。5.4 LED显示屏数字跳变的误区剩余车位显示屏上显示的数字偶发跳变——不是计数逻辑错误而是LED显示屏支持的Modbus地址和数据格式与PLC发送的不一致。PLC以二进制数发送例如发送123表示剩余123位但LED屏内部以BCD码解析结果数字就变成了乱码。这个问题的坑在于即使通信正常、双方地址匹配数据格式不匹配也会得到错误结果。解决办法是修改PLC发送侧的编码方式由直接发送Int值改为将值拆分为个位、十位、百位逐位转换为BCD码再发送。具体做法剩余位数为RemainingSpaces则BCD_HUNDREDS (RemainingSpaces / 100) MOD 10BCD_TENS (RemainingSpaces / 10) MOD 10BCD_UNITS RemainingSpaces MOD 10拼接成16位数据高位为百位低位为个位以Holding Register的方式写入LED屏的对应寄存器地址。编码逻辑虽然麻烦一点但一劳永逸。5.5 断电重启后的计数恢复验证最后一个值得提的是断电恢复测试。由于我在PLC变量里设置了断电保持属性理论上PLC重新上电后车位状态和计数应该和断电前一致。但实际测试时发现一个隐藏问题超声波探测器在PLC重新上电后有大约10秒的初始化时间在此期间探测器的输出信号是不稳定的。因为PLC程序在启动时已经根据当前信号的有车/无车刷新了车位状态所以此时PLC记录的状态很可能和探测器初始化完成后的真实状态不一致。为了解决这个问题我在PLC的启动组织块OB100里增加了一段初始化逻辑程序刚启动时先将所有车位状态清为空闲同时开始一个120秒的系统稳定期。稳定期内PLC只采集探测器信号不更新车位占用状态稳定期结束后再根据当前探测器信号进行第一次批量状态刷新。这个处理完全规避了探测器上电初始化时间窗口带来的状态误判问题。6. 维护阶段的一些实用心得项目交付后跟踪运行了三个月剩余车位计数准确率在99%以上唯一的几次误差来自超声波探测器被装修尘土遮挡上位机通信稳定。甲方反馈日常维护压力不大基本是定期清理探测器探头和检查道闸机械部件。从整个项目下来有几个经验想特别分享给准备做类似项目的朋友第一PLC程序的注释一定要写得像给陌生人看的说明书。停车场项目的维护者往往不是最初的开发人员一个好的程序注释可以节省大量后期沟通成本。我在每个程序块的头部都写明了该块的功能、输入输出变量表、修改记录包括修改日期和修改人。这一点被甲方电工多次点赞。第二系统要预留手动优先的后门。停车场运营过程中免不了遇到特殊事件某某领导的车要停预留位、施工需要临时禁停某区如果有手动控制界面和手动模式运维人员就不用跑到控制柜里拨开关直接在触摸屏上点点点就能完成临时干预。第三和甲方保持沟通渠道畅通远比技术本身重要。项目实施中有个意外收获——因为我提供了以太网通信接口的详细文档甲方让他们的IT管理员把停车场的车位数据接入到了园区物业管理平台用来做员工停车补贴核算。虽然这超出项目合同范围但对甲方来说是实打实的增值后续有什么扩展需求也第一时间想到找我。再分享一个小技巧给最终交付时使用。我给上位机加了一个数据导出按钮可以把每天的车流统计和车位占用率自动导出为CSV文件放在固定目录里。这样甲方管理人员每天下班前扫一眼就知道当天停车高峰时段是几点、车位利用率有多高为将来增开车位或者调整收费标准提供了依据。这种超出预期一点点的小功能往往比完美的技术参数更能打动客户。