Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890
Hello,
I am working within the same Tier where two different Subnetwork Controllers generate two different SubnetLines:
1724 → Yellow SubnetLine
1734 → Blue SubnetLine
Both subnetworks exist in the same tier but are created from different subnetwork controllers. For clarity, I will refer to them as Yellow (1724) and Blue (1734).
Scenario
I place a starting flag on a feature.
I run a Downstream Trace.
My intention is for the trace to stop at devices where:
OS (Operational Status) = Open
(Configured as an Attribute Filter Barrier)
Additionally:
NS (Normal Status) is used as a Tier Condition Barrier.
Observed Behavior
The trace starts within the Blue subnetwork (1734).
It then transitions into the Yellow subnetwork (1724).
If there is a device ahead with OS = Open, the trace correctly stops at that device.The tracing changes from the blue line to the yellow line, and the tracing process stops at OS=Open.
However, if there is no device with OS = Open ahead and the trace encounters the Yellow Subnetwork Controller, the trace fails with:
ERROR 001890: Invalid subnetwork connectivity, multiple subnetwork controllers with different subnetwork names found.
Expected Behavior
Even if no OS = Open device exists ahead, I expect the trace to stop when it reaches a Subnetwork Controller belonging to a different subnetwork.
I also tried adding a Filter Barrier:
Is Subnetwork Controller = True
However, the trace still returns the same error instead of stopping at the controller.
Question
Why does the trace continue into another subnetwork within the same tier instead of stopping?
Why does adding Is Subnetwork Controller = True as a filter barrier not prevent the ERROR 001890?
Is this behavior by design when tracing across multiple subnetworks within the same tier?
What is the recommended configuration to ensure a downstream trace:
Stops at OS = Open devices, and
Stops when encountering a different subnetwork controller,
without generating ERROR 001890?
Any clarification on correct trace configuration in this type of multi-controller tier setup would be greatly appreciated.
Thank you.
Hi again, @RobertKrisher @MikeMillerGIS
It would be better if I explained it in a little more detail.
UN Version 7
ArcGIS Pro 3.5.5
OS = Operational Status
NS = Normal Status
The Blue and Yellow represent two different Subnetlines within the same Tier Rank, fed from different sources.
These two fe eders are separated in the Subnetwork Definition by a Condition Barrier defined as NS = Open.
Inside Substation 5400, in Cell 1, there is a Circuit Breaker with NS = Open. With a normal Downstream Trace, the trace stops at this location.
Trace 1
As shown in the screenshot, when a Condition Barrier with OS = Open is used, the trace stops at the Circuit Breaker located in Cell 2.
In this case, the trace crosses from the Yellow Subnetline to the Blue Subnetline, and then stops at the Condition Barrier.
This is the expected result.
Trace 2
In this scenario, the Operational Status (OS) of the Circuit Breaker located in Substation 5400 – Cell 2 was changed to Closed.
Additionally, Is Subnetwork Controller = True was added as a Filter Barrier, because after the trace crosses from the Blue cable to the Yellow cable, there is no Circuit Breaker ahead and the energy continues toward the Subnetwork Controller.
However, in Trace 2, even though Is Subnetwork Controller = True is defined, the trace does not stop and instead returns the following error:
ERROR 001890: Invalid subnetwork connectivity, multiple subnetwork controllers with different subnetwork names found.
My question is:
Is this behavior working as designed, or could this be considered a bug?
In our network operations, we use the Normal Status (NS) field for permanent switching configuration.
The Operational Status (OS) field is used to manage temporary switching operations during the day (such as outages, maintenance, or repairs).
At the end of the day, the Operational Status values are synchronized with the Normal Status values. However, during the day we intend to run our trace operations using this configuration.
Thanks,
I also tried using a Condition Barrier with Category = Subnetwork Controller, but I still receive the same error. It doesn’t seem to make any difference in this case.
I think this might be a system limitation or possibly a bug. If a trace encounters a different Subnetwork Controller within the same Tier, we should be able to stop the trace using a Condition Barrier or a similar configuration.
@RobertKrisher I do not want to see the path between the two controllers; I want the trace to stop at the controller. If I manually set a barrier on the controller from the map using Set Barriers, the trace stops as expected. To me, this suggests that the Condition Barrier function is not recognizing the definitions Is Subnetwork Controller = True or Category = Subnetwork Controller.
Also, for a Shortest Path trace you need two starting points. In my case, I don’t know where to place the second starting point, so this is not a viable option for us.
