ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

终于有人把上位机说清楚了!干了8年老鸟一张图讲透:它到底是个啥,里面装的都是啥

终于有人把上位机说清楚了!干了8年老鸟一张图讲透:它到底是个啥,里面装的都是啥 说实话我干了三四年的时候你要问我上位机到底是啥我憋半天也就能挤出一句就是跟PLC通信的那个软件呗。直到后来带新人了被逼着把脑子里那些混乱的经验重新捋了一遍才发现这玩意儿用一句话就能说清楚但里面藏的坑三天三夜讲不完。今天就用最糙的大白话把上位机从里到外扒干净。你看完要是还觉得迷糊那我这么多年算白干了。一句话说透上位机它就是工控界的翻译官加监工你不用听网上那些高大上的定义。我给你打个比方PLC或者单片机就是一个只会说方言的哑巴工人。它闷头干活把温度、压力、转速这些数据塞在自己那个小本本里头但不会主动告诉你。上位机是什么就是你雇来的翻译官。他懂工人的方言他会按时跑过去翻工人的本本然后把上面那些鬼画符的数字翻译成老板能看懂的大屏报表。同时老板有啥新指令翻译官就用工人的方言吼一嗓子工人听到了就照做。所以上位机的本质就两层意思通信层充当嘴巴和耳朵负责跟底层设备说话和听话。应用层充当脑子负责把听来的信息整理好给人看以及把人下的命令翻译成设备能懂的语言。就这么简单。你代码里所有的逻辑翻来覆去就是在干这两件事。上位机软件到底长啥样拆开给你看就这3大块很多人觉得上位机神秘是因为把UI界面和底层混在一起看了。你拆开看任何一个正经的上位机软件不管界面多花哨骨子里就是这三块第一块通信驱动层这玩意儿是地基地基不稳楼全塌这是上位机的心脏也是新人最头疼的地方。说白了它就是一堆跟设备聊天的函数库。这里面包含了什么串口类打开关闭串口、设置波特率数据位、收发字节流。你写的时候得注意串口接收是触发事件的数据来的时候你不知道一次能来多少字节所以要在缓冲区里拼包、拆包、处理粘包。Socket类TCP客户端或者服务端处理连接、断开、重连、心跳保活。要处理网络异常网线拔了你的程序不能崩得自动重试。协议解析器这是最核心的。比如Modbus RTU你要把报文拼出来设备地址加功能码加起始地址加寄存器数量加CRC校验然后发出去。收到响应后按同样的格式拆开把数据字节转换成float或者int。很多新手死在这一步字节序搞反了、CRC算错了、功能码不对应通信死活不通。经验之谈把通信层跟业务层彻底分开。我吃过亏早期把串口收发逻辑直接写在窗体代码里后来换协议换得想死。你现在花点时间把通信层封装成单独的类库后面换啥协议都只需要换这一层界面代码一行不动。第二块业务逻辑层这层决定你的软件是玩具还是工具数据收上来之后你不能直接往界面上一丢就完事儿了那是串口调试助手干的活儿。正经的上位机这层要干三件事数据解析和转换。比如从PLC读上来的两个寄存器是十六进制你要换算成真实的温度值。公式可能是原始值除以10再减50也可能是原始值乘0.01再加20每个厂家的传感器算法都不同。你要在配置文件里配好系数让用户自己填不能写死在代码里。数据存储和报表。生产数据是要追溯的你不能只显示当前值。需要用SQLite或者MySQL把历史数据存下来用户能按时间范围查询、导出Excel。我这里说一句数据存储的设计比界面好看重要一万倍。现场生产出问题了甲方翻三年前的日志来追责你的数据库能撑住查出来吗报警和事件。温度超限了、压力过高了、通信断开了你的软件要弹窗、要发邮件、要写日志、要联动急停。这块别用Windows自带的MessageBox你弹个模态框把主界面锁死了产线正在高速运转呢操作工恨不得砸电脑。用自定义的浮动通知或者指示灯闪烁别阻塞主流程。第三块用户界面层别搞花里胡哨甲方只关心大字号这块是新人最喜欢折腾的地方换个皮肤啦、加个动画啦、搞个3D渲染啦。我告诉你全没用。你去车间看看操作工站着干活离屏幕一米多远背景是嗡嗡响的机器。你在界面上搞个灰色字体优雅排版人家根本看不清。做上位机UI的核心原则就三个字大、粗、亮。字体大显示数值的控件字号至少24起步关键参数直接上48号字体。配色粗正常用绿、报警用黄、故障用红、停机用灰。别整什么渐变阴影车间里没人在意这个。布局亮把最重要的参数放在正中间或者左上角操作工扫一眼就要知道当前状态你让他找三秒都找不到关键数据这UI就是失败的。WinForm还是WPF我个人的经验是没UI设计功底就别硬上WPF的MVVM。WinForm拖控件虽然土但胜在直观你一个按钮一个按钮拖逻辑清清楚楚。等你真需要做复杂动画或者数据绑定了再切WPF不迟。大部分人做到项目结束也没用到WPF那套高级功能。从软件角度看上位机到底复杂在哪我跟你交个底很多人觉得上位机难不是难在单点技术上而是难在多线程并发和实时性这两个东西同时出现。你琢磨一下这个场景你的主线程要刷新UI界面显示温度通信线程不停地从串口收数据数据库线程在往硬盘里写历史记录报警线程在实时监控阈值还有一条线程在定期往PLC发心跳包。五个线程同时跑而且都操作着同一份数据当前温度值。这不就是典型的多线程竞态问题吗你在UI线程里读温度值的时候通信线程正好更新了温度值读到的数据是旧的还是撕裂的你写数据库的时候另一个线程在改缓冲区会不会数据错乱解决方案就三板斧。lock锁访问共享数据的时候锁住用完释放最简单粗暴有效。ConcurrentQueue队列通信线程收到数据直接扔队列里业务线程从队列那头取出来处理生产者消费者模式天然线程安全。Invoke跨线程更新UI子线程不能直接改控件的Text属性必须用this.Invoke把更新操作委托给UI线程执行这个忘了写界面直接卡死或者报错我当年被这个坑惨了。再说实时性。车间里有些场景要求响应速度快比如检测到故障要在50毫秒内下发停机指令慢了设备就撞了。但C#是托管语言有GC垃圾回收GC一触发你的线程就可能暂停几毫秒到几十毫秒。怎么解决通信线程里不要new对象尽量用结构体或者预分配好的字节数组减少GC压力。用线程优先级把通信线程提到最高UI线程放到最低。实在要求极端实时性的微秒级那种别用C#那是C和嵌入式干的活C#做上位机本来就不负责那一层。再说一个让新手最困惑的事上位机和组态软件到底啥区别组态软件比如WinCC、组态王、力控它们其实是帮你写好的半成品上位机。你不需要写代码拖拖控件、配配变量、设设通信参数一个页面就出来了。那为什么还要自己用C#写上位机我告诉你核心区别组态软件是通用货架商品C#上位机是定制西装。组态软件的优点是快三天搭出来一个监控界面。但缺点是你想加个特殊算法加不了。你想对接个奇葩数据库对接不了。你想做个特殊报表做不了。它提供的功能就那么多你只能在它画好的框里跳舞。C#上位机就自由多了你能集成OpenCV做视觉检测、你能对接MES系统做生产排程、你能自己写算法做故障预测、你能把界面设计成任意你想要的样子。所以这俩不冲突工期紧、需求简单、甲方不在意界面你用组态软件快速交付。工期宽裕、需求复杂、想炫技或者攒点技术资产你用C#从头写。最后给你一个从零到一的行动路线图我踩过的坑总结出来的顺序你照这个来三个月出师第一个月死磕通信。第一周虚拟串口加VSPD写个控制台程序收发数据把串口类的基础API全部摸透。第二周引入WinForm把收发搬到界面上做成一个串口调试助手重点练Invoke跨线程更新UI。第三周研究Modbus RTU协议手写03和06功能码的报文打包和解析不用第三方库自己写一遍才能理解字节序和CRC。第四周把串口调试助手升级成Modbus调试工具能扫描寄存器、能读写数值。第二个月深入界面和业务。绑定DataGridView显示实时数据每隔500毫秒刷新。加入SQLite数据库把历史数据存进去做个曲线图用Chart控件画出来。加入报警逻辑超限就变色闪烁加写日志文件。把整个程序拆成三层UI层、业务层、通信层用类库分离。第三个月扩展和实战。加上TCP/IP通信让你的上位机能走网线连设备。加入配置文件读写串口参数、寄存器映射表都存到JSON里开机自动加载。做个登录界面和权限管理操作工只能看工程师才能改参数。找个实际设备几十块的Modbus传感器就行从头到尾跑一遍完整的闭环。最后一个忠告不要用第三方库写通信。我知道网上有NModbus这个现成的库一行代码就能读写寄存器。但请你前三个月别碰它。为什么因为你用NModbus三天就能出活但你对Modbus的理解永远是黑盒。CRC怎么算的报文怎么组的异常响应码有哪几种这些你全不知道。等到现场遇到个奇葩设备NModbus不兼容你就傻眼了。自己手写一遍通信层累是累了点但你写完之后再去用NModbus你会发现看一眼源码就知道它在干什么。这种掌控感是用第三方库永远换不来的。上位机这东西说白了就是通信加界面加数据库三个轮子搭起来一辆车。轮子本身不高级但能把三个轮子调稳了跑起来你就已经超过了80%的入门者。剩下的全靠现场的坑去填。
返回列表