Hatch Using LISP

First off, sorry for bringing this up again. But I'm making a last ditch effort to try and make something happen with hatch using LISP. And as many of you will recall, this is part of a totally automated project. No user input is allowed and all must be done with LISP code.

On the attached image you will see my quandry. The image on the left is the before shot and the image on the right is the after shot I want to achieve with the hatch command.

The green extrusion is a block brought in using LISP. The green rectangle is created with LISP. The red PLINE is also created using LISP. Once this is complete, I can manually use the hatch command and by just a simple click where you see the crosshairs in the left image it will perfectly fill the area I want. So I think, great, let me create the sketch and then code the hatch command in my LISP program to select that same point to get the results shown on the right.

But it appears that the hatch command will not do this...using LISP. One of those things which works so simple by manual methods which would appear to be a simple task for LISP.

NOTE: I have written the code to painstakingly draw a PLINE which closely follows the contours of the green extrusion and join it with the other PLINE to form a closed polygon. This can then be hatched using LISP. But this is a pain, and as the client adds more shapes to their product line it get's exceedingly harder to come up with the code to trace the extrusion profiles.

Is this something that just can't be done using LISP? I have found there are times when you can do something manually using your mouse and keyboard which you cannot recreate using LISP, but these are very few occasions.

Maybe...

draw (red) polyline

insert block

vla-getboundingbox (polyline+block)

zoom -> BoundingBox

zoom -> 0.9x

(command "_-hatch" pt "_P" "AR-CONC" "1.0" "0.0" "")

or

(setq EL (entlast))

(command "_-boundary" pt "")

(if (/= EL (entlast))

(command "_-hatch" "_S" "_L" "" "_P" "AR-CONC" "1.0" "0.0" "")

)

GP, thanks. I tried the second method and it works very well. The only trouble is that it leaves the boundary line intact. When this is all done, what I'm after is to have only a line at the top and a line at the bottom of what is the concrete slab. The users are very particular about this.

(setq EL (entlast))
(command "_-boundary" (polar pt1 pi (+ afrmwd 2)) "")
(if (/= EL (entlast))
  (command "_-hatch" "_S" "_L" "" "_P" "AR-CONC" "0.25" "0.0" "")
)

I'll tinker around with this a little more to see if I can get the final end result the users are demanding. The best part about this is that I don't have to do all the tedious tracing of the extrusion profiles and the boundary even fines the embed plate and works around it too.

Thanks and if you have any other suggestions, please clue me in.

Okay I think I finally have it. I've never really worked with the boundary command before. Anyway, it was a matter of selecting both the polyline and the boundary line and then doing an (entdel) on both of them. I can now draw back in the simple lines at the top and bottom of the slab so these picky users get what they're wanting...at least with this issue.

Thanks GP. That was great advice.

Happy to help.

Am I going crazy or what....? In the beginning of learning LISP I was informed that there are certain methods of coding which can prove to be unstable...that is at times it works, other times it doesn't. This is one of the hard things to deal with LISP programming, especially when my client sees the darn thing working and then the next day they come to me with a bug list which includes the very thing I had working only the day before.

(defun slab1 (_Point1  _Point2	_CPoint1 _CPoint2 _Left	   _Right
      _Up      _Down	/	 _h1	  _l1	   l2
      _pl1     _pl2	_r1
     )
(command "._CLAYER" "Concrete")
     (command "._PLINE"
       (polar _Point1 _Down (- _afrmdp1 0.4375))
       (polar _Point1 _Down (- slabdp 0.4375))
       (polar (polar _Point1 _Down (- slabdp 0.4375)) _Left 4)
       (polar (polar _Point1 _Down 1.0625) _Left (+ afrmwd 3))
       (polar (polar _Point1 _Left (+ afrmwd 3)) _Up 0.4375)
       (polar (polar _Point1 _Left afrmwd) _Up 0.4375)
       "")
     (setq _pl1 (entlast))
 
 (command "_-boundary" (polar _Point1 _Left (+ afrmwd 2)) "")
 (setq EL (entlast))
 (if (/= EL (entlast))
   (command "_-hatch" "_S" "_L" "" "_P" "AR-CONC" "0.25" "0.0" "")
   ); end if
 (setq _h1 (entlast))
 (entdel EL)
 (entdel _pl1)
     ; DRAW THE TOP OF THE SLAB BACK IN
     (command "._LINE" (polar (polar _Point1 _Left afrmwd) _Up 0.4375)
       		(polar (polar _Point1 _Left (+ afrmwd 3)) _Up 0.4375) "")
     (setq _pl1 (entlast))
     ; DRAW THE SIDE AND THE BOTTOM OF THE SLAB BACK IN
     (command "._PLINE" (polar _Point1 _Down (- _afrmdp1 0.4375))
       		(polar _Point1 _Down (- slabdp 0.4375))
       		(polar (polar _Point1 _Down (- slabdp 0.4375)) _Left 4) "")
     (setq _pl2 (entlast))
     (command "._MIRROR" _pl1 _pl2 _h1 "" _CPoint1 _CPoint2 "")
(princ)  
); end slab1

The hatch is what seems to go wrong with this. I can only assume that the remainder of it works because when it's done there is either a beautiful concrete hatch with just enough lines left around it to form the partial cut-away view of the slab, or there is a cut-away view but the hatch is just a bunch of slanted lines which only almost looks like the AR-CONC hatch it's supposed to be.

I wrote this to work with the front and side views of the drawing. That's what the _Up, _Down, etc... is all about. There are multiple conditions for this so I made this to be modular. I call the routine like this:

(slab1 pt7 pt8 ctrl1 ctrl2 pi 0 a90 a270)

And there are times when this runs and it works perfect. Then I move to another part of the code which calls an almost identical routine and it doesn't work. I then go back to the first routine which only 5 minutes ago worked perfect and it too now screws up the hatch like the second attempt did.

Q: Is this one of those types of codes which will prove unstable over the long haul or do I just need to go have my head examined?

As I previously mentioned, I'm sworn to NDA's left and right around here so there is a limited amount of code and images I can post. But here is something interesting that I just observed with this issue. The image on the left is what I end up with when it goes wrong. The image on the right is what I end up with when it goes right. The hatch is hosed up and there are lines from the boundry command which do not get erased by the entdel commands. It's the exact same code which produced both of these. The only difference was the one on the left was run at full speed, the one on the right was run with a breakpoint just before the code starts and I step through it using the F8 key.

This was running at full speed earlier today and all was well. I'm doing more testing on this now because the end results, when it's right are just what the users here are demanding.

To use boundary command must be the geometry that is used is entirely displayed on the screen.

draw (red) polyline

insert block

vla-getboundingbox (polyline+block)

zoom -> BoundingBox

zoom -> 0.9x

(setq EL (entlast))

(command "_-boundary" pt "")

(if (/= EL (entlast))

(command "_-hatch" "_S" "_L" "" "_P" "AR-CONC" "1.0" "0.0" "")

)

then... how can?

 .....................
 ..................... 
 (command "_-boundary" (polar _Point1 _Left (+ afrmwd 2)) "")
[b] [color=red] (setq EL (entlast))[/color][/b]
[b][color=red]  (if (/= EL (entlast))[/color][/b]
   (command "_-hatch" "_S" "_L" "" "_P" "AR-CONC" "0.25" "0.0" "")
   ); end if
 (setq _h1 (entlast))
 (entdel EL)
 .....................
 .....................

GP, thanks again. I did find that like you reference the only way to get this working consistently is to use the zoom command. What threw me off was that it appears to work without the zoom command as well, but sooner or later it will slip off the tracks as it was doing. So I'm inserting some more zoom commands into the blocks now.