电子发烧友App
前几天，有群友在群中提了一个疑问。
他做的MODBUS通讯的程序，原本只需要从通讯中读来1个字/位，然而却发现交叉引用中提示占用了4个字节， 即一个DWORD，问是怎么回事。
大致如图所示。
然后群友们的回答各种各样，有猜测变量在别的地方占用的，也有其它各种猜测，莫衷一是。
我就回复提醒说， 你把上面的count改为20，或者100，看看会怎么样。
他改过之后更懵逼了，交叉引用提示的还是只有4个BYTE被使用。我都要读写100多个字了，怎么还提示4呢， 其它的占用咋不提示呢？
我就把文章的题目作为总结和忠告告诉了提问题的网友和所有群友们，以及再次忠告所有的同行。
即， PLC编程软件中提供了交叉引用工具，便于你查找变量的使用情况。然而，这个工具的统计是不精确的。你不可以把他当成智能的读程序机器人，甚至还指望它帮你检查程序对错。
尤其对指针等的应用，通常交叉引用是无能为力的。比如上面的程序段，其实调用的就是指针。这就要求程序的设计者，在设计规划程序时，对指针的访问区域必须自己有严格清晰的限定，而不能全指望交叉引用帮你管理和发现问题。
对于指针使用，除了上述的直接使用&VB100之外，还可以先将其送到寄存器比如AC0中，而程序块的管脚使用这个寄存器AC0，得到的运行效果是一样的。
如图：
更进一步，你还可以在程序运行中监控这里的数值，比如读到的会是类似16#8000064之类。我这里PLC没有在线，就不验证具体数值了， 有志者自行在线验证数值正确。
然后我们再用这个数值替代程序中的&VB100或者AC0， 再次运行， 程序的运行结果仍然是相同的。
然而，这时候再去检索交叉引用里的字节使用，会发现别说4个字节了， 完全找不到使用的痕迹了。
这是一个技巧。如果之前没有掌握的人，可以趁机了解一下。
这项技巧是个双刃剑。即可以实现正反两方面的功能。
比如你要在程序中做点手脚，不希望后面读程序的人轻易发现，就可以使用这种方式。
而另一个方面，程序的功能中，需要使用一整片的V区数据，然而使用完了以后会立即恢复其原貌，所以本质上并没有使用，只是暂时借用。那么也可以用这种手法来实现。这样正常审查程序时程序会比较干净，自己也不会被交叉引用中大片无效的变量使用而干扰。
最后这一段比较绕，对SMART 200编程使用不深的用户可能难于理解。不过我的新书《西门子S7-200 SMART PLC编程技巧精粹》副标题：“给SMART插上FB的翅膀”，书中有对这一技能做了比较详尽的描述。
书稿是在6月底交给出版社的，最近反馈的消息已经在复审阶段，到正式出版还需要一段时间，读者们再稍微耐心等待。
上面碎片的技术话题到此结束。
后面是讲道理的环节。本来按照常规的定式，应该是先把道理讲完，然后再讲案例的。然而咱们有一些同行，不喜欢看道理，大篇幅的逻辑的话会因为不耐烦而看不下去。那就可以现在就关闭不看了。
我为什么要把这点技术细节专门拿出来讲解？因为这个话题又再次印证了我讲过的标准化编程可以不使用交叉引用的观点。见文章《【万泉河】PLC高级编程：抛弃交叉索引》
同时，这也是我总结的工控行业五连鞭技能的1/5的内容。
万线圈， 不用MT, 不用交叉索引， 不用IO映射， 不用UDT。……工控行业五连鞭
五连鞭中的第一条万线圈，本质上是不畏惧双线圈，如何避免双线圈错误的方法。所以5条技能的主题全部是否定式的 “不”。
而有的同行可能是只读题目，根本不会去仔细阅读理解全文的内容。然后就在后面各种回复：UDT挺好的呀， 你是不是不会用啊！是不是不会用交叉索引啊？厂家设计了M和T你还不用，还不让人用，太霸道了。你咋不去跟厂家建议把这些功能取消呢！
这些同行们都是基本逻辑理解能力有问题。忽略了我在讲到这些技能的时候，都有基本的前提条件：标准化编程烟台方法。
而这些被我摒弃的功能中，有的是隐含了杀鸡不用宰牛刀，有的是因为技能提高后，可以废弃不用的工具，其中一些工具的使用带来便捷的同时还带来了更多麻烦。
比如老祖宗讲杀鸡不用宰牛刀的时候，他听不到前半句杀鸡的前提，只看到了不用宰牛刀，就觉得很惊讶，为什么不用宰牛刀，我家里要杀牛， 你不让用，是不是坏？你有牛刀而不用，是不是傻？
另外还有一个道理：质疑和否定别人的观点， 并不会使自己显得更高明更伟大。
我这儿写几千字的文章， 有人在后面回复区区几十个字不认可不接受，只能表示他自己的理解能力还没有达到水平。有的时候我的回复，只是在帮助他， 或者帮助其他的围观读者，以防他们被误导。而其实我对这些杂音压根儿都不当回事的。
要想引起我的重视，很简单，对等的写和我一样长度的旗帜鲜明观点的文章或者案例故事，发表在你自己的专栏，博客，公号，或者只不过是一篇论坛帖子，也可以。
就像我的导师（爷爷）钱伟长先生，曾经和他的弟子胡海昌院士关于《广义变分原理》的学术观点有过长达十几年的论战，都是通过在科学期刊上长篇论文的形式。学术的观点对错与我们无关，是否有个人误会也无所谓，但这种论战方式至少是对等的。
比如最近就有一些文章发表的观点，比如“我为什么要用T”， “我为什么也不用M”,“我为什么也不用IO映射”，“我为什么用了IO映射”等等，虽然有个别的并不是在讲普遍道理，而只是讲述了他遇到的特殊应用需求。或者有的是跟我的观点相左，有的则是跟我观点相同。
这些都很好，都很令我欣赏。
经常有人拿这些同行的文章转发给我看，看看又有人反对我了，支持我了，或者直接在复制转发我的文章而不署名，我说，不管是反对还是支持这些都无所谓。
编程技术，是个极易验证的行业。正确的方法可以很容易验证正确，错误的方法也很容易被证伪。（题外话，这不是一个非常高深莫测的高科技行业）。那些发表的和我相同的言论，可以从时间间隔长度上可以看到差距。比如是相差1年，2年还是5年6年？当然，如果一直没人发表同样观点， 那也只是在不断增加这种差距：5，10，15，20 ….
而那些相反的言论，有没有拿出证伪我的观点或者方法不可行的证据？如果没有， 那也只是给他自己立了个标签，证明XXXX年XX月XX日，XX人还未掌握XX技能。所以有人以为我遇到了反对意见会很生气到跳脚，那是误会。恰恰相反，我会很高兴。这是证明差距的最好的证据了，我乐都来不及呢！
而有能力对我所有文章所有观点证伪的最有力的一击是，比如某位烟台方法的学员，在阅读了我的资料或者讲座教程后，跳出来反水，证明我文章所述是空话，我自己都没能实现的技能，自己先在文章中吹牛逼了。
有没有这种可能？是不是有人很期待这种情况的发生？
别闹了， 我写这些文章，更大的用处在于帮助烟台方法的学员学习理解和提高。他们通过学习我给的例程，我写的书， 毕竟所涵盖的行业范围还是有限，有时候一些细节没能提及，那么通过这些小短文，可以给他们多重印证的机会。
而外人不知道的是， 在学员群中，经常有学员不堪忍受所在的公司所在的行业，被逼迫使用一些所谓的行业模板框架，而被其中海量的多层嵌套的UDT给恶心到，或者为了读垃圾程序被交叉索引给绕到头晕，跑学员群中发牢骚发泄，然后其他学员们在同情的同时，发出不怀好意的笑声。
审核编辑：黄飞
工商网监
评论