最近被几个做设备集成的朋友问到同一个问题“手机APP怎么直接连PLC是不是很难”其实这事没有想象中那么玄尤其是现在很多PLC都自带网口或者加一个几十块钱的WiFi串口模块就能搞定。本文就把我实际调过的一条“简单APP与PLC通讯”链路完整梳理一遍从方案选型到具体代码再到调试时最容易踩的坑尽量让没有搞过上位机的人也能照着重现。这篇内容适合这几类人看想给自家小设备配一个手机监控界面的人、做毕设或课程设计需要APP控制PLC的学生、以及刚接触工业物联网、想先把基础链路跑通再做平台的开发者。我会用尽量少的术语但会在关键节点把原理讲透因为很多问题等到了现场排查再补原理就晚了。1. 先搞清楚APP和PLC通讯到底在做什么1.1 一个典型的应用场景假设现场有一台小型传送带设备PLC负责控制电机启停和速度。现在想在现场用手机APP看当前速度、累计运行时间并且可以下发启动和停止指令。这个场景就是APP与PLC通讯的典型需求。这里核心要解决两件事一是APP怎么物理连接到PLC二是双方按什么规则交换数据。物理连接通常通过WiFi或者以太网因为手机不能直接插网线或挂串口线。规则则取决于PLC支持的协议常见的有Modbus TCP、S7协议、Melsec协议等还有不少国产PLC支持自定义的ASCII协议。所谓“简单的APP与PLC通讯”本质就是把协议这部分封装好让APP像读一个普通存储器一样读写PLC的内存区。我见过不少人一开始就想直接调底层Socket然后自己解析协议帧。其实这对“简单”项目来说不是最优解尤其是Modbus TCP这种工业标准协议社区里已有非常成熟的现成库直接复用远比重复造轮子靠谱。1.2 通讯的本质数据表读写很多新手会被“通讯”两个字吓到觉得要处理什么握手、加密、消息队列。对绝大多数工业现场来说通讯就是一个“对一张共享数据表进行读写”的过程。PLC内部维护着多个数据区比如保持寄存器、线圈、输入寄存器等。APP只要按照协议规则构造一个请求帧发给PLCPLC解析后把对应地址的数据返回APP再解析响应帧拿到数值。这就是一次完整的数据交换。为了更容易理解举个生活化类比PLC就像一个柜子柜子上面有很多抽屉每个抽屉有编号地址抽屉里放着不同格式的数据整数、浮点数、开关状态。APP要做的事就是通过协议这把钥匙去指定抽屉里取东西或换东西。你不需要关心柜子内部的电路怎么走只需要知道抽屉编号地址、数据格式、以及开锁规则协议就行。理解这一步之后后面所有方案选型和代码逻辑都会变得非常清晰。凡是通讯异常要么是钥匙协议用错要么是抽屉编号地址写错要么是柜子本身没通电网络不通。2. 方案选型别一上来就写代码先选路通讯方式不止一种选错了后面会特别别扭。我见过有人买了一个只支持UDP的设备然后折腾了一周都连不上最后发现原来目标PLC只支持TCP两个完全不同的方向。所以这部分值得花点时间捋清楚。2.1 路数一串口/WiFi模块 透传 自定义协议很多小型PLC上面只有RS485串口没有网口。这时候常见的做法是给PLC配一个串口转WiFi模块模块工作在“透传”模式。透传模式的意思是模块把WiFi收到的数据直接转成串口数据发给PLC反之亦然。APP连接模块的WiFi后向模块的IP和端口发送数据帧模块原封不动地通过串口传给PLC。这种方案实现起来门槛低模块配置也有现成工具。但要注意如果PLC原始只支持Modbus RTU串口协议那么APP需要自己构造Modbus RTU帧并且处理CRC校验。这个方案的优点是硬件成本低十来块钱的模块就能跑缺点是传输距离和抗干扰能力有限而且如果PLC串口已经被触摸屏占用就会产生冲突。只适合那种“测试演示”或者“小范围内简单监控”的场景。2.2 路数二PLC自带以太网 Modbus TCP这是我最推荐给“简单项目”的路数。现在不少PLC本体就带以太网口并支持Modbus TCP协议或者可以通过内置函数实现类似功能。手机APP和PLC连到同一个路由器或者让手机连PLC的热点APP通过Modbus TCP协议直接访问PLC的寄存器。Modbus TCP相比RTU省去了CRC校验因为CRC交给TCP/IP协议栈处理了。报文结构也很简洁事务ID2字节协议ID2字节长度2字节单元ID1字节功能码1字节数据。用现成库的话这些帧都不用自己拼。这里要提醒一点如果你选的PLC型号原生不支持Modbus TCP可以看看官方指令库是否有“Modbus TCP Server”功能块把它使能并绑定到网口即可。许多日系和国产PLC都有这类库只是名称不同比如有人叫“MODBUSTCP_SERVER”有人叫“MB_SERVER”本质一样。2.3 路数三网关盒子/中间件还有一种更“省事”的方案在PLC和APP之间加一个物联网网关。网关通过串口或以太网和PLC通讯然后转换成MQTT、HTTP或WebSocket接口给APP。这样做的好处是APP不用关心PLC具体协议只需要按网关定义好的JSON接口传数据。但网关方案也有代价多了一个设备多了一层故障点而且很多商业网关的配置逻辑相当绕。对于“简单APP与PLC通讯”的定位我建议除非要远程访问比如不在同一个局域网否则没必要上网关。远程访问涉及内网穿透、云服务等一堆额外工作属于另一个更复杂的主题。2.4 选型对比表对比维度串口转WiFi透传PLC自带以太网Modbus TCP网关中间件成本低模块几十元无额外硬件中等数百至上千开发难度需要自己拼RTU帧和CRC有现成库难度低配置网关反而繁琐稳定性一般依赖串口线较好以太网抗干扰强看网关质量适用场景测试、临时演示局域网的常规监控远程访问、多设备平台化我个人的实际经验是如果能走以太网就不要走串口如果能用现成的Modbus TCP库就不要自己解析Socket帧。这个原则能替我省下至少一天调试时间。3. 实操用Modbus TCP让APP读取PLC数据以Android为例3.1 硬件侧的准备工作假设手头有一台支持Modbus TCP的PLC第一步是确认PLC的IP地址、子网掩码和端口号。默认端口一般是502但有些PLC可以自定义。如果使用手机直连PLC的以太网口可以不给PLC配路由器直接把PLC的网口设置为192.168.0.1一类地址手机连接PLC发出的WiFi热点如果PLC有WiFi功能或者用网线直连一个便携路由器。最好是在电脑上先用Modbus调试工具测试一遍能读到数据再去做APP。很多人直接拿手机写代码连不上就开始怀疑代码其实往往是PLC侧地址没映射好。这里我强烈建议先用调试助手“打个样”排除硬件问题再去写APP。在PLC侧还需要建立寄存器映射表。比如我想读取设备状态字一个整数地址设定为保持寄存器40001协议地址0启动命令映射到地址40100协议地址99。注意很多PLC软件里的地址显示是“40001”但协议帧里实际地址是“0”要做一次偏移换算。3.2 APP侧的核心代码骨架Android端我用过几个Modbus库比较顺手的是基于Modbus4J移植的Android版本或者Apache华通讯社区里常用的依赖库。实现流程很简单连接TCP Socket发送Modbus TCP请求帧接收响应帧解析出寄存器数值。举个例子读取保持寄存器地址0开始、长度为1的整数功能码是0x03。用库的写法大致是这样ModbusMaster master ModbusMaster.createModbusMaster(192.168.0.10, 502); master.setTimeout(2000); master.setRetries(1); ReadHoldingRegistersRequest request new ReadHoldingRegistersRequest(0, 2); // 地址0读2个寄存器 ReadHoldingRegistersResponse response master.getResponse(request); int value response.getRegisterValue(0);这里的地址0对应PLC侧协议地址0也就是显示地址40001。如果要在APP界面上显示速度值可能还需要做工程单位换算比如PLC内部存储的是原始值实际速度原始值×0.1那就在拿到value后再乘0.1再更新TextView。写入命令一般用功能码0x06写单个寄存器或者0x10写多个寄存器。比如要在地址99写入整数1表示“启动”就是构造一个WriteSingleRegisterRequest(99, 1)。有的PLC为了让命令可靠执行会要求APP先写置位再写复位比如地址99写1启动地址100写1停止启动命令执行后过200毫秒再把地址99写0避免PLC一直认为启动按钮被按着。这个逻辑需要在APP端加个延时线程。3.3 如何确认通讯成功写完代码第一次连接时经常会发现读不到数据。这时候不要急着改代码先按这个顺序排查PLC与手机是否在同一网段。最常见的错误是PLC是192.168.0.10手机连的WiFi却是192.168.1.x两个网段根本不通。防火墙或PLC端口是否开放。电脑上能Ping通PLC不代表502端口可访问有些PLC的防火墙回默认拦截来自其他IP的Modbus请求。寄存器地址是否越界。如果PLC只有100个保持寄存器你读地址200PLC会返回异常码2非法数据地址。确认这三项之后如果APP端还是超时可以抓一下报文。最简单的办法是在电脑上开一个TCP调试助手作为临时客户端代替APP去连接PLC看能不能成功收发。如果电脑能通、手机不通那就是手机端网络配置或权限问题如果电脑也不通那就回到PLC侧排查。另一个值得注意的小细节Android 9之后默认禁止明文HTTP流量但Modbus TCP是裸Socket不会受这个限制只是需要申请INTERNET权限。不过有的Android定制系统会锁后台网络如果APP退到后台再恢复时连接断开需要重连机制。4. 关键参数寄存器地址、字节序、轮询频率4.1 寄存器地址映射表Modbus TCP中寄存器按编号体系分为五类最常用的是保持寄存器4xxxx和输入寄存器3xxxx。输入寄存器通常是只读保持寄存器可读可写。做控制命令时一定要把命令写到保持寄存器不要写到输入寄存器。很多PLC厂家在软件里用“40001”这种地址来显示而协议帧中实际地址是“显示地址减40001”。比如上位机软件显示40001实际在协议帧中是0显示40100协议帧中是99。这跟Modicon定义有关新手很容搞混。我建议把所有需要交互的数据整理成一张Excel映射表包含变量名、数据类型、PLC显示地址、协议地址、读写属性、换算系数。这张表既是编程依据也是调试时的对照清单。实际项目里我遇到不下三次因为地址映射表错一行导致APP显示的是隔壁一台设备的温度。4.2 字节序与数据类型的坑Modbus TCP的寄存器是16位长度。如果要传输32位浮点数或者32位整数就会占用两个寄存器。这里就出现了字节序问题有的PLC把高16位放在前一个寄存器大端模式有的则放在后一个小端模式甚至还有word-swap和byte-swap的区分。比如读回来的两个寄存器值为0x1234和0x5678。按照大端模式组合32位值是0x12345678如果按小端模式组合则是0x78563412具体规则因库而异。不同的Modbus库对字节序的处理不同有些库提供“byte swap”和“word swap”配置项需要和PLC实际存储格式匹配。我调试时遇到过一台国产PLC它的32位浮点存储顺序跟标准Modbus定义正好相反。APP按标准库解析出来的温度变成了一个天文数字。后来用了一个土办法先写死一个已知的浮点值比如3.14在PLC里让它输出到寄存器然后再看APP收到的原始字节直接对比出字节序规则再在代码里做转换。这个方法比翻手册快得多。4.3 轮询周期设置原则APP向PLC请求数据的频率不是越快越好。工业以太网交换机的数据包高速并发可能会导致PLC的CPU负载升高尤其是那种非常老的小型PLCModbus请求处理能力本身有限。每毫秒刷一次读请求不仅APP界面跳变毫无意义还会让PLC整个扫描周期变慢。我常用的经验值是状态监控类数据500毫秒到1秒一次控制类命令按需发送不要轮询如果是触摸屏式的实时曲线可以300毫秒一次但前提是PLC的扫描周期在20毫秒以内且网络没有丢包。轮询次数多了还有一个隐患如果APP在短时间内发出大量请求超过了PLC通讯缓冲区大小有些PLC会返回异常码或者直接断开连接。所以一定在APP里做好互斥锁避免上一个请求还没响应就发出下一个。很多现成的Modbus库是同步阻塞式的天然会串行执行但如果你自己封装了异步Socket就需要小心这点了。5. 常见问题与排查技巧实录5.1 连不上PLC的排查清单可以按以下顺序逐项检查检查手机和PLC的IP地址、子网掩码、网关是否在同一网段。两台机器要通讯前提是网络层能通。可以用Ping命令排除。检查PLC网口是否被占用。有些PLC网口默认只允许编程软件连接需要在PLC设置里开放Modbus TCP服务功能。检查设备端口号。Modbus TCP默认是502但有的PLC厂商改成1502。如果你连502连不上试试1502或者查看PLC通讯设置里的实际端口号。检查端口监听状态。在局域网内用另一台电脑运行TCP调试工具尝试连接PLC的IP和端口。如果调试工具能连上说明PLC侧没问题问题在手机APP。检查Android的权限和进程。别忘加INTERNET权限如果APP放在子线程里连Socket还要保证线程没有被ANR。一个很容易被忽略的点有些PLC的Modbus TCP服务器一次只允许一个客户端连接。如果你电脑上开着编程软件在线监视手机APP再连接可能就会被拒绝。每次调试PLC之前先断开编程软件的在线连接或者把编程软件的连接方式改成上传下载完成后离线。5.2 读回来的数据是乱码/负数/错位这种情况多半是数据类型和地址对齐出了问题。读出来的整数变成“65535”之类的极大值比较常见是因为读取了空寄存器或者未初始化的地址。此时寄存器里都是0xFF或0xFFFF当成有符号整数解析自然就是-1或65535。可以先在PLC里给地址赋一个已知值再读一次看结果。读浮点数出来是NaN或者特别小的大负数一般是字节序问题。可以按前面说的“已知值对比法”来确认转换规则。如果不同变量之间的数据串位了比如读到速度值为温度的数值那就是寄存器地址映射表错位。检查PLC显示地址和协议地址的换算是否有误或者有没有把32位数据按16位去分配。5.3 通讯稳定性的经验补充很多“简单通讯”项目在实验室一切正常到了车间就频繁掉线。主要原因有两个一是工业环境电磁干扰强WiFi信号不稳定二是APP与PLC之间没有重连机制。针对现场问题我通常建议这么处理APP增加断线检测与自动重连比如判断Socket空闲超过3秒就发送一个心跳请求读取最小的寄存器地址如果连续3次心跳超时则关闭连接并重新建立。重连时注意不要让多个线程同时创建连接要用单线程的调度状态机去管理连接生命周期。另外如果必须用WiFi尽量选5GHz频段避开现场其他无线设备的2.4GHz干扰。但很多工业设备和WiFi模块只支持2.4GHz那就要做好物理布置让无线模块离PLC控制柜的变频器尽量远一点并考虑增加外置天线。如果条件允许最好用有线以太网加一个小无线AP把PLC所在的局域网换成稳定的有线骨干网再把AP挂在远离变频器的位置。调试时还有一个实用习惯把APP日志输出到文件记录每次请求的时间戳、发送报文、接收报文以及耗时。现场一旦出问题只要看日志就能定位是网络层波动还是协议层错误。我在一个项目里就是靠日志发现通讯中断经常发生在接触器吸合的瞬间后来给网络模块加了隔离电源才解决。6. 从“通了”到“可靠”关于简单项目的一点心得最后再说一个我个人的体会。很多人把APP与PLC通讯做完看到APP上能显示数值、能点按钮启停就觉得大功告成。但距离真正能用还差一步异常状态的处理。比如APP连着PLC这时有人误拔了网线APP里的控制按钮和状态栏仍然亮着用户可能误以为还在控制设备结果按了启动按钮没反应甚至引发安全隐患。所以至少要在界面上做一个“通讯状态指示”和“心跳超时自动置灰所有控制按钮”的功能。这不需要多复杂的代码却能把一个“演示Demo”变成“可用工具”。“简单”只是入门门槛低不代表可以忽略可靠性。通讯链路一旦建立你后续还能继续扩展很多玩法比如把设备数据转发到看板系统、做成多客户端同时访问、增加历史趋势曲线。但所有上层应用都依赖底层这条稳定的数据通路。如果你正卡在APP连不上PLC这个坎上不妨退回到最简单的测试场景电脑上用Modbus调试工具先复现一遍通讯再移植到手机。只要把网络连通、协议匹配、地址映射这三件事理顺绝大多数通讯问题都能迎刃而解。这也是我每次调通所有设备之后最想强调的经验。