工程经验总结1：关于96系列保护几个常见通讯问题的处理

关于96系列装置通讯方面几个常见问题的处理经验

任百群 04/10/08

1、需要改通讯接线和装置接地才能有效解决的问题

1.1主要故障现象

a)现场操作（特别是投合电容器）后，同一条变位的SOE频繁上送。（比如远方就地状态，根据后台或调度记录的该事件SOE时间完全一致，很容易判断出是同一条事件）。该现象常发生在RCS设备通过LFP规约跟别厂家RTU通讯构成的系统中。如果RCS设备跑的是103规约，该问题出现的很少。

b)投合电容器（特别是合电容器）操作后，电容器保护测控装置或同电容器保护测控接在同一条通讯线上的RCS设备通讯中断。有时复位电容器保护测控装置通讯能恢复，但大多数情况下单纯复位装置不行，往往需要给电容器保护装置掉电再上电，通讯才能恢复。但下次电容器再操作往往又会出现该问题。更换电容器保护184通讯芯片后，可能能好一段时间，然后故障现象又会依旧。

c)出线故障（尤其是相间接地故障）后，保护动作正确，但通讯中断，动作信息无法上送。用户到现场后复位装置或给装置掉电再上电，保护动作信息才能上传。

1.2故障原因分析

虽然更换保护装置CPU板485通讯接口芯片是我们在现场经常采取的维护手段。（该芯片型号184，双列直插封装。位置在CPU板右下方，同装置后端子排排列顺序相对应，从上往下三个184芯片分别对应对时口、串口A、串口 B）。但对于上述故障，更换184芯片往往只能暂时解决问题。如何区分是否需要换芯片其实很简单：对因为雷击等原因造成184芯片损坏而导致的通讯中断，是不可逆的。无论你复位也好，给装置掉电也好，通讯都不会恢复，这种情况只能是更换芯片解决。而上述故障，装置复位或掉电后，通讯就可以恢复。而且故障具有一定规律（比如合电容）且重复发生。对这种情况，就需要通过更改通讯接线方式来解决。

我们要改变一个习惯上的错误认识：即485通讯是差分信号传输，只需要A、B两根线即可，不需要信号地。在外界干扰不严重的情况下，工程上这样使用是可以的。但应该注意的是485的收发器只有在共模电压（在工程上可以简单理解为A/B对地的电压，注意此处的“地”是指485通讯芯片的地，即信号地，不是大地）不超过一定范围的情况下才能正常工作，当共模电压超过这个允许范围时，轻则会造成通讯异常（比如上述故障）重则造成芯片损坏。我们保护装置采用的485通讯芯片对共模电压的允许范围是-7V~12V之间。根据一年多来对此类故障的处理经验和相关技术资料的学习分析及相应实验的结果可以基本认定产生上述故障的原因是因为分合电容器或故障时大的电磁干扰导致保护装置485通讯共模电压超过允许范围，造成通讯异常。（分合电容和接地短路故障是变电站产生大的电磁干扰的几种主要情况之一。限于篇幅原因，相关资料和有关工程实验的过程此处简略，如果哪位同事感兴趣，可以找我联系）。

1.3通讯改线应遵循的几个原则

改变装置通讯接线方式主要是为了把共模电压控制在允许范围内，从而来提高装置抗干扰能力。在工程当中通讯接线应遵循下面几个基本原则：

a)采取“浮地”方式，确保装置信号地同装置地（外壳地）分开。

工程当中对信号地和外壳地一定要分清。信号地（或者叫数字地）可以简单理解为装置CPU板的地，保护装置CPU板232打印口的地端子和215端子内部是相连的，它们都是CPU 板的信号地。交流头、电源板的地和装置外壳的接地端子是连在一起的，它们是外壳地。在早期出厂的RCS保护上，CPU板的地（215端子）是和电源板交流头的地连在一起再接大地的。这种接线方式，不仅对通讯有影响，在某些干扰严重的情况下，甚至有可能引起保护的误动作。所以现场接线应保证装置CPU板的信号地跟装置外壳地独立。

b)把从总控单元到各保护装置的通讯地短接在一起，确保共模电压在允许的范围内。

按照485通讯方式的规定，发送端的共模电压小于3V，如果各装置和总控单元的485通讯地连在一起，理论上他们是等电位的，可以基本保证接收端的共模电压不至于因为外界的干扰造成超过允许范围。上述两个原则要结合起来效果才好，比如如果装置通讯地和大地相连，虽然通过把总控和装置的通讯地短接在一起，但因为总控和装置的通讯地跟各自安装地点的大地相连，当分合电容时会造成各地电位之间存在压差。如果干扰源内阻较大可能不会有太大影响，如果干扰源内阻较小会造成通讯地连线上有较大的环流，同时伴有强烈的高频干扰信号。所以既要把通讯地连在一起，同时也要保证信号地的“浮地”。这样即使大的干扰在连接通讯地的导线上耦合出较高的电压，因为信号地是“悬空”的，产生不了环流，同时总控和各装置的通信地是连在一起的，这样把共模电压也能控制在允许的范围内。短接总控和各装置通讯地可以单拉一根线，也可以利用1419通讯电缆中不用的另一对双绞线。比如蓝和蓝白这对双绞线接485的A、B，剩下的桔和桔白绞起来接装置通讯地。在现场这种办法实施起来更加简便一些。

c)1419屏蔽线各段接续在一起，遵循“单点接地”原则，在总控单元处接大地。

我们工程上常用的1419通讯电缆的屏蔽层要保证接续良好。我们都知道屏蔽层如果不接地（此处指大地）是不起任何屏蔽作用的。虽然屏蔽层是单点接地还是首尾两点接地还是一端直接接地另一端经过电容接地哪种屏蔽效果更好，似乎还有一些争论。但是目前最主流的看法还是传统的单点接地效果最好，工程上的实践也基本验证了这一点。个人认为如果变电站接地不太好，操作或故障时地电位存在较大压差时，两点接地和一端直接接地另一端经过电容接地（对高频信号，电容可以视做短路），都会在屏蔽层中产生环流。另外屏蔽层上也有大量的干扰信号，所以也不太适合用屏蔽层来短接各装置通信地。还是“各尽其责”让屏蔽层单起屏蔽作用为好。在总控单元处接地是考虑到同开关柜相比，主控室的地应该更好一些，运行中的电磁干扰会相对小一些。工程当中要注意确认总控单元的外壳地是否可靠接大地了，在总控外壳可靠接地的前提下，屏蔽层直接接到总控外壳地上即可。有些站看上去管理机外壳地同所在屏柜的地接在了一起，但因为用户施工原因造成屏本身接地不好，管理机就等于没有接地。在现场应注意实际测量一下，严格测量接地现场条件肯定不具备。可以采用测量管理机所在屏的地和不在同一排的某个保护屏的地之间的电阻的方法来大体推断。因为保护屏接地都比较严格，但通讯管理机所在屏往往属于用户远动班管理，往往不注意屏的接地。（尤其要特别注意通讯管理机是后加在已有屏上的情况）如果管理机所在屏同保护屏两地之间阻值较小，基本上可以认为管理机接地没问题，如果阻值较大，基本上可断定接地有问题。现场曾经发现过两个屏的地之间竟有几十K电阻。

d)通讯接线方面其它的注意事项跟我们以前强调的基本一样：

☆尽量采用1419通讯电缆，如果现场没有1419电缆，选择其它信号的通讯线时要注意双绞线的绞距越短（通俗讲就是绞的越密）它的抗干扰能力就越强。

☆通讯走线要采取“菊花链”方式把各装置串接起来，尽量避免“T接”和“星接”。现场经常碰到一种情况是：分散安装的装置，开关柜厂家配线是已经把485通讯口引线到柜

内端子排了。他们配线时往往是用的普通线，有时即使用了所谓的通讯线，双绞的也不是很紧密。如果我们在开关柜端子排上接通讯线一方面这就成了要避免的“T接”方式，另一方面他们的通讯线和1419的电阻特性也不匹配，会造成信号反射或衰减。所以请大家在现场接线时不要怕麻烦，两段1419通讯线应直接在装置背部端子上并接。

☆如果总控单元通讯口够用，尽量不要让一条线上挂太多装置，特别是分散安装的装置尤其要注意这一点。对集中组屏的装置，数量稍微多些一般倒没太大问题。如果通讯线距离很长，可适当降低通讯速率，其实对大多数工程而言9600bps的通讯速率也够了。

☆关于首尾两端485通讯A、B之间是否要并120欧匹配电阻，要视现场具体情况而定。并不是并上就更好，现场也曾发现跳上匹配电阻后，通讯反而不好的特例。其实按照我们常用的通讯距离和通讯速率来讲，理论上是可以不并匹配电阻的。工作当中个人的感觉是并和不并效果差别不大，大部分情况下还是不并吧。

1.4接线示意图

a)对分散安装装置：

b) 对集中组屏装置。出厂时屏内装置的通讯口（以前设计都是B口）和CPU通讯地（215端子）都已接好引至端子排（TXDZ）上了。接线时如果需要几个屏接到总控一个通讯口要注意首尾连接，防止“T接”。

1.5 公司各种通讯管理机的485通讯地

RCS96系列保护测控装置的485通讯地非常好找，一般是CPU板的215端子。有些装置485口的通讯地往往没引出来。对这样情况，我们可以找跟485口在同一块板子上的232口的地来代替，因为一般来说他们的信号地在内部是设计在一起的（当然也有例外）。下面把自己了解到的各种通讯管理机的485口通讯地的情况整理如下，便于大家在现场接线。

a)9691/9692/9693这三种通讯管理机硬件是一样的，只是程序不一样而已。可以当485口使用的是C3/C4/C5/C6和C13/C14这6个口。C13和C14这2个口是可通过跳线来选择232和485方式的，所以后端子上232口的GND跟485的通讯地是一个。C3~C6是422方式，但可以接成485使用。这4个口的通讯地内部已经跟电源地（即外壳地）连在了一起。所以如果用这4个口，短接各装置通讯地的绞线直接接外壳地即可。虽然这样看似不能做到完全的“浮地”，但单点接地也无大碍。因为C13/C14两个口接485方式方便一些，不用象C3~C6口那样还要并线，所以以前现场接线大家好用C13/C14。不过从运行情况看，C13/C14这两个口抗干扰性能似乎比C3~C6口要差，建议大家在现场改线还是用C3~C6口。

b)9698总控单元对下通讯口决大部分都是232/485复用，485的通讯地接本通讯口的232GND端子即可，说明书上标的很清楚。

c)9698A总控单元CPU板上C3~C7这5个485口的通讯地跟C1/C2这2个232口的GND相连。扩展通讯板4个口是232/485/422方式，通过组态配置控制继电器切换来实现的。只要把其中一个口设为232方式，它的GND就是该板的信号地。要注意CPU板J22跳线跳上则串口地和外壳地相连，建议最好不要跳上，一般出厂是不跳的。

d)9794/9784/9794管理机扩展通讯板485的通讯地跟同一块扩展板上其它232口的地是一致的。要注意扩展通讯板内部有个跳线，当该跳线跳上时，该板的信号地通过1个电容跟外壳地接在一起。出厂该跳线一般不跳。

1.5备注：

通过一年多的工程实践，采用上述原则改线，大部分情况下是效果明显的，也解决了很多长期存在的问题。但这种方法只是通过改变外部通讯接线的方式来提高装置的抗干扰性能。如果某个站的干扰情况很严重（从我们目前工程手段上来说，对干扰大小很难有一个实用的量化判断标准，不是单单看一个现场是否接地良好就能判断出的问题），改线后可能效果会不甚明显。比如北京密云西至变，这样改线后，合电容器时还是会经常出现电容器保护通讯中断的现象，只是改线后出现故障的次数比改线前少了。对此情况，可以再放一根控制电缆把经常出问题的电容器保护装置外壳地跟总控屏的大地连在一起。如果让用户单独再放控制电缆比较困难，可以用1419电缆把2对绞线都绞在一起用，效果也还可以。西至变到最后就是通过这种方式把问题最终彻底解决的。

2、RCS9000后台经常报某个装置的故障测距报告，但这个装置本身根本就没有距离保护。

2.1 故障主要现象

a)该现象常出现于采用RCS96系列保护测控装置构成的我们自己的综自系统中。后台事项里会报出某个装置的故障测距报告，记录的测距距离故障电流等参数往往都是0，但这个装置本身根本就没有距离保护，比如最常见型号是9611或9681。该现象一旦出现后往往会重复报，但没有什么明显的规律。大多数情况是固定的报某一台装置，偶尔也会报出别的装置的测距报告。

b)现场即使把报测距报告的这台保护的报告清除，保护装置掉电；总控重启或后台

重启后，故障现象依旧存在。

c)出现这种情况的站往往是投运以后一直正常，从某段时间开始才频繁出现该故障现象。如果你跟用户了解一下情况，可以发现一般是在该站某个保护设备做过定检以后不长时间就出现此现象了。（要注意：往往并不是后台报测距报告的那台装置保护定检）。或者查一下，是否某个装置老频繁启动（大部分情况是定值下的不合理，负荷情况变了；当然也有可能是装置某个回路有故障，但这种情况极少）

d)该故障跟总控单元型号无关，不管是9698还是9698A都出现过该现象。跟后台版本号无关，96系统后台从V2.04到V2.07都发现过该现象。

2.2 分析过程

后台显示的故障测距报告把收到的保护报文（测距是ASDU4）直接解释的。保护装置的名称是根据数据库设置里保护设备的地址跟通讯报文里的装置地址对应起来显示在后台的，后台自己不会产生ASDU4报文。而总控单元对ASDU4测距保护报文是过路转发的，即总控收到装置的ASDU4报文，不会做任何处理，直接转发给后台。所以总控它自己也不可能产生该类报文。据此判断，该测距报文应该是装置发出来的。通过在两个站现场同时检测后台和从后台看到的报测距报告的保护装置的通讯报文，发现后台报出来的测距报告却不是该地址的装置发出来的（比如后台报4号地址9612的测距报告，检测中发现后台报出来4号的测距了，但实际上该4号地址的9612并没有发出该报文）。清掉装置报告并不能解决问题的现象也说明了这一点。所以实际上出现该问题的原因是某台装置在某种情况下发出了1条ASDU4测距报文，但报文里打的地址却不是自己的。限于篇幅，具体原因不再分析，简单说跟装置对扰动数据（录波数据）的传输处理有关。当保护定检时（或频繁启动），短时间内会产生大量的扰动数据（虽然因为装置内存空间有限，实际存在的波形数量有限，大部分被冲掉了。但在后台没有把扰动数据要上来之前，装置里面的扰动数据表里波形的数目是不断增长的。这一点从装置上送的ASDU23报文里看得很明显。当这个数目大到一定程度就可能出问题。

2.3 处理措施

a)在现场最立杆见影的处理方法是把站内所有RCS96系列的保护装置的报告都清掉，复位。（注意，必须先要征得用户的同意。另外是站内所有的96系列保护装置都要清）。经此处理后，后台就不会再报了，偶尔会再报一次，然后也不会再报了。当然如果我们能查出来是哪个装置发出的测距报文，单清这台装置的报告就行了。但实际上这很难做到，所以简单起见就全部清吧。

b)清装置的报告（主要是清扰动数据数目）只是一个暂时的解决方法，还应做下列处理。查一下后台的Rcspro.ini里扰动数据传输的设置，是否把后台要录波功能封掉了。因为扰动数据的传输量非常大，以前有一段时间，大家在做工程时为了提高信号上送后台速度，好把后台录波功能封死。（这种做法在工程人员内部相传，曾经很普遍）。一定要把要录波功能打开。具体方法：打开D:\RCS_9000\Data\rcspro.ini文件（用写字板或记事本程序）

[EnableKernel]

DISTURB_DATA_AUTO=TRUE（该项设置如果设为FAUSE则不会自动要录波。TRUE为功能允许）

DISTURB_SAVE=TRUE

其实为了日后分析事故，即使没有上述问题，在现场也应该把后台录波功能打开的。

c)如果保护装置的通讯口用的是B口（最下面的那个485口），改为用A口。对分散装置，改线可能要容易一些。对集中组屏的装置，以前设计都是用B口，因为组屏设备端

子是焊线的，改起来很麻烦，用户可能不会同意。建议可以跟第1条提到的通讯接线结合在一起实施。

d)如果有装置频繁启动，要查找一下真正的原因。同时最好跟用户建议一下，日后再做保护定检时，做完后把装置报告清除。（注意跟用户说时要注意措辞，只说做完实验清报告便于以后真正的故障跳闸后，装置报告记录里没有多余无用的报告，便于查找分析就行了）

e)出现上述问题的装置程序都是2004年以前的。如果装置程序是2004年的则没有必要把用串口B改为用串口A。如果上面的4条措施都不能彻底解决误报问题，最后的办法就是更换装置程序为最新的2004年的版本。但个人认为，更换程序牵扯到重新校验还有市场影响等问题，单为了一个通讯误报测距报告就更换保护程序实无必要。而且采用上面的几条措施后（有2个站因为条件所限，并没有改串口），效果都很明显，未再发生同类现象。

f)对一些没有我们后台且RCS96装置是采用103规约通信的老站，为了防止扰动数据上不来造成这样那样的问题。在9698A/B程序里对此采取了一定的措施：如果没有后台或后台录波功能被封死了，9698A/B总控会自动召唤装置扰动数据，但不会保存。该功能应该是在V3.42以上版本的程序里都具备了。

3、后台没有报装置通讯中断，但从后台看到的装置上送的遥测数据不刷新，位置也不对。

3.1 故障现象

a)该现象一般发生于采用9698A/B总控装置，在开关柜分散安装的96系列保护测控装置上（比如9621）。用户反映的现象是从后台看该线路遥测数据不刷新，开关位置也同实际不符，现象就象装置通讯断了。但后台并没有报通讯中断。监视装置通讯报文，发现装置一直在报DFC=1（103规约里，DFC=1规约原文意思是装置接收缓冲区满，不能再接收命令）。总控在查询链路状态（但大部分情况是总控在发复位通讯单元命令（40），装置回确认命令了，但因为DFC一直为1，总控不认还是继续发40复位命令，不断的死循环。

b)采用9698总控的站不会发生此现象。别的公司后台采用103规约但没用我们的总控直接跟RCS96保护装置通讯的也一般无此现象。

c)发生此现象后，复位总控装置一般不会奏效。复位装置后故障马上消除。

3.2故障现象分析

a)正常情况下，总控发象遥控选择或执行等以68H开头的可变帧长的“长命令”时（相对于要一、二级数据这种以10H开头的固定帧长的短命令）。因为装置负责通讯的“小CPU”要和296主CPU交换数据，装置的应答确认报文会把DFC位置1。9698总控对此标志位是不做处理的。9698A/B总控的处理是严格按照103规约的要求，会马上查询装置的链路状态。在这个时间里，装置小CPU已完成和296主CPU的数据交换。对总控的查询命令，会应答“链路状态”正常（DFC也变为0了）。然后总控恢复正常的轮巡过程。具体过程可见下面的报文示例：

68 09 09 68 73 45 07 81 09 45 ff 00 0d 9a 16总控对地址69的装置启动总查询

10 30 45 75 16 装置确认（注意控制域30H，说明DFC=1）

。。。。。。。。。。。。

10 49 45 8e 16 虽然装置上送的ACD=1，但因为DFC=1，所以总控没有先要1级数据，而是

查询链路状态

10 2b 45 70 16 装置确认，功能码0bH代表“链路正常”。此时ACD依旧为1，DFC已经为0了

在往后就是正常的查询应答报文了。

b)当在某种异常情况下，总控下发的长报文命令，装置DFC=1一直没有清零。装置回答查询链路状态的命令，装置回答的是3Bh。虽然装置回了“链路正常”，但因为DFC一直为1，总控还会继续查询链路状态（发49命令），这样会一直死循环下去。造成遥测数据和开关变位都上不去（实际上是装置有1级数据也要求访问了，但总控一直在查链路状态，根本顾不上问要求1级数据命令，更甭说要2级数据了。所以变位不上，遥测不刷新）。北京雍合宫站的报文例子如下：

TXEN 68 0a 0a 68 73 99 40 01 0c 99 01 30 02 00 25 16 WAIT RXEN

RXIL 10 30 99 c9 16 RXIL

RXIL 10 30 99 c9 16 RXIL

。。。。。。。。。。。。。。。。。。。

10 49 99 e2 16 WAIT RXEN

10 49 99 e2 16 WAIT RXEN

RXIL 10 3b 99 d4 16 RXIL

RXIL 10 3b 99 d4 16 RXIL

。。。。。。。。。。。。。。。。。。。。。

。。。。。。。。。。。。。。。。。。。。。

10 49 99 e2 16 WAIT RXEN

RXIL 10 3b 99 d4 16 RXIL

（之后20分钟还如此，复位总控，回答10 30。一直死循环过10分钟通讯恢复）

c)还有一种现象是总控一直在发复位命令，装置也会确认了，但DFC=1一直置着。所以总控不认DFC=1的确认命令，继续发复位命令，装置DFC还为1，一直死循环下去。比如：北京魏善庄的例子：

TXEN 10 40 45 85 16 WAIT RXEN

RXIL 10 30 45 75 16 RXIL

。。。。。。。。。。。。。。

TXEN 10 40 45 85 16 WAIT RXEN

RXIL 10 30 45 75 16 RXIL 一直重复，复位装置后通讯恢复。

d) 9698A/B判装置通讯中断是看在一定时间内能否受到一定数量的报文，而不会管报文的内容。虽然DFC=1一直持续，造成进入一个死循环。但装置的应答报文是符合逻辑的，因为一直有报文上来，所以总控自然报不出通讯中断来，虽然这时候任何有效数据也上不来。在后台表现出来的现象跟通讯断了是一样的。

3.3 处理措施

a)这种现象在以前投运的老站出现的也比较多，我个认就遇到过5次了。虽然复位装置肯定马上就好了，但过一段时间还会出现。具体原因不好说，但从外部条件上来说跟上面提到电磁干扰和扰动数据传输似乎也有一定的联系。对此问题，可以参照上面的处理措施来预防。比如改线、改串口、打开后台录波、避免装置频繁启动等措施。

b)总控采用9698的站基本无此问题，我个人认为是因为9698的程序不判装置的DFC 是否为1，即使装置DFC一直为1，也不可能陷入上述的死循环过程。另外象四方、东方等厂家直接用103规约跟RCS96保护通讯的，也是按忽略DFC来处理的。实际上正常情况下，装置内部通讯“小CPU”和“主CPU”交换数据是非常快的，不考虑DFC状态，按照目前常用的19.2K通讯速率而言，应该没有太大问题。曾经在现场做过一个实验，装置进入DFC=1的死循环后，我没有简单的复位装置，而是拆下装置到总控的通讯线，用波士485/232转换器把笔记本接到装置串口上，模拟总控发命令。发现如果我忽略DFC=1，问装置1级数据，装置

正确响应（虽然DFC还为1）。而且问着问着，装置自己恢复把DFC置0了。实验的通讯报文记录如下。所以如果改线和改口后，DFC=1死循环现象还很严重，可否给9698A下一个象9698一样忽略DFC的程序呢？。

TD:10 40 4E 8E 16 (13:33:48:336)

RD:10 30 4E 7E 16 (13:33:48:467)

TD:10 49 4E 97 16 (13:34:24:769)

RD:10 3B 4E 89 16 (13:34:24:889)

TD:10 49 4E 97 16 (13:34:46:069)

RD:10 3B 4E 89 16 (13:34:46:190)

TD:10 7A 4E C8 16 (13:35:37:604) 不管DFC=1，问1级数据

RD:68 15 15 68 38 4E 05 81 04 4E C6 03 03 C4 CF C8 F0 BC CC B1 A3 01 00 01 00 53 16 (13:35:37:734) 装置正确响应。上来的是响应复位命令的ASDU5报文。虽然DFC还为1

TD:10 49 4E 97 16 (13:37:09:205) 很奇怪，我再查链路状态，装置不响应了。

TD:10 49 4E 97 16 (13:37:19:350)

TD:10 49 4E 97 16 (13:37:20:301)

TD:10 40 4E 8E 16 (13:37:42:503) 手动发复位命令

RD:10 20 4E 6E 16 (13:37:42:623) 在没有复位装置的情况下DFC自己恢复了。

TD:10 49 4E 97 16 (13:38:12:967)

RD:10 2B 4E 79 16 (13:38:13:087)

4、备注:

一些老96综自站的用户反映系统频繁误报信号。故障原因跟上述的第一条和第二条可能都有关系。但造成误报的原因会很多，未必都是装置原因造成的，有些是外回路问题，有些是通道或者主站问题，有些是总控程序或组态设置等等的问题，这都需要到现场具体情况具体分析。如果在现场实在不能明确分析出原因（好多用户反映的误报，等你到现场后，怎么做装置都正常。故障现象往往抓不到。）不妨就按照上面提到的处理原则，做一些预防措施。按照以往的经验，大部分情况下是有一定效果的。