Automatic ordinate dimension not attaching to the endpoint of line

Automatic ordinate dimension not attaching to the endpoint of line

Anonymous
Not applicable
2,097 Views
9 Replies
Message 1 of 10

Automatic ordinate dimension not attaching to the endpoint of line

Anonymous
Not applicable

I am trying to write a program that will allow me to select a group of lines and the program will automatically attach ordinate dimensions with the text lined up. So far I can select a group of lines and it will place ordinate dimensions correctly spaced when compared to the lines, but they are not near the lines.

 

I have the program taking the endpoint of the line and starting the ordinate dimension at the endpoint, but when I run the program the dimension isn't attached to the line. Am I using the endpoint correctly?

 

I'm teaching myself how to write lisp and this is the first program I am attempting so my code is probably clunky.

0 Likes
2,098 Views
9 Replies
Replies (9)
Message 2 of 10

ВeekeeCZ
Consultant
Consultant

You need to handle the osnaps... The easiest way is put "non" in front of all the points, e.g.

 

(command "DIMORDINATE" "non" Origin "non" dimEndPointLoc)

 

And also you should make your variables local...

 

(defun C:ADO( / Origin dimEndLocX dimEndLocYZ..........)
0 Likes
Message 3 of 10

Kent1Cooper
Consultant
Consultant

Welcome to these Forums!

 

Since you didn't attach an image of what you want it to look like instead of what it does look like, and it's not completely clear which are the Lines you're Dimensioning, I will assume something: that the cyan-colored lines are the extension-line parts of those Ordinate Dimensions, and that you want the cyan-colored Dimension text farther to the left, close to or right beside the definition points.  If that's the case, try changing the one 5 in the code to something smaller, maybe all the way down to zero.

Kent Cooper, AIA
0 Likes
Message 4 of 10

Anonymous
Not applicable

Sorry, it should look like this. The cyan dims are what the program is placing, the purple ones are just for reference. When I ran the program, it placed the x-origin dimension fine, but the other two dimensions were not attached to the lines. If you look down in the command window, you can see right below "Checkpoint 3" I had the program print the entity name the the endpoint location. It prints (2.71163 2.81984 0.0) as the endpoint location, and that is where the dimension was placed, but thats not the end of the line. The same thing for the next line, it returns (2.71163 3.81984 0.0) as the endpoint, but thats not where the endpoint is. 

Why is the program returning that as the end of the line if thats not the end of the line?

0 Likes
Message 5 of 10

ВeekeeCZ
Consultant
Consultant

Is it a DIMEXO (ext line offset) what bothers you?

0 Likes
Message 6 of 10

Anonymous
Not applicable

The problem is that the program is returning a random point in space, not the endpoint of the line. If I type in (entget (car (entsel))) into the command line and then select the line I want to dimension, this is what is returned:

 

((-1 . <Entity name: 7ffffb12830>) (0 . "LINE") (330 . <Entity
name: 7ffffb039f0>) (5 . "1AC92B") (100 . "AcDbEntity") (67 . 0) (410 .
"Model") (8 . "0") (100 . "AcDbLine") (10 2075.05 -130362.0 0.0) (11 2076.29
-130362.0 0.0) (210 0.0 0.0 1.0))

 

 

I didn't have the first file I posted saved, so I had to redraw it and the X,Y,Z location of the endpoints are now off way more. The 10th item is saying the X is 2075.05 and the Y is -130,362.0. I placed the origin at the top right corner of the box which is 3x5, why is entget returning ridiculous numbers for the endpoints of the line? 

0 Likes
Message 7 of 10

ВeekeeCZ
Consultant
Consultant

Sorry, I can't replicate your issue. See my image.

If you get some random points, be sure that you have turned off OSNAPs, as I wrote ...

 

(command "DIMORDINATE" "non" Origin "non" dimEndPointLoc)

 

0 Likes
Message 8 of 10

Anonymous
Not applicable

So apparently if I open a new drawing and use the default UCS location, it works fine, but if I move the UCS it doesn't work. I'm not really sure why it wouldn't work after moving the UCS though...

0 Likes
Message 9 of 10

ВeekeeCZ
Consultant
Consultant

I've simplified the code a bit, sorry about that.

 

(defun C:ADO ( / pt pttext i pti ss)

  (if (and (setq pt (getpoint "\nSelect origin:")) 			;ORIGIN PT UCS
	   (not (command "_.DIMORDINATE"
			 "_NON" pt
			 "_NON" (setq pttext (polar pt 0. 5.))))
	   (princ "\nSelect edges to dimension:")
	   (setq ss (ssget '((0 . "LINE"))))				;LINE FILTER
	   (setq i (sslength ss)))
    (while (not (minusp (setq i (1- i))))
      (command "_.DIMORDINATE"
	       "_NON" (setq pti (trans (cdr (assoc 11 (entget (ssname ss i)))) 0 1))	;PT CODE 11 WCS to UCS
	       "_NON" (list (car pttext)
			    (cadr pti)
			    (caddr pti)))))
  (princ)
)
Message 10 of 10

Anonymous
Not applicable

I couldn't fully understand what you did back in June and got busy at work so couldn't spend time on LISP, but I have had some time recently and have been working through an old LISP book. I was trying to write a program to put center marks in a lot of circles at once and was having the same issue with WCS vs UCS coordinates and thought about looking up my question here. I'm glad I did because my book does not contain the TRANS function anywhere! That completely solved my problems! Thanks! Now I have to finish this dimensioning program...

0 Likes