Pipe Network Data Reference not keeping Styles

[chris.safford]

Is there anyway to force the pipes and structures when data referenced into a new drawing to maintain the styles of the original drawing and not changing back to a "null" structure style?

[BlackBox]

I'm no expert, but AFAIK, the parts will only display differently if the style defined within the drawing consuming the data reference is somehow different from that of the data reference's source drawing style definition.

If you know both style(s) definitions to be exactly the same, then the only other thing I can think of is to check that all of the subject drawings are associated with the correct project (Toolspace, Prospector, Right Click Working Folder, Associate Project to... , etc.)... But one shouldn't be allowed to add a data reference if not already associated with the working folder's project; really not sure.

Is this only an issue with one project in particular, or the same for multiple?

Just your machine, or other employees as well?

If you still cannot resolve, perhaps post a sample drawing?

HTH

[chris.safford]

After doing a bit of testing, I have concluded the pipe styles are working properly but the structure styles are not.

I have uploaded 2 files:
Basefile (Contains the surface, alignment and pipe network) _XXXXXX_C-SP0001.dwg
"Sheet File" (Contains data references of the surface, alignment and pipe network) XXXXXX_C-101.dwg

Each structure in the LEVEE-RW parts list has its own style.
The issue is, we are using separate files for plan views and profile views and it is a pain to update the styles and if a structure changes in the "design" file, it needs to update in the sheet files (style).

Any help would be appreciated,

[BlackBox]

Keeping Styles in sync is most easily accomplished by undoing a lot of what has been done to make Civil 3D's internal Drawing-level Database viable. Methinks this may only be accomplished at the user level via custom .NET plug-in automation unfortunately.

In the mean time, depending on the version you are using (which is what, so others are aware?), consider the _AeccUiImportStylesAndSettings Command (2011 only, and requires the Subscription Advantage Pack), or the ImportStylesAndSettings Command (2012+). The former will just dump all Styles, whereas the latter will allow you to choose what to bring in.

You'll forgive me, as I do not have time at the moment to take a look at the drawings you posted... Hopefully someone else will come along shortly.

HTH

[rthomas436713]

Is there anyway to force the pipes and structures when data referenced into a new drawing to maintain the styles of the original drawing and not changing back to a "null" structure style?

I was looking for the same answer when I saw your entry, and luckily I've been able to figure it out...mostly. What determines the styles of your pipes and structures when you data reference them into another drawing is your Parts List that you assign to your Pipe Network when you create the data reference. If you go into the Netowrk Parts List, you can set the default style that pipes and structures will have when you place them into your drawing ("Pipes" tab and "Structures" tab within the Network Parts List dialog box; "Style" column under each respective tab).

What was key to my pipes coming in correctly was to make sure the Network Parts List had the same style settings as the root drawing. We are a small firm in desperate need of setting up some consistent standards to avoid issues like this. But the fix was easy enough: Set up the Network Part List as desired in the root drawing, open/switch to the drawing you want to create the reference in, go to Toolspace-->settings tab, and then drag the Network Part list from your root drawing into your current drawing. Overwrite the existing Network Parts List if prompted. If you already have your pipe network reference, delete from the drawing, a recreate the data reference, selecting the Network Parts List you just updated.

The only issue I could see you potentially having is this: you only get to set one style per structure type. If each of the structures you mentioned has its own style, but they are the same structure type (e.g., a 48 inch Cylindrical Junction Structure with No Frame), then the above won't work well for you. But if the structure types are all different, the above will work. Not sure why the same structure type would need a different style beyond existing or proposed, but if you set it to one that occurs more frequently, hopefully the manual changes will be minimized. Hope that helps.

[rkmcswain]

What determines the styles of your pipes and structures when you data reference them into another drawing is your Parts List that you assign to your Pipe Network when you create the data reference.

THIS.....is the answer.
Needed this today. Thanks.

[BlackBox]

THIS.....is the answer.
Needed this today. Thanks.

That only works if the desired Styles (and Parts Lists) exist within the referencing drawing, as data referenced Objects do not bring their original assigned styles with them, which is the case when XREFing an AECC* Object (in display only, the nested Style[s] are not actually copied into the referencing drawing).

Most in my limited experience (so take from this what you like) do not maintain a template with all possible styles, and instead must bring in Style(s) as needed in order to maintain 'clean' or 'light' drawings, which is where the import procedure mention above is a prerequisite step for assigning the appropriate style(s) within Parts List(s).

Cheers

[rkmcswain]

That only works if the desired Styles (and Parts Lists) exist within the referencing drawing

Cheers

And they do for us. We use the same template drawing for both. Thanks.

[indydrafter]

There is still a flaw in this, which we are currently experiencing. We would normally have disparate Parts Lists for Existing Storm and Existing Sanitary. However, we commonly deal with Existing Combined Sewer systems. In order to properly analyze these systems, we need to model them as a singular connected network. In order to model it as 1 network, but consisting of Existing Storm, Existing Sanitary, and Existing Combined parts, we have to utilize 1 Parts List which utilizes duplicate pipe or structure types for each of these network types. It works fantastically within the source/base drawing, but as soon as you create the Data Shortcut and Reference it into a production drawing, all styles adhere to the first default style used.

i.e. You have a 48" Slab Top Cylindrical Structure, but 3 copies of it labeled 48" Combined, 48" Sanitary, 48" Storm with each utilizing a different default style. You model each of these parts into a base drawing. Then you Data Reference the network into a production drawing. In that production drawing, all of the structures will display as the 48" Combined style, since that was the first defined within the Parts List.

We've already customized our Part Catalog to allow for 0" options for wall thickness, rim height, and more...this is due to clients required the inside dimensions being shown within profile and section views and misleading "sumps" within structures when slab thickness is anything but 0". Because of this, we do not have any flexibility in tweaking these part dimension to "trick" Civil 3D into thinking we are using different parts for different structure/style types. This has become increasingly frustrating. I need Civil 3D to do just 1 of 3 things, but it can't do any:

- Allow connectivity between disparate pipe networks (utilize different parts lists for each network)
- Recognize that duplications of the same part utilizing different names and styles should maintain their settings through a data reference
- Forget the duplication in the parts list, just override the style within the base drawing, but force those styles to carry through into data references

Any ideas? Am I missing something?

[rkmcswain]

- Forget the duplication in the parts list, just override the style within the base drawing, but force those styles to carry through into data references

Any ideas? Am I missing something?

Your last item, the one quoted above, was fixed in C3D 2015, SP1.

Unless I'm missing something and misunderstood you.