系列帖前言：    

为了响应1847的号召。今天跟大家分享一个我的《工作笔记》。这个工作笔记主要探讨PTP自由口通讯。

    不知道诸位同仁有没有这样的感觉，我们自己做PTP通讯时发现通讯正常，但是过一段时间通讯又不正常了。由于通讯程序中的信号大多只维持一个扫描周期，所以即使经过很长时间的查找，又很难找到程序到底哪里有问题。我做PTP程序比较多，我是有这样的感受。于是我为了调试PTP程序，干脆做了日志，记录每个收发，记录每个需要发送的位置的事件。通过日志中事件发生的先后顺序用以推断、猜测程序到底哪里出了问题。本篇重点不在如何做日志，当然，如果诸位同仁有兴趣，我也可以单独写一篇如何在复杂通讯程序中做日志。

        在查看日志的过程中，我发现我的通讯程序有诸多bug。其中之一就是今天要写的主题。除此以外，还有至少4篇笔记也是属于这个系列的。分别是

《通讯中的AA》、《通讯中的轮询》、《通讯编程的层次》、《通讯编程要注意容错》。在编程通讯代码的时候，如果能注意这5个点，那么PTP自由口编程将会无往不利。

    另外，我给PLC编程很多年了。我个人觉得，PLC编程有2个难点，一个就是较复杂的通讯。另外一个就是较复杂的MC编程。这2类编程有个特点，就是信号变化的特别快，靠肉眼观察信号的变化调试程序是不可能的。这个特点在通讯的编程里面尤其突出。

    较复杂的意思就是比如让你编一个类似PROFINET主站的程序。而不是去用西门子已经固化在CPU网口的PN协议。有人会问，我们会遇到 这么复杂的通讯编程吗？会的。一些复杂的设备的确需要复杂的通讯，才能控制好这类设备。复杂的通讯程序有一些固定套路。本系列帖就是探讨这些套路的。懂得这些套路后，再面对难度不高的编程时，就会得心应手。所以这也是我为什么把通讯单拿出来与大家分享如何编程的原因。下面我们就开启头脑风暴之旅。

第一篇正文

    一个好的稳定的通讯代码需要在编程过程中多方面的注意。今天先说说发送块的问题。

图  1

    上图是我犯的众多错误中总结的原则之一。这个原则就是：

    复位发送信号（INTF_AA.Req_Send）必须在调用发送块的前面。

    我之后编写的不管是简单的PTP程序还是复杂的PTP程序都遵循这一原则。以太网通讯程序同样需要遵循这个原则。

    这里要强调的是，如果不遵循这一原则，我们的PTP程序不一定会出错。但是如果我们的PTP程序有些复杂，那么一定会在某个我们不可预知的时刻出现错误。

    在这里我先不说明为什么要遵循这一原则。诸位同仁可以在此讨论，说说你们的观点。最后我会把答案揭示。

    当然编程复杂的PTP程序还有其他原则需要遵守，我也希望其他同仁可以撰写笔记，甚至进行讨论。如果有时间，我后续也会把其他一些原则，以及这些原则产生的原因分享。

    如果你觉得本次讨论对你有帮助，请点击“有帮助”。你的支持是我的分享的动力。