1980年代后期我加入了一家生产数字运动控制器的小公司，那时我还是一名年轻的工程师。当时数字技术已经足够成熟，也足够便宜，可以在许多应用中代替以前用的纯机械或模拟电子控制装置。此外，随着数字光电编码器这类位置传感器的成本不断降低，在以前只能使用模拟转速表进行速度控制的应用中，也可以采用位置控制。
这是一个小公司，所以我必须是一个全能型选手，我的其中一个头衔是应用支持工程师，负责处理客户问题。那时候，一条带输送装置的装配线刚刚采用了我们的控制器，这条装配线用于生产最早的小荧光灯泡。搭建这条装配线的工程师对它的运行情况非常满意，因为这条装配线达到了前所未有的精度和速度。
然而，当装配线全面投入使用时，出现了一个大问题。这是一条自动化装配线，本来应当24小时三班不停地运行。但是，当它这样连续工作时，从白天到晚上都非常正常，但是每天凌晨2点左右，在最困乏的午夜时分，装配线都会意外停机。由于这一时间段值班的工作人员很少，因此整个晚早剩下的时间这条装配线一直处于停工状态。等其他工程师上午8点左右上班以后，再重置系统，然后生产将重新开始。每天都是这样。
当然了，由于公司损失了四分之一的生产时间，夜间停机这一问题很快就引起领导的重视，公司专门指派了经验丰富的技术人员来通宵监控系统，以便寻找问题的根源。有同事说他们以前曾遇到过这种情况，通常是由模拟漂移问题引起的。一开始，占上风的观点是认为工厂温度在夜间下降，导致一些模拟电路不能正常工作。（虽然系统中的放大器是由数字控制器驱动的，但它们仍然是模拟器件。）
很多天过去了，寻找漂移问题没有任何结果。从模拟示波器的迹线来看，在系统崩溃之前，关键的信号并没有发生漂移。后来使用了恒温器，以便让夜间的温度与白天保持一样，并且通过单独测量进行确认，但是停机仍然每天晚上都发生。
领导让我看一看从控制器可以获得什么样的信息，以找便找出问题所在。数字控制器有数据记录功能，我觉得这可能会有用。
这个功能按现在的标准来看来确实比较原始，但在当时还是很先进的。一方面，那时的内存非常昂贵，因此，如果按发现问题所需的采样率来计算，它只能存储不到一分钟的数据。此外，这一功能是设计用来存储短时非连续性事件的，例如伺服调整动作。如果缓冲区满了，它就会停止工作。
为了使用这一功能来解决我们遇到的问题，我不得不编写一些低级代码来欺骗缓冲区的状态位和存储指针。当缓冲区对关键运动寄存器的记录快到末尾时，我的代码会检查运动算法中是否有任何误差情况。如果没有错误，我会重写存储指针，它就会重新寻址到缓冲区的开始。如果发生误差，就让缓存停止记录。这样，缓存就可以记录下来系统停机前最后一分钟的数据。这就相当于为系统建立了一个黑盒记录仪。
在系统运行良好时，我们运行了几次数据记录缓冲区，得到了一些参考图以进行比较，然后将其设置为连续运行一整夜。那天晚上，故障照常发生了，但是我们获得了可用于分析故障原因的有用数据。
一大早我们就上传了记录的数据，并将这些数据绘制成图。一看到图，我们便恍然大悟，明白问题出在哪里了，懊恼自己“为什么以前没想到这一点”。
这些图表明，系统在出现故障前一直都运行得很好。当传送带中的32位位置寄存器达到其最大正值并要翻转到最大负值时，故障发生了。传送带始终朝“正”方向移动，以它的运行速度，从零位置启动到故障发生的时刻，大约需要18个小时，这就是为什么它总是发生在深夜的原因，也是为什么在运行时间较短的装配线中从未见过这一故障的原因。
我们在短短几分钟内就判断出问题的根源在于相关应用软件中的数学逻辑不能正确处理位置寄存器翻转。我们又花了几分钟时间，确定了如何修复，这个故障从此再也没有发生过。
回过头来看这个问题，我发现那些老手（最初我完全服从他们的意见）虽然对不同类型的系统都很有经验，但经验主义往往会阻碍了他们找出问题。我们公司那些有经验的老同事非常关注模拟速度控制系统中发生的各种问题，而没有意识到数字定位系统可能会出现完全不同的问题。
很幸运，这一经历使我在“千年虫问题”发生的十年前就知道存在“翻转失败”这样的软件问题，所以我很清楚什么会引起问题，什么不会引起问题。
作者简介：
Curt Wilson是工业控制公司Delta Tau Data Systems的工程和研究副总裁。他拥有斯坦福大学机械工程学士和硕士学位。
（原文刊登于Aspencore旗下EDN英文网站，参考链接：Looking for drift in all the wrong places，由Jenny Liao编译。）
最前沿的电子设计资讯
