Polyline scale from midpoint

[brawleyman]

Thanks for all of your guy's help! But after playing around with several different things and testing stuff out, I am going to have to approach this from a totally different side.

Now that I understand a little more of what I am up against, scaling isn't going to work at all. Looks like I will need to look at something that will change the 2 different pline widths (lines in yellow are more narrow, mains in blue are wider for the bigger supply pipe) and search for any of those heads located on the end of a line and shorten/lengthen the pretty pipe on that side of the line.

I can figure out the part with scaling the 2 different widths based on color, but not on width because some plines are wider than the others (I would need it to find lines based on width because we show all "existing" pipe as grey 8 and hidden while new pipe is yellow or blue continuous depending on if they are mains or lines. Color can be different, but the widths are a constant to differentiate the 2 different types of pipe)

I suppose it is back to the drawing board to see what can be figured out...

[irneb]

I still can't understand why you don't want to go the anno route. It means you simply have to modify the blocks to include a wipeout inside their definition (one modification per block type), and also to set them to annotative. Once you've done that you can overwrite the new version into any other drawing so you don't need to re-do the modification every time.

Next you can set all the pipe widths=0 and rather use ObjectLineWeight to differentiate how "thick" they should appear. Then set LTScale=1.0, MSLTScale=1 and PSLTScale=1.

As a sample I've done just that to your sample Drawing1.DWG (the pipes and sprinkler head modified) and included 2 viewports at different scales: 1/32", 1/8" and 1/4". All showing the exact same linework. See attached eTransmit (extract fully to see the CTB file as well). It took me all of 1 minute to achieve this.
capture_06082012_142917.jpg

IMO this is a lot simpler and faster to do, and even easier to accomplish in lisp - so if you want to automate this process it won't be as complex to achieve.

[brawleyman]

I still can't understand why you don't want to go the anno route. It means you simply have to modify the blocks to include a wipeout inside their definition (one modification per block type), and also to set them to annotative. Once you've done that you can overwrite the new version into any other drawing so you don't need to re-do the modification every time.

Next you can set all the pipe widths=0 and rather use ObjectLineWeight to differentiate how "thick" they should appear. Then set LTScale=1.0, MSLTScale=1 and PSLTScale=1.

As a sample I've done just that to your sample Drawing1.DWG (the pipes and sprinkler head modified) and included 2 viewports at different scales: 1/32", 1/8" and 1/4". All showing the exact same linework. See attached eTransmit (extract fully to see the CTB file as well). It took me all of 1 minute to achieve this.
Attachment 35274

IMO this is a lot simpler and faster to do, and even easier to accomplish in lisp - so if you want to automate this process it won't be as complex to achieve.

I'll look into that and play around with it some. I know I probably won't use the pline width thing you are talking about because I have to use HydraCAD's routine to run it and the plines have to plot out the different widths, not just look like it on the screen. I suppose I could use the annotation stuff on the heads so that they look good on our enlarged 1/8" plans and overall plans of 1/16". Would annotation work when the original heads are in a file that is x-ref'd into a sheet file (our setup is that we have an FP Master dwg where we put our work on top of the architects xref background, then xref our FP Master into our sheet file(s))?

I will play around some with this stuff. I may just have to stick with what I have currently setup to where you change the scale of the drawing, then click a separate button to update the size of all the blocks in model space with an alert that the blocks will change but you have to redo the pretty pipe. I just wish the "block" for the pipe risers were actual blocks and not a "HYDRAPIPE" entity.

[pBe]

I still can't understand why you don't want to go the anno route. It means you simply have to modify the blocks to include a wipeout inside their definition (one modification per block type), and also to set them to annotative. Once you've done that you can overwrite the new version into any other drawing so you don't need to re-do the modification every time.

Deja Vu

So you scale the block by a factor depending on the desired scale? I would suggest you start using annotative, that will be two less entity to worry about.

[i'm more inlcined to use annotative blocks in this case, where even XREF is updated right then and there] BUT you mentioned before the software you are using doesnt have that capability.

I am working with HydraCAD and I am just having to work with what they have set up....

But this...

Next you can set all the pipe widths=0 and rather use ObjectLineWeight to differentiate how "thick" they should appear. Then set LTScale=1.0, MSLTScale=1 and PSLTScale=1.

..is by far the best suggestion i've seen on this thread.

[brawleyman]

I am sure that with any other setup, those suggestions would work great. HydraCAD has some great tools that can, at times, work wonders, but then other things seems like it is in prehistoric times. I am just trying to find the best ways to work around or with the program to incorporate our design standards while still trying to maintain some compatibility with it as well.

Our current setup consists of using HydraCAD for all of the sprinkler design mixed with tool palettes to bring in sprinkler heads and some other basic sprinkler blocks. Then my setup does everything else with tool palettes bringing in all of our standard sheet notes and sprinkler details and my routines for quickly creating bubbled areas of work then creating viewports from those areas, quick plotting, scale setup, company standards, model/paper space switcher, xref cleanup, email current drawing help, etc. I haven't really been able to integrate the 2 systems together, but they can tolerate working together.

I really appreciate your guy's help in trying to figure some stuff out for me, but unfortunately, after digging through more stuff and analyzing HydraCAD deeper, there really isn't that much that I can do to automate what I want. I suppose we will just have to do some things manually.

[irneb]

... and the plines have to plot out the different widths, not just look like it on the screen. ...

Well, then leave them as PL's with their widths intact, don't change that at all. I think we all thought they needed to adjust according to the scale (hence the "Scale from midpoint), but if they need to stay in real world pipe sizes then simply do nothing to them except for: Stretch each of their endpoints to the closest block's insertion point and send them to back. This actually takes away 1/2 the work I did on the drawing, so it makes it even easier.

... Would annotation work when the original heads are in a file that is x-ref'd into a sheet file ...

Yes anno scales work perfectly even between xrefs, I'm using them extensively in my projects and as long as you keep all your drawings containing the same set of scales there's no problem. Just make sure you don't have 1 or more DWG's with a scale which is not inside another - otherwise you'll end up with those XREF_ scale names (stupid ADesk programmers don't understand scales at all!) You can modify the standard scale list in newer ACads (I think 2010 had this as well, didn't use that version - only jumped from 2008 to 2011 to 2012, but in 2008 they were uneditable and hard-coded, while in 2011 they were saved in registry so you could edit them to your liking). Then all you need to do is a scalelist reset in each DWG to have all your drawings match each others' scales, this could even be scripted so you can run it through 100's or 1000's of drawings in one go. I know, I've done so before.

I may just have to stick with what I have currently setup to where you change the scale of the drawing, then click a separate button to update the size of all the blocks in model space with an alert that the blocks will change but you have to redo the pretty pipe. I just wish the "block" for the pipe risers were actual blocks and not a "HYDRAPIPE" entity.

Yes, I've noticed that the "risers" (I assume they're those DN # tags) open as Proxy objects. You could use AECtoACAD to convert them into blocks, but that means they become unnamed blocks (i.e. with a name like *U####). That means BEdit doesn't want to work with them. It is possible to use lisp to rename them though.

All the other blocks can be done pretty straight forward: Simply a BEdit, and set their Annotative property to Yes in the Properties Palette, BClose & Save. Then you get something like this:
capture_06082012_170301.jpg
Note those Proxies converted to unnamed blocks through AECtoACAD seems to go a bit haywire.

[brawleyman]

The plines for the pretty pipe are not real world sizes, the 2 different sizes are just to differentiate whether the pipe is a main (thicker line) or branch line (thinner line). The standard in Hydracad is to set mains to 3.5 and branch lines to 2.5 when at 1/8" scale. Perhaps I could figure something out so that I could basically create my own program for making the pretty pipe with the 2 different sizes based on the original construction lines layers and just have the pretty pipe stay the same length as the construction lines and use wipeout in the blocks to hide the pipe behind? Only thing is that the program also prompts for choosing which line is above the other, if applicable, and breaks the line with break line symbols on either side of the upper pipe (this helps you see the difference between pipe that is under/over other pipe and pipe that is actually connected).

Next question. I don't know anything about proxy objects like you mentioned about the risers. I just tried adding a wipeout to the original block that HydraCAD uses for the riser, but when it is inserted in the drawing, the wipeout doesn't have an effect. I tried bringing it to front and sending the pipe to the back, but it's like it disappears. This object is really the only thing holding me back from doing everything else because the riser has an "opening" where the pipe goes to the center of the riser (this shows that the riser goes down, otherwise if the pipe stops at the outer edge of the riser, it means the riser goes up. Makes sense when you look at a top view of actual pipe and is meant to look like it does in real life). From what I can gather, HydraCAD has to use this block so that it can do it's calculations, so there really isn't an alternative to making a custom block, I have to use their original one. I will keep playing with it some more to see what I can manipulate with it.

[pBe]

Are you taking a dfferent route now brawleyman? I tried the code on your attached drawing . it appears to be doing what its supposed to do. (with a minor fix on the code). Thing is the code is written to run on its own. A click of a button will do all. It will scale the blocks and it adjsut the plines. I understand your reluctance in using Annotative ,i gave you workaround but it sould run in its own all you need to do is chagne the dimscale and run the code.

Also, it was just the one scale that wasn't working for some reason, I tried a couple others and they worked

If you mean for some reason you change the scale from 1/8 to 3/32 and it doesnt process ALL plines. i already found that bug and squashed it. one thing you need to be aware of. depending on the current lenght of the pline and how it was drawned the code will process the rest of pipes unless it met a certain condition the it wont be adjusted. say for example , the current lenght is 6" at dismcale 1 (1/ and you use dimscale 2 . wiich means 6" would be decucted on the both ends. then its either we delete the line or leave it alone , we can go as far as tweaking the code to show you which pipes are not processed by highlighting them at the end of the run or changing the color.

Anyhoo. i had fun writing the code for this but unfortunately it doesnt worked for you as you intended it to be. BTW using Annotative objects is a heck of a lot easier.

Cheers