机器视觉项目，线体流速是6秒每个产品，原本以为留给视觉拍照和算法的时间足够了，结果客户那边突然找到我，问我算法还有没有优化空间，因为他们那边的产品线经常堵，就是因为上了视觉方案导致的！
我开始还不知道咋回事，因为这个项目我是还记忆犹新，这个项目的视觉拍照到算法走完需要500毫秒，虽然在我以前做的项目里不算快的，但500毫秒的拍照和检测时间也足够线体反应了，怎么会把线体堵住呢？
上位机程序逻辑
客户跟我解释半天我才明白怎么回事，虽然这个线体的流速是6秒，但是，程序的可反应时间只有3秒不到，这是为啥呢？
我们得先了解整个检测过程的逻辑，然后就知道里面出现了什么情况了！
这个项目我只负责软件部分，客户那边自己装的硬件，包括上位机，我除了调用相机时是和相机直连的，其他的像一些传感器和PLC模块都是跟IO卡通讯的。
在产品经过红外传感器时，需要等待1秒左右，程序会向IO卡发送升起挡板的指令，程序会向IO卡的某个数据位发送一个夹紧指令，将产品夹住，然后程序会去监听夹紧设备的信号，直到夹紧设备发送了已经夹紧的信号，程序才会触发拍照和视觉算法，最后程序会再向IO卡发送松开指令，夹紧设备会松开产品，程序再发送一个挡板下降指令，挡板下降后产品流走。
这里面，虽然看似所有硬件都是由程序控制的，但是除了升起挡板、夹紧产品、收起挡板、松开产品是主动由程序发起指令的，但这指令背后，还是由红外传感器被动触发的。
所以，一开始客户问我程序还有没有优化空间，我是比较纳闷的，我觉得只要机械工程师和电气工程师当初的设计是合理的，不应该会影响到线体流速，因为整个线体的流速是6秒，6秒之内怎么说程序也执行完了！
加日志分析原因
开始，我以为是程序出了Bug，导致最后产品没有松开或挡板没有下降导致的，结果客户给我否定了，说所有指令程序执行的都没有问题。
细问之下，我才知道，原来看似程序有6秒的执行检测时间，但是，实际上只有3秒！
客户跟我说，虽然线体的流速是6秒，但是这6秒是当前产品到下一个产品之间的流速。产品在检测完以后，还需要流到下一个检测工位，这个时间是3秒左右！这就导致了实际给视觉程序的时间就只有3秒了！
听他这么一说，我直接回道：“那3秒不也足够嘛！”
客户说他也是这么认为的，但是实际上有的时候就是会卡线体！
于是，我在代码里面加了一个计算时间的日志，主要用来监测从红外传感器触发到最后收起挡板时，程序的总耗时，并且还加了一个从拍照到检测结束的耗时。
最后发现，从红外传感器被触发到最后收起挡板的耗时约为2.8秒左右，从拍照到检测结束耗时约为500毫秒左右（和我想的一样），当然了，这500毫秒是包含在2.8秒之内的。
2.8秒这个时间肯定是足够的，我跟客户说，等线体再次被卡住，再来找我！
结果，没几天客户就又来找我了，说线体卡住了，我一看时间，从红外传感器被触发到收起挡板的耗时竟然来到了3秒以上，其中拍照和检测耗时还是500毫秒左右。
于是，我跟客户说，拍照和检测的执行时间相对来说是比较固定的，变数在硬件上。
设备响应超时
经过大量的验证，我们发现问题出现在夹紧设备上。
这个夹紧设备的逻辑是这样的，在程序发送夹紧命令的时候，夹紧设备的气缸会往前推，推到最前面的时候，夹紧设备的内置传感器会发送一个已经夹紧的命令，问题就出在这。
按照正常情况来看，从夹紧到已经夹紧的这个过程大概要1秒左右。但是，有时候明明已经夹紧了，夹紧信号却没有发出来，这就导致了本来1秒可以执行完的动作，就在那等着。
但是，我在写程序的时候做了设置，就是当程序在发送夹紧命令时，如果在1.5秒以后仍然没有收到设备已经夹紧的信号，程序就会直接拍照然后执行算法。
遇到这种情况，本来可能3秒内可以执行完左右步骤，现在可能就需要3.5秒的时间了，影响线体流速，线体就被卡住了！
最后，我将监听已经夹紧的信号的等待时间修改成了1秒，让客户再看看会不会再卡线体了！
过了很久，客户找到我，说现在线体已经不会再卡了，但是出现了另外一个问题，那就是相机拍照有时候会模糊！
就坡下驴，我跟客户说：“你们的这个夹紧设备的设计是有问题的，原本设计是1秒夹紧，但是经常出现1.5秒还没夹紧的情况，这个你们得排查一下到底是什么原因导致的！”
然后，我跟他解释了为什么相机拍照有时候会模糊，因为现在程序是等待1秒，如果还没有收到已经夹紧的信号的话，那么程序会直接执行拍照。此时，可能产品真的没有被夹紧，线体还是在动的，因此产品也是在晃的，所以有概率拍到的照片是模糊的。
结语
最终，我让客户那边想办法解决夹紧设备信号的问题，并没有给客户优化拍照和视觉算法相关的代码。因为我知道，即使是优化了，可能也优化不出来多少时间空间，而且优化的意义也不大！
因为，原定1秒的夹紧过程因为硬件问题导致1.5秒后还未执行完成，这是程序影响线体流速的主要原因！
当然，这不是最后的解决办法，可优化的空间还是很大，但得一步一步来！