Why Did My Trace Do that (Part2)?

Here’s one that’s thrown us from time to time and usually results in a “I could have had a V8!” head slap when we remember the cause (and you think we’d remember after the first time). We’ll start with the familiar experience of receiving the “Trace Returned No Results” message, below. We’re just outside the substation and everything is connected. The primary segment on which we placed the trace flag is just downstream from the feeder breaker.

WDMT2_000

So we check the usual suspects.   We add our “Bit Twiddler” layers to the map and label primary based on “Energized Phases” (below left) and it shows everything, including our flagged segment, to be energized on ABC.  Then we try the Feeder Manager Translator (below right) and it confirms, again, that Feeder Manager thinks our segment is energized, and that it’s not in a loop, doesn’t have multiple sources and is not an island.

WDMT2_001

Just to be absolutely sure about the connectivity we try the ArcMap “Find Connected” trace from the Utility Network Analysis toolbar. Sure enough, everything is connected (below).

WDMT2_002

WDMT2_005
Then we try to trace another feeder in the substation, and that one works!  (At right) So what’s the difference?

We’re sure it’s not the connectivity, maybe it’s something with the circuit breaker? Or possibly the “Source” record that’s related to the breaker?

We examine the breakers and see that both have a PhaseDesignation, Operating Voltage and have inherited a FeederID value from the related “Source” record.

Checking in ArcCatalog we see that the Source class has the required CIRCUITSOURCE model name and the circuit breaker class has the required DYNAMICPROTECTIVEDEVICE model name.   But of course they do, the other feeder would not have traced correctly if model names were not assigned as expected by Feeder Manager.

So what’s left.

Let’s look at the circuit breaker attributes. Everything matches.. except AncillaryRole!  (This is where the head-slap comes in.)

WDMT2_006

Let’s talk about this for minute.

In nearly everything it does, Feeder Manager needs to find a “source.” Usually this is a source distribution feeder circuit breaker.  And it turns out there are a couple ways an implementation can tell Feeder Manager where to find the source.  One is by means of the ArcGIS “AncillaryRole” field.  (Funny name for a database field… makes you think of a sub-title for a mystery novel, like “The Maltese Falcon: The Fat Man’s Ancillary Role”.)

If a class in network with the class model name DYNAMICPROTECTIVEDEVICE HAS an AncillaryRole field AND the value is set to [1] “Source” then the feature will be considered a source by Feeder Manager. So just by changing the value from “None” to “Source” on our breaker feature will resolve the problem.

But there’s another way to do this as well. We can check the option “Locate Sources Using Feeder Manager” in which case Feeder Manager won’t bother with the AncillaryRole field at all.  It will just look in any class that has the DYNAMICPROTECTIVEDEVICE model name and consider any feature that has a related Source record as a feeder source.

WDMT2_007

Summary

Our initial problem was that we were getting a “Trace returned no results” error message for a trace initiated on a primary that seemed fully connected.  We subsequently found that traces on another feeder worked.  After trying several diagnostics we found that our problem was that our circuit breaker source did not have its AncillaryRole field set to “Source” and we had the “Locate Sources Using Feeder Manager” option unchecked.   Changing either one of these conditions solves our problem.  (Cue head slap.)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>