发表于：2021/12/18 18:09:16
#0楼
【万泉河】辟谣一个一直以来的所谓的高效编程方式：IO映射
一直以来， 同行之中一直流传着这样一个所谓的高效编程的方式：IO映射。
何为IO映射？
即说的是，PLC的主程序中不要直接使用物理的I和O地址，而是在OB1程序的开始和结束，分别做一个批量映射，在开始时把I信号批量复制到中间寄存器或者全局DB中， 而在结束时，则对应的把另一个表征输出的全局DB的数据或寄存器区域的数据批量拷贝到O地址区。
有什么优点？
传说优点是可以保证程序中所有的I/O物理地址只使用1次， 如果卡件的单个通道坏了，可以直接把映射表改一下，既可以更换到另一个备用通道，而主程序逻辑可以丝毫不需要改动。
比如如果正常程序， 一个%I0.0在整个程序中用了100次，就不需要逐个修改了， 只需要在映射部分改一下即可。
100次有些夸张，但也绝非不可能。比如上篇文章中提问者问及的灯检查按钮， 如果按照传统的黑虎掏心式的程序写法， 一个指示灯用一次，那100个设备的100个指示灯，果然就需要100次。
熟知这个经验方法的同行应该不在少数， 而且因为简单易表达，所以很多熟手就特别愿意作为一种宝贵经验分享给同行。
而接受分享经验的一方，如果是初入门，就会被洗脑认为是行业的标准姿势，尤其是如果再有机会见到一些前辈同行的项目程序资料，也会先入为主了。
而如果是已经养成自己一套编程习惯的工程师，如果没有从这个经验方法中发掘到认同的优点，也不会去强烈反驳，只需要自己默默地继续我行我素，不予理会即可。因为毕竟对方是好心好意地经验分享，你不接受就罢了，还跟人吵架争论就显得不知好歹了。
由此，从来只有传播的，没有阻断的，导致这个传闻越来越广， 简直快要成为行业标准了。
甚至还发展出一些实现IO映射的高级技能技巧干货。
比如， 昨天，就有人在微信群中分享了一篇文章。
西门子SCL语言：5句代码完成IO映射的功能
https://mp.weixin.qq.com/s/BSa3U5LL8Zf5ftFzd3n1Lw
为了尊重其文章版权，我尽量原汁原文引用其图片：
https://mmbiz.qpic.cn/mmbiz_png/RsvL41ewpMn3dy4PQcvUUjwTMiagbZIZyq0lgZEgdE29Ze55QO3gprs0phgFwMgDJqn3rYZV8C57WKBJlGYm4XQ/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1
其文章的核心内容是用PEEK/POKE指令，做了个循环，批量式地实现了IO映射。
随后我们在微信群中进行了简单讨论，反对者居多数，支持者态度也不明显。 我就不直接引用原话了。
我给出的质疑是，如果真的发生了I/O通道替换，应该怎么做？
毕竟， 既然你做的目的是这个，它就当然会发生。 否则你岂不是白忙活了嘛？
好像也没有什么更好的答案。 只能是在循环之后再多一句指令，打一个补丁：
比方原本是把%I0.0 映射到了数据块符号定义的地址：DI_DB.DI00，现在物理通道改为了%I31.7，则为：
DI_DB.DI00:=%I31.7;
即， 在循环逻辑中对DI_DB.DI00做了一次赋值，然而紧随其后，又再次赋值，按照先后理论，后一次的值才是真值，程序中可以正常运行了。
然而，如果真的发生IO通道坏而不想更换卡件，要换IO点的话，如果没做过IO映射，该怎么处理呢？
也同样打一句补丁即可，只需在程序的最开始增加：
%I0.0 :=%I31.7;
在PLC中，I和Q原本就不是简单的电气通道，而是个寄存器，无非是PLC底层系统，在循环的每个周期，把电气信号转换为数值之后，对应到了寄存器中。 而如果你程序中某个位置对这个寄存器的值进行了修改，那么随后的程序中，程序执行时采用的就是新值，而不再是原本的电气信号的值了。
所以，我猜那些大力宣扬IO映射方法的工程师，大概是不知道这一基础知识点的吧？
下面是我对IO映射方法本身的抨击：
首先， 如果是设备程序的提供者， 你交给甲方的设备，你忍心卡件是带病的，有坏通道的吗？甲方会同意接收吗？
其次， 如果是设备的运行维护，设备运行过程中卡件的某个通道坏了，你们不舍得更换整个卡件，而是通过修改程序来对付， 那么你们的程序版本准备如何管理？能把修改后的程序称作最新程序吗，如果运行时间久了，卡件的坏通道越来越多， 终于打算整体更换的时候怎么改，再改回来吗，还是坏的通道的位置就继续废弃下去了？
而如果做IO映射的目的是为了在不同的项目中， IO地址变换了，老的程序仍然可用，只改映射部分，那么除了第一次的程序，映射规则非常整齐甚至可以用循环来实现，后来的项目，更改的部分要对应做正确映射，手工处理之复杂，烧脑，简直是个灾难。大家可以脑补换掉其中的1/3通道的地址试一下。
再者，IO映射过程中符号表的定义也是个大问题。 原本整理符号表都是一个比较大的工作量，再多一个映射表，相当于工作量翻倍。
而在调试时，除非自己能把映射关系倒背如流，否则就需要不断地在主程序和映射程序之间跳转监控，调试的工作量也翻倍了。
当然， 我全文说的是传统的编程方法。因为我知道大家如何做的，也见过无数这样的程序。 所有这些与烟台方法无关。
在讲述烟台方法的文章中，我有描述过我们的程序中IO地址只用一次，但那是结果，而不是出发点。 通过烟台方法实现的标准程序，自然而然的不需要IO地址多次调用，即便想重复使用的机会都没有。或者说如果多次使用了，就是方法错了。 每个人自己知道自己程序结构哪里没处理好，工艺解耦不彻底。
当然啦， 我说这些其实与烟台方法无关，对标准化学习营的学员，并没有什么指导意义。 所以，如果有人对我此文的观点不认可的话， 仍然要坚持自己的方法和原则的话， 那我只需要你了解到2件事：
一，这个行业里有人是反对做IO映射的；
二，PLC编程烟台方法没有用到IO映射。
同时也奉劝一些初学者擦亮眼睛，学会独立思考，不要人云亦云， 不要轻易被带偏。这个行业一方面门槛没那么高，好多看起来高大上难度极高的知识其实是没必要会的，网上充斥了太多的无用的知识。 另一方面这个行业技术发展又太慢，真要只靠网罗现成的干货资料，特别是指望通过淘宝几块钱买几个G的资料自己就能练成高手的，几无可能。
最后再补充一点， 这里引用的程序用到了PEEK/POKE， 这是相当难的指令了，在大部分新手眼里是个极高的门槛，而我要告诉大家的是，这两个指令我从来没用过，也实在发掘不出需要使用它们的场合。 或许我做的都是常规应用， 还没机会遇到更高级别的应用吧！有同行真正用到躲不开不得不用的场合，请教给我。
所以，大家还可以了解到第3点：
三，PLC编程烟台方法没有用到PEEK/POKE。
一直以来， 同行之中一直流传着这样一个所谓的高效编程的方式：IO映射。
何为IO映射？
即说的是，PLC的主程序中不要直接使用物理的I和O地址，而是在OB1程序的开始和结束，分别做一个批量映射，在开始时把I信号批量复制到中间寄存器或者全局DB中， 而在结束时，则对应的把另一个表征输出的全局DB的数据或寄存器区域的数据批量拷贝到O地址区。
有什么优点？
传说优点是可以保证程序中所有的I/O物理地址只使用1次， 如果卡件的单个通道坏了，可以直接把映射表改一下，既可以更换到另一个备用通道，而主程序逻辑可以丝毫不需要改动。
比如如果正常程序， 一个%I0.0在整个程序中用了100次，就不需要逐个修改了， 只需要在映射部分改一下即可。
100次有些夸张，但也绝非不可能。比如上篇文章中提问者问及的灯检查按钮， 如果按照传统的黑虎掏心式的程序写法， 一个指示灯用一次，那100个设备的100个指示灯，果然就需要100次。
熟知这个经验方法的同行应该不在少数， 而且因为简单易表达，所以很多熟手就特别愿意作为一种宝贵经验分享给同行。
而接受分享经验的一方，如果是初入门，就会被洗脑认为是行业的标准姿势，尤其是如果再有机会见到一些前辈同行的项目程序资料，也会先入为主了。
而如果是已经养成自己一套编程习惯的工程师，如果没有从这个经验方法中发掘到认同的优点，也不会去强烈反驳，只需要自己默默地继续我行我素，不予理会即可。因为毕竟对方是好心好意地经验分享，你不接受就罢了，还跟人吵架争论就显得不知好歹了。
由此，从来只有传播的，没有阻断的，导致这个传闻越来越广， 简直快要成为行业标准了。
甚至还发展出一些实现IO映射的高级技能技巧干货。
比如， 昨天，就有人在微信群中分享了一篇文章。
西门子SCL语言：5句代码完成IO映射的功能
https://mp.weixin.qq.com/s/BSa3U5LL8Zf5ftFzd3n1Lw
为了尊重其文章版权，我尽量原汁原文引用其图片：
https://mmbiz.qpic.cn/mmbiz_png/RsvL41ewpMn3dy4PQcvUUjwTMiagbZIZyq0lgZEgdE29Ze55QO3gprs0phgFwMgDJqn3rYZV8C57WKBJlGYm4XQ/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1
其文章的核心内容是用PEEK/POKE指令，做了个循环，批量式地实现了IO映射。
随后我们在微信群中进行了简单讨论，反对者居多数，支持者态度也不明显。 我就不直接引用原话了。
我给出的质疑是，如果真的发生了I/O通道替换，应该怎么做？
毕竟， 既然你做的目的是这个，它就当然会发生。 否则你岂不是白忙活了嘛？
好像也没有什么更好的答案。 只能是在循环之后再多一句指令，打一个补丁：
比方原本是把%I0.0 映射到了数据块符号定义的地址：DI_DB.DI00，现在物理通道改为了%I31.7，则为：
DI_DB.DI00:=%I31.7;
即， 在循环逻辑中对DI_DB.DI00做了一次赋值，然而紧随其后，又再次赋值，按照先后理论，后一次的值才是真值，程序中可以正常运行了。
然而，如果真的发生IO通道坏而不想更换卡件，要换IO点的话，如果没做过IO映射，该怎么处理呢？
也同样打一句补丁即可，只需在程序的最开始增加：
%I0.0 :=%I31.7;
在PLC中，I和Q原本就不是简单的电气通道，而是个寄存器，无非是PLC底层系统，在循环的每个周期，把电气信号转换为数值之后，对应到了寄存器中。 而如果你程序中某个位置对这个寄存器的值进行了修改，那么随后的程序中，程序执行时采用的就是新值，而不再是原本的电气信号的值了。
所以，我猜那些大力宣扬IO映射方法的工程师，大概是不知道这一基础知识点的吧？
下面是我对IO映射方法本身的抨击：
首先， 如果是设备程序的提供者， 你交给甲方的设备，你忍心卡件是带病的，有坏通道的吗？甲方会同意接收吗？
其次， 如果是设备的运行维护，设备运行过程中卡件的某个通道坏了，你们不舍得更换整个卡件，而是通过修改程序来对付， 那么你们的程序版本准备如何管理？能把修改后的程序称作最新程序吗，如果运行时间久了，卡件的坏通道越来越多， 终于打算整体更换的时候怎么改，再改回来吗，还是坏的通道的位置就继续废弃下去了？
而如果做IO映射的目的是为了在不同的项目中， IO地址变换了，老的程序仍然可用，只改映射部分，那么除了第一次的程序，映射规则非常整齐甚至可以用循环来实现，后来的项目，更改的部分要对应做正确映射，手工处理之复杂，烧脑，简直是个灾难。大家可以脑补换掉其中的1/3通道的地址试一下。
再者，IO映射过程中符号表的定义也是个大问题。 原本整理符号表都是一个比较大的工作量，再多一个映射表，相当于工作量翻倍。
而在调试时，除非自己能把映射关系倒背如流，否则就需要不断地在主程序和映射程序之间跳转监控，调试的工作量也翻倍了。
当然， 我全文说的是传统的编程方法。因为我知道大家如何做的，也见过无数这样的程序。 所有这些与烟台方法无关。
在讲述烟台方法的文章中，我有描述过我们的程序中IO地址只用一次，但那是结果，而不是出发点。 通过烟台方法实现的标准程序，自然而然的不需要IO地址多次调用，即便想重复使用的机会都没有。或者说如果多次使用了，就是方法错了。 每个人自己知道自己程序结构哪里没处理好，工艺解耦不彻底。
当然啦， 我说这些其实与烟台方法无关，对标准化学习营的学员，并没有什么指导意义。 所以，如果有人对我此文的观点不认可的话， 仍然要坚持自己的方法和原则的话， 那我只需要你了解到2件事：
一，这个行业里有人是反对做IO映射的；
二，PLC编程烟台方法没有用到IO映射。
同时也奉劝一些初学者擦亮眼睛，学会独立思考，不要人云亦云， 不要轻易被带偏。这个行业一方面门槛没那么高，好多看起来高大上难度极高的知识其实是没必要会的，网上充斥了太多的无用的知识。 另一方面这个行业技术发展又太慢，真要只靠网罗现成的干货资料，特别是指望通过淘宝几块钱买几个G的资料自己就能练成高手的，几无可能。
最后再补充一点， 这里引用的程序用到了PEEK/POKE， 这是相当难的指令了，在大部分新手眼里是个极高的门槛，而我要告诉大家的是，这两个指令我从来没用过，也实在发掘不出需要使用它们的场合。 或许我做的都是常规应用， 还没机会遇到更高级别的应用吧！有同行真正用到躲不开不得不用的场合，请教给我。
所以，大家还可以了解到第3点：
三，PLC编程烟台方法没有用到PEEK/POKE。
PLC标准化编程
