Dimension measurement doesn't match with Dimension Text

Dimension measurement doesn't match with Dimension Text

Anonymous
Not applicable
822 Views
3 Replies
Message 1 of 4

Dimension measurement doesn't match with Dimension Text

Anonymous
Not applicable

 Hi all

 

Is it possible to match dimension measurement to dimension text?

 

I have a small code; it extract measurement from dimension line and insert into text as a field (measurement). There is a case that the dimension measurement is differ from dimension text when the dimension is in the board line between of precision (1/16”).

As shown on the picture, the dimension text shows 2-10 15/16” but it is shown as 2’-10 7/8” in dimension measurement. In other case, it shows 1’-0 13/16” in dimension but it shows as 1’-0 3/4”.

 

Is there any to fix for it? 

 

Or add a review processes to compare the string value of dimension text and dimension measurement so if they are not same, add an alert,

(alert "Dimension text does not match with Dimension measurement. \nPlease review it"))

 

Please refer to attached dwg file for the sample.

 

Many thanks in advance.

 

 

(defun c:test (/ ent dtxt)
(vl-load-com)
(and (setq ent (car (entsel "\nSelect Dimension: ")))
(eq "DIMENSION" (cdr (assoc 0 (entget ent))))
(setq dtxt (car (entsel "\nSelect Destination: ")))
(wcmatch (cdr (assoc 0 (entget dtxt))) "*TEXT")
(vla-put-TextString
(vlax-ename->vla-object dtxt)
(strcat
"%<\\AcObjProp.16.2 Object(%<\\_ObjId "
(itoa (vla-get-ObjectId (vlax-ename->vla-object ent))) ">%).Measurement \\f \"%lu6%zs13\">%")))
(vla-put-layer (vlax-ename->vla-object dtxt) "0")
(princ))=

0 Likes
823 Views
3 Replies
Replies (3)
Message 2 of 4

dbroad
Mentor
Mentor

@Anonymous

 

Interesting problem.  They should be reporting the same value but don't.  Seems like a very subtle bug in the program where the rounding algorithm for fields is different from the rounding algorithm for dimensions.  The best way to fix the problem is to draft accurately though.  By stretching the line to an exact 1/16" length module, both values will report correctly.  Right now the fraction converts to 29/32".  So the field rounds down and the dimension rounds up when reporting.

Architect, Registered NC, VA, SC, & GA.
0 Likes
Message 3 of 4

Anonymous
Not applicable
Hi Dbroad,
I can’t avoid the bug as I have to drawing many lines based on equal divided distance of odd dimensions. It does not happen all the times, but it happens quite often in my work.
I understand there is bug, but I wish the lisp gives an alert to user to review current the dimension when the bug happens. It is easy to neglect the bug when the user works on hundreds of dimensions a day.
Thank you.
0 Likes
Message 4 of 4

dbroad
Mentor
Mentor

You could add an application that would scan for object fields and compare the output with the objects they report on and flag those objects.  It could be done as a separate command or as part of a reactor.  You could check on creation but if you are changing the length values after placement of the fields, then report on creation won't work.  The field already has the objectid of the dimension so it shouldn't be difficult to cobble a check routine together.

 

In almost all kinds of work, there are issues with the scraps that don't get added into dimension strings due to rounding quirks.  The movie, "Entrapment", for example, was based around a scheme to get rich by sending all of the unaccounted bits of money that weren't accounted for sent to a single account.  I prefer to set the units to a value small enough to be within the tolerance of construction and then live with the quirks.

Architect, Registered NC, VA, SC, & GA.
0 Likes