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和端口实时性、稳定性、跨平台兼容性全都说得过去。给刚接触的朋友划一个选择表通信方式实时性配置难度适用场景上位机侧依赖数据库中转秒级简单报表统计、历史存储ADO.NET/ODBCOPC DA/UA毫秒级较难实时监控、高速控制OPC Client库Modbus TCP毫秒级中等控制指令下发、实时读取NModbus/自定义库串口自由协议取决于协议中等老设备、无网络环境MSComm/SerialPort从这几个方案实际落地的角度讲我最想强调的是不要把“让上位机直连PLC”和“让上位机通过组态屏读数据”这两种方式搞混淆。直连PLC需要上位机配置与PLC品牌匹配的通信协议比如S7协议、三菱MC协议而通过组态屏中转时上位机只需要跟组态屏一种设备通信协议固定Modbus TCP、OPC或数据库这才是组态屏作为“数据中继”角色最舒服的用法。3.2 C#.NET访问组态数据实战我直接用C#.NET演示一个最稳定省事的思路昆仑通态组态屏作为Modbus TCP ServerC#写的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”时寄存器值可能是0x4142C#端解析方式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 现场通讯不稳的排查速查表结合我自己的调试经验把常见故障整理成速查表现象可能原因排查动作上位机连不上组态屏IP不在同一网段、防火墙拦截ping测试临时关闭防火墙确认组态屏IP能连上但寄存器全为0寄存器地址映射未配置或配置错误在组态软件寄存器查看画面中验证地址对应变量数据偶尔跳变双主站冲突或字节序错误检查是否多主站同时访问PLC做高低字回环测试画面卡顿上位机读取频率过高降低轮询周期把读取放到独立后台线程历史数据缺失组态屏掉电保存未启用在变量属性中勾选掉电保存串口数据乱码波特率/校验位不一致将所有设备的串口参数统一用USB转485调试监听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地址、寄存器映射表必须在项目交付时整理成一张文本配置表。很多项目后期维护难、新人接手难就是因为这些信息只存在老工程师的脑子里。写配置表的过程比较枯燥但它会在一年后你被甲方电话叫醒时让你少掉很多头发。