Break line subfunction causing entire perpindicular lines to erase, why??

[Anonymous]

Would anyone be able to tell me why my subroutine in one very specific scenario is causing the lines not to be trimmed around the fitting but instead to erase the entire entity?

This is occuring when a line bisects another line or at a bend, if these fittings are placed onto the corner they are instead erasing the entire line on both ends, rather than just trimming inside the fitting as the other 200+ inserts do.

I'm somewhat unfamiliar with the v-lisp portion of this subroutine that issues the break command, using a combination of vlax-curve-getpointparam, vlax-curve-getstartpoint, vlax-curve-getendpoint...but I'll paste the entire subfunction down below and attach the entire lsp and dcl that are running the subfunction....

If anyone could point me in the right direction as to how I should go about fixing it, I would be greatly appreciative.

Thanks in advance!

Sub:

(defun MySub (a1 a2 a3 insertpt1 / OBJ P2 P3)     

(vl-load-com)          

   (if (= objx 1)     

   (progn          

(setvar "osmode" 0)       

(command "_insert" a1 insertpt1 "" "" pause)    

(if (> a2 0.0)        

(progn (setq obj (vlax-ename->vla-object name))

(if (eq (vla-get-ObjectName obj) "AcDbPolyline")    

(setq p3 insertpt1   

         p2 (angle insertpt1  (vlax-curve-getpointatparam obj  (fix (vlax-curve-getparamatpoint obj insertpt1)))))       (setq p3 insertpt1      

         p2 (angle (vlax-curve-getStartpoint obj) (vlax-curve-getEndPoint obj))) )         

(command "break" name (polar p3 p2 a2) (polar p3 p2 a3)) )       

(princ "\n......Selected....\n......Breaking Lines....")    

)           

)         

(progn          

   (command "_insert" a1 insertpt1 "" "" pause)   

(hms:attrt)         

   (princ)         

)      

)       

(princ "\n......Insertion Completed!")   

(princ)        

)           ;MySub

[Kent1Cooper]

Without studying it deeply, I have a quickie suggestion....

Try reversing the break points [switch the a2 and a3 distance arguments in the Break command].  It shouldn't make a difference for Lines, even though it does matter for certain closed entity types, but you never know what may be affecting things.

[Anonymous]

Hi Kent,

I tried it, but it did not work. The psv still ate the entire lines.

The PSVS are made to be placed on perpindicular lines but are not trimming the perpendicular line at all.

[hmsilva]

Hi bhull1985,

please attach one of these dwg's

"PILOT REGULATED PRESSURE RELIEF VALVE"

"PRESSURE AND VACUUM VALVE"

"PRESSURE SAFETY VALVE WITH VENT CAP"

"PRESSURE SAFETY VALVE" "THERMAL RELIEF VALVE"

or even better, attach a sample dwg with one of these dwg's already inserted in the situation that gives error.

Henrique

[Anonymous]

Sure thing Henrique, and hello.

The best that I've been able to get them is with the trim distances switched in the break command as per Kent's suggestion, but also I've had to swap the "Mysub" arguments for the trim distances that is part of the MAIN routine, and not part of the subroutine. In the cond statement. But they're still not trimming as they should, by following the curvature of the lines. As you can see in the attached drawing, they are not breaking properly, but alas this is still better than having them eat the entire line, which you can reproduce by swapping the trim distances back to the other way, and then swapping the break commands arguments to get the lsp to the state they were in before

[hmsilva]

---

@Anonymous wrote:
...

As you can see in the attached drawing, they are not breaking properly

...

---

Hi Brandon,

what you mean by "not breaking properly", do you want to brak the two entities, or it is only one?

If possible attach a sample dwg, with the before, and after you insert a block, and with what you intend to achieve.

Henrique

[Anonymous]

Alrighty Henrique, I've done as you asked.

The attached drawing shows how the lines around the psv's should be trimmed.

Some of the orientations are hypothetical, as we would not actually place fittings at such an orientation but I would like for the code to be able to detect any touching entites that are in the boundary of our closed shape blocks and trim it out.

Hopefully this is a bit clearer! And thanks for your time 🙂

[hmsilva]

---

@Anonymous wrote:
...

Hopefully this is a bit clearer!

...

---

Brandon,

when I asked a sample dwg with the before, it was before insert the block, and it was to trying to understand if the block was inserted into a single entity (a unique LWPOLYLINE), or in two entities (two LWPOLYLINES or LINES), because if so, you'll have to use a different approach, perhaps using ssget with some fuzz to select the two entities, and break each entity...

Henrique

[Anonymous]

Dang, alright.

Well to answer your question, Henrique, would need to be on a case-by-case basis.

The prog needs to check for two-line and single entity LWpolylines, POLYLINE, and LINE.

In just the psvs, and in one specific case on the other catagories (angle valves) but we're not concerned about the angle valves at the moment. As all of the ones in the PSVs.lsp are angled, it would be much more pertinent to fix this entire lisp portion first.

Sometimes a user with issue these commands manually, resulting in TWO lines that are perpindicular to eachother. The Psv's would be placed on the intersect of these lines.

More often, however, the users select the "process line" selection that will draw on the correct layer, a LWPolyline, and as such that will result in a single line entity with a 90 degree hard turn in it, at which the psv fitting will be placed.

There is no specifically correct way to do these, in fact we've alloted a variety of methods in order to have the designers comfortable in laying out the drawings in the way that they do. What the lisp routines i've collected and designed and meshed into our system to do is take care of all the menial and restrictive, standardization and tedious tasks......when they want to draw a process line, they select which type and put their cursor where they want it to begin, and drag to the point where it would change directions. The lsp enhancements currently would ensure that the linetypes are pre-loaded into the drawing, establish layer controls, setting current the correct layer if exists or if the standard layer does not exist, it will be created before placing the fitting. The process lines once drawn will also trim away any un-needed line segments that appear under our fittings. This is the basis behind these lisps and what we've all been working on these last few months (selective all, but definitely more than myself), and up until this point they've worked quite well for our purposes for 10-15 users on our system. This is the first error or adverse effect we've had with it in a few weeks since having it completed.

It's to-do with the polar command missing it's resultant angle because the line is not a 180 line around the fitting as the others are...these lines, be it one polyline or two segments, have the 90 degree in them. The middle of the fitting is placed on the intersect, resulting in the appearance of the blocks on the drawings I have posted previously.

Hopefully I managed to explain a bit more this attempt!

[Anonymous]

And hopefully my assesment of the problem is correct as well!