|
本帖最后由 mcu_lover 于 2020-7-10 21:26 编辑
在这个HMI设计器中,规划之初,是支持不同型号的。也就是说,未来设计的HMI型号功能各不一样。比如屏幕分辨率大小192*64, 128*64,等等,
支持的通信口有RS232,RS485,有的带一个通信口,有的带两个通信口,有的带三个通信口。此外,操作面板的按键个数也不一样。因此,对这些
硬件资源进行统一的抽象管理,就是上位机在设计之初就要考虑进去的事情。因为它直接影响到后续所有的功能模块的规划和扩展。
除了HMI类型抽象在设计之初要规划明确之外。另外一个重中之重的部分是通信协议的抽象管理。可以说,这一块是整个系统规划中最重要的核心一环。
通信协议的抽象,即牵涉到上位机画面设计部分,各类控件元素的交互设计,又涉及到下位机在开发通信驱动,以及对通信事件进行管理部分的核心代码
规划。因为HMI交互的对象,为各类品牌的PLC,比如欧姆龙,三菱,松下,西门子,基恩士,或者各类控制器自带的协议,又或如常见的标准MODBUS协议
等等。不同厂家的协议各有差异。这就要求我们在规划之初,就找出这些协议的共性,抽象之后,设计成通用的接口,待后续的下位机进行实现。对于这块
后续,当规划到这里时候,会单独进行分解。
想象一下,我们现在使用一个HMI新建工程时候,因为支持的HMI型号各异,因此首先进行HMI型号的选择,其次,要选择与之连接的PLC品牌,以及该
品牌下面的对应的PLC系列型号。那在设计时候设计器就应该包含这两个模块。
前面提及到,我们需要对HMI类型进行抽象统一管理。让我们想想,不同的HMI,虽然功能强弱程度不一样,但至少在功能特性上面是一样的。例如,显示分辨
率的大小,通信口的类型及通信口的数量等等。因此,对于这些功能共性,我们就可以进行统一标识,放在配置文件中保存。
对于配置参数的保存,一般而言,有两种模式,一种为二进制模式,一种为ASCII模式。对于二进制模式来说,保存占用空间少,读取解析也快,对于ASCII模式来
说,占用空间大,解析花费的时间也长。对于此,我个人的观点是,程序永远是写给人看的,而不是给机器看,在效率不是关键的场合,应该尽量以ASCII为主。毕竟
可读的ASCII字符格式对于开发人员来说,还是非常友好的。想想一下,你打开一个文件,看到一堆十六进制的字节数据,恐怕只有再回到代码里面,对照着保存逻辑
结构,才能看的懂哪几个字节代表什么参数含义。
这里我们选择xml格式的文件来进行所有的参数管理和存储。回到HMI类型管理这里,我们为每个HMI抽象的参数如下:
可以看出,每个参数都有具体的名字以及对应的参数值。例如屏幕分辨率的宽度,高度,前景颜色,背景颜色,通信口数量,通信口类型等等。不管是查看还是修改参
数都非常直观。对于后续新增功能的添加也是只需要新增对应的项目,然后程序里面新增对应的处理代码即可。
在代码层面,我们则定义好相对应的HMI属性类,进行统一的参数管理。
例如:HMI属性类,可以后续根据需求进行新增变更等。
HMI资源管理类,加载HMI xml配置文件,生成HMI配置资源列表。
对于PLC资源的管理也是类似如下,可以大概看看如下的配置文件信息:
在这个配置文件中,我们可以看到支持的PLC厂商名称,以及对应的PLC系列。当后续我们开发出了新的驱动之后,在这里添加新的项目即可。
而每个具体的PLC的资源,则抽象之后,按照厂商名称单独存放。通过唯一的ID进行访问。例如台达的PLC,我们抽象之后的配置信息如下:
从上图,可以看到,PLC系列的相关信息,默认的通信配置参数,以及通信装置资源,如 X Y M T C D 等各类PLC内部的寄存器访问信息。根据这些配置信息,我们就
可以在代码中设计对应的类进行操作管理。
有了上面这些基础抽象之后,我们设计器实现的新建方案时候,呈现给用户的界面如下所示:
HMI类型选择:
HMI 通信配置以及PLC选择
对于HMI以及PLC资源的管理原理简介到此。所谓万丈高楼平地起,当前期的规划我们考虑清晰之后,后续的新增功能变更就可以在原来的基础之上方便进行。 |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有帐号?注册
x
阿莫论坛20周年了!感谢大家的支持与爱护!!
你熬了10碗粥,别人一桶水倒进去,淘走90碗,剩下10碗给你,你看似没亏,其实你那10碗已经没有之前的裹腹了,人家的一桶水换90碗,继续卖。说白了,通货膨胀就是,你的钱是挣来的,他的钱是印来的,掺和在一起,你的钱就贬值了。
|