C#开发手机组态APP，WiFi远程监控西门子S7-1200 PLC

搞工控上位机的兄弟，估计都遇到过这个场景：设备在车间里，人不在旁边，客户一个电话打过来问“现在温度多少？运行正常不？”，你只能打开电脑、连上PLC编程软件慢慢看。要是能在手机上像点外卖一样直接看到现场数据，甚至点点按钮就能操作，那体验完全不一样。这个项目做的就是这件事——用C#写一个手机组态APP，通过WiFi无线通信，随时随地监控西门子S7-1200 PLC。

我拿到这套源码的时候，第一反应是“这不就是组态软件的移动端降级版嘛”，但仔细看完后发现，它其实把C#上位机开发、Modbus TCP通信、S7-1200配置、Android端界面组态、WiFi网络排障这些环节全都串起来了。适合正在学C#上位机、或者手头有S7-1200项目想加手机监控功能的工程师参考。这篇文章我会把整套方案从头拆到尾，从PLC侧配置到VS2019里的Android工程创建，再到核心通信代码和实际踩过的坑，一步步说清楚。

1. 项目整体拆解：这套源码到底解决了什么问题

1.1 需求本质：从手机看PLC，不只是“远程”

先说结论：这个项目的本质不是“远程控制”，而是“移动监视 + 有限控制”。很多刚入行的朋友一听到手机监控PLC，脑海里就是“把组态软件做成APP”，但实际做过的都懂，这里面的核心矛盾在于——组态软件帮你把PLC协议、屏幕刷新、画面绘制全包了，而自己用C#写，等于要把这层封装全部手动解开。

从现场工程角度看，S7-1200作为西门子小型PLC的主力，几乎每个中小型设备上都有它的身影。传统做法是HMI触摸屏放在柜门，或者上位机组态软件跑在工控机上。可一旦设备分布在多个车间、多个场地，或者你是设备供应商，要远程查看售后设备的运行状态，固定点位就不好使了。手机APP天然是这种场景的补充，哪怕只是把启停状态、温度、压力、故障码推送到手机上，也能省下大量现场往返的成本。

这个项目里最值得关注的一点，是它走的是“手机直连PLC”的路线，也就是WiFi通信方案，而不是先把数据传到云平台、再从云平台推给手机。直连的好处是实时性高、几乎没有中间层延迟、局域网内丢包率低，而且不需要购买云服务，也不需要处理数据上云的权限和合规。缺点也很明显，就是手机和PLC必须在一个局域网里，无法跨公网访问。这个取舍在工控项目里其实非常常见，客户要的常常就是“我在车间里走到哪都能看到设备状态”，而不是“我在家也能看”，所以直连方案完全够用。

1.2 方案选型：为什么是C# + Modbus TCP + WiFi

这套源码的技术栈选型很有代表性。C#在工控上位机领域早就不是新鲜事，从WinForm到WPF，再到现在的跨平台方案，C#做设备端监控软件成熟度很高。VS2019作为IDE，上至.NET Core下至老Framework项目都能搞定，它身上带一个经常被忽略的利器——可以开发Android应用，也就是Xamarin.Forms，这正是手机APP能通过C#一套代码跑起来的基础。

通信协议方面，S7-1200本身原生支持多种以太网协议，Profinet、S7协议、Modbus TCP都可以。这套源码选的是Modbus TCP，这是很务实的决定。S7协议虽然功能强、效率高，但它是西门子的私有协议，跨平台和第三方库的支持相对要小心处理；Modbus TCP却是工业界的“普通话”，几乎所有PLC和上位机都认，而且C#领域里封装好、测试充分的Modbus库非常多，比如NModbus、HslCommunication。尤其HslCommunication，我在这类监控项目里用过很多次，它对西门子PLC的支持非常完善，读DB块、读M区、写线圈都很顺手，还顺便把Modbus和S7协议都封装了，代码量能省一大截。

为什么选WiFi而不是蓝牙或者4G？蓝牙连接距离短，穿墙能力弱，顶多做个调试工具用；4G走公网网关，要做NAT穿透、做安全认证，工程复杂度指数上升。WiFi刚好卡在合理区间：覆盖一个车间没有问题，手机和PLC通过同一个局域网路由交换，只需要保证IP能互相ping通，剩下的TCP通信完全按标准来，对开发者和使用者来说都是最简单的模式。这套源码把WiFi直连作为主线，思路是对的。

1.3 系统架构速览

把整套源码拆开看，逻辑其实非常清晰。最底层是物理设备层，S7-1200 PLC通过以太网线连接到一个工业无线路由器或者AP，PLC分配到一个固定IP。中间是通信链路层，手机通过WiFi接入同一个局域网，获得与PLC同网段的IP地址，两者之间的网络路径就是“手机 → WiFi AP → 网线 → PLC以太网口”。最上层是应用层，APP内部采用“连接管理类 + 数据读写类 + UI绑定类”的经典三层结构，连接管理负责建立和维持Modbus TCP会话，数据读写类封装了HslCommunication对PLC寄存器的访问方法，UI绑定类把读到的数据通过事件和属性通知实时更新到组态控件上。

这套结构的好处在哪里？它把“通信”和“展示”彻底解耦了。就算你后面把底层的Modbus TCP换成S7协议，或者把直连改成走云平台中转，界面和逻辑部分几乎不用动，只需要改数据访问层。对维护来说，这也是救命的，因为现场最常见的问题就是通信断、数据不刷新，如果通信代码和UI代码扭成一团，排查起来会非常痛苦。这套源码在这一点上做得很规矩。

2. 硬件与PLC侧准备：通信的基础

2.1 S7-1200侧：MB_SERVER要这样配

手机APP要读到PLC的数据，PLC这一端必须先把Modbus TCP服务器功能打开。S7-1200里实现这个功能的方式是调用两个指令块：MB_SERVER和MB_CLIENT。在这个项目里，PLC是作为Modbus服务器，所以只需要在OB1里调用MB_SERVER指令块。

MB_SERVER的配置有几个关键点。首先是背景数据块DB100，每个MB_SERVER调用必须有一个独立的背景DB，这个DB用于存储通信状态，你不能复用多个连接。第二是IP Port端口，默认一般是502，现场如果和别的设备冲突可以改，但APP连接时填的端口必须和这里一致。第三是MB_HOLD_REG，这个指向一个数据块，作为Modbus的保持寄存器区，APP读写的所有数据最终都映射到这个DB里。

我把自己做实验时的一个配置记录放出来，直接对照看：

这里有个很容易踩的坑：MB_SERVER的保持寄存器区域是一个连续的数据块，比如DB60，它不是直接把CPU的DB块地址映射成Modbus地址，而是把这个数据块里的数据当作Modbus的数据源。换句话说，你现在读到的Modbus寄存器地址40001，对应的是DB60.DBW0，而不是你程序里某个全局DB的DBW0。所以PLC编程的时候，你需要在程序里把想监控的变量放到这个保持寄存器DB里，或者通过MOV指令把实际变量值定期搬运进去。这是整个工程最绕但最重要的一个点，很多人APP连上了却读到全零数据，问题往往就出在这里。

2.2 WiFi网络与环境配置

网络部分看着简单，但恰恰是现场问题最多的地方。先明确一个目标：保证手机和PLC之间能够互相访问，且IP地址稳定。我建议给PLC设置固定IP，网段取常见的192.168.0.x或者192.168.1.x，无线路由器关闭DHCP模式的干扰或者设置好DHCP地址池，确保分配给手机的IP不会和PLC冲突。

这里分享一个实用技巧：S7-1200的以太网口是自适应的，无论是直连路由器的LAN口还是通过交换机连接都可以。但WiFi AP最好是工业级的，如果用家用路由器，芯片处理能力弱，在电磁干扰大的车间里容易丢包。项目里实测下来，普通家用路由器在距离20米隔两堵墙的情况下，Modbus TCP请求超时率会明显上升；换上工业AP后，同样点位很稳定。所以，既然是无线监控项目，AP设备的选型优先级应当排在正式开发之前。

另外，如果手机要访问的PLC在另外一个网段，比如PLC是192.168.0.10，而WiFi局域网是192.168.1.x，那就需要在路由器上做路由表或者静态NAT，但这种复杂度不建议在小项目里引入，最好的办法就是统一IP规划：WiFi网段和PLC网段保持同一个。

2.3 点位映射：Modbus地址与PLC存储区的对应关系

Modbus TCP本身的地址模型有四张表：线圈（Coil）、离散输入（Discrete Input）、输入寄存器（Input Register）、保持寄存器（Holding Register）。PLC的MB_SERVER实际主要支持保持寄存器和线圈，其中保持寄存器可读可写，对应PLC数据块里的字或字节，线圈对应PLC的位变量。

这套源码里用的主要是保持寄存器。Modbus的地址号从40001开始，但对应到PLC里的具体位置，需要你去查MB_SERVER的背景DB和保持寄存器DB的偏移。举一个很常见的例子，如果你想让APP读到DB60.DBW0的值，也就是保持寄存器的第一个字，那APP这边就是读取地址40001，类型是ushort或者short。要读DB60.DBW2，就是40002。要读两个个字拼成一个32位浮点数，就连续读40001和40002，再按大端或小端合并。

这个映射关系在Excel里列一张表，是工控项目的基本礼仪。列清楚“APP显示名称 | Modbus地址 | 数据类型 | PLC对应地址 | 换算系数”，维护起来才不会乱。我见过不少项目初期不列这个表，后期加点位加得自己都晕，排查问题靠猜，效率非常低。

3. VS2019工程搭建：手机组态APP的开发环境

3.1 创建Xamarin项目与权限配置

VS2019里开发Android APP，需要先安装“使用.NET的移动开发”工作负载，也就是Xamarin。这个工作负载在安装VS2019的时候很容易被忽略，因为它默认不勾选。装好之后新建项目，选择“移动应用 (Xamarin.Forms)”，模板语言选C#。这套源码用的是Xamarin.Forms的单工程结构，如果你不想拆成Android、iOS各一个原生工程，选这个就对了。

创建完工程后，有一个非常关键的操作：给Android项目添加网络权限。默认的新建Xamarin工程在AndroidManifest.xml里是不包含任何网络权限的，如果直接跑通信代码，你会发现连接时必定抛权限异常，或者莫名其妙连不上。需要在AndroidManifest.xml里加入：

xml复制<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />

INTERNET权限是通信的基本权限，ACCESS_NETWORK_STATE可以让你在代码里判断当前网络是否可用，ACCESS_WIFI_STATE用于读取WiFi状态。这三个权限加完之后，还要注意一个事情：如果你的应用需要访问局域网设备，而手机系统是Android 9及以上，部分定制ROM会默认阻止APP访问本地网络。这个问题在小米和华为的部分机型上尤其明显，需要在系统设置里手动允许该应用在后台使用数据。这些权限/设置不处理到位，代码写得再对也白搭。

工程结构上，建议建一个名为“Communication”的文件夹，把所有和HslCommunication相关的封装都放进去。然后建一个“Models”文件夹放数据模型，比如一个“TagItem”类表示一个监控点位，包含名称、Modbus地址、数据类型、当前值等属性。这样层级清晰，代码不至于都堆在MainPage里。

3.2 HslCommunication库的引入与封装

HslCommunication是这套源码的核心依赖，它提供了SiemensS7Net、ModbusTcpClient等一系列工业通信客户端。这里我用的是ModbusTcpClient，因为它直连PLC走Modbus TCP协议最稳妥。

在VS2019里安装HslCommunication很简单，用NuGet包管理器搜索“HslCommunication”直接安装最新稳定版即可。装完之后，封装一个通信服务类是这套源码的精华所在，我建议所有走到这一步的人好好看这个类的设计：

csharp复制public class PlcModbusClient
{
    private ModbusTcpClient _client;
    private readonly string _serverIp;
    private readonly int _port;

    public PlcModbusClient(string serverIp, int port = 502)
    {
        _serverIp = serverIp;
        _port = port;
        _client = new ModbusTcpClient(_serverIp, _port);
    }

    public bool Connect()
    {
        var result = _client.ConnectServer();
        return result.IsSuccess;
    }

    public void Disconnect()
    {
        _client.ConnectClose();
    }

    public OperateResult<ushort> ReadInt16(int address)
    {
        return _client.ReadInt16(address);
    }

    public OperateResult<float> ReadFloat(int address)
    {
        return _client.ReadFloat(address);
    }

    public OperateResult<bool> WriteBool(int address, bool value)
    {
        return _client.WriteCoil(address, value);
    }

    public OperateResult WriteInt16(int address, ushort value)
    {
        return _client.WriteOneRegister(address, value);
    }
}

这个封装看起来简单，但好处很大：所有方法都返回OperateResult类型，它是HslCommunication定义的结果对象，包含IsSuccess和Message属性。调用方可以统一处理成功和失败，不用在业务代码里到处写try-catch。我在实际工程里通常还会把连接状态做成一个事件，连接断开时自动通知UI更新状态栏颜色，这样在手机上可以一眼看出通信是否正常。

3.3 组态界面设计思路

手机APP的组态界面，说白了就是安卓页面上放一堆控件，每个控件绑定一个Modbus地址。这个项目的组态界面没有用复杂的图形引擎，而是用Xamarin.Forms自带的控件组合实现。用到的组态元素大致有这么几类：

• 实时数值显示，用Label显示温度、压力、流量等模拟量值
• 开关状态，用BoxView画一个带颜色的圆形，绿色表示运行，红色表示停止
• 按钮控制，用Button向PLC写启动、停止指令
• 简单趋势，如果需要画曲线，可以用SkiaSharp画实时折线图

界面设计上的核心技巧是“把数据绑定放到ViewModel层”。我用的是MVVM模式，每个页面有一个对应的ViewModel，ViewModel里定义标签属性，然后用INotifyPropertyChanged通知界面刷新。比如温度值：

csharp复制public class MonitorViewModel : INotifyPropertyChanged
{
    private string _temperature;
    public string Temperature
    {
        get => _temperature;
        set
        {
            _temperature = value;
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Temperature)));
        }
    }
}

后台定时器每500毫秒读取一次PLC数据，读取到温度之后，把值赋给Temperature属性，界面上的Label就自动更新了。这个模式看起来是Xamarin开发的基础操作，但放在组态App场景下正好合适——PLC的数据天然是“一堆点位 + 周期刷新”，和MVVM的属性绑定完美契合。

4. 核心通信代码：连接、读写、刷新

4.1 连接管理：连接、断开、重连

整个APP的使用路径就是：打开APP → 点击连接 → 开始刷新数据 → 切后台/关页面 → 断开连接。连接管理这块要处理好几个边界场景。第一，连接要异步执行，不能卡死UI线程。第二，连接要能超时返回，现场网络不通的情况太多，不能一直转圈。第三，断线后要支持自动重连。

我用一个比较简单的状态机来管理：Disconnected、Connecting、Connected、Reconnecting。UI层面根据状态显示不同的按钮文字和颜色。连接的核心代码：

csharp复制private async Task<bool> ConnectAsync()
{
    _status = ConnectStatus.Connecting;
    OnStatusChanged?.Invoke(_status);

    var result = await Task.Run(() => _plcClient.Connect());
    if (result)
    {
        _status = ConnectStatus.Connected;
        OnStatusChanged?.Invoke(_status);
        StartAutoRefresh();
        return true;
    }

    _status = ConnectStatus.Disconnected;
    OnStatusChanged?.Invoke(_status);
    return false;
}

自动重连我建议用后台的定时器检查，每5秒检查一次连接状态，如果不是Connected状态就重新执行ConnectAsync。这里有一个很必要的限制：重连次数不能无限，否则APP一直在后台尝试连接，耗电也浪费带宽。最多重连3次，失败之后就停在Disconnected状态，提醒用户检查网络。

4.2 数据读取与组态控件绑定

连接建立之后，工作重心就变成了周期性的数据读取和界面刷新。数据读取的定时器用Xamarin.Forms的Device.StartTimer，它是在UI线程上执行回调的，所以读到的数据可以直接更新Label属性，省去了Dispatcher切换。但访问网络本身不能放在UI线程，否则界面会卡死，所以实际代码里，定时器回调内部要启一个Task去异步读取PLC数据：

csharp复制Device.StartTimer(TimeSpan.FromMilliseconds(500), () =>
{
    Task.Run(async () =>
    {
        var tempResult = await _plcClient.ReadFloat(1);
        if (tempResult.IsSuccess)
        {
            _viewModel.Temperature = tempResult.Content.ToString("F2");
        }
    });
    return true; // 返回true表示持续执行
});

这里有两个细节可以分享。第一个是读取周期，500毫秒是手机组态APP比较合理的默认值，改到200毫秒刷新会更快，但对WiFi信号质量的考验明显增加，掉线率会上升；改到1秒以上功耗下来了，但实时性会变差。第二个细节是批量读取，如果你一个界面有几十个点位，一个一个读会非常慢。Modbus TCP本身支持一次读取连续多个寄存器，HslCommunication也提供了ReadInt16数组的重载，你在设计点位时就应该尽量把连续变量放在相邻地址，这样一次读取能覆盖多个点位。

组态控件的绑定，用一个“点位表”驱动最省事。我定义了一个List，每个TagItem有TagName、Address、DataType、Value等属性，后台读取循环遍历这个表，一个个读，读到的值更新到对应的TagItem.Value。界面上有几个Label就绑定哪几个TagItem的Value，这样加新点位只需要往表里加一行配置，完全不需要改代码逻辑。

4.3 写操作与安全确认

监控APP和纯粹的只读组态不同，它包含了控制功能，比如启停电机、切换模式。这部分的代码逻辑不复杂，但安全性要求高得多。我给自己定了一条规矩：凡是写操作，界面必须要二次确认，并且要记录操作日志。Xamarin.Forms里做二次确认很简单，用DisplayAlert弹窗：

csharp复制private async void OnStartClicked(object sender, EventArgs e)
{
    bool confirmed = await DisplayAlert("确认操作", "确定要启动电机吗？", "确认", "取消");
    if (!confirmed) return;

    var result = await Task.Run(() => _plcClient.WriteBool(2, true));
    if (result.IsSuccess)
    {
        await DisplayAlert("提示", "启动指令已发送", "确定");
    }
    else
    {
        await DisplayAlert("提示", $"写入失败：{result.Message}", "确定");
    }
}

写入操作有几个常见的坑。第一是写入线圈地址和Modbus地址容易搞混，写线圈用的地址是从0开始的，而读保持寄存器是从40001开始的，地址编号体系不一样，代码里一定要分开。第二是写数据要区分数据类型，写int和写float在寄存器组织上不同，如果你把一个浮点数按整数写进去，对端会被解析成一个乱七八糟的数。第三是写操作要确认PLC侧的保持寄存器DB确实是可写的，有些变量在PLC里被定义为只读，你写的时候不会报错，但PLC内部会忽略掉。

5. 实战排错：连接失败、卡顿、掉线全记录

5.1 连接失败的5个常见原因

这个项目从开发到联调，我在连接这一步卡过很多次，这里把最典型的5个原因列出来，遇到问题可以一条条排查。

IP地址不对。这是最基本的，但也是出错率最高的。手机WiFi获取的动态IP可能和PLC不在同一网段，或者PLC的IP地址填错了一个数字。我的排查方法是在手机上下载一个TCP调试助手，先用它尝试连接PLC的502端口，如果调试助手能连上，APP代码肯定也能连上；如果连不上，先从网络/IP层面查。

MB_SERVER没调用成功。如果你确认网络通、IP通、端口通，但APP连接依然失败，多半是PLC内的MB_SERVER指令块没有进入运行状态。常见的错误是背景DB没有指定、连接描述没有正确配置。在编程软件里在线监控OB1，看MB_SERVER的STATUS引脚，如果是16#0000表示正常，其他错误代码可以查手册，最常见的16#80B1是连接参数错误。

防火墙拦截。电脑调试的时候，Windows防火墙会弹窗确认；手机的防火墙相对简单，但部分安全软件或企业设备管理策略会拦截局域网连接。检查手机有没有安装什么安全管家类APP，先把它们的拦截功能关掉再尝试。

端口被占用。如果PLC里有其他上位机或HMI也用了502端口，MB_SERVER会绑定失败。这种情况在现场很常见，特别是老的触摸屏会占用 Modbus 端口。解决办法是把PLC侧的MB_SERVER端口改成自定义，比如1502，APP连接时填对应端口。

跨网段访问。手机在192.168.1.x，PLC在192.168.2.x，中间没有网关、没有路由，APP必然连接失败。对策是调整其中一边，让它们处在同一网段。如果确实需要跨网段，务必配置好路由规则。

5.2 APP卡顿与UI线程问题

在Android手机上跑Xamarin.Forms，最容易遇到的就是UI卡顿。卡顿的根本原因是频繁堵住UI线程，只要在UI线程上同步做网络请求，界面必然卡。我之前试过直接在Device.StartTimer的回调里调用ReadFloat方法，结果每次读取都会卡一下，500毫秒刷新频率甚至能把界面卡成PPT。

正确的做法是网络操作全部放到后台任务里。但这里还有一个隐患：后台任务读到的数据返回给UI线程时，如果更新频率太高，UI一样会卡。我通常用一个“节流”策略，后台读取按500毫秒执行，但只有当数据变化超过一定阈值时才更新UI。比如温度变化超过0.1度才刷新显示，频率值变化超过1Hz才刷新，这样既保证了实时性，又减少了UI的无效刷新。

另外要留意Android的内存回收机制，如果设备和PLC之间的通信建立了多个定时器，页面关闭之后却没有停止这些定时器，会导致内存泄漏连带APP越来越卡。页面卸载时一定要调用Disconnect并停止所有定时器。

5.3 断线重连与稳定性优化

WiFi终究是无线环境，信号波动、路由器重启、手机WiFi休眠等因素都可能让长连接断开。这套源码里的自动重连逻辑，在稳定运行中起了很大作用。我的做法是，通过一个后台高频的心跳读取来判断连接是否有效——每2秒尝试读取一个快速变化的寄存器，如果连续3次失败，就认为连接已经断开，进入重连流程。

这里有一个经验上的取舍：心跳读取会增加一点通信负载，但能让系统及时发现断连，避免用户看到“数据一直不变”的假象。相比偶尔一次心跳带来的流量，我觉得及时感知断线更重要。实测下来，在室内WiFi环境下，3次失败判定断线、5秒后首次重连、重连最多10次的策略，效果比较理想。

重连成功或者断开时，建议通过本地通知或者状态栏变色提醒用户。组态界面上的连接状态指示灯，就是一个很好的交互反馈，绿色代表在线，红色代表离线，用渐变动画演示状态切换，用户一眼就能看出当前通信是否正常。

5.4 常见问题速查表

这张表是排障的第一步，真正遇到问题的时候，还需要根据具体的日志信息去定位。这里强烈建议在通信代码里加上日志输出，HslCommunication的方法返回OperateResult，里面自带的Message可以写到日志文件，以后排查问题就是照日志看，比现场干猜高效太多了。

最后说几句实在的

项目做完回顾下来，我最大的感受是：手机组态APP监控S7-1200这套方案，门槛没有想象中那么高，但细节真的多。你只要把PLC侧的MB_SERVER配好、保持寄存器映射清楚、Modbus TCP地址算对、UI线程和网络线程分离，基本上后面就是润色的事了。可偏偏这些环节每一个都可能让人卡壳几天。尤其是Modbus地址离线时觉得简单，联调时一错就是全错的数据，浪费大量时间。

如果你手头正好有S7-1200项目想加手机监控，我的建议是别急着去搞那些很重的组态平台，先按这套源码的思路把最小原型跑通：一个PLC、一台路由器、一个手机APP，先实现一个温度显示和一个电机启停，再逐步加点位。跑通了这个原型，后面要扩到几十个监控点、多个页面都只剩工作量的问题。这也是这套源码对我最大的价值——它不是给你一个庞大的空壳，而是给了你一条从0到1真正能走通的路。