0110 【万泉河】火星终会撞地球 点击:95 | 回复:0



万泉河

    
  • 精华:0帖
  • 求助:0帖
  • 帖子:74帖 | 62回
  • 年度积分:67
  • 历史总积分:413
  • 注册:2009年12月04日
发表于:2023-01-10 16:30:06
楼主

0110 【万泉河】火星终会撞地球

 

去年发表的一系列关于启保停和SR互换的文章中,讨论过关于把多个工艺模块相关的逻辑根据工艺模块分拆到各自模块中实现的方法。

 

最简单的举例是ANDON系统,如果每个工位 都有一个灯开关,其中任何一个工位需要灯亮的时候,都可以将灯点亮。

 

然后有人就不服,觉得简单取“或”确实容易实现,但难一点的需求就实现不了了。 所以给提出的要求是用双联开关来实现。 即任何一个工位, 切换开关的位置,即从01或者10,都要触发灯的点亮状态,原本为亮变为灭, 而原本为灭要变为亮。

 

这就是80工位例子的出处。 事实上我不仅仅实现了这种控制要求,而且一口气给做到了80个工位。

 

而这个要求在实际应用中是没有任何用处的。在工位大于2的情况下,不可能有人设计用双联开关来控制指示灯。 所以仅仅是一道逻辑题目而已。

 

而这个逻辑的实现中,有一个逻辑盲点。 反对者称为是漏洞。 即如果凑巧有2个工位的工人同时按动了按钮,会得到期望之外的运行结果。

 

这个凑巧要巧到什么程度?需要在OB1的同一个运行周期内触发。 即假设OB1的循环周期为10ms,两个人在互相不通气的情况下,遥相感应,同时在10ms精度的时间内动手操作,才能触发这种几率。

 

所以我打比方比火星撞地球的几率还小。

 

当然,并不是因为几率小而不去管它,而是,即便发生也无所谓的。 就好比你乘坐电梯,电梯内的人要操作按钮关门,而电梯外凑巧有人要开门,这种运行结果完全随机。而且对大家也都无所谓。 除非有人站在上帝视角告诉他们答案,你比对面的人先按了几个毫秒,而门没给你开,你吃亏了。 每个工位的人自己并不知道自己触发的时机早一点点还是晚一点点,因为他们都在自己黑盒子里,并不知道自己之外的其他工位的状态。

 

所以,在80工位的程序里面,对这种不重要的情况没有特别处理。

 

我也早就提前表示过了, 如果逻辑需要,那可以通过其它的逻辑方法补足,但不妨碍逻辑的模块化分布本身。 那是做标准化模块化的起点。

 

我因为一直没想过火星到底啥时候能撞地球,所以也没有去管它。然而,这个问题却最终又被我自己撞到了。

 

其实是一位烟台方法的学员。 他的设备中多套相同的工艺,即一个FB3个实例(将来还会拓展到4个,5个),其中有一台公用的泵,工艺中根据条件启动和停止。

 

然而,我到如今搞不懂他的工艺的是,启动停止的指令竟然是公用了一个硬件的按钮,而故障条件则来自每个工艺中的类似于压力高的故障信号。

 

即,按传统设计方法,工艺要求原本是耦合在一起的启保停逻辑:


 

而学员按照80例程给出的思路方法把逻辑拆到一个FB的三次调用后,则相当于如下的逻辑:


 

由于启动按钮是来自同一个DI信号,所以最终会发生的现象是,如果在压力1或者2不满足,而压力3满足的情况下,按动了启动按钮,那么最后设备输出会启动一次后立即停止。 而即便做了上升沿处理,也会产生一个周期的输出。

 

火星撞地球这样原本永远不会发生的小概率事件,在这里竟然莫名其妙的真的发生了。

 

学员来跟我请教的时候,我好长时间没搞明白需求。来回反复视频会议开了好几次,总算明白了他遇到的问题,总结简化为上面的逻辑。 而事实上的应用比这里总结的还要复杂。

 

学员自己的应对方法是对运行指令做一个滤波后再输出, 只要错过了一个脉冲周期,就不会再出错了。

 

而我开始给出的方法是,3个实例做成顺控,启动按钮依次发到3个实例中,只要不同时触发,则不会产生误动作了。

 

然而都不是最好的解决方案。

 

终极的解决方案是:启动和停止指令分开发送。

 

即,对设备块做二次封装或改造,把运行指令分开为启动指令和停止指令。

(其实原本设备就要有专用FB块处理,而不会直接发送到Q输出点,80例子只是演示逻辑本身,而没有涉及此方面)

 


 

启动指令为1时用于启动设备,而停止指令为0时用于停止设备。

而在设备输出之后,分别将启动指令清0和停止指令置1

 

而在设备块中的逻辑则为:


这样的逻辑可以支持模块化的多次调用,逻辑中既实现了停止指令的更高优先级处理,也实现了不同工艺块之间的指令取或逻辑,用于最终输出到设备。

 

总结:

烟台方法的所有处理都是为了模块化, 模块化才能带来标准化。 而具体的处理方法,要根据工艺需求的不同做出灵活处理。

 

不可以幻想一个逻辑,甚至一套程序块,就能包打天下,能兼容解决天下所有的逻辑需求可能性。

 

任何一个逻辑需求,只有自己遇到了,才有意义。如果自己的行业中永远用不到,那就没必要提前兼容,甚至提前做到自己设计的模块里。 除了增加系统负担,增加错误风险, 毫无益处。

 

同时我也很了解有一些同行思考问题的思维习惯 ,在动手之前,需要自己心中所有疑问都能得到彻底解决了,都有了完整的解决方案了,才肯去动手实践,才肯改变自己原有的技术方案路线。

 

其实,路是人走出来的,车到山前必有路。

 

最后,这个问题仍然是与具体的PLC型号无关的, 是针对所有PLC的共性问题。

 

总的来说,烟台方法的算法就是在PLC品牌之上与品牌无关的。

 




正在下载,请等待……
下载附件需0积分!

1分不嫌少!


楼主最近还看过


热门招聘
相关主题

官方公众号

智造工程师