Hello Julie Hamilton
The FDRMGRNONTRACEABLE model name can be used on a feature class as whole or specified on a feature instance level in order to prevent Feeder Manager from traversing the feature during tracing.
This can be used in certain parts of your network model to prevent loops and other network anomalies that would otherwise exist in a purely connectivity driven model.
Here is an example use case: Substation Equipment Traceability - Blair Services
For more details see our resource center:
Hopefully this makes sense. Let me know if you still have questions.
One additional note:
If you assign the model name at the class level, all features in that class will be non traceable.
If you assign it to a Boolean field (True/False) on a feature class then only features with that field set to "True" will be non traceable allowing for more control.
Hopefully this helps.
In this case, the model name is is assigned to a long integer field on our OH/UG secondary conductors. I struggle to understand its purpose. After testing, I can still trace features regardless of the value in this field.
The FDRMGRNONTRACEABLE model name may be assigned to a feature class or to an attribute field. If it is assigned at the feature class level, the entire class will be omitted from Feeder Manager traces.
You may also create a Feeder Manager NonTraceable Indicator field to which the model name is assigned. Below is required data type and domain for this field. You may change the name of the field, but the FDRMGRNONTRACEABLE field model name assigned later must have the EXACT spelling.
Feeder Manager NonTraceable Indicator
The user will be able to select Traceable or NonTraceable for individual features.
If you created a FdrMgrNonTraceable field on one or more edge feature classes, you may also wish to create a domain to be applied to fields carrying the FDRFieldiMGRNONTRACEABLE field model name (this model name will be assigned in the next step). This will make the field contents easier to interpret, and will enforce a restricted range of values for that field.
- Field Type: Compatible with fields with model name FDRMGRNONTRACEABLE
- Domain Type: Coded Values
- Split policy: Duplicate
- Merge policy: Default Value
Thanks again for your reply. I read this information before I posted the question and have checked that all requirements were met although, I am not getting the expected behavior. That is, features with the value set to NonTraceable or 1, are still tracing with the ArcFM trace tools. With your confirmation, I can move on to other possible causes.
Did you check that your featureClass is ArcFMized?
I'm aware of cases for primary and secondary conductors in the distribution system where some customers use a FDRMGRNONTRACEABLE field to help designate spans that are de-energized. In this way, ArcFM traces should not trace the span in any circumstance. There are other ways to accomplish this behavior (like setting a PHASEDESIGNATION to 0), but the FDRMGRNONTRACEABLE should be a sure fire way to stop ArcFM tracing -- though of course ArcMap tracing has no knowledge of this.
Thank you for the reply Ed.
I am investigating ways to get feeder manager to ignore secondary conductors in a mesh network where we have numerous cross connections on the distribution side of the transformers. This causes the values in the feederID fields to be incorrect for all connected upstream features. The effort to find and fix all of these errors is insurmountable given the resources.
If I turn the phase designation to 0, will that prevent feeder manager from updating the feederID fields based on the connectivity of those features? Another option we are investigating is to set the enabled field to false and the Feeder Manager setting to respect this value.
Thanks again Ed.
For dealing with mesh networks we usually do something like setting the primary just upstream of the network transformer to non-traceable. This prevents traces initiated within the mesh from leaking out into the radial network. Of course it also prevents traces from the radial network to enter the mesh -- which is something you'd probably like.
Really, the network transformers - or specifically the network protectors on the transformers - should provide an one-way barrier to a trace. Kind of like a check valve.
ArcFM/Feeder Manager doesn't do this now, but its been suggested for inclusion. (And maybe if someone buys John Bennett a beer or something).