1. 为什么要做这次PLC采集方案横评先交代一下背景。我平时的工作很大一块是帮工厂做设备数据采集甲方手里的PLC五花八门西门子、三菱、台达、欧姆龙、汇川、倍福、AB、ABB变频器什么牌子都有。PLC采集这件事说简单也简单说坑也多。简单是因为PLC天生就是为工业控制设计的老老实实按协议读寄存器就行坑多是因为现场环境千奇百怪通信不稳定、IP冲突、网线断开、串口被占用、防火墙拦截、软件授权过期哪个都能让你白干半天。这次横评的目的不是要评出哪家PLC最好而是把常见的采集方案放到同一个天平上称一称OPC UA、Modbus TCP/RTU、S7comm、三菱MC协议、CC-Link、EtherNet/IP、EtherCAT这些主流方案各自的适用场景、上手难度、踩坑点、数据刷新率、稳定性我一个个梳理出来。你看完至少能知道自己手头的项目该选哪种协议遇到问题该往哪个方向排查跟甲方聊需求时该确认哪些关键信息。1.1 先说清楚PLC采集到底采的是什么PLC采集采集的不是“电信号”而是PLC内部的数据区。这些数据区按厂商不同有不同的名字M区、D区、V区、DB块、I/O区、保持寄存器、掉电保持区、定时器、计数器。采集的本质就是通过通信协议把这些存储区的数值读出来交给上层系统比如MES、SCADA、ERP、上位机软件或者IoT平台。这里有个关键概念PLC的数据区和通信协议是两回事。同一个数据区可以用不同协议去读同一种协议也能读不同品牌PLC的数据。只是有些协议是公开的有些是半公开的有些是私有协议这就决定了采集方案的选型空间。比如西门子的S7-1200既可以用S7comm私有协议快速批量读DB块也可以用OPC UA走标准化接口还可以用Modbus TCP走最通用的路子。选哪种要看上位机是谁、现场网络长什么样、实时性要求多高。1.2 横评的维度怎么定我这次横评主要看六个维度协议开放性、工程成本、通信实时性、抗干扰能力、配置复杂度、生态支持。协议开放性决定你选型时有没有自由度。开放协议如Modbus、OPC UA谁都能写代码对接私有协议如S7comm虽然实现资料也不少但毕竟不是公开标准。工程成本包括网关硬件、授权费用、开发工时。有些方案看似免费但调试耗掉的时间成本远高于买一个网关的价钱。实时性要看应用场景。采集温度数据50ms够用做伺服轴联动就要到1ms甚至更低。抗干扰能力看工业现场能不能稳得住是不是一有大电机启动就通信超时。配置复杂度直接影响新手能不能快速上手。生态支持是看社区资料多不多遇到问题能不能搜到答案厂商售后响应快不快。这六个维度合起来基本能覆盖90%以上PLC数据采集项目的选型需求。下面我会逐个方案展开讲每个方案都会从这几个角度给结论。2. 主流PLC采集方案逐一拆解2.1 OPC UA跨平台、跨厂商的“通用语言”OPC UA是目前工业互联里最火的采集协议之一和传统OPC DA相比它已经不是单纯的DCOM通信而是基于TCP/IP的标准化通信框架。它的好处是跨平台、跨厂商西门子、倍福、罗克韦尔、ABB、汇川这些主流的PLC都原生支持或者在软件里可以快速启用。实际项目中我测过用Python的asyncua库直接连西门子S7-1500只需要在PLC侧启用OPC UA服务器设置好用户名密码然后在Python里把endpoint地址填进去就能建立会话读写节点。这里说的节点Node对应的是PLC里的数据标签需要在TIA Portal里把需要采集的变量发布出来。换句话说OPC UA把PLC的“寄存器地址”抽象成了“变量名”上层系统不用关心这个变量在DB块的哪个偏移量只用按名字读就行工程维护方便很多。OPC UA的兼容性确实好但也要注意版本问题。有些老PLC固件不支持OPC UA比如早期的S7-200 SMART、部分FX3U就需要加载额外的通信模块或者用其他协议采集。OPC UA对网络环境也有要求不允许跨网段乱串防火墙如果做得太严握手都不稳定容易出BadTimeout或者BadNoCommunication这类错误。排查思路一般是先确认端口4840是否通再看安全策略是否匹配。这里补充一下如果你要采集的设备很多而且来自不同品牌OPC UA几乎是必须考虑的方案。因为一个统一的OPC UA服务器可以把不同PLC的数据汇成一个信息模型上层系统只需要对接这一个接口不用为每台PLC各写一套驱动。2.2 Modbus老将不死小数据量场景依然能打Modbus是工业现场最古老的“普通话”之一分Modbus RTU和Modbus TCP两种形态。RTU走串口RS-232、RS-485都有TCP走以太网端口502。很多PLC虽然没有原生以太网口但通过扩展模块也能支持Modbus通信。Modbus的优势是简单、透明、资料多、几乎任何上位机语言都能对接。你不需要装任何厂商SDK只要知道从站地址和寄存器地址就能用一条TCP连接读取大量数据。比如台达DVP系列PLC用485做主站采集从站站点只需要把通信参数设成9600、8、N、1然后在程序中用MODRW、MODRD指令去读写指令的参数就是站号、寄存器地址、数据个数非常直观。Modbus的缺点也很明显数据描述能力弱只知道寄存器的值和地址不知道这个值是什么含义安全性差默认无认证广播效率低不适合大规模分布式采集。另外Modbus地址映射在不同PLC里不一致同一台设备有的从40001开始有的从0开始有的偏置1有的偏置0踩坑率很高。我的经验是接Modbus设备第一步一定是从站手册里把寄存器映射表拿准不懂就问厂家别猜。尤其是那些第三方仪表、变频器厂商手册里的寄存器地址往往和实际通信报文里的地址差一个“偏移”如果按手册原样填进去读出来的数据全是乱的。2.3 S7comm西门子私有协议性能强悍但封闭S7comm是西门子S7系列PLC的私有协议底层是TCP端口102。它和Modbus TCP最大的区别是数据组织方式更灵活可以直接读写DB块、M区、I/O区而且通信速率高适合需要快速大量采集的场景。我用C#写过一个采集服务用的就是S7comm协议通过HslCommunication这个开源库三行代码就能连接S7-1200然后调用Read方法按块读取DB数据。这比OPC UA的重型握手轻快很多实测在50ms定时读取100个DB变量的场景下CPU占用率很低数据抖动也很小。如果你的需求只是把西门子PLC的数据读出来做展示、存历史库S7comm是一个非常高效的选择。S7comm的问题在于它不是一个公开的标准文档西门子自己也没出官方SDK给所有语言用所以第三方实现版本各异兼容性需要一个个测。比如S7-200系列和S7-1200/1500的协议细节就不完全一样连接参数也不同你在代码里声明的PLC型号枚举值如果填错很可能连上但读不出数据。再一个S7comm默认不加密如果有安全要求更好的做法是走S7-1500的S7commPlus或者OPC UA。S7commPlus的加密和认证机制更强但第三方库支持度不一使用前要确认你选用的通信库是否兼容。2.4 MC协议与CC-Link三菱生态的两种打开方式三菱PLC的采集方案里最常听到的两个词是MC协议和CC-Link。MC协议是三菱的开放式通信协议支持以太网和串口两种载体用来读写D区、M区、W区非常适合上位机直接采集。CC-Link则更多是PLC之间的组网总线CC-Link IE Basic是基于以太网的实现在FX5U和伺服之间做同步控制特别顺溜。实测里用C#通过MC协议读写FX5U只要把IP、端口、站点号填对ReadDeviceBlock方法可以直接按连续地址读D区。需要注意MC协议的帧格式有字节序问题比如32位整数的字高低顺序如果不对读出来的数值就是反的。很多新手在这上面卡两三天其实是没搞清楚“字节序”和“字序”的区别。简单说MC协议里一个16位寄存器占一个“字”如果你要读一个32位浮点数它占两个连续的字这两个字的先后顺序在不同型号PLC里可能不一样需要在程序里做高低字交换。CC-Link IE Basic的好处在配置在GX Works3里选好网络类型填好站号系统会自动分配通信参数不用自己算地址映射。缺点是只能在三菱生态内玩如果上位机是第三方系统往往还是走OPC UA或者MC协议更省事。我见过有项目为了采集几台三菱PLC专门上了CC-Link IE Basic的主站模块和远程IO站其实数据量根本没到那个程度用MC协议轮询反而更简单。2.5 EtherNet/IP与EtherCAT美系和欧系的高端局EtherNet/IP是罗克韦尔AB主推的协议基于以太网和CIP协议栈支持隐式报文和显式报文。隐式报文适合周期性IO数据交换显式报文适合按需读写比如读取参数。ABB变频器和西门子PLC走总线通信时很多情况选的其实是Modbus TCP或PROFINET但如果是AB PLC和第三方设备互联EtherNet/IP基本是必选项。EtherCAT是倍福在运动控制领域的主推协议特点是实时性极高数据刷新可以到微秒级同时支持分布式时钟同步。它不是一个简单的数据采集协议而是现场总线本身所以如果你的采集对象是伺服轴、编码器、IO模块并且需要同步联动EtherCAT是目前很主流的选择。EtherNet/IP和EtherCAT的工程复杂性都比Modbus高不仅需要专门的网卡、主站配置软件还要求上位机有相应的通信栈。小项目用它们有点杀鸡用牛刀但如果做高端设备、多轴联动这些协议几乎是绕不开的。我测试时用倍福的EL6022串口模块做过协议转换采集也通过TwinCAT的OPC UA接口把EtherCAT总线上的轴位置、速度数据传给上位机整体实时性确实比普通Modbus轮询高了一个量级但调试门槛也明显上去了。2.6 白嫖AI生成PLC代码说说我的实测感受热词里有一个“ai plc代码生成”我也试过几次包括用大模型生成三菱FX系列的梯形图指令、西门子S7-1200的SCL代码。结论是AI在处理标准逻辑、注释生成、代码解释这些场景下确实能提效但离“直接可用”还有距离。比如我让AI生成一段三菱FX5U通过CC-Link IE Basic控制伺服回原点的代码它给出的框架和指令注释基本正确但伺服参数的具体地址、回原点的速度曲线细节都需要我手动补。还有一次让AI写S7-1200的PID自整定调用代码它把OB背景DB的调用方式理解错了编译直接报错。所以现在的做法是把AI当“高级助手”用让它生成初稿、解释不懂的指令、检查逻辑漏洞但最终编译、仿真、联调必须自己做。完全指望AI一步到位反而花在纠错上的时间更多。3. 实操环节从通信建立到数据落库3.1 虚拟机连接PLC网络模式怎么选热词里有一条非常典型“tia用vmware连plc用什么网络连接模式”。这个问题我当年也踩过坑。VMware里跑TIA Portal博途要连实体PLC网络模式通常有三种桥接模式、NAT模式、仅主机模式。结论先说优先用桥接模式并且把虚拟网卡对应到实际连PLC的那块物理网卡上。原因很简单NAT模式是让虚拟机通过宿主的IP去访问外网PLC和虚拟机不在同一个二层网络里博途扫描设备列表根本扫不到。仅主机模式更是只能和宿主机通信和外部PLC完全隔离。桥接模式下虚拟机的网卡直接接到物理网卡上相当于虚拟机和PLC就在同一个交换机里博途就能通过广播帧发现设备。实操上有几个细节需要注意桥接时要注意VMware的“桥接到”选项是否选对了网卡。如果你电脑既有Wi-Fi又有有线网卡默认桥接可能选到Wi-Fi上而PLC接的是有线网卡结果是死活扫不到。PLC和虚拟机的IP要配在同一网段。比如PLC是192.168.0.10那虚拟机的IP就设成192.168.0.88子网掩码一致网关可以不填。关掉Windows防火墙对VMnet的拦截或者在防火墙里放行西门子通信端口像S7comm的102端口、OPC UA的4840端口。我见过不少次通信代码没毛病就是防火墙在中间作梗。如果你用的是WinCC 8.0关联PLC变量同样会遇到虚拟机网络问题。WinCC的通道设置里要选择正确的网卡有时候还要在PG/PC接口里手动指定访问点否则变量连接状态一直是灰色。3.2 用C#实现一个最小可用的S7采集服务做一个最小能跑的西门子采集服务我习惯用HslCommunication库它同时支持S7comm、三菱MC、Modbus TCP、欧姆龙Fins等协议很适合做多品牌采集。下面是最简代码逻辑using HslCommunication; using HslCommunication.Profinet.Siemens; var plc new SiemensS7Net(SiemensPLCS.S1200, 192.168.0.10); plc.SetPersistConn true; var result plc.ConnectServer(); if (!result.IsSuccess) { Console.WriteLine(连接失败: result.Message); return; } // 按DB块读取DB10中的起始字节0开始读4个字节 var read plc.Read(DB10.0, 4); if (read.IsSuccess) { for (var i 0; i 4; i) { Console.WriteLine($字节{i}: {read.Content[i]}); } }这里有个很重要的点SiemensPLCS枚举不是随便选的S200、S300、S400、S1200、S1500对应的协议细节有差异填错了可能连接失败或者读取地址解析错误。另外Read方法返回的字节数组是“裸数据”如果读的是Int类型建议用ReadInt16、ReadFloat等类型化方法不要自己拼字节。实测下来SetPersistConn设为true能保持长连接防止频繁重连导致PLC侧连接资源耗尽。西门子PLC的连接资源是有限的比如S7-1200默认只有几个可用连接如果调试时不停断连重连PLC侧会提示连接资源不足。这里建议每台上位机只建立一个通信连接数据采集用同一个连接顺序执行不要为了快开多个连接否则会把PLC的连接池撑爆。3.3 台达PLC通过485组从站网络台达PLC在小型设备里用得很多尤其是DVP系列。如果你要采多台台达PLC的数据可以组一台485主站把从站的数据汇总后再上传给上位机。这比每台都单独接网线省施工成本但要注意通信时序。举个例子一套项目里有三台DVP14SS一台做主站两台做从站。通信参数统一设成96008None1主站地址1从站地址2和3。主站的PLC程序里用MODRW指令定时读取从站的D寄存器再把这些数据写到自己的一个数据缓冲区内。上位机只需要跟主站通信就能间接采到三台设备的数据。有一点心得485线的A、B绝对不能接反A接AB接B共地方式最好统一终端电阻在总线两端各接一个120欧姆从站地址不能重复距离超过100米建议降低波特率。现场遇到过最诡异的情况是单独测每个从站都能通三台一起组网就时好时坏。排查到最后发现是其中一台设备的电源地线没接好导致485信号地的电位漂移把所有从站的A、B线并到一起后问题消失。另外如果你是用LabVIEW跟松下PLC串口通信道理也一样。LabVIEW里用VISA节点配置串口参数然后按松下PLC的通信帧格式收发数据。关键在于帧的校验码计算和超时处理这方面串口通信比以太网更容易受干扰所以轮询间隔要适当放宽不要设成10ms这种极限值。3.4 用桥接方式实现C#与西门子PLC通信如果你用的是C#写上位机而PLC是西门子S7-1200/1500网络连通性测试可以直接用命令行工具。先Ping通再telnet测试102端口是否开放。在Windows上telnet默认没装需要先启用Telnet客户端功能。如果102端口通说明S7comm链路没被防火墙挡剩下的就看代码里的IP、机架号、槽号对不对了。S7-1200默认机架号是0槽号是1S7-1500是0槽号一般是0或1具体看硬件组态。HslCommunication里SiemensS7Net的默认参数就是0和1所以连1200时基本不用改。如果你连的是S7-300或S7-400槽号往往不同连接失败时首先检查这两个参数。还有一个常见坑S7-1200固件版本太低时不接受多连接同时建立或者连接建立后一段时间无数据就会自动断开。这时除了SetPersistConn还要在PLC侧把“允许来自远程对象的通信”设置打开并且延长连接保持时间否则上位机程序跑一会儿就报超时。3.5 数据落库的三种方式采集方案不只是通信协议的事还要考虑数据最终去哪儿。最常见的落库方式有三种上位机软件直接写数据库、工业网关采集后转发MQTT、边缘计算盒子处理后上传云平台。三种都实测过各有优缺点。直接写库适合小规模项目比如工控机读PLC数据然后INSERT进SQL Server优点是链路最短排障简单缺点是数据库并发一旦上来PLC通信线程容易被拖慢。所以我在写库逻辑里都会加一个缓冲队列通信线程只负责读数据并塞进队列数据库线程从队列里取数据批量写入。这样PLC通信的实时性和数据库写入的IO压力就解耦了。网关转发MQTT适合跨地域多厂区网关负责把PLC数据统一成JSON格式然后通过MQTT发到中间件上层系统订阅即可。这个方案的关键是网关的选型要确认它支持你用的PLC协议比如西门子的S7comm、三菱的MC协议是不是固件里自带还是需要付费授权。有些网关标称支持几十种协议买回来才发现要单独买协议包预算一下子就超了。边缘计算盒子则适合需要预处理、质量判断、报警判断的场景在盒子内部先做计算只把结果上传节省带宽也减少云平台压力。比如采集温度数据盒子内部先算出一分钟内的平均值、最大值、最小值只把这三个值传上去云平台需要原始值时再追加查询。但边缘盒子的计算能力有限如果采集点上千个还要跑复杂算法盒子的CPU会吃紧选型时要留足余量。不管哪种方式我始终建议在代码里加一个“采集数据质量”字段比如0表示正常1表示通信超时2表示数据越界。这样上层系统看到异常数据时第一反应是查数据质量而不是怀疑传感器本身坏了。这个字段在后期排查故障时价值极高千万别省。4. 常见故障与排查技巧实录4.1 常见报错速查表下面这张表是我从历次现场实施中整理出来的基本能覆盖多半PLC采集项目的常见报错。报错/现象常见原因排查思路PLC报Link100以太网链路断开或总线故障检查网线、交换机端口、IP冲突确认总线参与站是否掉站西门子8180错误模块或通信参数错误核对硬件组态查看模块诊断缓冲区和PLC系统时间PLC连接失败BadTimeout防火墙拦截、IP不通、端口被占用先Ping再telnet测试端口确认安全策略数据值乱码/负数数据格式不匹配、字节序错误确认是Float还是Int、高低字顺序、数据类型长度网关离线供电不稳、网络抖动、证书过期查看网关日志检查电源和网络设备更新证书采集速度慢轮询周期太长、从站过多缩短定时周期批量读取尽量用块读代替单点读VMware里博途扫不到PLC桥接网卡选错、IP网段不一致检查虚拟网络编辑器确认桥接到正确的物理网卡这些报错里最难排查的其实是那些不报错但数据不动的情况。比如三菱PLC的自整定PID参数有的项目要求上位机远程触发自整定结果参数写不进去或者写进去了没生效PLC还没有任何报错。这种时候要先用GX Works3监视PLC的运行状态确认自整定指令是否被CPU真正执行再回头看上位机写入的数据类型对不对。4.2 滤波消抖问题从PLC侧解决还是上位机侧解决热词里有“plc使用的滤波消抖的方法”这也是采集项目里极易被忽略的点。有些传感器信号天生带毛刺比如接近开关在临界位置附近反复抖动如果直接把这信号采上来数据就是一堆跳变的假值上位机看到的就是“每分钟都在报警”。消抖处理有两个层次。PLC侧可以用输入滤波指令例如三菱FX系列在程序里加一段定时滤波逻辑检测信号连续超过10ms才认为有效西门子S7-1200则在模块属性里配置数字量输入滤波时间单位是毫秒。上位机侧则可以再做一次软件滤波比如用滑动平均或死区判断把跳变值剔除掉。我的建议是能PLC侧处理的全在PLC侧处理因为PLC的实时性最好而且数据在源头就干净了后面所有层次都省心。上位机软件滤波是兜底方案用来处理那些没法改PLC程序的历史遗留设备。要注意的是滤波时间设太长会把真实信号也滤掉比如快速计数信号会被吃脉冲所以滤波参数要按实际工艺频率算不能一刀切。4.3 定期锁机程序设备管理角度的技术理解热词里还有“plc定期锁机程序”。我明确说在未经设备所有者授权的情况下利用PLC程序锁定设备逼迫付款这不道德也可能违法我坚决反对这类做法。但从技术角度讲了解锁机机制是设备管理和安全防护的一部分——设备被异常锁定时你要能判断并解除。真正的防锁机思路是对PLC程序做版本管理定期备份采购设备时要求厂家提供源程序或加密说明在关键网络节点加防火墙限制未授权的远程访问PLC的密码要掌握在设备所有者手中并留有程序注释。如果怀疑被锁机第一时间断电保存现场让有权限的技术人员查看程序确认锁定逻辑所在再决定是修改程序还是恢复备份。4.4 变频器开关量控制和通信控制的区别热词里有一条“plc数字量输出点控制变频器开关量和开关量控变频器一样吗”。这个问题看起来基础但现场实际应用时很多人会混。数字量输出点控制变频器本质是用一个开关信号来启停变频器比如PLC的DO点接到变频器的DI端子按下启动按钮后PLC输出一个24V高电平变频器就运行。这个方式只能控制启停、正反转、多段速没办法做精细调速也不能读取变频器电流、频率这些运行参数。而通信控制比如Modbus RTU、PROFINET、CC-Link是把控制字写到变频器对应的寄存器里比如启动命令、目标频率、加减速时间同时还能读回变频器的输出频率、输出电流、母线电压、故障代码。所以如果你的项目只需要远程启停用DO点就够了省成本也简单如果你要监控运行状态或者做闭环调速必须走通信。我印象最深的一个项目甲方一开始用的是DO点控制ABB变频器后来想在触摸屏上显示变频器实时电流发现根本没有模拟量输出通道只能加一块模拟量输出模块成本比直接上一块Modbus通信模块还高。后来把所有变频器都换成了Modbus RTU通信一台PLC主机带十几台变频器参数读写、故障复位、运行监控全搞定业主也满意。选型时不要把目光只盯在硬件成本上接线上省的那点钱后期维护会加倍还回去。5. 横评结论与选型建议5.1 按项目规模选采集方案横评做下来我的结论其实很朴素没有最好的协议只有最合适的方案。项目场景推荐方案理由单台PLC简单采集Modbus TCP/RTU结构简单资料多开发快西门子系统多设备S7comm或OPC UA通信快标准化好远期扩展方便三菱系统MC协议或CC-Link IE Basic原生支持生态匹配AB/Rockwell系统EtherNet/IP工业标准AB生态首选多品牌混合采集OPC UA跨厂商提供统一建模运动控制/伺服联动EtherCAT实时性和同步性最强老旧设备无网口Modbus RTU/485扩展模块改造成本低稳定可靠另外如果你在做一个PLC毕业设计或者课程项目不用一上来就追求最复杂的方案。很多学生问“stm32和plc如何通信”其实本质就是UART或以太网走Modbus协议一端做主机一端做从机。STM32做主站PLC做从站STM32定时发送读取命令解析返回报文把数据显示在OLED屏上就是一个完整的采集项目了。这个思路可以扩展成智能家居、环境监测、电梯控制、地铁排水系统等各种课题原理完全一致。5.2 给新手的落地建议如果你是第一次搞PLC采集我建议按这个顺序走先把以太网扫盲理解IP、网段、端口、广播这些概念然后拿一台手里的PLC从Modbus TCP或者OPC UA开始读一个变量、显示在电脑上把这个闭环跑通再慢慢扩展到多个变量、多台设备、数据库落库。每一步都要做记录尤其是IP地址、端口号、数据区地址、数据类型这四个要素漏掉任何一个排查起来都让人头大。我习惯把每一台设备的采集参数维护成一张Excel表包含设备名、品牌、IP、协议、端口、数据地址、数据类型、轮询周期、备注每次出问题先查表。这个习惯帮了大忙比如现场换了一台同型号PLC但IP被改成了另一个地址如果没有这张表光是排查IP问题就要一下午。如果你用的PLC型号太老比如欧姆龙旧款编程软件版本和通信驱动兼容性会是个大麻烦。网上流传的一些注册码、破解补丁我不建议用一方面法律风险另一方面版本不匹配可能导致程序丢失。正规渠道找厂商代理要试用授权或者选一个开源库用代码方式访问反而更省心。5.3 进一步扩展的方向采集方案做完之后后续还有很多可扩展的方向。比如把采集到的数据接入开源可视化系统用Grafana直接展示设备运行状态也可以把数据推送到企业微信或钉钉机器人实现移动端报警或者在边缘侧加一个简单的机器学习模型做设备健康度预测。这些扩展方向里性价比最高的其实是报警通知。实现成本很低效果却非常直观客户验收时会觉得系统“很聪明”。前提是你在采集层把数据质量做好别让误报把用户的信任消耗光了。5.4 个人体会我在多次实施里的体会是PLC采集项目失败的案例绝大多数不是死在协议选型上而是死在现场的网络基础设施、接地、电源、电磁干扰这些最不起眼的地方。协议选得再好网线用错一根干扰一来照样丢包防火墙策略做错一条授权再齐全也连不上。所以我的工作习惯是动代码之前先花半天把现场的拓扑图画明白把每一段的网线、交换机、防火墙、IP规划、PLC型号、固件版本都记录下来。折腾完这些“脏活”后面写通信代码反而是最快的一步。如果你也在做类似项目建议从这个习惯开始它能帮你省下的时间远远超过你为此付出的那点精力。