系列帖前言
不知道诸位同仁有没有这样的感觉，我们自己做通讯时发现通讯正常，但是过一段时间通讯又不正常了。由于通讯程序中的信号大多只维持一个扫描周期，所以即使经过很长时间的查找，又很难找到程序到底哪里有问题。我做通讯程序比较多，我是有这样的感受。于是为了调试通讯程序，干脆做了日志，记录每个收发，记录每个需要发送的位置的事件。下图就是一个通讯日志。
通过日志中事件发生的先后顺序用以推断、猜测程序到底哪里出了问题。本篇重点不在如何做日志，当然，如果诸位同仁有兴趣，我也可以单独写一篇如何在复杂通讯程序中做日志。
在查看日志的过程中，我发现我的通讯程序有诸多bug。其中之一就是今天要写的主题。
这个系列的文档除了这篇外，还有至少4篇也是属于这个系列的。分别是
《通讯中的AA》、《通讯中的轮询》、《通讯编程的层次》、《通讯编程要注意容错》。在编程通讯代码的时候，如果能注意这些问题，那么通讯编程将会无往不利。
这里的通讯可以是以太网通讯，也可以是自由编程的通讯。在很多层次上，道理是相通的。
本系列帖以SIEMENS的1200，1500PLC为背景进行讨论。
另外还想说，以我多年PLC编程经验，我有一个感受。PLC编程有2个难点，一个就是较复杂的通讯。另外一个就是较复杂的MC编程。这2类编程有个特点，就是信号变化的特别快，靠肉眼观察信号的变化调试程序是不可能的。这个特点在通讯的编程里面尤其突出。
较复杂的意思就是比如让你编一个简易的PROFINET主站的程序。而不是去用西门子已经固化在CPU网口的PN协议。有人会问，我们会遇到这么复杂的通讯编程吗？会的。一些复杂的设备的确需要复杂的通讯，才能控制好这类设备。复杂的通讯程序有一些固定套路。本系列帖就是探讨这些套路的。当我们对通讯程序的编写不再发怵了，那么对于那些相对简单的PLC编程自然手到擒来。所以这也是我为什么把通讯单拿出来与大家讨论的原因。下面我们就开启头脑风暴之旅。
第一篇正文
一个好的稳定的通讯代码需要在编程过程中多方面的注意。今天先说说发送块的问题。
图 1
上图是我犯的众多错误中总结的原则之一。这个原则就是：
复位发送信号（INTF_AA.Req_Send）必须在调用发送块的前面。
我之后编写的不管是简单的通讯程序还是复杂的通讯程序都遵循这一原则。以太网通讯程序同样需要遵循这个原则。
这里要强调的是，如果不遵循这一原则，我们的通讯程序不一定会出错。但是如果我们的通讯程序有些复杂，那么一定会在某个我们不可预知的时刻出现错误。
在这里我先不说明为什么要遵循这一原则。诸位同仁可以在此讨论，说说你的观点。最后我会把答案揭示。
当然编程通讯程序还有其他原则需要遵守，在后续的文档中陆续推出。
