| Knowledge Base Article #141 - Applying Pre-Fault Voltages to an Impdeance Test procedure |
|---|
| Date | Nov 21, 2006 |
| By | ENOSERV |
| Filed Under | RTS |
| Class | General |
| |
| Issue Addressed |
|---|
| When working with Impedance Elements within a micro-processor relay, many manufactures firmware look for a stable system prior to issuing trips for the relay. |
| |
| Causes of Issue |
|---|
| This creates a problem for RTS, as we currently do not offer an option to the User for applying Pre-Fault data prior to a Static Test procedure. |
| |
| Solution to this Issue |
|---|
The easiest solution to prevent mis-operations of impedance elements based on lack of stable pre-fault voltages would be to remove any Loss of Potential function from the relay settings to prevent the action you see, if this is possible. This is what is done in the SEL and GE-UR series distance relay test procedures by ENOSERV.
If this is not desired or possible, then another solution would be to create the test procedure as an Impedance -> General Fault -> Double FaultW/Deviation test. This procedure allows you to apply Pre-Fault, Fault, and Post Fault conditions to the relay. With the Double Fault option, you can tell the program the impedance value of the relay in RTS-Defines, then in Action Specs deviate the applied Impedance by a factor such as 105% and 95%. This checks for a NO-OP operation (or delayed timed) followed by an operation within a specific operate time. You can check the circle at different points by selection in the User Option Screen. By my experience, this procedure works very when testing within 10-15 degrees of the MTA setting. Once you go beyond that, you will see the relays inherent nature of not operating at a perfect circle when testing in a dynamic fashion rather than a static operation as is typically performed.
The next solution is treating the routine as it has been performed In the past. Previous test procedures were created using what is called "Traditional Code" where the User/Developer created loops and controlled what happend within the loops. With the method, a User/Developer could apply pre-fault conditions and eliminate the problem by controlling the test uint themselves. This would be an immediate solution with a lot of control, but requires a deeper knowledge of internal processes. Although, this final goal may not be effective for the Doble 6000. This unit must know everyting that will occur prior to operating. With this unit, the Pre-Fault condition would be applied, the unit shuts off, then it applied the ramping condition. This could very easily confuse the relay.
What we desire and have plans to achieve at ENOSERV is to add the functionality into the test procedure itself. This requires modification to the interface, but more importantly modification to the code for each test set. This is why the modification has not been made to the point, as it is a large task. It is planned for implementation in the future.
|