偶然看了万泉河版主的反UDT同盟的帖子。反不反不一定,但觉得万版说得某些方面看有点道理。
以前曾用UDT和模块组合的方式实现过Modbus的通用化。所以想试一试这种相反的做法,还是同样以走ModbusRTU通信的温控器为例,不用UDT,封装成单个的温控器FB,感受一下不同特点。
找了老版本程序中用UDT最少的,改写省事,做个FB,生成5个温控器,测试OK。
每个温控器只要填进去自己的从站号,引入公共资源就行。下图中圈红框的是和公共资源有关的,其它都是设备自己的内部功能。
设备都要使用PLC资源,有的独占,有的共享。Modbus设备就属于需要共享485端口资源的设备。其它通信资源一般也有共享,可以参考这种模式。
给每个设备标准FB匹配一个界面交互标准UDT,这个UDT就和这个FB的接口衔接对应。一种FB一种UDT,成对儿的,从底层到视觉交互。
这种FB内部没有UDT,所以需要用struct来包含很多的等长数组,便于间接寻址关联操作。
原来设备UDT中,与界面交互有关的元素(例如按钮命令、参数设置、数值和状态反馈等等)都变成了FB的接口参数,而原来UDT中其它与内部功能相关的数据,就都被封装到FB内部去了。所以FB封装这种方式,把原来UDT中封装的数据,分成了内外两类,这对某些操作成为一种便利。
FB封装好处是:并行调用,复制即用,设备对外呈单个界面。缺点是:数据结构定义复杂了,逻辑聚合不好分块调试,通用功能块内化不能多个设备间共享了。
亲自动手同样的东西用相反的方式各做一套,还是挺有收获。用不用UDT和是不是单模块封装,是两种相反的策略,互有代价。
模块中采用了优先级策略。多个站点轮询中,任意站点出现写任务,会优先跳转到该站点首先执行写任务。改善界面的敏捷性和用户体验。多个站点如果都有写任务,会按照出现的先后次序来。