做上位机开发这么多年,我发现一个很有意思的现象:很多工程师在PLC通讯这块特别纠结。串口通信还是以太网?西门子还是三菱?每次接到新项目,光是选型就能讨论半天。说实话,这个问题我之前也纠结过,直到后来在苏州上位机系统开发项目中摸索出一套标准化的编程方法,才算彻底想明白。

串口通信和以太网通信,到底该怎么选?

咱们先说说这两种通信方式的区别。串口通信,比如RS485、RS232,最大的优点是稳定可靠,抗干扰能力强。在无锡上位机开发的一个项目中,客户现场电磁环境特别恶劣,用以太网经常断线,最后换成串口通信才稳定下来。

但串口通信也有明显的缺点:速度慢,距离有限。如果你需要做实时曲线展示,采集频率要求比较高,串口通信可能就不够用了。这时候就得考虑以太网通信,比如Modbus TCP、PROFINET、EtherNet/IP这些。

其实在嘉兴PLC数据采集项目中,我们经常遇到这种情况:老设备用串口,新设备用以太网。客户希望在一个系统里统一管理,这就需要我们的上位机软件能够同时支持两种通信方式。

多品牌PLC的通信差异有多大?

说到PLC品牌,西门子、三菱、欧姆龙这三家应该是国内用得最多的。但它们的通信协议差异很大,这点做上位机开发的朋友应该深有体会。

西门子的S7系列用的是S7协议,串口通信走PPI或者MPI,以太网走S7.Net或者PROFINET。三菱的FX系列用FX协议,Q系列用MC协议,串口和以太网的指令格式都不一样。欧姆龙的CJ系列用Host Link协议,NJ系列用FINS协议,也是两套东西。

在宁波上位机公司的一个项目中,客户现场有西门子S7-200、三菱Q系列、欧姆龙NJ系列三种PLC。如果每个品牌单独写一套通信代码,工作量至少翻三倍。所以我们当时就决定,必须做一套标准化的功能块,把不同品牌的差异封装起来。

标准化功能块的设计思路

我们的设计思路很简单:抽象。把不同品牌、不同通信方式的差异抽象成统一的接口。上层业务代码只需要调用统一的方法,不需要关心底层用的是什么协议。

具体来说,我们定义了一个IPlcCommunication接口,包含Connect、Disconnect、Read、Write这几个基础方法。然后针对每个品牌、每种通信方式实现具体的类。比如SiemensS7Serial、SiemensS7Ethernet、MitsubishiMCSerial、MitsubishiMCEthernet等等。

这种设计的好处是,如果以后要支持新品牌或者新的通信方式,只需要新增一个实现类,不需要改动现有代码。在杭州PLC开发服务的一个项目中,客户后来要加一台基恩士的PLC,我们只花了半天就搞定了。

串口通信的编程要点

串口通信虽然稳定,但编程上有一些需要注意的地方。首先是波特率、数据位、停止位、校验位这些参数,必须和PLC端完全一致,否则通信不上。在南昌物联网系统开发的一个项目中,我们就因为校验位设置错了,调试了一整天。

其次是数据帧格式。不同品牌的PLC,数据帧格式不一样。比如西门子的PPI协议,数据帧包含起始符、长度、命令、数据、校验等部分。三菱的FX协议,数据帧结构又完全不同。我们需要为每个品牌实现专门的数据帧解析逻辑。

还有一点很关键,就是超时处理。串口通信是异步的,如果PLC没有响应,不能一直等下去。我们在功能块里加入了超时机制,默认5秒超时,超时后自动重试或者抛出异常。

以太网通信的编程要点

以太网通信相比串口通信,编程上要简单一些。因为TCP/IP协议栈已经处理了很多底层细节,我们只需要关心应用层协议就行。

但以太网通信也有自己的挑战。首先是网络连接管理。TCP连接可能会因为网络波动断开,我们需要在功能块里加入重连机制。在上海PLC上位机开发的一个项目中,客户现场网络特别不稳定,我们的重连机制发挥了很大作用。

其次是数据打包。以太网通信通常是字节流,我们需要把数据打包成PLC能识别的格式。比如西门子的S7协议,需要按照特定的格式组装请求报文。三菱的MC协议,也有自己的报文格式。这些都需要在功能块里实现。

统一化功能块的实现细节

说了这么多,具体怎么实现呢?我们的做法是用C#开发了一套功能块库。每个功能块都实现了IPlcCommunication接口,对外提供统一的调用方式。

比如读取数据,不管是串口还是以太网,不管是西门子还是三菱,调用方式都是一样的:Read(string address, int length)。功能块内部会根据配置自动选择对应的协议和解析逻辑。

在无锡上位机开发的一个项目中,我们用这套功能块,把现场20多台设备的通信统一管理。客户最满意的一点是,后来他们自己加了几台设备,只需要在配置文件中添加设备信息,不需要改代码。

非标上位机开发中的实际应用

做非标上位机开发,最大的挑战就是需求不确定。每个客户的工艺都不一样,用的PLC品牌也不一样。如果没有一套标准化的功能块,很容易陷入重复开发的泥潭。

我们的经验是,把功能块做得足够灵活。比如在苏州上位机系统开发的一个项目中,客户用的是很老的西门子S7-200,通信协议是PPI。我们的功能块已经支持了,只需要在配置文件中指定PLC类型和通信参数就行。

还有一个宁波上位机公司的案例,客户现场有串口通信的温度控制器,也有以太网通信的PLC。我们用同一套功能块,把两种设备的数据统一采集,在界面上做实时曲线展示。客户特别满意。

给同行的几点建议

最后给做上位机开发的朋友几点建议。首先,不要纠结于串口还是以太网,要根据实际场景选择。如果现场电磁环境恶劣,优先选串口;如果需要高速采集,优先选以太网。

其次,一定要做标准化的功能块。不要每次都从头写,那样效率太低。把常用的通信协议封装成功能块,以后直接复用。

还有一点,就是配置化。尽量把通信参数做成配置,不要硬编码在代码里。这样以后换设备或者改参数,不需要改代码。在嘉兴PLC数据采集项目中,我们就因为这个设计,节省了大量维护成本。

如果你也在做杭州PLC开发服务、南昌物联网系统开发、上海PLC上位机相关的项目,欢迎交流。我们这套标准化功能块已经在多个项目中验证过,可以分享给大家参考。