北京的冬天终于下雪了，早上上班的路上倒是空气出奇的好，赶到办公室，屋里的暖气也不像往年那样闷热得离谱，这种“和谐”的天时地利可真是难得啊。真在感叹生活一片大好的时候，电话响了……
一个上海的某系统集成商工程师正在现场，生产线正在逐步开机调试阶段，反映塔的温度正在稳步上升，到了150摄氏度左右，画面上的数值就不变了，底色也变灰了……
用户很着急，电话里也一直抱怨：在FAT的时候什么问题都没有，怎么一到现场就掉链子了？是不是WinCC的问题？我们的模块肯定是正版的，我们也使用CP1613的容错连接了，怎么还出问题……
可以理解用户在现场面临的压力，但作为我们，不能也因此乱了方寸，否则问题没解决反而可能带来更大的麻烦。
OS上的数据显示变灰，首先就需要考虑是不是通讯的问题：
让用户切换到其他对象，查看数据、操作是否正常，用户打开了一个隶属于同一个AS的PIDConL对象，手自动的切换、设定值的数据等都没有问题，这说明数据连接没有问题。
确保通讯没有问题，那就需要考虑是不是程序中出了些问题，让用户简单描述了CFC中的程序结构：



这是一个典型的简单PID回路！
让用户监控CFC程序，为了准确起见，让用户把驱动块的在线监视截图发过来了：



截图上豁然显示模块过来的数据是16#FF！考虑到之前模块能够正常工作，而且热线上也出现过类似的问题。所以首先让用户检查模块的接线，是不是存在松动或者同模块上通道组中其他通道的处理情况等等。在此基础上，提醒用户着重留意是否有EMC的问题，例如信号线是否和动力线、变频器交叉在一起等。
挂完电话之后就一小会，用户的电话又进来了——各种检查过程都没有发现问题！各种布线都规范，而且变频器等都没有启动！
问题的处理陷入了僵局……
难道会是模块的问题？又或者是Pt100的问题导致返回的信号值超范围？
之后跟客户又咨询起了问题发生前后的详细现象，在这个过程中，用户的一句话让我怀疑了起来：
“…问题出来后，我也怀疑是不是模块的问题，换了一个Pt100接到这个通道上，结果显示又正常了…”
换了Pt100，测量环境温度没有问题，而且，问题出现前的真实温度在150度。
——原来如此！
指导用户打开项目的硬件组态窗口，查看这个RTD模块的配置信息：



模块的测量范围上，选择的都是“Pt 100 Cl.”，这不就是气候性的测量范围嘛。在S7-300的模块数据中有一个表格显示气候性测量方式的数据表示范围：



对于Pt100气候型的测量范围只有-145~155，远远低于标准型的-273~1295。所以在温度超过155摄氏度之后，通道的数据就变成了16#FF，驱动块的QBAD变成1了，这也直接导致画面上的数值显示变灰。
回顾这个问题的处理过程，可谓是一波三折啊。如果用户发过来的功能块监控截图上如果显示了驱动块的Mode在线值，那也可以看到是气候型的。如果用户读取了模块的诊断信息也是可以看到是数据超范围了……
但这一切都在惯性思维的驱使下疏忽了：用户是多年经验的老工程师，组态一定是没有问题的?突然出现的数据不正常，那就应该是接线或者EMC的问题……
总而言之，对于工程过程中的问题，细枝末节上的不注意往往会导致不可预计的大问题。这个问题产生的原因还比较单一，如果用户程序再犯点小错误、OS组态再出现错，那么处理过程的复杂度还不得直线攀升？！
关注西门子服务网站热线故事，关注自控领域的更多精彩！