【万泉河】PLC编程：我梦寐以求的符号寻址

以前我对符号编程是无感的。主要觉得给那些变量起名字太麻烦。 英语不够好，起不出规范的英语名字， 怕被人笑话。 又不肯用中文拼音，因为那样更让人笑话。

所以我情愿绝对地址编程，每一个I/O的含义，放在注释里即可。 然后编程的时候每用到一个变量，就从变量表里面查注释然后选择，

用的也挺舒服的。

2008年，董毅从德国总部带着任务找到我帮忙做PORTAL系统的测试，咨询过我对符号寻址的意见，我表示毫无兴趣。 想想啊， PLC里面变量都是8位一组一组的，不管是模块还是内存，原本用绝对地址整整齐齐的，搞什么符号寻址，名字东一个西一个的，找都不好找。

尤其那时候我正在做一个AB PLC的项目和一个Schneider 昆腾的项目，正被符号烦着呢。最终，我甚至在它们里面直接按照西门子的习惯来的，OB1, FC101,FC102， M0.0, M0.1....参考着西门子的程序基础上转化，还很方便。

所以，后来做软件测试，做的程序，也是用绝对地址的，发现也不错，使用很方便，效率还很高。视频采访我的时候，给说了不少好话。 也不算违心。

但项目中用的还是S7-300/400，有那么几年等待期，S7-1500产品线还不全，不够普及。后来有机会做了几次PCS7，对CFC编程，以及和WINCC的集成，有了更多的理解。 所以又几年，专心研究S7-300里的CFC编程，有了一些心得。

在我看来，CFC的本质是在STEP7的绝对地址寻址的系统里实现了符号寻址。 原本FB的上传到WINCC的管脚，是按照绝对地址的顺序在WINCC中建立结构变量的，如果 对FB的接口进行了修改，比如增加或者减少了管脚，传到WINCC的变量的地址发生了变化，如果不对WINCC中的结构变量进行修改，那会导致通讯数据错乱。所以必须随时对WINCC中的变量进行同步修改。

如图是一个FB块的管脚定义，其中一些管脚如MON_T, OP_dwCmd, QdwState等，将来是需要在上位中访问的。

CFC能做到对WINCC变量结构自动更新，但代价是，需要不断地编译编译再编译。一次变更接口后，至少需要编译两次。第一次编译是对PLC程序的编译，本质上是把FB的背景数据块进行了更新。第二次则是对WINCC的编译，结构变量的结构和地址更新的同时，变量数据也进行了更新。

图中列出了编译后在WINCC中生成的结构变量的定义，其中的各变量元素的偏移量，2，16，116，88，96，102，都可以和前面图中FB的定义的地址对应上。

所以，等PORTAL 版本升级到V13以后，逐渐开始在一些项目中使用S7-1200的时候， 我就更留意它对符号寻址的支持，也看它啥时候能支持CFC。

等啊等，等出病来了， 也没等到CFC。 而对符号寻址的支持，好像也一直不太如意。

所以想，是不是等内置到PORTAL里面的WINCC逐渐强大了，变量间可以无缝传递了，就完美实现符号寻址了？

观察对象：WINCC结构变量的定义方法，元素是不是需要设置偏移量，即绝对值地址。

很遗憾， 到目前为止，不管是WINCC 7.X 还是PORTAL WINCC V15, 其结构变量的定义，都离不开偏移量，都离不开绝对地址。 所以导致你如果要模块式编程，就要使用结构变量，除了FB的IDB不能使用优化块以外，对FB的丁点的改动，都会对上位变量产生干扰。 都需要随时人工修改。

如图：

PORTAL的FB块已经与时俱进为优化块了，那些勾选了可从HMI访问的管脚是留给WINCC访问的，但因为优化块没有偏移量，没有地址WINCC却不能直接用元素的符号名称来建立结构变量访问。

这体验简直太糟糕了。

标准化设计方法的模块，不是固化不定的模块，而是需要不断改进不断更新的。 允许更新，方便更改，是标准化设计的基础前提条件。

我们首先需要认识到这一点。

但这基础条件，不是作为应用方的我们所能决定的。 我们只能被动等待，我还算好一点，忍无可忍的时候，可以把建议直接提到德国，但也不能确定德国人会在后面几年后的版本里面落实。 而大部分人甚至都没有渠道传递这种需求给开发者。

那么，在系统的基础前提条件没有达到之前，我们能做的只有通过各种手段，绕过系统的局限，来最大意义上实现标准化模块化的工作。