0826【万泉河】生产节拍是如何与OB1周期搭上关系的？

双线圈，起保停，OB1周期，我所探讨的PLC编程中的话题越来越基础， 读者群体出现了明显的两极分化， 一部分认为我闲着没事做，搞的水准越来越低。 而另一部分则认为我在这些话题中表达的观点有太多错误，他们不能接受。

其实不能接受可以理解， 也确实真实存在。 但其实问题出在他们自己。 我做的这些文章， 都经历过我前些年项目应用的实践考验， 无非我近来把这些思想汇总总结，上升到理论而已。 错是不会有的， 如果有错， 所生产的设备， 设备养的猪， 早就受不了了。轮不到后知后觉到现在。

所以也从另一个侧面回应了那些指责水准低的同行，如果水准低， 所有人一眼都懂的常识，那么就不会有那么多争论。当然有一些心怀叵测的坏人除外。所以， 如果认为这些话题技术水准低， 那更应该站出来发表公正的观点， 以正视听。

前面一篇文章《0819 【万泉河】PLC的OB1循环周期时间有多重要？》其中主要的观点，假设在OB1周期正常设计的60ms基础上增加了0.4ms，即周期增加不到1%的情况下，对设备的生产效率影响微乎其微， 我甚至都不愿意去算计这个数量级， 而直接宣布为0.

我也举了例子， 假设汽车厂生产线的OB1提升一倍， 会不会导致汽车产量提升一倍？这回同行进步比较明显，没有反驳的了。

不过，有好几个人不同的渠道提出了反对意见，不是汽车，而是口罩机。 举例说以口罩机的生产节拍， OB1周期就是要影响到。

有一位叫做@葉贰 的网友的回复：

扫描周期差一点还真能体现设备好不好。

假设就口罩机，焊接耳带，一个PLC平均扫描周期100ms，一个plc平均扫描周期50ms，皮带传输口罩要5s，一天160个口罩的差额就出来了，效率就是钱。

编程效率确实是应该追求的，但是为客户创造价值才是自动化编程的主要目的，你的程序运行效率比别人低，你的编程效率就会是笑话。

这其中表达有点语焉不详。 我就有点晕头。 所以转去询问了一番烟台方法的学员， 其中不乏有亲自做过口罩机设备的。

针对这位的观点，我首先回复的是，我们提高编程效率的程序， 只需要占用不到1%的时间，而不会把你原本50ms的时间拉大到100ms。 所以如果你两套程序运行周期差别那么大， 大到都影响了设备的生产效率， 那一定是程序的控制原理错了。甚至有可能两套都错的。

烟台方法学员帮分析的这个网友同行的观点，说的可能是当生产节拍在秒级的情况下，OB1周期长短导致的感应到检测信号的时间有迟到的可能， 执行元件的执行也有滞后的可能，综合起来有可能会导致动作比正常慢一个周期， 那么当OB1周期跟节拍的占比越大的时候， 影响就越严重。

我做了下数学题，假设楼上那位讲的5S是生产节拍的话， 那么分别按照5.05S和5.1S计算一天内的生产周期数：

86400/5.05=17108

86400/5.1=16941

两者相差-166。符合楼上说的数据了。

原来如此！

那么，我要跟这位说的是，如果100ms与50ms的周期差距导致了产量差距的话， 那么你凭什么就认为这个50ms的程序是合理的呢？为什么就不应该提高到10ms甚至5ms呢？

假设5ms，计算产量为：

86400/5.005=17262，比50ms的时候又增加了155。这也是钱啊！仍然不可忽略啊。

所以，可以断定，前面的50ms的程序仍然不是最优的。 甚至有可能系统程序逻辑设计从一开始就是错的。

对于生产节拍达到秒级， 甚至秒级以下下， 比如到100ms级别甚至更低的控制逻辑，在系统方案设计阶段，就已经要充分考虑到这个特性，对每一个细节事先进行规划，优化设计。 而不应该把运行结果过度依赖到PLC的OB1周期上， 甚至因为PLC系统增加了什么控制功能负担加重， 而影响到了生产本身。

其实， PLC系统，从祖宗一代开始， 这些问题就早就充分考虑到了。 任何PLC品牌， 指令集里面都有中断，直接读取外设， 直接输出到外设这样的指令。 做啥用的？就是为了快速处理这种快速响应需求的应用场合。

就是，尽管PLC系统中不存在多线程的机制，但你完全可以通过自己搭建程序逻辑，做出远比OB1周期快得多的一套快速处理线程。

比如，检测位置的光电信号应该接入到具有中断功能的特殊输入点， 上升沿触发中断，然后进行计算， 延时等待，条件具备后输出并立即输出， 通常是气缸类动作元件，执行响应的执行动作。

其中的延时，有可能还分两部分， 一部分其实是距离，即编码器脉冲的高速计数，对应固定的距离，而另一部分才是真正的时间， 补偿的是动作元件的执行滞后时间。

所以，从条件触发中断，到动作执行，中间是有延时时间的。通常是满足机械结构功能而设计的距离和时间。需要快一点的时候， 把延时及距离调节小一点， 需要慢一点的时候，则分别调节大一点。但都不可能为0。所以这个时间也并不是越快越好。因为如果为0 ， 都不需要进PLC系统了， 直接硬线导通动作就是了。

所以其实， 中断处理与动作执行之间，快速响应也并不是硬性需求。 本质上来说，需要的是时间的确定性，即在触发和动作之间，时间时机是确定的可控的。 目的便是抵消OB1运行中触发周期要么前一个周期要么后一个周期这种不确定性。 以及不同CPU， 主频不同导致的OB1周期不同而带来的波动。

上述最后一段，是我个人总结的对中断机制的观点， 从未与同行沟通确认过。 有兴趣的同行可以私下沟通详细探讨。

最后讲一个亲身经历的OB1周期影响生产节拍的故事。只不过关系次序是倒过来的。

我在西门子工作期间，接到一个客户的案子，那一年， S7-200出了新机型， CPU的性能比上一版本有了较大的提升。 然后，就有客户反馈，他们的OEM设备在用了新CPU之后不能用了， 跑不起来了。

我到现场之后， 看到是一台XX成型机设备，其中有设计的学习示教功能，即人工先模拟示教， 定型之后机器自动运转实现刚才示教的动作。 看了前面工程师做的程序，其中逻辑功能没看懂。 但很明显，是在调试过程中一点点凑出来的！

在旧的CPU的时候OB1周期100ms，可以运行很好。 而换新CPU 之后， 同样功能执行时间缩短到了10ms， 然后整个估凑的算法就失灵了。

我因为不太懂其设备运行原理，就给简单处理了一下， 直接加了100ms的时间中断，把她原来的程序全部挪到这个时间中断里跑， 功能很快就正常了。

这个客户是一家老国企， 其后没几年， 企业倒闭了。而在倒闭之前，许多员工携带核心技术资料到处创业， 使用的都是这套设备的原装程序和设计。 我在之后十多年，又在另外的场合遇到了这套设备和这套程序。看到了我在其中给贡献的垃圾补丁。他们整个行业的人也还一直记得我，知道我给动过。

总结：不管是举例的成型机， 还是网友回馈的口罩机，如果发现OB1周期会影响生产节拍和生产效率，那么首先自查，系统设计方案设计方法有可能是错了。

你或许可以通过拼凑，临时搭建出一套可用的程序，但这套程序方法是健壮性严重不足的，而是先天带有缺陷。会成为定时炸弹，未来随时可能引爆。

所以，回到题目的最开始， 如果你的程序本身是合理的健壮的，我帮你在实现标准化架构中增加的代码导致0B1周期增加不到1%的情况下， 对产量的影响， 仍然是0。