Sum of Dimension text

[LoganAC34]

I need a LISP that can total the selected dimensions and display the totaled amount. I've seen a lot of posts with a similar function but they don't quite do exactly what I want. They all sum the actual value of a dimension rather than the amount displayed in the text of the dimension line in the drawing. 

For example in the drawing attached the two dimensions within the 2'-10 7/8" dimension do not add up to 2'-10 7/8". Due to precision and rounding, they instead add up to 2'-10 15/16".  Sometimes this happens, sometimes it does add up to the overall dimension.  

The LISP would need to be able to add up the amount displayed instead of the actual value of the dimension, as well as preferably any text override. So if i override the text in the 11 13/16" dimension to 11 3/4", the two dimensions would then add up to 2'10 7/8". Preferably the total would display in the command line. 

[Kent1Cooper]

A recent related topic, in case something there gives you any ideas, or gets you started in a direction.  What you are asking could certainly be done with parts of what my Message there describes -- figure out what the displayed value must be by looking at the measured value in terms of the Dimension Style's roundoff value, and convert that into an actual number, then add those up.  A difference would be the using of an override text value where present, in place of the actual measured value or its rounded-by-Style value.

But I confess to being curious:  What would be the purpose of knowing what a string of dimension text contents add up to, knowing that it probably isn't correct?

[3wood]

You can also try ADDDIM.

When it prompts "Use text overrides? [Yes/No] <Yes>:", just select "Yes".

You need set drawing units to "Architectural" first.

[LoganAC34]

It isn't that I know that they wont add up, its that i'm checking to see if they add up. We have a precision of 1/16" on panel details and we have to provide linear dimensions so when we send the drawings to the glass company they can make it. We also have to provide an overall dimension. The smaller dimensions round off and sometimes not sum up to what the overall dimension displays. If that's the case, we remove/add a 1/16" to one of the dimensions to make it add up correctly. I can not change the precision of the dimension style to prevent rounding. The way we check for a rounding issue now is adding up the dimensions manually and seeing if the sum we get equals the overall dimension. Most of the time the dimensions do add up correctly, its the off chance they don't which still happens often enough. 

[LoganAC34]

Unfortunately I cannot set the units on the drawing to architectural. I mean, I probably could just to use this function, but all of our drawings are in decimal because that's what we draw in. Plus I already used that function and it doesn't add up like I wanted. It still adds up to 2'-10 7/8" with or without including overrides when it should add up to 2'-10 15/16" if it was working like the way I wanted it to. Thank you for the suggestion though. 

[3wood]

Actually you don't need add-on. Just set Dimension Roundoff to 1/32''. You can change the dimension style or overwrite individual dimension settings.

[Kent1Cooper]

---

@LoganAC34 wrote:

... add up the amount displayed instead of the actual value of the dimension, as well as preferably any text override. .... 

---

Try this [minimally tested]:

(defun C:DDVS ; = Dimension Displayed Value Sum
  (/ sum ss n dim mea ddata sdata disp prec)
  (setq sum 0.0); initial value to add to
  (prompt "\nTo add displayed values of Dimensions,")
  (if (setq ss (ssget '((0 . "DIMENSION"))))
    ;; Does not limit to only linear-variety Dimensions, but could be made
    ;; to ignore angular and ordinate Dimensions in stepping through.
    (progn ; then
      (repeat (setq n (sslength ss))
        (setq
          dim (ssname ss (setq n (1- n)))
          mea (cdr (assoc 42 (setq ddata (entget dim)))); measured value
          sdata (tblsearch "dimstyle" (cdr (assoc 3 ddata))); Style's data
          disp ; displayed value
            (if (member '(1 . "") ddata); no override of content?
              (rtos mea ; then -- measured distance as [if] rounded in display
                (cdr (assoc 270 sdata)); mode
                (cdr (assoc 271 sdata)); precision
              ); rtos               
              (cdr (assoc 1 ddata)); else -- use override value
                ;; [Assumes override is distance-type content only, and in
                ;; correct format; does not account for override in higher
                ;; precision than in Style's setting!]
            ); if & disp
          prec (max (cond (prec) (1)) (cdr (assoc 271 sdata)))
            ;; highest precision of all selected Dimensions' Styles
          sum (+ sum (distof disp)); [decimal/real-number units]
        ); setq
      ); repeat
      (prompt
        (strcat
          "\nSum of displayed distances = "
          (rtos sum (getvar 'lunits) prec)
            ;; Assumes all selected Dimensions' Styles use same units mode
            ;; as drawing's LUNITS setting [otherwise, how to express sum?].
            ;; Uses highest precision of selected Dimensions' Styles, in case
            ;; any are higher than drawing's Units precision setting.
          "."
        ); strcat
      ); prompt
    ); progn
    (prompt "\nNo Dimensions selected."); else
  ); if
  (princ)
); defun

On the question of override text content that's of higher precision than the Style's setting, it might be possible to determine that an override is that way [e.g. the Style's roundoff value is 1/2" but you override it with something ending with quarters or eighths or sixteenths of inches].  Currently, such an override would be added into the sum correctly, but if no Style's roundoff level is that precise, the result will be rounded to the tightest Style roundoff value, which will round off that override's contribution.  If you only do overrides to a coarser  value than the Style's roundoff, as in your example of taking 13/16" to 3/4", it doesn't matter.

[LoganAC34]

Thank you for taking the time to make this. It works pretty good other than a few things. The units of the drawing are in decimal and you need to have them set to architectural for this to work. I can't change the units unless I am just going to change them to use this function and then change it back when i'm done. Preferably I would like it to work without having to change the units to architectural. The other thing is that you need to have the fractions of an inch not stack. This isn't really a problem since if I override the dimension I wont stack the fraction, but to make the LISP more versatile, is there a way to calculate overrides with stacked fractions?

Also one last thing, could you make a version that works with millimeters? If you can, the dimension style has a precision of 0 meaning no decimals and it only measures in millimeters.

[LoganAC34]

This doesn't really work. It works for just that example. If you use the same method with another example, it doesn't.

[Kent1Cooper]

---

@LoganAC34 wrote:

.... The units of the drawing are in decimal and you need to have them set to architectural for this to work. ....

---

Are the Dimension Style definitions set to use Architectural units in a drawing in which the units are decimal?  That seems a very odd way to go about things, but if that's really how it is, I think you could simply change this:

(rtos sum (getvar 'lunits) prec); using the drawing's  linear-units setting

to this:

(rtos sum 4 prec); using Architectural units regardless, without  changing LUNITS setting

[Kent1Cooper]

---

@LoganAC34 wrote:

.... could you make a version that works with millimeters? If you can, the dimension style has a precision of 0 meaning no decimals and it only measures in millimeters.

---

For that, don't  make the change in Message 10, and change this:

prec (max (cond (prec) (1)) (cdr (assoc 271 sdata)))

to this:

prec (max (cond (prec) (0)) (cdr (assoc 271 sdata)))

which is probably how it should be done in any case, for any variety of units [I forget now why I set it up to use 1 as default].

[LoganAC34]

Yes it is. I know its kind of weird but its just how my company does it. We draw in millimeters and switch between dimensioning in feet/inches and millimeters.

I changed your first solution in message 10 and it didn't seem to do anything. The drawing units still needed to be changed to architectural for it to work. I also tested with the change below and it didn't seem to change its function at all.

Your solution in message 11 did work though for making it function with millimeters. Thanks, works perfectly!

[Kent1Cooper]

---

@LoganAC34 wrote:

.... We draw in millimeters and switch between dimensioning in feet/inches and millimeters.  ....

---

Does that mean that you use a Dimension Style with a linear scale factor  applied when you dimension in feet/inches?  Otherwise, I don't see how you can switch dimensioning  units in things drawn  all in the same units.  That would certainly be an important thing to know....

[LoganAC34]

Yes, sorry. Its .0394.

[Kent1Cooper]

---

@LoganAC34 wrote:

Yes, sorry. Its .0394.

---

Try this [untested]:

(defun C:DDVS ; = Dimension Displayed Value Sum
  (/ sum ss n dim mea ddata sdata disp prec)
  (setq sum 0.0); initial value to add to
  (prompt "\nTo add displayed values of Dimensions,")
  (if (setq ss (ssget '((0 . "DIMENSION"))))
    (progn ; then
      (repeat (setq n (sslength ss))
        (setq
          dim (ssname ss (setq n (1- n)))
          mea (cdr (assoc 42 (setq ddata (entget dim)))); measured value
          sdata (tblsearch "dimstyle" (cdr (assoc 3 ddata))); Style's data
          disp ; displayed value
            (if (member '(1 . "") ddata); no override of content?
              (rtos ; then -- measured distance as scaled & [if] rounded in display
                (* mea (cdr (assoc 144 sdata))); measurement x linear scale factor
                (cdr (assoc 270 sdata)); mode
                (cdr (assoc 271 sdata)); precision
              ); rtos
              (cdr (assoc 1 ddata)); else -- use override value
            ); if & disp
          prec (max (cond (prec) (0)) (cdr (assoc 271 sdata)))
          sum (+ sum (distof disp)); [decimal/real-number units]
        ); setq
      ); repeat
      (prompt
        (strcat
          "\nSum of displayed distances = "
          (rtos sum 4 prec)
          "."
        ); strcat
      ); prompt
    ); progn
    (prompt "\nNo Dimensions selected."); else
  ); if
  (princ)
); defun

Warning commentaries from the previous code still apply.

EDIT:

I suggest you change your .0394 to .03937, which really gets you more  additional decimal places of accuracy than it looks like, because the next two digits in the mmm-to-inches ratio are 0's.

This leaves the question of the mode  of the reported sum.  You want it to work with millimeters, but when you use it with Architectural-mode Dimensions, you want it to report in those without  changing the LUNITS setting of the drawing.  The latter is achieved in the code by using the 4 for Architectural units, but that's not going to give you what you want when you use it with millimeter units.  It could be made to pull the mode setting from the Dimension Style of one of the Dimensions, so it would work right in either context, but that would depend on all Dimensions selected being in Styles that use the same mode.  Can you count on that?

[LoganAC34]

Actually the dim scale linear is already set to .03937. I looked at the value in the properties palette thinking it would show me the same value, but the one in the dimension style window shows the more accurate .03937. 

I could not get the lisp to work properly, the first time I tried to use it, it would give me "error: bad argument type: numberp: nil". But after trying to mess with the code an none of that working I recopied the code and tried again. Then it started giving me 2 3/4" which if you multiply that by 25.4 (how many millimeters are in 1") it would give me the actual length of what I was summing up (not the desired number). 

---

@Kent1Cooper wrote:
It could be made to pull the mode setting from the Dimension Style of one of the Dimensions, so it would work right in either context, but that would depend on all Dimensions selected being in Styles that use the same mode.  Can you count on that?

---

We have many dimension styles and we do mix them sometimes but when this lisp is going to be used its either millimeters or feet an inches or just inches, never summing multiple modes together. So when trying to total a string of dimensions you can count on them being the same mode.

[Anonymous]

What I ended up doing was getting  a toggle lisp for dimstyles. Basically had two dimstyles set up; one for fractional, the other for decimal. That way I can error check to see if the fractional dimensions are truly their decimal equivalent by flipping back and forth so I will know where I need to make adjustments. In my opinion, this was a better solution.

[LoganAC34]

I can't get the lisp to work correctly for imperial dimensions. I was playing around with the lisp trying to learn from it and i don't know what i'm doing. I was trying see if I could at least get it to function like the way I want to even if it isn't the best way and I couldn't get anything. Right now it doesn't work at all. When I try to use it on dimensions that only display measurements in inches, it gives this error: "; error: bad argument value: rtos mode: 7" I would love to have this lisp work. 

[LoganAC34]

I'm not quite sure how this helps me. How would switching between fractional and decimal dimensions let me know if a string of dimensions does not equal up to their over all dimension? Wouldn't I need to still manually add up or check each dimension?

[Kent1Cooper · Accepted solution]

---

@LoganAC34 wrote:

I can't get the lisp to work correctly for imperial dimensions. ..... 

---

If the issue is with those that have a linear scale factor applied in their Style, I must not have tried the code in Message 15 on Dimensions in such Styles, and I find in experimentation something I didn't expect -- the "measured" distance stored for a Dimension is not  the true distance [with the linear scale factor applied only in display], but already has the linear scale factor applied to it!   Replace this line in the code in Message 15:

    (* mea (cdr (assoc 144 sdata))); measurement x linear scale factor

with just this:

    mea; "measurement" is already x linear scale factor

and see whether it works for you.