由坐电梯引发的编程思考

admin

在去年初的时候，挪了个小窝，当时就听小区的业主群聊的时候说小区的电梯很差。。。

平时我并不是留心乘坐的电梯是否有问题，然而自从我入住了新居之后开始留心起来了。

在未装修好的时候，朋友带着小孩过来参观。在负一楼进电梯的时候小朋友很兴奋，电梯一开门就冲进去了，然而电梯立马就关起门来。。。见到电梯门要关了，朋友立马多次按了电梯外面向上和向下的按钮，然而电梯竟然没有开门而是继续关门，然后向上运行了。。。大家立马慌了神，小朋友只有4岁，一个人在电梯里怎么办？？然后分头去找，直到过了好一会才在负2层的电梯里找到他！此事令我对这个电梯的安全性有了很大的质疑。。。也令我对电梯的运行留心了很多。

我们整栋楼有6部电梯，然而只是分三组一控二，并不是一控六，在实际使用中会产生同一楼层三组同时按，然后会出现大量的重复停的情况，不仅电梯运行效率低，同时在早上高峰期需要等待的时间更长了。

一控二的程序比一控六的程序简单多了，然而实际情况是这样的吗？

1.电梯门在关闭的过程中（没关闭）的时候在外面按上下键出现不开门的情况，这种问题直接导致小朋友被锁电梯，严重出现安全隐患。（此问题反馈后，电梯公司应该修改了程序，之后暂时未出现过了）

2.在特定的情况下（比如两部电梯同时从不同楼层的高层下来）出现多次按上下键无显示反应，等电梯过了该楼层又可以显示了。（此问题反馈后解决）

3.电梯楼层显示不正确，比如说负一上行，电梯的楼层有时候是正常的1、2、3显示，有时是-1直接到3了（电梯会飞？？）；有时下行的时候明明在6楼停留很久突然快速的下到4、3了。（此问题一直存在，反馈后相对会好点，但运行还是不理想）

4.电梯的控制逻辑感人，你经常是无法判断哪部电梯在你的楼层停然后开门给你。比如说我在1楼按向上的电梯，按亮的时候左边的电梯是在20几楼并且还是向上运行的，右边的电梯在负一层还是显示向下的箭头，这时候正常人都会认为是右边的电梯从负一上来一层开门的，结果过了好一会负一的电梯上来了并不停一层直接上去了。。。。（这是什么电梯控制逻辑？？）

5.电梯开关门时间并不固定，而是时快时慢令人摸不着头脑。最简单体会就是有时候电梯开门进去没两秒钟电梯就关门了，有时候进去等很久还没关门，要按关门键一段时间才关门。。。

其实以上几个问题归根结底都是电梯的控制逻辑有问题（存在严重缺陷！），用外行话说就是一个新手写的电梯控制程序！！说实话坐了这么长时间的电梯，还是第一次感受到有这种不负责任的电梯控制逻辑存在，这些明摆着的电梯控制BUG都不解决，你能保证你坐的电梯是安全的？？不会出现错误的故障的控制逻辑？？难道要真出了安全事故才去补救？？

-------------------------------------------------------------------------------------------

在我们plc编程中，安全是永远放在第一重要性的，一套控制程序如果只按正常的流程运行是没问题的，正常运行时程序运行是正常的，但是在编写完程序之后是否认真审视过自己的程序是否是没有问题了,是否合理了，是否做过实验程序去验证了你的程序完全没问题了？后面这些步骤很多时候都给我们偷懒去省略了。编程难并不是难在按正常的逻辑去编好你的程序，而是编好后或者在编程的过程中需要考虑现场可能出现的各种问题，在此情况下你的程序是如何与之应对的。充分考虑了各种情况下的各种应对措施，你才能够大胆的说：“我的程序是安全的，你随便用吧，没有BUG的”

这类的考虑通常有以下几个方面：

1.错误的参数设置的对应处理：正常参数设置是设备正常运行的前提，但是操作人员并不是编程人员，水平参差不齐，在设置错误的参数时候，你的程序是怎么运行的？是否会导致现场的设备错误的动作导致安全隐患？这个错误其实在我们的编程中是很常见的。

2.断电重上电的对应处理：程序在运行中突然遇到断电了，重上电之后设备是什么状态的？是否会产生一些错误的动作？这类问题一般出现在变量是否需要断电保持以及定时器是否需要断电保持。要验证此类问题一般需要通过做一个模拟实验程序，通过实际的通断电去验证你的程序是否安全。

3.通讯中断的应对处理：现在运用各类总线，各类远程I/O，各类通讯日益频繁，在我们的编程过程中就需要认真考虑到当此类通讯出现故障的时候，你的程序该如何去应对的：包括短时瞬断的应对，长时间通讯中断的应对等等。

4.设备故障的对应处理：在控制过程中当其中某个设备故障了，程序是否做了对应处理，此类设备故障处理相信大多数的程序员都会做到，但是否全面安全就要考量了。

5.控制按钮的保护处理：在控制过程中“开”和“关”是否有互锁，多次按动不同的按钮会否对设备控制产生影响。

总的来说一个好的程序最重要的第一条就是安全，在安全的基础上才能去考量你的编程逻辑，编程技巧是否好，是否对程序进行了标准化。按正常的逻辑去编程可能你很快去编好了，在编好后你如果按安全的角度综合考虑增加了各种各样的补丁程序，你就会发现你的程序变得很臃肿了，这个臃肿的程序你觉得会是不好的程序吗？肯定不是的，你能编好臃肿而安全的程序说明了你对方方面面的了解，也说明了你对控制工艺的深入研究。可以在下一次的编程中尝试将臃肿的程序合理化，逻辑化，可读化，那你的程序就又上升了一步。之后可以对相类似的控制工艺进行程序的标准化，模块化的编程，日后这类程序就可以信手拈来。