LISP add-on - need to assign sequential ID # to attributes

[Anonymous]

I have this awesome LISP from @dlanorh, and now need some new functionality added. Maybe the original creator can help me out? 🙂

In addition to what the LISP already does (calculating the sq ft and entering it in the attribute "Area ="), I would like to assign each polyline a unique ID # in one of the other attributes in that same block. The block is "RoomTagArea" and the attribute is "ID:". (Polylines and blocks are on the same layer.) The unique number would have the prefix "SM" followed by 6-digits starting at "000001". So the end result would look like "ID: SM000001", "ID: SM000002", "ID: SM000003", and so on for the blocks found within each polyline. Is this possible?

I've attached the original LISP and a screenshot of what the blocks should look like after running the LISP. Thanks!

[Anonymous]

Almost forgot...after the LISP is run, here is the DWG...

[dlanorh]

Hi Becky,

Sorry but I can't open the drawings, you'll need to save in AutoCAD 2010 format and re-post.

Thoughts on polylines failing. If the polyline is self intersecting (this would include segments that overlap) it is causing this line to fail.

(setq ss (ssget "_CP" c_lst (list (cons 0 "INSERT") (cons 2 i_blk) (cons 8 lyr) (cons 66 1))))

This is the line that feeds the coordinates of the polyline into the ssget "_CP" (Crossing Polygon) which means it fails and returns nil. This is the line that searches for the block within the polyline and would return a selection set of blocks found or nil for no blocks found. As the ssget fails it is mimicing no block found. I have come across this a couple of times, in fact there is a current question on this forum that is more than likely down to the same problem.

The solution is to run the polylines through correcting program which checks and corrects such aberrations. This would need to be completed before running the lisp as they can significantly change the shape of a polyline. I have a couple which remove zero length and overlapping segments and one that removes large self intersections, the latter however is proprietory. It, however, sounds like your polylines fall into the former category. I'll dig them out tomorrow.  

[Anonymous]

Sorry about that Ron! Resaved them as 2010. Thanks for your patience.

That other LISP that removes zero length polylines sounds great! That would save me so much time going forward searching endlessly for faulty polylines in my drawings.

[dlanorh]

Attached is SlimLWPoly.lsp

This can be run on multiple LWPolylines, select multiple at select objects prompt, you can use the implied crossing/window etc. It handles open and closed polylines.

It will not process polylines with arc segments, a global width (other than default) or variable width segments, and takes no account of any UCS (user coordinate system) i.e. designed to work in World plan (top) view.

Hope this helps

[Anonymous]

Thanks for the Slim Polyline LISP! I tried it on three drawings with known zero length segments. It worked on only one out of the three drawings (when selecting all of the polylines at once). These are the two errors I received:

This is the first error:

After the first error, I wondered if the DWG (which I received from an architect) could have 3D elements in it, so I flattened the drawing, ran the LISP again and received this error:

There are no arc segments, no global/variable widths, and everything seems to be default settings otherwise...thoughts?

[cadffm]

For simple situations like vertex 4+5 at the same point, use command OverKill

[dlanorh]

Can you send me a sample drawing with some of these polylines. It is impossible to completely debug from screen shots or error messages.

[Anonymous]

These are the actual polylines giving me trouble. I've already deleted open polylines. There are no arcs, etc. Thank you for taking a look.

[dlanorh]

I think I've found the problem, I altered the lisp to change the colour of the polylines to yellow then back to bylayer after it was processed. So far i've found eight or so rooms where the lwpolylines are drawn closed and then closed. I will attempt to correct this and repost the lisp.

[dlanorh]

Tested and working on your drawing. I've left in the "color" change, so if you get errors again the yellow polyline is the first one found causing a problem. I've also tweaked the fuzz twenty fold. I was thinking in metric not architectural units when I set it, and it didn't need to be as fine as it was.

I should have a bit more time over the next couple of days, to complete the revamped lisp, taking into account the polyline problem just encountered.

[dlanorh]

Just an update to say the re-write is progressing and almost finished, then on to testing and debugging.

[dlanorh]

Hi Becky,

I'm still testing, and everything major seems to be working for a new drawing. I do have a question with regards to the CSV file. I have attached the output from my small test (two rooms witten out to a separate dwg) and wanted to check if this was what you required. It currently sorts the output on the room attribute (data stored in the "#:" tag of the block).

1. Is this sort correct?

2. Do you want the "???:" or "Area =" stripped from the front of the data?

3. I can display the "sq Ft" as Ft with a superscript 2 if required.

[Anonymous]

Hi Ron,

I believe I changed the sort order of the lisp to use the ID: attribute. I forgot that I had done that. There are a few little tweaks I made to the original lisp (assuming it was easy for me to figure out, that is, haha).

One additional thing I forgot to ask:

If, after all the checking to make sure the plines are drawn correctly and all have room tag blocks, etc, is there a way to differentiate the plines that are identified by the lisp as not having blocks? Maybe have them change color? On the larger drawings, especially, I spend a lot of time scouring the floor plan searching for plines that don't have blocks, or where the data didn't get filled in (because inevitably our drafters will miss spaces, me included). Trying to streamline my process, and this is one area that I would love to trim down.

As always, so appreciative of your help on this!

[dlanorh]

I'll reset the sort to sort on Polyline ID ("ID:") Attribute.

It should be possible to get the lisp to insert any missing blocks. I have a little routine that finds the innermost point of a closed polyline (written by _Gile), but this would mean setting the attributes to preset. This would mean you wouldn't be prompted for any attribute values on inserting the block.

I am going to upgrade the checking routine as I've found it neccessary to ensure all polylines are constructed in a counter-clockwise direction. This aids in identifying if blocks are inside or outside. If they are all constructed in the same direction this makes the checking easier.

I had already implimented the color change for polylines without blocks. I used colour 50 (a yellow) but if you would rather have something else let me know. I have tested the lisp on the "Pline-Test" drawing you uploaded an everything is working OK.

Points to note.

You are no longer asked for a starting Number. Once the block selection set has been processed the lisp knows if it is an update. In this case it knows the last number used and will start from this +1. It will also know the the ID: number three letter prefix and will use this for any new ID's. If it is a new drawing the ID number is set to 1 and you are asked for the prefix. This will automatically make the prefix uppercase.

The pre-process polyline check still needs to be run.

Having thought about it perhaps the two could be combined into one pre process routine that checks polylines and if each polyline has an associated block.

Attached is rareasV7.lsp. Feel free to try and break it 😱

[Anonymous]

The new LISP is working like a charm! I've only tested it on a few drawings, but it seems to run smoothly. I especially appreciate the new message that pops up at the end, and the color change of polylines that are missing the block tag.

But is there a way to take out the pop-up request for the ID prefix? We've been using our company standard "AHS", and I don't foresee changing it ever. Using the old LISP, I was able to change the prefix directly in the code if I ever needed to. But if it's too much of a hassle to remove that prompt, I understand.

I will test it on some more drawings and let you know if anything seems amiss! Thank you for your hard work on this!

[dlanorh]

Hi Becky,

I'm away from the office for a week, and I've had trouble connecting the laptop, tablet only at present. Once this is sorted (hopefully today) I can upload the amended code. Its a simple amendment.

[dlanorh]

OK I seem to be online for the moment. Attached is the updated Areas lisp and an updated Check LWPolylines lisp. This replaces the Slim Poly lisp, and should be run prior to the areas lisp. It checks and correctly sets up the polylines as well as checking for polylines without blocks. Problem polylines will be highlighted in yellow (50) and polylines without blocks will be green. A blank block will automatically be inserted.

The Area lisp won't popup asking for a prefix but if non present (first time through) will default the prefix to "AHS".

[Becky_Sharp]

Hi @dlanorh!

Becky Sharp here...I'm reaching out in the hopes that you are available for some lisp assistance.

The original RAREAS v7 lisp listed a unique ID and sq footage for each polyline into the block attributes. I've also programmed the lisp to output the pline length (perimeter of each room). But what I also need is the total pline length MINUS doors/cased openings. Essentially, I need the length of the baseboard molding in each room. The only unique thing about openings on my floor plans is that the adjacent polylines overlap and share vertices. (The exception would be exterior doors.) Is there a way to deduct the overlapped segments from the total length of each pline using a lisp? I've attached the sample DWG, the most current version of the lisp, and a snip of the sample drawing. The attribute "RoomLF" is the total pline length in linear feet, and the attribute "BaseLF" is meant for the baseboard length in linear feet. Thank you in advance!

[Sea-Haven]

Having a quick look at your dwg if your doors were a block then door width would be known in some way and could be subtracted from perimeter, you do have a ellipse so maybe dist, centre - start. Just an idea. 

A bit of test code 

(defun c:wow ( / plent ss obj totlen elen )
(setq plent (entsel "\nPick rectang"))
(if plent (setq co-ord (mapcar 'cdr (vl-remove-if-not '(lambda (x) (= (car x) 10)) (entget (car plent))))))
(setq ss (ssget "cp" co-ord (list (cons 0 "ELLIPSE"))))
(setq totlen (vla-get-length (vlax-ename->vla-object (car  plent))))
(setq obj (vlax-ename->vla-object  (ssname ss 0)))
(setq  elen (distance  (vlax-get Obj 'StartPoint) (setq end (vlax-get Obj 'Center))))
(alert (strcat "total length is " (rtos totlen  2 3) " Door width is " (rtos elen 2 3)))
(princ)
)

Note Vestibule #112 will not work.

[dlanorh]

Hi Becky,

I'm very rusty here, but I think the lisp selects all polylines on a certain layer, checks that they are closed and that the closed polylines have the relevant block inside it, and processes each pair individually.

Your options are checking if each polyline intersects any of the other polylines for two consecutive vertices (this method will not work with external doors) and would require a re-jigging of the way the lisp works, checking each polyline to see if it contains a door profile (doors usually come in standard sizes) which would require checking the length of each segment against a list of known door sizes. Both have their drawbacks and are not foolproof, but would allow a simple subtraction to be performed.