@Zane 版，前几天在某公众号看到您的论文，公众号嘛，在手机这样的移动端看不太清楚，只简单看了个大概。

以您的成就，是处于山顶的人，而我是山脚下的无名之辈，所以面对您提出的问题，很有压力的。

作为久经沙场的一员老将，无论是您的帖子还是文章向来是以全面、系统、章法结构严谨来服众的，既然是已经出版发行的文章，想必是经过严格审查，论文评审委员会的成员们也都是业界翘楚，所以，对您的文章也就不作任何评论了，只说一点我对里面数据方面的想法。

如果沿用您采用的IO地址的数据结构（UDT)的话，每个IO点的地址设定需要从UDT中获取，我个人认为这就限制了使用简单结构如数组形式对数据进行操作的灵活性和查找的快捷性，这在查找操作中是致命的，尤其是还有嵌套的形式，虽然在数据的封装性上我们获得了一定效益，但是封装在某些情境下也带来了相当的劣势。

如果是我的话，我倒宁愿把所有IO点所具有的每个相同的属性（暂时用来借指UDT中的内容）都拿出来，放到一个简单的数组（表）当中，保持数据结构内数据的保持纯粹单一性，而不是驳杂，再分别使用查表的方法进行处理。要调取每个IO点不同的属性值，只需要使用一个索引index，在多个表中直接获取就可以了，也就是下图中从左到右的变化。

数据的组织形式，决定了我们对数据进行操作的算法的快捷与否，而算法也决定了代码和程序的长短。

在不改变原有UDT的前提下，只能额外再加一些做上述表分割工作的FC或者FB来实现查找操作。

周末闲翻故纸堆，看到有这么一段话：

Let the data structure the program. The theme of this column is that data can structure a program by replacing complicated code with an appropriate data structure. Although the particulars change, the theme remains: before writing code, good programmers thoroughly understand the input, the output and the intermediate data structures around which their programs are built.

英语学得不好，翻译做不到“信、雅、达”的程度，就不翻了。

我还在想，在HMI上不搞什么数字输入了，就直接弄字符串也未尝不可，直接输入"IX.Y"，再对字符串进行分解就是了；甚至还有，在HMI上做能根据变量名查找对应地址，以及反操作的功能，即通过输入地址查找地址对应的变量名。当然，这又是个问题了。

至于如何使用您文中的程序架构，还有数据封装的问题（是直接封装还是做完查找操作后再封装），还得细想想，能否再扁平化一些。

暂时就想到这些，见笑了。