|
|
本帖最后由 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周年了！感谢大家的支持与爱护！！
月入3000的是反美的。收入3万是亲美的。收入30万是移民美国的。收入300万是取得绿卡后回国，教唆那些3000来反美的！
|
发表于 2020-7-10 21:28:10
收藏
发表于 2020-7-10 22:05:34
楼主
欢迎欢迎。有空多过来看看。
