西门子S7-200EM232CN模块

西门子S7-200EM232CN模块

        初步的试验所得出的结论，让我看到一丝曙光，然而就像黎明前总是伴随着黑暗，接一下来的一系列问题让我有些不知所措。

        在使用PUT/GET编程的时候，我想每一个工程师都会读一读在线帮助或者程序手册，去了解这两个功能块如何编程，尤其故障代码的含义。而阅读手册的时候，我又顺便了解BSEND/BRECV，以及USEND/URECV，这时候我会纠结这些功能块到底有什么区别？

        按照手册，BSEND/BRECV通信要建立连接，而USEND/URECV是*建立连接的，那么S7到底是什么妖魔鬼怪？一个协议可以随着心意变化，而不是固定的协议交换模式，这是个使我百思不得其解的地方。那么手册中所提到的S7协议，不是单一协议吧？也就是说BSEND/BRECV，USEND/URECV以及PUT/GET使用不同的S7协议，虽然它们都叫做S7协议。那么要如何测试呢？作为西门子的私有协议，如何找到答案呢？

        S7的PUT/GET Server侧，是不需要编写任何功能块的，而 BSEND/BRECV，以及USEND/URECV双方都是编写功能块的，那么PUT/GET Server侧不编程就可以实现通信是如何做到的呢？又是谁帮助它实现了S7的数据交换呢？

        因为300PLC手册中提到此通信发生在CCP，而此时400PLC作为客户端，编写的GET接收数据，是不是发生在时间片？因为手册中已经提到CPU循环周期的AP部分由若干时间片组成，而GET是编写在AP中的，那么400PLC中的GET的通信必然发生在时间片？可以肯定吗？

        如果300PLC侧接收数据，那么400PLC侧需要使用PUT指令来发送数据，在Wireshark中所看见的就是400PLC侧发出的S7报文，由300PLC接收，在300PLC内部是何时接收的，在哪里接收到的呢？如何证明300PLC是在CCP接收数据呢？那又如何证明400PLC使用PUT指令进行的通信发生在时间片呢？

        上述这些问题都是源于那个通信负荷默认20%的CPU属性这个参数，那么是针对所有该PLC的通信服务吗？根据手册，这个参数至少对于CCP产生的通信应该是无效的，尽管手册中的只言片语，通过上面的试验也可以确定CCP自成一体。那么除了AP，和CCP，CPU的整个循环周期时间就剩下PII和PIQ了。而PII和PIQ是在每一个循环周期开始刷新，用于IO数据刷新，保证数据一致性，那么20%只能作用AP吧？那它能影响哪些通信服务呢？西门子PLC推出了那么多的通信服务，例如TCP/IP，PROFINET IO等等受20%的参数控制吗？如果控制，那又如何作用呢？参数的大小调整会对通信服务产生什么样的影响呢？

        反复研读手册，手册会提到通信的地方，必然会提及数据一致性这个概念，那么数据一致性的真正意义是什么？什么时候需要注意呢？又如何注意呢？手册常常提到通信PLC可以保证具有一定的数据一致性长度，例如TCP的一致性是8K，为什么？为什么会有这样的限制？300PLC的S7通信常常会提到240字节的数据一致性，而S7 PDU也是240个字节，它们之间又有什么关联呢？

   PROFINET就像是我的亲密伙伴，因为在西门子，他的面市和我的入职几乎是同时开始的，我们是一起成长的。初的PN产品，例如ET200S只有一个PN端口，只能支持RT，设备连接只能通过交换机。初的我，是技术支持团队的一个新人，是网络通信的一个菜鸟，完全不懂通信理论。然而放在同事桌子上的PROFINET培训文档，吸引着我让我随手翻开，像是冥冥中注定，他和我注定在我的职业生涯中深深的纠缠在一起。我们也相互的成就着，通过我的努力，他给我们中国客户的生产带来了翻天覆地的变化，通过他的发展，也给我的职业生涯带来了深远的影响，那么他有什么奇妙之处呢？

      首先，在技术上，PROFINET基于以太网，也就是由于以太网，使之能够具有快速的通信速度和灵活的拓扑结构，而PN就是以太网上的实时协议集合，就和TCP是以太网的协议一样，**而已。但是这对于企业生产就不同了，因为在PN之前，以太网是不能延伸到现场级的，而如今以太网一直延伸到现场的末端，带有PN接口的传感器和执行器比比皆是。以太网的安装确实给用户带来了诸多的便利，然而，由于用户大都想着就近连接交换机即可，这种可能导致混乱的连接拓扑，还有就是交换机产品的选择，错误的选择同样会给用户生产带来一些问题，这两个看似很小的问题，却可能会给企业生产带来毁灭性的伤害。

      早年去一家钢厂，骨干网使用了冗余环网，正常生产了一段时间，却突然全网瘫痪，导致高炉停产，对于钢厂来说这是一个非常大的事故了。而现场的问题解决却是很简单，原因是冗余环网使用了西门子的SCALANCE X交换机，然而冗余管理器RM却使用了第三方的交换机，那我还说什么呢？前些天，去了另外一家钢管厂去做预维护，询问网络的拓扑连接是如何的，回答是不知，这是中国用户目前普遍存在的问题。通过PRONATA进行现场网络拓扑的扫描，竟然发现网络拓扑出现两个环网，而且是现场级的，也不知什么原因鬼使神差的让生产可以正常进行，我们知道环网会产生广播风暴，导致全网瘫痪。可是由于生产还在继续，我们无法确定真正的原因是什么，只能告诉用户这种环型链接风险较高，需要尽快整改。

      其次，对于PROFINET RT通信，我想这是中国用户常用的PN协议，因为配置简单，只要用过PROFIBUS DP就能做很快的转换。然而用户往往会有两个问题，一个是不清楚如何选择交换机，选择的依据是什么？另一个是不清楚分布式IO多能串联多少个，级联深度的依据是什么？

      对于个问题，我给用户传达的信息就是只要是交换机都支持PROFINET，然而并不是所有的交换机都适用，这种前后矛盾的话，大家肯定会觉得疑惑不解。PROFINET使用百兆全双工的技术，那么交换机必然是选择的连接部件，而我们在使用PN RT协议的时候，都知道RT通信的报文是带有**级的，也就是含有**级是6（高为7）的VLAN标签（其ID=0），这个标签使之PN数据在网络链路传输时可以“横行霸道”，因为除了MRP冗余环网之外的网络链路上的数据没有**级比它高的，其它数据难以望其项背，这样才能大程度的保证它的实时性。那么如果你选择了例如SCALANCE X300/400系列的交换机用来连接IO设备，那么VLAN标签的**级的意义就消失了，因为这些交换机默认支持VLAN，而这些交换机恰恰判定VLAN ID=0的数据没有**级，也就是说此时的PN数据只能和普通数据一样，不再被**转发，这意味就显而易见了。*二个问题，可能是困扰大家多的问题，因为它影响现场到底如何安装布线。到底能级联多少？我的答案就是能带多少IO设备就能级联多少IO设备？然而我们需要考虑线型网络末端的IO设备的刷新时间的大小，这就需要一个公式了，也就是说一个IO报文从PLC侧发出，经过若干台交换机，这些交换机是支持C&T或是S&F，那么这个公式就是报文的传输时间，加上经过各个交换机的延迟时间，达到终的设备。这个时间才是你参考的Update time的时间，如果不能满足你的实时性要求，那么这台设备需要在线型拓扑中靠近PLC，也就是你的IO控制器。  

      后，我想谈的就是PROFINET网络如何诊断了，这个是用户经常忽略或者无法正视的问题，因为一旦谈到诊断，那么必然需要全面的IT知识，不像前面所描述的，仅是需要组态和计算，从基本的Ping指令到Wireshark的使用，这些都是*的。但这些往往是用户缺乏的。具体诊断PN网络的方式有很多种，那是根据不同的故障现象采取不同的方法。这里和大家谈谈用户所面临的经常丢站的故障。

      丢站的根本原因就是IO数据没有在时间内出现，也就是**时了，这时会报丢站，OB86被激活。那么什么原因会导致IO数据在时间内不能出现，主要是两种原因，种就是网络拥堵严重，数据不能在时间内到达IO设备，那么这种情况使用Ping指令就可以来判断网络链路的状态；*二种就是数据发生畸变，可能是由于干扰或者安装的线缆短路所致，也就是IO报文的CRC检验出现错误，这种情况可以通过Step7在线查看分布式IO的端口的Statistics或者登陆管理型交换机的网页查看丢站IO设备所对应的端口的Statistics，再或者对于S7-1500来说使用LPNDR功能块来读取对应IO设备的端口的Statistics，来查看是否存在CRC错误。如果存在CRC错误，那么导致的原因就是前面我说的两种原因，干扰或者短路造成的，那么就去查EMC和线缆的状况。当然，Wireshark工具是诊断PN网络的重要的工具，当你具备IT知识的时候，建议你使用Wireshark这个工具去检测和发现网络故障，因为它是良好利器。

       关于PROFINET技术，其实它包罗万象，涉及各种IT知识，当你想理解它时，你就需要理解终端设备，例如：PLC和分布式IO，其实西门子PLC通信原理也是来源于我对PN的研究，然后理解TCP协议，路由协议等等，也就是这一根绿色的网线使我在技术上越走越远，越走越宽。这里我仅仅提到了PROFINET技术的冰山一角，深奥的理论主要集中在IRT上面，需要对其设备集成的交换机内部要有全面的理解，因为IRT需要对时，各个时间片段的计算是非常关键的，在这里我无法一一的给大家说明。而现在由我的同事，网络*冯学卫先生正在网上论坛主持PROFINET通信探秘技术π的活动，他是一位非常的工程师，对于IT和各种网络协议都非常的了解，我们经常在一起讨论关于网络，PN，通信的各种问题，对各种技术细节进行深入的剖析，例如Step7中IO RT的时间预留后台是如何计算的等等。大家如果想

S7-200的子程序SUB，一旦写好，用在程序中之后， 是不可以修改其输入输出管脚的。 因为你一旦动了管脚接口，调用这个子程序的地方，就会报错。报错以后还没法和STEP7一样可以通过更新只更新改动部分。

正常处理的只有把原本的调用删掉， 从头重新调用，并为每个接口逐个分配变量。

这相当讨厌。

比方说我一个底层的设备，如果调试中发现需要增加些功能，实在不可避免决定要增加接口。而我主程序中已经对这个设备调用了几十次， 那就必须几十个实例都重来一遍。

而这还不算完。

谁敢保证这一次接口的变更就是后一次了呢？下一次如果还需要修改，就需要原样再来一次。

估计换谁， 都受不了这种折腾。

而这也是标准化编程的大忌。

貌似许多人对标准二字有误解，看到我提出的标准化，就有些不服气。你万某有何德何能提出标准，俺们智力才艺都不比你差，凭什么要遵循你提出的标准，凭什么用你的标准而不是我自己的标准？我们国家历史上因为技术标准落后一步而受制于人，吃的亏大了去了。可不能重蹈这样的覆辙！

而另外有一些人，则强调没有办法做到整齐划一的标准。理由是设备配置千差万别，没有一模一样的设备， 所以做不到标准化。

错啦！都是属于对标准化的误解。 我们追求的标准化，是把系统做成搭积木一样的标准模块，每个模块自成体系，逻辑互不干扰。 通过接口与其他系统模块对接，不同的系统设计， 在接口不变的情况下，只需要更换相应的模块，即可以实现快速组装。

而接口，也不是一尘不变的，可以根据需要随时改进，而在接口改动的时候，也只是对接的模块之间局部变更， 不要影响到整个系统。 不会因为接口的改动，而需要系统重新调试。

甚至，我现在推广了二期标准化示例项目之后，下一步的计划就是对接口的优化升级。过去，我在开发阶段，采用的接口只是借用的别人以前做的， 现在终于有精力，腾出手来，把接口改造为我满意的样子。

而我和我的团队成员，丝毫不需要担心接口的更改会导致影响到已有逻辑模块的运行， 甚至带来bug。

这就是标准化设计的优势。心不累。不需要和以**样，程序中改动一点点就紧张万分，就担心把整个系统原本正常运行的功能搞崩溃。  

所以，我在开发SMART 200标准化架构的时候，首先就意识到子程序（库函数）接口不能更改的这个问题很严重。并认为有可能是众多人都不愿意投入精力在SMART 200系统做标准化的主要原因。

所以首当其冲必须解决这个问题。