york空调 模块出水故障（约克空调水模块）-分类信息网

1.约克空调售后服务电话4000303798/约克中央全国24小时维修热线

约克空调售后服务电话4000303798

温馨提示：如遇YORK约克空调不启动，YORK约克空调不制冷不制冷，YORK约克空调加氟等故障请不要自行处理，请拨打YORK约克空调售后维修服务电话预约专业工程师为您提供服务！

同时向海内外展示中国的书画艺术，进行文化艺术交流，弘扬文化自信，展示大国形象。

2.YORK CMO型船用空调压缩机典型故障分析

一 典型故障案例回顾

案例一 ：

20XX年8月，有两艘船舶的空调压缩机在运行中损坏。第一台为#2缸组后（轴端）活塞连杆组件损坏，造成该缸排出阀、活塞、连杆和2只缸套等损坏。

案例二：

20XX年8月，另一艘船舶的No.1空调压缩机运行中发现异常，人工停车检查，发现一只缸的连杆断裂，活塞破碎，波及4个缸套损坏，能调机构底座损坏严重 ，整台机架报废。

四只缸套破损

缸套 连杆碎裂

案例三：

20XA年8月，另一艘船舶的No.2空调压缩机运行中发现异常，人工停车检查，发现一只缸的连杆断裂，活塞破碎，波及4个缸套损坏，能调机构底座损坏严重 ，整台机架报废。

活塞 连杆碎裂

四只缸套损坏

机架损坏

二 早期机损故障特点

1、损坏首先发生在#1或#2缸组的近吸口一缸(轴端), 该缸活塞连杆组件损坏最严重；

2、碎裂的部件运行中又波及其他缸组；

3、压缩机最终因滑油低压而停车；

压缩机缸组排列顺序

三：故障原因分析：

1、新设备投入运行不久频繁发生机损的根本原因----液击。

2、因为常可以听到缸头有明显的间歇性液击声音；

3、伴随着吸入压力忽高忽低，低压上升到约0.7mpa时，液击出现；同时，过热度、送风温度、膨胀阀开度等都在震荡。

4、液击造成排出阀总成和缸盖敲击，导致spring guide碎裂，其压紧螺帽脱落，最终排出阀解体，螺栓落入缸内。

四：压缩机液击原因分析

导致液击的因素：

1、根本原因--最低过热度参数设置太低

2、压缩机常运行于x模式，即一拖二模式

3、外界热湿负荷大，电子膨胀阀开度100%

4、双管系/长管系布置---特有的不利因素

• 最低过热度参数设置过低—出厂设置为5℃，压缩机—有明显液击声，低压—不稳，膨胀阀开度—震荡，从0%-100%，交替变化。
• 经实际验证，最低过热度提高至9℃，压缩机运行非常稳定，上述现象全部消失。
• X模式，即一台压缩机供两台蒸发器，再加上外界热湿负荷较大时，两只电子膨胀阀开度很大，甚至100%，大量液体涌入，导致低压上升，蒸发器后过热度急剧下降；以致在5℃膨胀阀被迫关闭后，过热度仍然可能下降至临界温度。（从控制器可以读出各参数）
• 最后，双管系/长管系布置，是一个特有的不利因素，回气管含有大量冷剂气体，一旦进入临界温度，形成的液体不能被过热器完全“消化”，从而导致靠近吸口的1#和2#缸组发生液击。

可见：压缩机损坏原因为长期液击所致；

而非：活塞、连杆的材料、强度和设计问题

五：应对措施：

多次故障后，船舶采取相应的措施：

1.缩短拆检周期，特别是排出阀的检查；

2.改为手动模式运行，效果明显，因手动模式下的过热度出厂设定为16℃，相对自动模式下的5℃，非常安全！

3.西安约克中央空调常见问题及解决方法

在西安约克中央空调在使用过程中，或多或少也是遇见些问题，下面小编为您总结了故障及解决方案。

西安约克中央空调故障一：机器露点温度正常或偏低，室内降温慢产生原因及解决方法

1、送风量小于规划值，换气次数少，请查看风机类型是否符合规划要求，叶轮转向是否正确，皮带是否松弛，开大送风阀门，消除风量缺乏要素。

2、有二次回风的体系，二次回风量过大，请调理，下降二次回风风量。

3、空调体系房间多、风量分配不均，请调理，使各房间风量分配均匀。

深圳约克中央空调故障二：体系实测风量大于规划风量发生原因及解决方法

1、体系的实际阻力小于规划阻力，风机的风量因而增大，有条件时能够改动风机的转数。

2、规划时选用的风机容量偏大，请关小风量调节阀，下降风量。

西安约克中央空调故障三：系统实测风量小于规划风量发生原因及解决方法

1、体系的实践阻力大于规划阻力，风机风量减小，条件答应时，改善风管构件，削减体系阻力。

2、体系有堵塞现象，请查看清理体系中可能的堵塞物。

3、体系漏风，应堵漏。

4、风机达不到规划能力或叶轮旋转方向不对，皮带打滑等，查看、排除影响风机出力的要素。

深圳约克中央空调故障四：室内噪音大于规划要求发生原因及解决方法

1、风机噪音高于额定值，请测定风机噪音，查看风机叶轮是否碰壳，轴承是否损坏，减震是否良好，对症处理。

2、风管及阀门、风口风速过大，发生气流噪声，请调节各种阀门、风口，降低过高风速。

3、风管体系消声设备不完善，请增加消声弯头号设备。

4.记一次现场Modbus通信排障

前 言：组态软件和现场的Modbus设备通信缓慢、丢包，这个是大家多多少少都会遇到的问题。产生问题的原因千奇百怪，今天和大家分享一个前些天遇到的挺有意思的一次故障排查。

A． 故障现象：

有个朋友在厂里做FMCS厂务监控系统的项目，需要对YORK空调面板上的一些参数进行采集和设置，上位机软件采用Intouch 2014R2SP1。现场有百余个YORK的面板，面板上带有RS-485 Modbus RTU协议接口，通过MOXA的MB3180网关分为多路把Modbus RTU转为Modbus TCP协议供上位机采集。现场每个MB3180下大约有20个面板需要采集。网络拓扑示意如下：

在调试中，用户发现在Intouch上虽然可以读取到所有面板上的数据，也能通过Intouch修改面板上的设定参数，但是数据更新非常缓慢，一般都在20秒以上，而且有时通过Intouch下发的控制命令会有丢失。用户现场排查过物理链路，均采用120欧姆特征阻抗屏蔽双绞通信电缆，RS485网络没有星型节点，网络两端有120欧姆终端电阻。

B． 思路：

在电话里听到朋友描述时，感觉上像是干扰造成的485通信故障，然而到现场后，发现朋友已经可以在办公室复现这个问题。他使用1个MB3180连接了4台面板，面板Modbus ID从1到4，9600波特率，ODD/8/1，在办公室里使用笔记本上的Intouch工程仍可重现通信缓慢的问题。这是一个非常好的消息，意味着我们不用再去现场检查物理线路的问题。

于是，笔者先找他要了这个面板的手册，下面是大致要采集和控制的数据内容。（当天时间较紧，忘记拍照了，而且也没找到这个电子版手册，下图是从别的渠道获取的地址数据。）

由上图可知，获取的数据比较简单，但是像TempSP,Fan_Mode,Status,Mode这些参数都是在保持型寄存器中，上位机会进行读/写操作。所以，笔者有了第一个猜想：

1.会不会是上位机写入的数据超过了这些参数的范围？

在以往的工程经验中，见过很多由于Modbus主站向下写入的数据超过从站变量数据范围导致的通信问题。比如，向某变频器发送整数7表示启动，发送15表示停止，如果你发了一个16，但变频器里没有对应的动作，如果变频器协议机制比较完善，它会返回主站一个功能码为0x83的异常响应报文，主站也就知道是自己发的数据超出了从站该变量的范围。但是，如果从站设备的软件编写不够严谨或者存在问题，它有可能不会回复主站。由于Modbus在大多数情况下是主站对配置数据逐条轮询，并设有超时时间和重试次数，如果对某一参数写入失败且设备没有返回异常响应报文，主站会等到超时时间后再重发本次数据（即重试Retry），如果重试几次之后仍未收到正确的从站响应报文，主站才会跳过执行下一条或者放弃该从站转到另一从站ID进行数据轮询。在超时等待和重试中，会浪费大量时间。再者，极其个别的设备，如果写入了超过范围的数据，可能会造成设备通信程序甚至整机的死机或重启。判断通信缓慢是不是由这个造成的也很简单，把软体里的写入操作全部屏蔽掉，看看还有没有这个问题。如果没有了，仔细研究从站手册，看看哪些参数会有此问题。如果看不出来，则把屏蔽掉的写入操作逐条恢复，直到发现问题再仔细甄别数据范围。 不过，在屏蔽了对上述所有变量的写入操作后，通信仍未改善，看来不是这里的问题，于是笔者有了第二个猜想:

2.会不会是上位机软件组包导致的？

在组态软件中，为了提高读写效率，一般会对数据进行组包。比如在本例中，当读取以下5个数据时，如果组态软件的组包长度比较大，比如100，那么组态软件一般会使用03功能码直接读取从40003开始的连续10个字来获取数据。如果组包长度设的比较小，比如设成5，那么组态软件会分成2次03功能码操作分别读取从40003开始的连续4个字和从40012开始的1个字。

设置较大的组包数值可以让软件减少一个轮询周期内的会话次数,提高通信效率和速度。但可能会有两个潜在的问题:一是某些设备因为软件限制不能处理超过一定长度的Modbus报文，比如设备可能最大只能处理数据域不超过10个字的报文，但是你发了一个读连续50个字的报文，设备可能会不回复或者出各种问题。二是如果在连续数据包中，比如上面从40003开始到40012这10个地址，在从站设备中只存在表上列出的5个，中间40007-40011这些不存在，则设备响应也可能会有问题。

这种问题判断很简单，使用Modscan或者Modbus Poll这类工具软件，尝试读取连续数据看看有没有问题就行。如果发现是此问题，可以缩小组态软件的组包长度进行解决。

可是，在用Modscan做了几组对上面的不同寄存器进行的读写测试后，发现数据读写都很正常，一点问题都没有。但是我们发现了一些有意思的现象，在只连接Modscan的时候，4个实验设备读写完全正常，一次无效应答都不存在。可是如果换成Intouch, 通信立刻就出现了问题。有啥区别? ModScan轮询速度慢,是1秒钟才读取一次数据，可Intouch快了很多。于是第三个猜想涌上心头：

3.会不会是报文间隔时间太小导致的？

“在之前的工作中，笔者遇到过一些从站设备对通信的处理能力比较弱，或者是程序编制不完善，当485总线繁忙时，由于其处理器计算能力或者程序编制不合理，出现较总线不繁忙时通讯响应迟缓，设备动作卡顿，通讯中断，甚至设备重启等情况。仅在今年，笔者就遇到过一个特气集控器，主站03报文询问过快之后设备显示器停滞不刷新数据；某家电一线品牌的中央空调集控器，速度快后不定时通讯中断，必须重启设备才可恢复;某模拟量模块，速度快后模拟量读数失真；某压力表，速度快后直接重启。

想到这里，笔者在PLC主站的轮询逻辑中增加了100ms的延迟时间，即当主站收到从站的正确响应后，等100ms之后再发送下一条请求。验证，问题得到解决。”（见作者在剑指工控之前发的文章《流量积算仪Modbus通信的一些小问题》）。考虑到上述情况，笔者拿了一个随身带的HORNER XLE控制器做了个测试。在XLE里配置了4台温控器后，如果使用默认的Slave Speed Fast，XLE会在收到从站设备响应后只等待3½个字符时间后，就会进行下一次数据请求，此时监控XLE的通信状态，会发现从站出现了很多无效报文返回，数据交互异常缓慢，和Intouch故障现象相同；在把XLE的响应速度设为Slow后，XLE会在收到报文后等待100ms才发送下一组报文，此时通信状态就完全正常了。

在基本确认问题后，剩下的就是如何在Intouch的轮询中增加这个延迟时间。笔者对Intouch不是专家，在查询手册和咨询了几位朋友后，也没在Intouch中找到在哪里能增加这个报文间隔时间，所以就只能把目光盯向了Intouch和设备之间的MB3180网关。

在查询了网关的说明书后,发现其有如下参数-帧间延迟(Inter-frame Delay),其说明如下: In Modbus RTU slave mode, user can determine the time-delay to transmit the data frame received from the slave device to the upstream. The MGate MB3000 will automatically determine the time interval if it is set to 0. 即在RTU模式下, 用户可以修改此参数设定MB3180网关转发从站响应报文的延迟时间.默认情况下该参数为0,这里我们把它修改成100. 然后测试,问题得到解决。

C. 后记:

现场通信缓慢是个非常令人头疼的问题, 除了软件因素,硬件问题如终端电阻不接/接错位置, 屏蔽层触碰数据线, 通信接头接触不良等都可能造成类似的故障现象。不过,再复杂的问题,只要有心,一步一步假设、试验、排除, 终归是可以解决的。