Topic: Pipe Networks & Labels

[BlackBox]

I'm short on time, and not coming up with what I need in a brief search; hope for some help, which I already know that I should already know... The kicker is, that I used to know, as I remember fixing this, just too long ago.



I'm adding a Sanitary Pipe Network -

I need the pipe to end at the inner wall of my structure, but the rule doesn't seem to be applying.

The minimum cover is wrong, or is at least based on something that I don't care about, and need it to be based on the Structure's Rim elevation (rim elevation is showing as correct)... As example, high point of the run should be Structure Rim elevation - (minus) 3.50 FT

Following an Apply Rules, downstream pipes seem to raise themselves, despite needing to be 0.1 drop across structure?

One of my Structure Labels includes a Block which represents the structure number - the Block attribute is ignored, okay, so be it - I've added text component to correct, but the block doesn't show in dragged state, WTF?


TIA

[mjfarrell]

sample please

[mjfarrell]

you will want to use an expression - to get pipe length to inside or outside walls..and use that in your label


as to rules...IF based on RIM elevation...

it might be easier to build a reference surface using only points at rim centers...and use that as the surface the rule should consider....

[BlackBox]

I need the pipe to end at the inner wall of my structure, but the rule doesn't seem to be applying.

Fixed this - Structure Style, Plan tab, uncheck 'Enable part masking'.

The minimum cover is wrong, or is at least based on something that I don't care about, and need it to be based on the Structure's Rim elevation (rim elevation is showing as correct)... As example, high point of the run should be Structure Rim elevation - (minus) 3.50 FT

Following an Apply Rules, downstream pipes seem to raise themselves, despite needing to be 0.1 drop across structure?

Skipped this - remembered I have the benefit of using SincPac's PIPEELEVATIONEDITOR Command.

One of my Structure Labels includes a Block which represents the structure number - the Block attribute is ignored, okay, so be it - I've added text component to correct, but the block doesn't show in dragged state, WTF?

Still need to figure this out - the Block shows fine when in default label location, but as soon as the label is in dragged state, the block disappears?

[mjfarrell]

is your dragged label

"as composed"


or otherwise?

[BlackBox]

As composed does retain the block; just Not sure why stacked text removes the block component (never realized it was THAT literal Haha).

I rarely use As Composed because it precludes the ability to remove leader justification, and inherently requires a Left / Right if not also Upper / Lower versions of the same style, which is a complete waste to my mind.

Is there a way to have a Structure's Profile Label leader NOT point to the Structure's center when in dragged state?

I've set the default label location to be the top of structure (the MH rim in the case of sanitary), but the leader still points to structure center which is just dumb.

Thanks for all of the prompt replies, MJF.

Cheers

[Jeff_M]

BB, Drag the label straight up, add a vertex to the leaderon the straight up leaderline, PIN the label, drag as desired.

[mjfarrell]

which is a complete waste to my mind.

Is there a way to have a Structure's Profile Label leader NOT point to the Structure's center when in dragged state?

Yes as shown above, and all this label gymnastics, is a long standing issue of all users and pipe labels that autodesk just continues to ignore.
One would think they never saw a set of storm or sanitary plans, ever.  Or if they did, they didn't bother to notice how or why we label things in the real world.

[BlackBox]

BB, Drag the label straight up, add a vertex to the leaderon the straight up leaderline, PIN the label, drag as desired.

Thanks, Jeff - that does help me to 'correct' the leader's attachment to the top of the structure.

I'm still having an issue though, where the leader no longer attaches properly to the now 'as composed' label content... Prior to 'as composed' the leader would attach to middle, etc.

Also, using 'stacked text' removes the block from the label contents as noted above, but I just noticed that it also changes the structure number (located within the block's placement, since the block's attribute is not being used), so that it is no longer the text height specified under Layout tab (larger than the structure content)... Do I really need to add two separate labels (one for structure number, and another for structure content)?

Cheers

[BlackBox]

Okay, changing the dragged state leader's arrow head size to 0.0 fixes the leader's attachment to the 'as composed' content.

[Edit] - I also broke the labels out into 'structure info' and 'structure number' which provides the look I was after; both selected to show the grips in dragged state:

[mjfarrell]

what a hack-fest, right?

[BlackBox]

what a hack-fest, right?

Regretfully, this [still] is.

I'll be using my difficulties & frustrations in this thread to as reference in the beta forums later.

[mjfarrell]

what a hack-fest, right?

Regretfully, this [still] is.

I'll be using my difficulties & frustrations in this thread to as reference in the beta forums later.

Then I encourage you to look at(try) all various pipe and or structure labels; that should give you about 5 pages of defects.

Like why the pipe labels will not go to invert/pipe  end @ structure wall....like we really label them (NOT) center line at end, i.e. center of structure.

[mjfarrell]

OH, and IF they really want to fix a busted up part of pipe functionality...

Let them consider this....

Let say one has a pipe run that starts someplace and ends at the desired connection point, like an existing manhole.
Now consider that it doesn't match vertically like top or bottom existing pipe...

One should be able to go to furthest pipe and raise or lower as required, and have that change ripple through all pipes and structures in that run.

As it currently exists, one must manually edit each pipe in the run. because each pipe acts as if it is NOT connected to anything else in the universe.
Rather stupid, compared to how Land Desktop would allow a change to an entire run, including adjusting slope throughout.

[BlackBox]

At the risk of agreeing with you twice in one year, I'll instead simply say that you're not wrong about your issues with Pipe Networks.

You should participate in the beta forums, and express these issues there, matter-of-factly, and often.



That said, this (automagically adjusting a pipe network's 'rippled' elevation changes) sounds like an amazing new SincPac feature to me, and *may* even build on the sewer latteral functionality.

Cheers