Digital Automatic Voltage Regulator(DAVR)

Hello everyone,, Myself into operation of a co-generation plant with three GE make frame 5 gas turbines with [email protected] with Mark-VIe control system. In the generator control panel we have Beckwith make generator protection relay (model:M-3425A) and the DAVR is of Brush make (Make: BRUSH, Model: PRISMIC A32 Excitation Controller ).
Now, one message (Communications are down for both channels) has appeared on the screen of the AVR.
Screenshot of the AVR is attached herewith for your convenience. Due to lockdown we can not call Brush engineer from UK to India.
Our esteemed forum may kindly help in the following issues
(i) needful action to be done taken right now from our side for resetting this communication down message.
(ii) May please also confirm that the communication down message of the AVR will impact the normal operation of the AVR or not.
Regards
 

Attachments

Hello, Jagriti,

1) What have you done to troubleshoot the problem--and, most importantly, what were the results?

2) Have you RTFM? (Read The ... Fine Manual) What does it say about this alarm message?

3) What are ALL of the other Alarm messages on the DAVR with the communication alarm message?

4) Is the unit with the communication alarm message running? If not, have you tried re-booting the DAVR, and if you haven't--why not? If the unit is running, when is the next possible shutdown when the DAVR can be shutdown?

5) Since you can't bring the service person to your site can you communicate with the person or someone in Brush's technical support department by telephone and/or email for help with this problem?

6) Do you have any clue what these two failed communication channels are used for? Is there DAVR data usually available on some HMI or other screen or display in the control room that is now not showing data? (This missing data might indicate what the communication channels are used for.)

7) If the unit is running can the VAr or power factor of the generator be changed? (That would indicate that the DAVR is receiving commands to change generator terminal voltage or field voltage/current from the HMI/operator interface being used to control the generator terminal voltage. If the VAr or power factor of the running generator cannot be used to change the VAr or power factor of the running generator, that would indicate the DAVR is incapable of being used to control the generator.)

8) Have you consulted the drawings provided with the DAVR when it was installed and commissioned to try to determine what communication channels the alarms might be referring to (presuming the alarm refers to external communications, such as to the Mark* VIe or a control room operator interface/HMI)?

It is strongly recommended you consult the DAVR manual for information about what might be causing the alarm, and consult the drawings provided with the DAVR when it was installed and commissioned and then contact the technical support department of the manufacturer with information and questions and be prepared to tell them about any troubleshooting you may have done and what the results of the troubleshooting were.

Many companies recognize they can't send their personnel to site because of the pandemic lockdown and are more open and willing to support their equipment via telephone and email than in the past. It can't hurt to try.

Please write back to let us know what you learn from your investigations into the questions above, and how you fare in resolving the problem!
 
Hello, Jagriti,

1) What have you done to troubleshoot the problem problem--and, most importantly, what were the results?

2) Have you RTFM? (Read The ... Fine Manual) What does it say about this alarm message?

3) What are ALL of the other Alarm messages on the DAVR with the communication alarm message?

4) Is the unit with the communication alarm message running? If not, have you tried re-booting the DAVR, and if you haven't--why not? If the unit is running, when is the next possible shutdown when the DAVR can be shutdown?

5) Since you can't bring the service person to your site can you communicate with the person or someone in Brush's technical support department by telephone and/or email for help with this problem?

6) Do you have any clue what these two failed communication channels are used for? Is there DAVR data usually available on some HMI or other screen or display in the control room that is now not showing data? (This missing data might indicate what the communication channels are used for.)

7) If the unit is running can the VAr is power factor of the generator be changed? (That would indicate that the DAVR is receiving commands to change generator terminal voltage or field voltage/current from the HMI/operator interface being used to control the generator terminal voltage. If the VAr or power factor of the running generator cannot be used to change the VAr or power factor of the running generator, that would indicate the DAVR is incapable of being used to control the generator.)

8) Have you consulted the drawings provided with the DAVR when it was installed and commissioned to try to determine what communication channels the alarms might be referring to (presuming the alarm refers to external communications, such as to the Mark* VIe or a control room operator interface/HMI)?

It is strongly recommended you consult the DAVR manual for information about what might be causing the alarm, and consult the drawings provided with the DAVR when it was installed and commissioned and then contact the technical support department of the manufacturer with information and questions and be prepared to tell them about any troubleshooting you may have done and what the results of the troubleshooting were.

Many companies recognize they can't send their personnel to site because of the pandemic lockdown and are more open and willing to support their equipment via telephone and email than in the past. It can't hurt to try.

Please write back to let us know what you learn from your investigations into the questions above, and how you fare in resolving the problem!
Hello ALL,

Jagriti,

I would add some notes on CSA "good questions/comments" I would ask you same questions!

By the way after have look on the screen shot that you shared, looks like unit is running
( voltage & current are displaying live value).

Can you confirm?

Error message:
1Comms disconnected
2Communication are down for both channel.

You should now first know the meaning of these messages ( I mean is that communication between Channel A for Normal / Channel B for standy which is disconnected /down )

Or as CSA asked is the communication between Mark6e or DCS and Channel A&B.
.
If so this is a serious problem !! And looks like unit is runing with such Comm failure
Very very bad/dangerous thing to run the unit in this situation/configuration.


There is a company named SVRI in netherlands, which is working/specialized on BRUSH Prismic AVR equipments .

Here the contact adress of this company:
SVRI Electrical Engineering, Vrijland 11, NL-3271 VH Mijnsheerenland, The Netherlands
tel.: +31 (0)85 0020069, e-mail: [email protected], website: www.svri.nl
trade reg. 72942800 rotterdam, vat: NL132564579B02, bic: INGBNL2A, iban: NL47 INGB 0006053041


You can try to contact them, as you said that BRUSH UK can not come to your site in INDIA.

Without be able to check OEM, manual/drawings our support would be very poor .

My experience on GCP/GPP is oriented, on ALSTOM/GE/SIEMENS GENERATOR CONTROL& PROTECTION PANEL

In case you have such documents, you can share with us we can support by this way.

Regards,
Controls Guy
 
Hello CSA/Controls guy
Thanks a lot for the info ...sorry for delay in response. please note :-
1. We have contacted Brush and they said that most likely the CAN component failure may be reason….may be because of power spikes like from significant thunderstorm nearby. As per their advise we tried to reset the alarm , but it is not going. (I have no idea about CAN component).
2. We have checked n the manual also but found no solution.
3. No specific alarms….will check again.
4. Will try to reboot the AVR in the next shutdown
5. Pl Refer….no-1 above
6. AVR data available in the HMI
7. AVR is communicating with the HMI …eg we can control the MVAR/PF etc.
8. To be checked…not sure, yes may be external communication like MODBUS etc?

Thanks Controls guy for the SVRI details...will try to contact.
Since the AVR is presently working, we are waiting for S/D to happen. During S/D, how to check the CAN component is the issue now. Please give some clue if possible.
thanks again
 
Hello CSA/Controls guy
Thanks a lot for the info ...sorry for delay in response. please note :-
1. We have contacted Brush and they said that most likely the CAN component failure may be reason….may be because of power spikes like from significant thunderstorm nearby. As per their advise we tried to reset the alarm , but it is not going. (I have no idea about CAN component).
2. We have checked n the manual also but found no solution.
3. No specific alarms….will check again.
4. Will try to reboot the AVR in the next shutdown
5. Pl Refer….no-1 above
6. AVR data available in the HMI
7. AVR is communicating with the HMI …eg we can control the MVAR/PF etc.
8. To be checked…not sure, yes may be external communication like MODBUS etc?

Thanks Controls guy for the SVRI details...will try to contact.
Since the AVR is presently working, we are waiting for S/D to happen. During S/D, how to check the CAN component is the issue now. Please give some clue if possible.
thanks again
Hello Jagriti,
Thank you for these clarifications.

The thing that I know is that there is sort of CAN bus transfer used on BRUSH prismic AVR.
Without be able to check out Manuals or Drawing, I can not give much support .
I am speaking of this issue you got , with one of my colleague who did BRUSH Prismic training in Laughborough UK.

I will come back to you if I get more datas/informations to add.

Brush UK may be right about CAN bus transfer causing an issue at your site as you can read on this following doc :
https://pdf.directindustry.com/pdf/brush-group/prismic-a12/26585-871675.html


Regards,
ControlsGuy25.
 
All,

I think this is a much more serious problem--potentially--than originally thought (well, than I originally thought).

CAN bus is a often-used communications protocol by many OEMs and manufacturers. And, from the literature ControlsGuy25 has provided the link to it seems that BRUSH is using it for communicating between a primary DAVR module and a back-up (hot standby) DAVR module to switch from one to the other if there are problems requiring a switch.

I'm SWAGging (Scientific Wild-Arsed Guessing) that the DCS is communicating with the primary DAVR module, possibly even the back-up (hot standby) DAVR module, BUT, that in the event of a serious problem which would normally transfer operation from the primary to the back-up it would not happen (the transfer).

Now, that may or may not be a problem if the DAVR module can be switched to MANUAL control from AUTOmatic control and the operator would then have to pay more close attention to the VAr flow/Power Factor of the generator.

But, that's all a SWAG. From the literature provided, it seems CANbus may also be used to display data on the color screen which is an option for the equipment.... And maybe that's the second channel that's not communicating (yet another SWAG).

In any case, if the unit is running and is capable of being controlled in the normal fashion, it seems to be okay. What you probably DON'T have is the redundancy afforded by the back-up (hot standby) controller that would be automatically transferred to in the event of a problem requiring a transfer. Now, it might be possible for an operator, with training and knowledge of the method required, to manually transfer to the back-up (hot standby) DAVR module in the event of serious problem--BUT, quite often those issues require immediate attention to prevent a unit trip, and so relying on a manual intervention is most often not a good idea (since most operators have never been trained in the procedure and there is not SOP (Standard Operating Procedure) for doing so to refer to in preparation for such and event, which would (should) list the various scenarios which might precede the need to initiate a manual transfer to the back-up (hot standby) DAVR module.

This is where automation has a long, Long, LONG ways to go. Automation by itself is a GREAT thing (in most cases), but when it's not applied properly and when power plant managers and operations managers expect the automation to do everything to keep the plant running and prevent nuisance trips--well, the programming and configuration just isn't there yet in MANY applications. If, in the present state of the art of Automation, the control system was programmed to take preventive action in all cases and not rely on the operator to make some decisions about trying to keep the unit/plant running, well, the control system would be deemed unreliable and a hazard to operations. So, many OEMs and manufacturers leave only the most critical protection functions up to the control system, and leave other not so critical--but still important, nonetheless--to operators to decide what to do. BUT--and this is the great failing of automated control systems today that Power Plant Managers and Operations Managers have yet to understand and recognize--the automated control systems DO NOT properly inform the operator of the severity of the alarm, and provide visual guidance in how to deal with the problem to prevent serious damage while still keeping the unit running if it is deemed critical to do so. So, operators get just ANOTHER alarm, and they don't know what to do, and the unit didn't trip, so they just ignore the alarm. And, often, damage or serious damage ensues.

Automatic control system manufacturers and suppliers/integrators do a HORRIBLE job of communicating the shortcomings of Automation. They do a GREAT job of describing the capabilities of the systems they design, manufacture and configure and install and commission--but the job is far from finished in the the Automation industry. Is AI (Artificial Intelligence) the answer? Or Machine Learning? Probably some combination of the two. But, in the interim Power Plant Managers and Operations Managers NEED TO KNOW that the automated control systems they are using TODAY are still not capable of 100% replacing human operators--and those operators NEED training and procedures for those functions that are left to operators to make decisions about in order to protect equipment (and in many cases human life).

Anyway, I would have a technician look in the manuals provided with the BRUSH equipment for information on the CANbus modules provided with the equipment to see if there are any tests which can be performed on the CANbus modules (while the unit is running, and even when the equipment is shut down). I'm pretty certain there are some basic functions that can be enabled or tested--but that's another type of SWAG (a SILLY Wild-Arsed Guess)!!!

Grounding is very important during electrical storms!!! MANY plants never test their grounding (earthing) grids after initial installation and construction and commissioning. And, it is even MORE important in these days where control systems require both Protective Earthing and Functional Earthing. AND, if control systems (such as the Mark* series) are upgraded to newer generations which employ both earthing systems AND they are not available on older sites AND the grounding is not properly configured during installation and commissioning then electrical storms and serious ground issues with other equipment in the plant can cause unwanted problems. I suspect (the second type of SWAG this time!) the BRUSH equipment is similar in this respect--built for both types of earthing but capable of being installed where only the protective earth is available.

BUT, plants NEED to periodically test their earthing grids during planned outages, using a qualified firm with the proper equipment to do so. It's not time-consuming, and it has identified many serious problems which, when resolved, stopped a LOT of nuisance trips and other control system problems which had driven plants and operators and technicians CRAZY for years. (Sometimes the fix is expensive, but so is the lost revenue when the plant trips "for no good reason").


Best of luck! Please write back to let us know what you find!!!
 
Hello CSA ... Thank you so much for the information. We are contacting these issues again with Brush. Will update again further. thanks all
 
Hello everyone..
As per advice from Brush, we have powered off the AVR ( both 24VDC & PMG), but the screen issue did not go. Then we have reset the AVR also but it remains.
Regarding auto/manual changeover, When contacted Brush, it was informed that there are two CAN link ( from 2 A50s (?) ), namely X10 ( for screen ) and X9 for auto/manual changeover. They feel that X9 might have not failed yet and the same can be determined (whether X9 has failed or not) , if we download the logs & register data from the AVR for analysis. Data download is being done us. We thank M/s-Brush for the inputs. kind regards.
 
Top