777.jpg856x337 106 KB 张佳乐：惯导 rs232接口，平时用 232只要rxd txd就能通信，但是惯导需要接地线，线都接好，指示灯闪烁，没数据，对调rxd txd 没数据，那我试试把地线接电源正吧，然后愉快的烧掉了。于是不小心接到电源+，。卧槽你做成双极性输入的不就烧不掉了，从此师兄再也不信任我的接线。
gps模块某电容和电阻接反了导致没数据，换回来之后南京的我偏移到了合肥，说好的精度1.5m呢，这都不知 15km了好吗？
张奉陕：电路板的同轴输出接插件，sma头。下面连信号的引脚因为电装工艺问题根本就没焊上，但是距离焊盘很近。导致的现象就是信号质量特别差，但是确实有信号。查到这个问题的原因才发现原来是虽然信号传输线有断路，但是因为离得特别近所以形成了电容，信号就交流耦合过去了。
事后总结出了硬件毛病先把外观检查一下，再查一下比较基本的问题，比如供电，短路断路。都排查完毕再发表高深莫测的玄学理论。。。
阿琳：和同事一起调试蒸汽吹灰设备，忘记了排空冷凝水，把水喷到价值近千万的催化剂上面了。
后果：罚一个月工资，更换了打湿部分的催化剂。
同事调声波吹灰，忘记了烟道内还有农民工在做业，直接开起来。几个工人在一个封闭的铁盒子里被6个功率不小的超声波喇叭震耳欲聋。幸好迅速跑出来了没有造成永久性的听觉损伤。
后果：被农民工打一顿，我也不幸遭殃被连带打了一顿。
积木狗：买来的机器人是日标供电，三相220V，国内没有这样的电源，需要增加变压器把三相380转为三相220。
临时试机的时候，没有万用表，我把变压器的输入输出接反了，导致三相380变为了三相650V！
现场很惨烈，电源接通的一瞬间，火花闪电黑烟和噼里啪啦的爆炸声不亚于有人在车间里扔了一挂粗鞭炮………
有个同事冒着触电危险把手伸到机器人关闭了电源………
后来维修花了五六万……………
匿名用户：遇到过for循环中，手算应该是3000，实际是30000的浮点运算…gcc -s然后化简到几行汇编，依旧算错…
遇到过两个线程互相发Linux signal，上万次之后就会死锁…哦这个最终追出来了，是kernel里面的问题，不算硬件故障…
FPGA上能遇见的各种稀奇古怪的问题，转到互联网之后，我想我应该很难再遇到了吧
Patrick Zhang：我也经历过2次。
第一次，是某款PLC。厂家声明，此PLC已经在全球用了XX万套，是很成熟的产品。但在编程阶段就显得极不成熟。PLC投运后，出现死机现象，几经折腾也弄不好。最后，厂家的工程师自己来处理了，并且告诉我：我用的是全世界第一套！
经验教训：原来，老外也会忽悠人。
第二次，是另外一款PLC，此PLC被广泛使用，是技术成熟产品。
但被用在地铁中，却发现了死机。检查后发现，我们将此PLC同时用于逻辑控制和通信管理控制。由于两套系统都属于0类中断处理程序，于是PLC的CPU在运行受阻时，就将两套系统全部重启。造成严重事故。
说来有点意思，任何PLC都有几个字节的内部存储空间，用来记录严重故障时的关键值。此内部存储空间一般不公开。我就用此技术记录了死机前最后一刻的状态，找到了事故的根源。PLC的制造商也据此修改了设计。
一个感觉，PLC的技术进步类似于空难，也是在故障中不断修改和完善的。
事后，我们把两套系统用两台PLC独立完成，两者之间不存在建立横向联系，由此彻底杜绝了问题的根源。
总之，出了问题首先要分清责任。我们要敢于承担工作压力，但不能盲目的承担事故责任，要保护好自己；第二要仔细认真地分析事故原因。
事实上，分析事故原因难度很大，甚至都会超过开发商的技术水平。
若只是简单地把责任推给供应商，则自己的技术永远不会进步。
亲爱的工程师朋友们，你们还遇到过哪些有趣的硬件故障呢？欢迎分享哦！
/3 
