标签: 排故

版权声明： 本文由博主 “cuter” 发布。欢迎转载，但不得擅自更改博文内容，也不得用于任何盈利目的。转载时不得删除作者简介和版权声明。如有盗用而不说明出处引起的版权纠纷，由盗用者自负。 博客官方地址： ChinaAETna ： http://blog.chinaaet.com/cuter521 EDN China ： http://bbs.ednchina.com/BLOG_cuter521_356737.HTM   按照 【 博客大赛 】 创建 Zynq Linux 设备树文件 一文提供的办法（基本上完全参考 Xilinx Wiki ）创建出来 dts 文件，然后利用 dtc 工具编译生成 dtb 文件，使用该 dtb 文件并不能成功启动 Linux ，而是卡在“ UncompressingLinux... done, booting the kernel ”如图 1 所示。 图 1 Linux 内核启动失败   有网友说这是 dts 文件有问题，但是整个创建过程已经严格地按照 Xilinx WiKi 来了，估计是版本不匹配吧，生成的 dts 文件不能被内核识别。   最终解决办法是用 digilent 自带的 dts 文件，将我的硬件环境里没有的设备全部注释掉，然后生成 dtb ，启动成功。   比较 digilent 自带的 dts 和我们用 SDK 生成的 dts 文件可以发现，主要有两点不同： 1） 设备有差异，如图 2 所示。 图 2 设备数量不同 2） Compitable 属性不同，应该是指定的驱动程序有差别，如图 3 所示。 图 3 驱动程序描述不同 3） 二者对时钟的描述方法差别比较大，如图 4 所示。（问题应该不大） 图 4 时钟描述不同 做出判断的原因是查看了 driver/clk.c 文件，发现对应的处理函数，虽然没有仔细分析，但可以猜测时钟能够被解析。 4） QSPI 描述差别较大，如图所示 4 。 5） 网口描述差别较大，如图 5 所示。 图 5 网口描述不同 毫无疑问，把这些全改掉就可以启动，但我尝试定位到底哪些必须改： 1） compatible = "xlnx,zynq-7000"; 必须改为      compatible = "xlnx,zynq-zed"; 2） 其他 compatible 必须改； 3） 多出来的设备要注释掉； 以上三个报错如图 1 所示。 4） 网口描述必须要改，否则报错如图 6 所示； 图 6 网口描述导致的报错 5） QSPI 描述必须要改，否则报错如图 7 所示。 图 7 QSPI 导致的报错 从图中可以看出“ couldn’t determine bus-num ”：无法决定 bus-num 信号； 同样的，片选信号“ num-chip-select ”也要在 dts 中描述，否则会报类似的错误。   本文采用了笨方法解决了问题，但是有时间的话应当研究 Linux 是如何解析 dts 文件的，搞清楚整个解析过程，就可以轻松定位到出错的原因。  

版权声明： 本文由博主 “cuter” 发布。欢迎转载，但不得擅自更改博文内容，也不得用于任何盈利目的。转载时不得删除作者简介和版权声明。如有盗用而不说明出处引起的版权纠纷，由盗用者自负。 博客官方地址： http://blog.chinaaet.com/cuter521 http://bbs.ednchina.com/BLOG_cuter521_356737.HTM     按照 【博客大赛】 Zynq Linux 设备树文件的学习与创建 一文提供的办法（基本上完全参考 Xilinx Wiki ）创建出来 dts 文件，然后利用 dtc 工具编译生成 dtb 文件，使用该 dtb 文件并不能成功启动 Linux ，而是卡在“ UncompressingLinux... done, booting the kernel ”如图 1 所示。 图 1 Linux 内核启动失败   有网友说这是 dts 文件有问题，但是整个创建过程已经严格地按照 Xilinx WiKi 来了，估计是版本不匹配吧，生成的 dts 文件不能被内核识别。   最终解决办法是用 digilent 自带的 dts 文件，将我的硬件环境里没有的设备全部注释掉，然后生成 dtb ，启动成功。   比较 digilent 自带的 dts 和我们用 SDK 生成的 dts 文件可以发现，主要有两点不同： 1） 设备有差异，如图 2 所示。 图 2 设备数量不同 2） Compitable 属性不同，应该是指定的驱动程序有差别，如图 3 所示。 图 3 驱动程序描述不同 3） 二者对时钟的描述方法差别比较大，如图 4 所示。（问题应该不大） 图 4 时钟描述不同 做出判断的原因是查看了 driver/clk.c 文件，发现对应的处理函数，虽然没有仔细分析，但可以猜测时钟能够被解析。 4） QSPI 描述差别较大，如图所示 4 。 5） 网口描述差别较大，如图 5 所示。 图 5 网口描述不同 毫无疑问，把这些全改掉就可以启动，但我尝试定位到底哪些必须改： 1） compatible = "xlnx,zynq-7000"; 必须改为      compatible = "xlnx,zynq-zed"; 2） 其他 compatible 必须改； 3） 多出来的设备要注释掉； 以上三个报错如图 1 所示。 4） 网口描述必须要改，否则报错如图 6 所示； 图 6 网口描述导致的报错 5） QSPI 描述必须要改，否则报错如图 7 所示。 图 7 QSPI 导致的报错 从图中可以看出“ couldn’t determine bus-num ”：无法决定 bus-num 信号； 同样的，片选信号“ num-chip-select ”也要在 dts 中描述，否则会报类似的错误。   本文采用了笨方法解决了问题，但是有时间的话应当研究 Linux 是如何解析 dts 文件的，搞清楚整个解析过程，就可以轻松定位到出错的原因。

最近在收集这个关于PROFIBUS DP网络通讯的时候会出现怎么样的故障，那有应该如何排故呢？结合一个产品（德国COMSOFT公司的 NetTest II）进行学习中，发现好文，跟大家分享一下，来自济南钢铁股份有限公司的王工，张工，以及刁工，整理并发表在山东冶金的一篇文章， 使用NetTEST II分析和测试工具，可系统化测试一段PROFIBUS DP。大多数 常见错误，例如，安装错误、短路、线路或屏蔽断裂可在实际运作之前探测出和排除掉 - 无论是DP从站是否被连接、断开、通电或断电。结合案例分析 PROFIBUS的故障多出在DP接头，线缆问题，电磁干扰问题 故障1， 调试期间，只要送电就偶尔报通讯故 障，各子站随机出现通讯故障，特别是单独几个子站尤为频繁。粗略检测回路电阻，阻值为112 Ω 左右，阻值在正常范围内。   对于这种情况：首先检查接线顺序问题，通讯DP 头A、B 端子的电缆是否有接反现象， 其次看接线是 否有不良现象，然后测量总线上的回路电阻值，理论上电阻值在110 Ω左右就没有问题；偶尔报通讯故 障一般就是信号衰减的问题，主要有接线和通讯头 两方面原因， 但通过测量，这2 个原因都能排除；计 算此通讯双绞线的长度，直线距离150 m 左右，但加 上电缆是曲折敷设的并且进出子站都有一定的长 度，此电缆的总长度应该在260 m 左右，这样就会导 致信号的衰减以至于通讯不正常。临时敷设光缆成 本高，于是考虑在子站22~25 所在的配电室配加1 个RS485 中继器，对信号进行稳定。加装中继器后，通讯稳定 那么这这期间用到的仪器可以采用，NetTest II 检测每个从站的电平信号，以及电压范围。 故障2， 正常生产时，各子站随机出现通讯故障，导致跳闸而无法生产。粗略检测回路电阻，阻值 为85 Ω，阻值不在正常范围内。     对于这种情况：检查两端的DP 通讯头，发现末尾 的DP 通讯头阻值异常，应该是220 Ω，却只有140 Ω左右，更换正常DP通讯头后，恢复正常。 故障3， 正常生产中，当辊道运行时偶尔22~25 子站报通讯故障，造成跳闸，也无法生产，辊道不运 行时没有问题。粗略测量阻值为112 Ω，阻值在正 常范围内。  对于这种情况：根据检验先测量电阻值，如果阻值是在正常的范围内，再如果也没有增加线缆的话，考虑可能是电磁干扰问题（变频器，电机，高频电气），为了避免或者验证这个情况的话，动力线缆（电源线）最好不要跟通讯线缆**在一起，尽量分开敷设。 故障4， 正常生产中，偶尔部分子站报通讯故 障，造成跳闸现象，但不频繁。粗略检测回路电阻， 阻值在112 Ω以上，偶尔有波动，阻值在正常范围内，   对于这种情况：那么这种情况跟第三种情况是比价相似的，所以一般是先排查出DP接头，线缆问题，是否存在电磁干扰问题？如果都不是以上情况，考虑是否接地，接地系统混乱是会导致环路电流，对PLC干扰主要是接地点位不均，电位差导致环路电流，最好就是可以做到一个系统，统一接地! 针对上面列举的几项故障问题，这边的NetTest II，是非常合适的，所以要熟练的操作，把这些掌握的理论知识真是运用到实际现场分析中去。

    人们都说，实践是检验真理的唯一标准，这也许是每一人都懂的大道理，但真正做到这一点却没那么容易，因为人们都是希望事物能够按着自己所想的趋势发展，而往往轻易地忽略了实践的真实性和主导性。只有不断的进行实践，我们才能真正地了解事物的存在，预见事物的发展。     这不，上个月小谢基本有20多天都是在外出差，要么去各种生产现场测试，要么跟一线技术人员在实验室做实验，要么就是参与专业的技术培训，这些都让我深深地感受到实践的重要性。以前那种只靠书本和理论的学习模式已经不够用了，只有真真正正地实践才能让你完全消化所学到的知识，并转化为自己的东西。     上个月主要去了山东做现场Profibus的诊断测试，用的是一套来自德国的诊断工具PROFIBUS Tester 5（简称PBT5），一共跑了6个现场，其中包括电厂，钢厂，造纸厂，饲料厂等，做了6份报告，主要发现了一些极为常见又而无法用肉眼发现的Profibus故障，如Profibus线缆短路，交叉，Profibus接头老化，松动，Profibus组态错误等。如图1是一个信号质量的柱状图，其中有一部分站点的信号电平过低，呈黄色，可能是传输距离太远导致信号减弱，也有个别站点的电平远远高于其它的站点，可能是供电出了问题，当然也有一部分站点的电平相对平稳，说明信号质量不错。 图1、站点信号电平     另外，通过这个诊断工具也可以扫描到所有站点的波形，如图2所示是站点3的信号波形，从波形中可以看到，正常情况下应该是方波信号，但现在已经出现了很严重的毛刺，而且毛刺比较集中，可能的故障原因就是有高频的设备对站点3产生的信号干扰，也有可能是近端的终端电阻失效了。 图2、站点3的信号波形     这些故障其实都是比较常见的，但我们在实验室做实验的时候由于环境比较好，系统也比较小，就比较少遇到，而实际上在一些已经工作有两三年的Profibus系统中，这些故障都是时常发生的，这个时候现场的维护工程师就需要用最短的时间来找到问题所在，并解决故障，不然就会给生产带来极大的损失。     通过这次带着诊断设备去现场测试，发现很多的问题都是书本上没有提到的，这让我学到了很多，也积累了宝贵的现场经验，而这样的实践积累也才是最实际，最有用的，如果只是单纯的学习理论，那根本就不足以解释现场遇到的各种问题。只有在实践的过程中发现问题，再查找相应的理论支持，用理论来辅助我们分析问题，解决问题，这才是最为关键的。     附件有一份现场的测试报告，有兴趣的友人们可以下载看看！