Topic: Problems with Breaking lines and blocks

[ademontis]

Hi everybody, I am a CAD engineer working for a company that handles chemical plants projects, and in my work i often have to insert blocks from a customized ToolPalete (which i created) on a polyline. The bad thing is that everytime i add a block (a valve, a steam trap, etc) I have to break lines by myself at the intersection points and delete the part of line that remains 'under' the block.
I have tried the 'AutoBlockBreak' by Lee Mac and it is very useful except it doesn't allow me to use blocks from my customized Tool Palette; I have also tried th script at:

http://www.theswamp.org/index.php?topic=25808.0

but it doesn't work well with polylines that are made up of more than one segment (I think it is because of the fact that the script only gest StartingPoint and EndPoint).

Is there a way to modify one of these script in order to accomplish the goal?
The best thing would be to add the upmentioned script with the ability to handle all middle points in a polyline.
In the attachment you find an image showing the problem.
Using the BR-LI script from the 'original situation', it doean't recognize the polyline as a 2-segmented route, and deletes a piece of it.

Thanks in advance, i hope someone may help...
it is a very importand matter for all P&IDs drafters
Alex

[Nibster]

if having not having breaks in the line is ok, have you tried the down-n-dirty method of using a wipeout?  You shouldn't have any troubles with those if you're using tool palettes.

issues have been found when someone tries to copy/paste wipeout'd blocks into a drawing that doesn't already have the block defined (correctly inserted).

[alanjt]

Lee did this one a while back...

http://lee-mac.com/autoblockbreak.html

[ademontis]

Thank you both, sadly the wipeout solution is not an option because it would mean to 'redefine' every single block, and i am not allowed to.
The script by Lee you have suggested is the same I have tried, it works fine except i am not able to adapt it to take blocks from my tolpalette instead of inserting them manually inserting the blockname.

[Nibster]

Lee did this one a while back...

http://lee-mac.com/autoblockbreak.html

that is pretty sweet!  I did notice that for dynamic blocks, it defines the trimming boundary as if all geometry is turned on, not just what is visible.  not a big deal to me because having to extend the lines back to the valve symbol is still less work than trimming.

I wonder if that could be modified into a reactor so the tool palette can be used to place the blocks on the correct layer OR manually select blocks....  hmmmmm.....  

[Lee Mac]

Thanks guys

If lots of people want it modified I might consider changing the code around so that it may be called with an inserted block and will trim that block... this way, one could call it with (entlast) following a tool palette insertion...

[alanjt]

Thanks guys

If lots of people want it modified I might consider changing the code around so that it may be called with an inserted block and will trim that block... this way, one could call it with (entlast) following a tool palette insertion...

I think they're trying to do it from Tool Palettes.

[Nibster]

Thanks guys

If lots of people want it modified I might consider changing the code around so that it may be called with an inserted block and will trim that block... this way, one could call it with (entlast) following a tool palette insertion...

if it's not the last block inserted, could it be modified to work by just picking blocks to trim around?  I also find a lot of piping diagrams where the drafter just placed the symbols and never trimmed the lines in our campus databases.

[Lee Mac]

Thanks guys

If lots of people want it modified I might consider changing the code around so that it may be called with an inserted block and will trim that block... this way, one could call it with (entlast) following a tool palette insertion...

if it's not the last block inserted, could it be modified to work by just picking blocks to trim around?  I also find a lot of piping diagrams where the drafter just placed the symbols and never trimmed the lines in our campus databases.

My thoughts would be to create a sub that could be called with whatever the user chooses - a new block or existing - that way the routine has far more flexibility than it currently does.

[ronjonp]

IMO ... the mask option seems like the easiest\cleanest route. Why is it that you cannot redefine the blocks? If you have a library of blocks, you spend a day adding the mask then you never have to worry about trimming again. 

In some of my blocks I use a solid background that is color 255 and it has worked well (even better than wipeouts). Attached is an example.

[Nibster]

IMO ... the mask option seems like the easiest\cleanest route. Why is it that you cannot redefine the blocks? If you have a library of blocks, you spend a day adding the mask then you never have to worry about trimming again. 

In some of my blocks I use a solid background that is color 255 and it has worked well (even better than wipeouts). Attached is an example.

does a plotter's "lines over-write" setting affect this method?

[ronjonp]

You know ... I'm not sure  . 99% of our deliverables are PDF's and it has worked flawlessly with them.

[Lee Mac]

You know ... I'm not sure  . 99% of our deliverables are PDF's and it has worked flawlessly with them.

I think it depends on the PDF Printer - some people report that wipeouts show up, others don't.

[Nibster]

I think it depends on the PDF Printer - some people report that wipeouts show up, others don't.

oh yeah, i remember now.  THAT'S why the '255' fix is used, because wipeouts show up as black boxes in the ADOBE & 'dwg to pdf.pc3' drivers.

[dgorsman]

Commercial P&ID packages are pretty cheap and will manage all this for you.  I know its tempting to roll your own, but from experience its not worth it.

[ademontis]

IMO ... the mask option seems like the easiest\cleanest route. Why is it that you cannot redefine the blocks? If you have a library of blocks, you spend a day adding the mask then you never have to worry about trimming again. 

In some of my blocks I use a solid background that is color 255 and it has worked well (even better than wipeouts). Attached is an example.

I could if I were allowed to, but we draw P&IDs for clients that have their own blocks (different standards) and we are not allowed to redefine them. 

[Lee Mac]

If lots of people want it modified I might consider changing the code around so that it may be called with an inserted block and will trim that block... this way, one could call it with (entlast) following a tool palette insertion...

Finally got around to doing this...

http://www.theswamp.org/index.php?topic=35832.0

[cmwade77]

Lee did this one a while back...

http://lee-mac.com/autoblockbreak.html

that is pretty sweet!  I did notice that for dynamic blocks, it defines the trimming boundary as if all geometry is turned on, not just what is visible.  not a big deal to me because having to extend the lines back to the valve symbol is still less work than trimming.

I noticed this issue as well and thought I might try to take a look at it when I get the time, but if someone gets to it first, then so be it.

[Lee Mac]

Lee did this one a while back...

http://lee-mac.com/autoblockbreak.html

that is pretty sweet!  I did notice that for dynamic blocks, it defines the trimming boundary as if all geometry is turned on, not just what is visible.  not a big deal to me because having to extend the lines back to the valve symbol is still less work than trimming.

I noticed this issue as well and thought I might try to take a look at it when I get the time, but if someone gets to it first, then so be it.

A difficult one, since the code currently uses the BoundingBox method to retrieve the block outline, the fix might involve dissecting the block into its component parts (depending upon those objects visible in the current state), and using the BoundingBox method on several objects to construct a block outline. Of course, an alternative would be to use the Boundary Polyline command, but I should imagine this would lead to inconsistent results in many cases.

[Crank]

[...]
I think it depends on the PDF Printer - some people report that wipeouts show up, others don't.

That's why you should make the color of wipeouts 255 as well.

[alanjt]

[...]
I think it depends on the PDF Printer - some people report that wipeouts show up, others don't.

That's why you should make the color of wipeouts 255 as well.

Damn Crank, that's a great idea. Does it actually work?

[Crank]

It works: I use this for all my wipeouts, and never had (or heared of) problems with solids in pdf-files.