Topic: Civil 3D Pipe Lengths - It Just doesn't Add Up

[Dinosaur]

Has anyone else tried preparing storm sewer plans in Civil 3D?  If so, have you noticed that the length labels for the pipe runs in plan view will differ slightly from the length generated in the profile label?  Even more vile, It is quite common for neither length to be the true length of the run.  My pipes are set to run from inside face to inside face of the structures, the structure walls are all set to be 6" and I have requested the 2d pipe length rather than 3d.  My alignments have a PI at each wall face as well as the center of the structure and the structure locations are correct on the plans, yet a run that should be exactly 31 feet across a street will label the correct length in plan view most of the time but almost invariably yield a distance as much as 0.05 plus or minus but never the true distance for the length label in profile and longer runs will have even greater error.  This throws off the slope calculations in many cases and the flow rates that I must show and match to the hydrology calculations are never the same.  An associated problem, the pipe runs themselves seem to be quite unstable and will snap away from the structure walls to the center point of the structure with very little provocation, which in turn blows out all of the lengths and slopes yet again.  None of these problems appear on my sanitary sewer plans which have the pipe running to the center of each structure.

[Cannon]

The table has a very specific property. Are you sure they're calling the same thing? We built that table to be 2D length IIRC.

[Dinosaur]

I am pretty sure they are calling the same thing.  I have a base plan xref to start from with the alignments and networks created in the storm sewer drawing.  I create the pipes and structures on top of the alignment with a basic set of rules and edit all of the structure and pipe properties to their design values.  To make this work, I have been dragging the pipe endpoints to the appropriate structural walls and edit the results in toolspace.  All of the numbers in toolspace seem to be correct but when I add the labels, I get the condition I described. I am including screen shots of a typical result in plan vs. profile label result.

[Cannon]

Without seeing the label styles, I can't tell you. Try changing one of those labels to the other's style and see if they match up. I'd still be it's a style issue.

BTW, nice work on the pipe flow labels and expressions. One of my favorite things to build.

[Dinosaur]

I tried switching labels - the plan label returns the correct 2d length when I use it in the profile view, but the profile label just dissapears when I tried to use it in the plan view.  That may be because I aam specifying an elevation for the origin of the profile label.

The annotation in the plan label works most of the time unless the pipes revert to joining at the center of the box.  In both styles the anchor component is the feature.  The The contents from the label composer are as follows:

<[2D Length - Center to Center(Uft|P2|RN|AP|Sn|OF)]> L.F.

Compare to the contents of the profile label from the label composer:

<[2D Length - To Inside Edges(Uft|P2|RN|AP|Sn|OF)]> L.F. OF
<[Pipe Inner Diameter or Width(Uin|P0|RN|AP|Sn|OF)]>"%%C CMP
@ <[Pipe Slope(FP|P2|RN|AP|SD|OF)]>

When I change the highlighted areas in both styles to "inside edges" both labels yield the same wrong distance.  When I make them both "center to center" the profile numbers are 0.01 off in this case but as much as 0.03 for other similar pipes.

The length differences are rarely more than a few hundredths but It drives the reviewers insane if I leave them different so I am ending up with a child style with the correct length entered directly for each offending pipe.  It does not seem to matter if the box falls on a curve or in a straight section of street or if the pipe is meeting the box at a skewed angle or straight.

[Dinosaur]

BTW, nice work on the pipe flow labels and expressions. One of my favorite things to build.

Thanks, but I can't take full credit.  The inverts and basic labels are mine but I haven't mastered the expressions to get those Q and velocity numbers into the labels.  Those are still just simple blocks of mtext with values copied from our hydrology calc chart . . . but I AM listening. 

[Cannon]

You'll have to came to AU. Can't giveaway all my best stuff. 

[Dinosaur]

You'll have to came to AU. Can't giveaway all my best stuff. 

But I am going to buy your book . . .  . . . will it be in there?

[Cannon]

I honestly don't know, Dana's on pipes, and I haven't read it yet.

[Dinosaur]

OK, here is a second chapter to my rant about labeling pipes.  I have heard some grumbling about it in various forums, but now it is biting my keester big time.
I absolutely CAN NOT use Civil 3D structure labels in plan view for my current project containing seven different sewer lines.  The fixed insert point for the label no matter the viewport's rotation is making it impossible.  I have viewports twisted in every direction except straight up with usually several labels visible in multiple viewports and nearly always at least one common to two different lines in every viewport.  These labels can be positioned to appear correctly in one view, but in most other viewports they look poorly placed at best and in many cases they are interfering with or completely obscuring vital information.  Short of making multiple label on different layers for my nine different viewports, I have no choice but to make the structure labels with mtext and make the Civil 3D labels on a no-plot layer.
Do these software designers think that all projects are basic rectangular grid layouts with 2% maximum slopes or what?

[LE]

Do these software designers think that all projects are basic rectangular grid layouts with 2% maximum slopes or what?

That's a good one!!! yes

[MMccall]

Share the pipe networks out to separate 'one sheet only' drawings and label them there to work with the location and orientation of each sheets viewport.     Xref and share other data as needed to complete the rest of the sheet.

[Dinosaur]

I know, I appreciate the suggestion and that is the only compelling reason I have ever seen for the one tab per drawing argument.  I have always put multiple sheets in one drawing - even in the old r13 - EaglePoint days and have a lot of shortcuts (and yes habits) that save me considerable time especially at the very start when setting up the sheets and near the end when one group of notes or something similar needs to be done on each sheet.  Very much so when some moron has added new linework on new layers in the base drawing that just CAN'T show up on those sheets.  Whatever, the deed has been done now; they are all in one drawing for this project and my structure labels must be in mtext.

[jpostlewait]

Sorry to hear that.
We have been a one sheet one file structure for a while.

Wow an insert flash button. Have no idea what the teletype button does.
Helios is pretty cool. Don't like how to get to P.M.'s but small thing.

[Dinosaur]

Sorry to hear that.
We have been a one sheet one file structure for a while.

Wow an insert flash button. Have no idea what the teletype button does.
Helios is pretty cool. Don't like how to get to P.M.'s but small thing.

Yes, I think the multiple tabs thing would be more a problem in an environment with a lot of users working on each project.  We very seldom have more than one person at a time pushing on a single project.  Even when all three of us join forces, breaking things up into street, storm, sewer, grading, plat keeps everyone of all of the other's toes.  I will try to remember to give it a try, but some of our projects are so small it may be more cumbersome.  The last full project out was so small, I kept the whole thing in the model with zero xrefs.

Do you have the top header expanded all the way showing your avatar?  If so, the top line should say something like" Hey, jpostlewait, you have ### messages, ## are new.  Just click on the number of messages and you are there,