企业官网建设流程全解析

1. 项目定位与整体设计

1.1 需求明确：为什么是昆仑通态 + 上位机

做工业自动化上位机开发这些年，我接到的需求里很大一部分不是“从零写一套完整的上位机”，而是“现场已经有用昆仑通态做的HMI画面，现在客户希望在办公室电脑上也能看数据、做报表、出统计”，甚至是要把原来的VB6老系统升级成C#.NET。

昆仑通态这套组态软件在中小型项目里实在太常见了。不管是水处理、环保监测、设备改造还是小型产线，TPC触摸屏加昆仑通态组态基本是国内工控行业最普及的搭配之一。它的优势很明确：上手快、驱动全、画面组态效率高，一个普通电气工程师培训一周就能出基本能用的画面。

但组态软件也有明显的短板。复杂逻辑处理、数据库交互、定制报表、Web端展示、与MES/ERP对接这些需求，组态脚本做起来非常痛苦。这时候就需要上位机开发介入：让VB6、VB.NET或者C#.NET把组态系统拉进更庞大的信息体系里。

我这次要拆解的项目标题里其实藏了三条明确的技术路线：VB6写老的串口通信上位机、VB.NET做中等规模数据管理、C#.NET做现代化分层架构。三种方案我都实际在项目里用过，它们和昆仑通态配合的亲密程度并不一样，后面我会把每条路线的适应场景和通信方式都摆出来说清楚。

不少网上教程只讲了“昆仑通态怎么被上位机读”，或者只讲“上位机怎么读取PLC寄存器”，很少把组态屏当作一个独立节点来设计通信架构。实际上昆仑通态触摸屏大多数型号本身就带以太网口、串口，它在整个系统里可以作为数据中继、边缘采集站或者单纯的HMI，三种角色对应完全不同的开发方案。

1.2 三层语言怎么选：VB6、VB.NET、C#.NET

很多刚入门的朋友看到标题会问：都2025年了还有人在用VB6吗？答案是：非常多。工业现场存量系统里VB6写的上位机比很多人想象中多得多。它稳定、轻量，对串口和ActiveX控件支持非常成熟，尤其老款工业采集卡、读卡器、称重仪的官方示例代码当年全是用VB6写的。但要正视现实：VB6没有64位原生支持，Unicode支持差，遇到稍复杂的表格、报表、多线程就会非常别扭。

VB.NET算是一个过渡方案。它的语法比C#啰嗦，但继承了Visual Basic的亲切感，对从VB6迁过来的老工程师很友好。在.NET Framework 4.x时代，VB.NET和C#编译出来的IL几乎一样，性能和功能并没有本质差距，只差拥抱新生态的态度。

C#.NET则是我现在最推荐的选择。原因很实在：C#上位机开发实战类资料最多、第三方NuGet库最丰富（如Modbus库、S7协议库）、部署维护成本可控。虽然工业现场Java、Python上位机也不少见，但C#在Windows生态下的串口、网络、WinForms/WPF开发体验，目前仍是最顺畅的。

三种语言和昆仑通态的通信路径也有区别。VB6时代最常见的做法是MSComm控件走串口，只把昆仑通态当成透明下位机，双方各读各的。VB.NET时期很多人开始用OPC或者直接读写数据库实现上位机与组态系统互通。C#.NET项目则更有意思：既可以把组态屏配置成Modbus TCP Server，让上位机直接读寄存器，也可以通过SQLite/MySQL中转数据，做到完全松耦合。

2. 昆仑通态组态开发的关键环节

2.1 工程建立与组态环境基本配置

先说说最容易忽略的基础配置。打开昆仑通态组态软件后，建立工程的常规步骤如下：设置工程名称与保存路径，然后进入主控窗口、设备窗口、用户窗口、实时数据库、运行策略五个核心面板。这个结构理解透了，后续开发会顺很多。

主控窗口是工程的入口和总体框架：启动画面选择、运行权限设置、启动时自动加载哪个用户窗口、退出时是否提示保存，都在这里配置。设备窗口是整个组态系统连接外部硬件的通道，PLC、仪表、扫码枪、摄像头、Modbus设备的驱动全部要挂在设备窗口下面。用户窗口就是我们画HMI画面、添加各种图元和动画的地方。实时数据库是组态软件的数据中枢，凡是外部设备采集进来的值、脚本算出来的值、用户手动输入的设定值，最终都落在实时数据库的变量里。运行策略则决定了“什么时候执行什么逻辑”，比如定时采集、扫码触发、报警联动。

设置TPC型号这步很多人会跳过，但千万别省。同一份工程在不同型号的昆仑通态屏上运行的差异，主要就是分辨率、存储空间、脚本兼容性。工程属性里必须明确目标设备型号，否则会出现编译能通过、下载到屏上却运行报错的情况。早期我用通用型号编译的工程下载到某款1024×600屏上，画面比例错乱了一个多小时，后来才发现是型号选错了。

设备组态是整个项目正确性的一半。添加设备驱动时，通道地址的规划极其关键。比如用昆仑通态的PPI驱动连接西门子S7-200时，地址映射要严格对应PLC内部寄存器区：I区、Q区、M区、V区各有各的表示方式，写错一个前缀，数据读出来全会乱掉。更隐蔽的问题是32位变量拆分成两个16位寄存器时，高低字顺序在不同PLC协议里并不统一，因此在实时数据库里关联变量时要明确是“高字在前”还是“低字在前”，否则数值会被放大了65536倍还察觉不到。

设备调试窗口是排查这类问题的利器。写变量地址后点击“读取”按钮，看原始报文和数据值是否正常，这一步不通过就不要继续画画面了。我个人的习惯是：每接一种新设备，先建立一个最小工程，只建一个窗口、一个变量，确认该变量的读写都正常，再往大工程里复制，避免后期排查像大海捞针。

2.2 实时数据库的变量划分与管理

实时数据库里变量的命名规范，直接决定后期上位机对接时的工作量。有些项目里组态变量名是随便起的：“y1、y2、temp1”，上位机开发人员拿到变量表时一脸茫然。我见过比较高效的规范是：前缀_设备编号_信号类型_物理量，比lights比如“M1_TEMP、M2_SPEED、SYS_FAULT_CODE”这样语义明确且不容易重名。

变量类型也不能全用浮点型。昆仑通态支持开关量、数值型、字符型、事件型，但实际使用中有几个非典型技巧：模拟量报警值建议用独立的设定变量，而不是直接在报警属性里写固定上限；字符串变量在不同驱动里的长度限制差异很大，对接扫码枪时要提前测试最大字节数；组态重启后实时数据库变量会恢复初始值，如果有些产量、累计电量需要断电保持，必须勾选掉电保存属性，否则断一次电数据全清零，客户基本上会直接让你返工。

运行策略脚本有一种易踩坑的情况：在不同驱动类型下数值类型自动转换的时机并不一致，VBS脚本里写!"数值变量"这种取值方式时，布尔型数据会表现出True/False与1/0两种形态，影响后续比较运算。我通常会在比较时强制转换：

If CInt(!"M1_RUN") = 1 Then !"M1_STATE_TEXT" = "运行中" Else !"M1_STATE_TEXT" = "停止" End If

这样写虽然看起来繁琐，但至少能保证无论是组态软件自动刷新阶段还是上位机远程写入阶段，都不会出现类型不匹配导致跳变。

实时数据库还有一个用法非常适合与上位机配合：把上位机远程下发的指令值也定义成变量，并且勾选“操作优先级”。比如C#上位机通过Modbus写某个地址来启动设备，昆仑通态本地按钮也控制同一个变量，那就要明确谁的优先级更高，甚至用报警/事件机制记录“最后一次写入来源”。这个设计在甲方审计操作记录时特别有用，因为组态软件里的历史事件和时间戳可以自动形成一个操作追溯链。

画面组态的核心在于“动”。昆仑通态界面动画其实是它相对其他国产组态软件的显著优势。按钮换色、流动箭头、电机旋转、液位升降这些动画效果都不难实现，关键是把动画关联到变量而不是固定值。比如液位填充效果，关联一个0到100的整型变量，并设置最大最小对应高度，这样实际运行时画面就会跟随现场真实数值变化，客户的第一观感会非常专业。

2.3 用户窗口的组态布局与动画关联

进入用户窗口后，右侧工具箱里有大量图元：按钮、指示灯、仪表盘、曲线、报表、实时曲线。我设计的布局习惯是分区域展示：顶部为总状态栏和报警滚动条，中间主体为工艺流程画面，底部为操作按钮区与当前用户信息。顶上放报警滚动条是我从十几个现场实用反馈中沉淀下来的，操作工不看专门的报警页，但滚动条一闪他们就知道设备出事了。

画面切换可以用按钮的“用户窗口切换”动作实现。这里推荐把窗口名改成拼音或英文，同时窗口标题设置为中文显示名，避免程序内部引用路径出现乱码。多个画面之间需要传参数时，可以使用全局变量在内存中暂存，但不建议频繁切换窗口并大量读取历史数据，组态屏性能有限，窗口动画一多切换会明显卡顿。

动画关联时要注意连动变量与刷新周期。昆仑通态的画面刷新是周期性的，默认采样周期设置过大会导致动画看起来“一顿一顿”。在采样周期允许范围内，适当将关键动画关联变量的刷新设为100ms左右，体验会有明显提升。但是刷新周期过短又可能增加PLC通信负担，影响整体响应。根据现场经验，一般动画控制在200ms，数据记录控制在500ms，报警扫描不需要太快，1000ms足够。

界面动画里还需要留神“泄漏”问题。某些老版本用“可见度”动画关联设备离线变量时，变量值为0时会把图元整个隐藏，连描述文字一起消失，运行人员看到空白区域会误以为是设备停了。稳妥做法是用“填充颜色”或“闪烁”表达离线状态，而不要直接隐藏图元。

3. 上位机与组态软件的数据交互实操

3.1 通信方案选型：ODBC、OPC还是Modbus TCP

上位机和昆仑通态之间传数据，没有专属协议，全部走通用工业通信手段。用得最多的是这么几条路：ACCESS/SQLITE数据库中转、ODBC直连组态存储数据、通过OPC Server读写组态屏实时变量、将组态屏设置成Modbus TCP Server，让上位机直接读写寄存器。

数据库中转是最稳的。组态软件通过数据库插件把数据定时写进SQL Server / MySQL / ACCESS，上位机再通过ADO.NET或者ODBC查询新的记录。这种方式的优点是完全解耦，组态屏和上位机不用互相等待，数据库挂了也无非是停止记录，不会导致PLC通信中断。缺点是实时性差，一般适合秒级以上的数据采集和报表统计。

OPC方式实时性非常好，缺点是OPC Server的搭建与DCOM配置在Windows上常年是坑。尤其在客户现场没有域环境、两台电脑账户密码不一致的情况下，DCOM权限问题能消耗一整天。如果你面对的是老工程师维护的环境，我建议优先避开OPC跨机访问。

所以我现在最常用的是Modbus TCP Server方案。把昆仑通态当成一个数据服务器，定义若干个Modbus保持寄存器地址，组态屏在后台将PLC采集到的真实数据映射到这些寄存器里。C#上位机只用一个Modbus TCP客户端库就能连接组态屏的IP和端口，实时性、稳定性、跨平台兼容性全都说得过去。

给刚接触的朋友划一个选择表：

从这几个方案实际落地的角度讲，我最想强调的是：不要把“让上位机直连PLC”和“让上位机通过组态屏读数据”这两种方式搞混淆。直连PLC需要上位机配置与PLC品牌匹配的通信协议，比如S7协议、三菱MC协议；而通过组态屏中转时，上位机只需要跟组态屏一种设备通信，协议固定（Modbus TCP、OPC或数据库），这才是组态屏作为“数据中继”角色最舒服的用法。

3.2 C#.NET访问组态数据实战

我直接用C#.NET演示一个最稳定省事的思路：昆仑通态组态屏作为Modbus TCP Server，C#写的WinForm上位机作为客户端读取和写入保持寄存器。目标Android设备型号对应组态屏的寄存器范围，比如保持寄存器从40001开始。

先引入一个社区常用的库NModbus，通过NuGet安装即可：

Install-Package NModbus

连接组态屏并读取一个寄存器数值的完整示例：

using Modbus.Device; public class MCGSClient { private ModbusIpMaster _master; private readonly string _ip; private readonly int _port; public MCGSClient(string ip, int port = 502) { _ip = ip; _port = port; } public void Connect() { var client = new TcpClient(_ip, _port); _master = ModbusIpMaster.CreateIp(client); _master.Transport.ReadTimeout = 3000; _master.Transport.WriteTimeout = 3000; } public ushort ReadRegister(byte unitId, ushort startAddress) { // 组态屏寄存器按照16位保持寄存器访问，unitId一般填1 ushort[] values = _master.ReadHoldingRegisters(unitId, startAddress, 1); return values.Length > 0 ? values[0] : (ushort)0; } public void WriteRegister(byte unitId, ushort startAddress, ushort value) { _master.WriteSingleRegister(unitId, startAddress, value); } }

读取组装变量时经常遇到一个字节序问题：组态软件内部以字符串存放的设备编号，在Modbus寄存器里往往是两个字一字，上位机需要手动转换高低字节得到可读ASCII文本。这个细节让我踩过坑。例如读取设备编号“AB”时，寄存器值可能是0x4142，C#端解析方式：

public static string RegisterToAscii(ushort regValue) { char high = (char)((regValue >> 8) & 0xFF); char low = (char)(regValue & 0xFF); return $"{high}{low}"; }

反之，写入设备编号时要把ASCII字符串拼成ushort。这种手写转换逻辑不复杂但极易出错，建议封装成通用静态工具类并写单元测试覆盖：

public static ushort AsciiToRegister(string text) { if (string.IsNullOrEmpty(text) || text.Length < 2) return 0; return (ushort)((text[0] << 8) | text[1]); }

实操时还需要注意Modbus库的异常处理。工业现场网络偶尔会闪断，上位机读数据时如果直接抛异常而不做重试，程序会看起来像“卡死”一样。我习惯于在读取外围包一层带超时和重试的封装：

public ushort ReadWithRetry(byte unitId, ushort startAddress, int retryCount = 3) { for (int i = 0; i < retryCount; i++) { try { return ReadRegister(unitId, startAddress); } catch { Thread.Sleep(200); } } throw new TimeoutException($"读取组态屏寄存器 {startAddress} 超时"); }

不过也要提醒一句：重试虽然能扛住瞬时网络抖动，但不能掩盖硬件层面的故障。如果一小时内日志里全是重试成功记录，就该排查交换机、网线、组态屏网口是否过热了。

3.3 VB6和VB.NET接入方式的差异

C#讲完了，回到老项目里最常见的VB6做法。VB6实现相同功能依赖于MSComm控件或者直接调用Windows API的串口函数。如果现场还是串口连接，核心初始化代码大致如下：

MSComm1.CommPort = 1 MSComm1.Settings = "9600,n,8,1" MSComm1.InputMode = comInputModeBinary MSComm1.RThreshold = 1 MSComm1.PortOpen = True

发送Modbus RTU请求帧时，直接在字节数组里拼CRC校验，这种底层操作VB6写得比C#更繁琐，因为VB6里没有现成的byte[]处理辅助，经常要用一个自定义ByteBuffer类来完成高低位拼接。那几年做这类项目基本是靠复制粘贴CRC算法，再加上一个十六进制转字节数组的通用模块。

VB.NET和C#其实同属于.NET框架，串口通信代码除了语法层面不同外差别不大。用System.IO.Ports.SerialPort替代MSComm，后台线程轮询读取数据，使用BackgroundWorker或者Task处理界面更新。VB.NET在写这类代码时有个优势：很多制造业老工程师的Excel/WPS VBA功底非常扎实，从VBA迁移到VB.NET几乎是平滑的，变量声明、函数调用风格天然亲和，上手成本远低于C#。

有一个VB系开发特有的坑值得单独说：深拷贝还是浅拷贝。在VB6里用Dim arrCopy() As Byte : arrCopy = arrOriginal做数组赋值，本质上是引用复制，修改arrCopy会波及原数组。很多老工程师当年在这上面吃过亏。而在VB.NET里同样的赋值逻辑语义已经变了，数组重新分配为独立副本。从6迁移到.NET时，老代码里凡是做过数组赋值再修改的地方，都要逐一检查是否要被新行为影响。

如果你需要让VB6程序直接调用C#.NET写的组件，唯一可靠的方式是给C#代码创建COM可见类，然后在VB6里通过CreateObject调用。我为某个老项目做过一次这个桥接，感受就是“能跑但很别扭”：结构体传参限制多、调试时无法进入C#内部、部署时要处理COM注册权限。所以现在的建议是，老VB6系统如果不是非动不可，尽量别碰跨语言调用；一旦决定升级，就整体用C#或VB.NET重写，保留业务逻辑文档即可，不要在VB6和C#之间做强耦合。

4. 常见问题与排查技巧实录

4.1 数据对不上、变量不更新，典型故障点

做组态上位机的项目，最容易出现的异常是“明明组态屏上数值正常，上位机读回来却不对”。排查路径我固定按以下顺序来。

先检查组态屏那边映射的寄存器是否已经被占用。昆仑通态的Modbus地址一旦和数据对象编号绑定，就不能再让其他设备访问相同地址，否则写的时候会互相覆盖。常在画面里新增了按钮关联某个地址，但没注意到这个地址同时在采集脚本里被写入，结果导致触摸屏和上位机同时争抢这个地址，数值跳动不定。

再检查字节序。比如浮点数在Modbus里占两个字，组态屏存储的顺序可能和C#端的解析顺序不一样。之前演示了高低字节转换，实际项目中值得先做一个“回环测试”：上位机先写入一个已知浮点数（比如1.2345），组态屏实时数据库中看一眼，如果显示的是一大串乱码，确定是高字低字反了，调整一次解析即可定位。

还有一种情况是刷新周期。上位机连续读取太频繁，组态屏可能根本处理不过来。有些型号的组态屏对Modbus请求处理是单线程的，高位频次读取时CPU占用直线上升，还有可能拖慢触摸屏自身的页面刷新。建议上位机普通数据读取频率设置在200ms以上，不要在循环里无脑query。如果你需要10ms级的实时控制，请绕开组态屏直接连PLC。

变量不更新还有可能是通信掉线后没有自动重连。多数组态屏的Modbus Server在检测到TCP断开会等一段时间才释放连接，上位机这里表现就是第一次连接成功，断线重连却一直超时。我通常会在上位机里加一个心跳任务，每5秒发一个读取请求，同时监听连接状态，发现异常快速TcpClient.Close然后重连。

4.2 PLC通信与组态屏相互干扰的处理

多点并发访问时有一类很隐蔽的故障：PLC同时被组态屏驱动和上位机直连驱动访问，导致PLC通信协议栈忙不过来，时不时出现部分寄存器无法访问。这是因为组态屏本身就是一个通信主站，如果上位机又作为主站去跟PLC交互，同一时间内多个主站发送请求，从站会忙或直接丢帧。

做法上有两种路线。第一，桥接模式，数据全部先由组态屏读出，上位机只跟组态屏对话，不要直连PLC，这在系统设计上最安全。第二，时间片错峰，上位机只在组态屏停止轮询的空隙读取，比如把组态屏的设备扫描周期改成800ms，上位机读PLC的周期也错开500ms。实际效果看现场设备数量，但总归是不如第一种干净。

还要注意串口扩展的坑。如果组态屏只有一个串口，却同时接了外设通信单元、扫描枪和变频器监控，串口就要做多主站轮询。多个设备地址不同，通过协议转换可以让它们挂同一条485总线，但波特率和数据帧格式必须统一。有些组态屏型号内置了串口分时轮询的能力，不过总线的设备数量过多时，轮询周期会被拉得很长，控响应经常迟钝。遇到这种情况我建议“串口只用来带现场设备，上位机永远走以太网”。

4.3 现场通讯不稳的排查速查表

结合我自己的调试经验，把常见故障整理成速查表：

5. 扩展场景与运维心得

5.1 U盘存储、扫码枪与网络摄像头的实际用法

昆仑通态在不少工厂里不仅仅是HMI，还被当成边缘小网关用。U盘存储就是一个典型：组态软件可以定时把历史数据导出成CSV文件存到U盘，也可以在U盘插入时自动执行配方下载。现场没有上位机、没有网络的场景下，这个功能非常实用。运维人员每个月插一次U盘把历史产量考走，连组态软件授权都不用额外买，中小企业会议报表所需的原始数据一般就这么攒出来了。

关于昆仑通态触摸屏连接扫码枪，项目里最常见的是通过RS232串口接扫描枪实现产品序列号录入。扫码枪模式需要设置成“键盘口模拟”或者“串口发送”，组态侧通过串口驱动接收ASCII字符。这里有几个需要注意的点：扫码枪的结束符通常是回车，组态脚本要识别这个回车才触发一次完整扫码；扫描内容如果含有空格、中文，字符编码不一致也会显示乱码，建议在串口配置中统一为ASCII或UTF-8；扫码枪插入后要测试不同扫码速度，太快的连续扫码会超出组态屏的接收缓冲，导致漏数据，此时可以在扫码枪侧加大回车延迟。

再就是网络摄像头。组态屏通过内置的流媒体插件，可以直接在画面里显示网络摄像头的RTSP视频流。这意味着组态画面成为了一个轻量的视频监控与工控联合界面。值得注意的是，不同厂商摄像头的RTSP路径格式不一样，比如大华和海康的URL规则差异很大，组态里要按摄像头型号填写正确的地址、用户名、密码。同时网络摄像头的引入会增加组态屏带宽和CPU负载，别在低端TPC型号上同时挂四路以上视频流，否则画面会严重掉帧，影响核心工艺流程监控。

5.2 C#上位机与组态脚本的分工边界

我一直坚持一个观点：能用组态脚本做的简单逻辑，绝不上位机做。PLC的启停互锁、报警值判断、设备联锁这些逻辑放在组态脚本里更贴近现场，调试时也不用开着Visual Studio来回编译。上位机只应该做组态软件不擅长或做不好的事：海量数据存储、复杂报表、权限审计、与第三方业务系统接口对接。

很多失败的组态上位机项目，核心问题不是技术，而是职责划分混乱。把画面动画做到了上位机里，却把组态屏当成了摆设；或者把复杂的统计计算塞进组态脚本，结果触摸屏频繁卡死。合理的架构是：组态屏负责现场交互和设备直连，上位机负责数据资产和业务流管理，二者通过Modbus TCP或数据库同步，各自干擅长的事。

如果要做稍微复杂一点的分工，可以考虑在C#上位机中引入分布式通信中间件，比如MQTT，把组态屏采集到的数据推送到多个客户端，实现车间看板、移动端App、WEB报表同源更新。昆仑通态本身也支持MQTT协议，但和C#上位机集成时，仍建议由上位机作为MQTT Broker的客户端之一，组态屏直接连Broker发送JSON数据。这样可以避免上位机与组态屏之间做频繁轮询的负担。

我在C#上位机中处理MQTT数据时使用MQTTnet库的结构大致如下：

using MQTTnet; using MQTTnet.Client; var factory = new MqttFactory(); var mqttClient = factory.CreateMqttClient(); var options = new MqttClientOptionsBuilder() .WithTcpServer("192.168.1.100", 1883) .WithClientId("upper-machine") .WithCredentials("admin", "password") .Build(); await mqttClient.ConnectAsync(options, CancellationToken.None); mqttClient.ApplicationMessageReceivedAsync += e => { string payload = Encoding.UTF8.GetString(e.ApplicationMessage.PayloadSegment); // 将JSON解析并存入数据库/更新界面 return Task.CompletedTask; };

这种扩展方式适合未来要做数字化工厂的甲方，前期在上位机层面规避一些重复采集的工作量。

5.3 运维维护中容易忽视的细节

运维阶段最容易忽视的是备份。工程源码要定期导出备份，组态屏的工程文件也要复制一份放到上位机目录里。我见过不止一次：触摸屏故障后换新屏，现场却找不到原始工程文件，只能联系原设备厂家，一折腾就是几天。上位机程序同样需要给工程目录做版本管理，哪怕只是简单地在部署时把日期加在安装包名里，也比裸跑强。

部署环境的兼容性也非常重要。VB6写的上位机在Win10/11上经常遇到MSComm控件注册失败，这是因为OCX控件没有以管理员权限注册。解决办法有三种：手动regsvr32 mscomm32.ocx注册；在安装包里加入批量注册脚本；或者干脆换SerialPort实现重写这一小段功能。如果是老系统换新电脑，建议不要只复制exe过去，而是把整个依赖目录（包括ocx、dll、配置文件）一起迁移，再做一个环境自检的小工具，能减少大量售后麻烦。

昆仑通态组态软件本身在Win10/Win11下的运行也需要留意。老版本组态软件对高DPI的支持并不完善，工程在4K显示器上会字体发虚、控件偏移。解决办法是把组态软件安装目录下的exe右键属性里设置“兼容性”选项卡“高DPI缩放替代”为“系统（增强）”，并且把画面分辨率尽量锁定为目标TPC的分辨率，不要用屏幕自适应。经验上是，运行画面和组态画面始终采用1:1比例，避免字体缩放带来位置漂移。

最后，上位机与组态屏之间所有通信参数、IP地址、寄存器映射表，必须在项目交付时整理成一张文本配置表。很多项目后期维护难、新人接手难，就是因为这些信息只存在老工程师的脑子里。写配置表的过程比较枯燥，但它会在一年后你被甲方电话叫醒时，让你少掉很多头发。