Z-Axis

John Gaunt

Does anyone else get situations where entities develop z coordinates a small amount off 0,0?

Sometimes lines will not chamfer, fillet (R=0) usually works in its place.

Sometimes splines will not offset because one of their control points is off z=0,0.

I only draw in 2d.

Flatten fixes most if not all of the problem when it happens seemingly at random, but now I have to be selective about its use (it can go too far).

James Cameron

I know what you mean John. I don't know if I inadvertantly switch an "elevation" button or perhaps when I get a drawing from another where there is depth from a 3d item. Needless to say it can be frustrating. If I keep the drawing "in-house" as in Bricscad and it doesn't see Acad things seem to run more smoothly You can kind of watch in the properties window for a 'Z' coord(edit there if necessary). Of course you've discovered the flatten function. Be aware of the elavation setting, probably not telling you anything here. This probably wasn't much help but I find it's nice to know others are out here.

John Gaunt

Oh mine happen in any file at all. The Z is off by such small amounts it usually still shows as 0 in Properties. It only applies to one end of one line, one control point of a spline.

I have submitted a support request.

Watch out for Flatten - it now explodes blocks.

Gerrit Kiers

Maybe you should try out a tool that allows you to scale with different scale factors in XYZ directions. and scale with a vextor 1,1,0 ? That should flatten all.

I believe you can find free tools, GeoTools has one tool as well (I have not tried any).

[Deleted User]

An old lisp routine I find use for:

(defun c:scalez ( / zscent ss n scale ent ent1)
   (defun zscent ( / k p)
        (setq k 9)
        (while (setq p (assoc (setq k (1+ k)) ent))
           (setq ent (subst
          (list k (cadr p) (caddr p) (* (cadddr p) scale)) p ent))
      )
     (entmod ent)
  )
 (setq ss (ssget) n (if ss (sslength ss) 0)
            scale 0)
  (while (> n 0)
     (setq ent (entget (ssname ss (setq n (1- n)))))
       (if (or (= "POLYLINE" (cdr (assoc 0 ent)))
                (= "INSERT" (cdr (assoc 0 ent)))
          ) 
            (progn
                (setq ent1 ent)
               (while (/= "SEQEND" (cdr (assoc 0 (setq ent
                   (entget (entnext (cdr (assoc -1 ent))))))))
                   (zscent)
              )
             (setq ent ent1)
           )
     )
     (zscent)
  )
 (command "redraw")
)

John Gaunt

Thanks for all suggestions, but reducing entities to 0-Z is not the real problem.

The thing is, somewhere in the course ofworking in any file some of my entities "develop" a non-0 Z coordinate so small it does not show when luprec is 8.

Lines then refuse to chamfer, splines snapped to a block slightly off 0-Z have one control point out of flat and won't offset.

I'm wondering how anything can get that way accidentally and if anyone else has noticed it?

Lines sometimes offset the wrong way, dunno if that is connected.

Greg Skelhorn

Hi John,

A wild guess is the tolerance (or fuzz) for zero (and in some cases equal) is too small. Working with floating point numbers we will always experience inexact values due to the finite precision. I was bumping into something similar on occassion during the beta cycle of v10. I recall difficulties with offset, fillet and the tangent snap but I think most of my reports have been dealt with. I have not been able to upgrade to v10 yet due to difficulties with the web store so I cannot comment on the released version.

I generally work with very large coordinate values based because I am generally georeferenced. Are you working with large coordiante values also?

Have you submitted a problem report yet?

 

John Gaunt

Hi Greg, my work is HVAC so the coordinates are just the average large building.

Although I was sent a file recently which had been drawn about 9,000 km away from 0,0 and everthing in it was slightly out of square (anything up to 20mm in plan) and one of my lisps which draws a small arc would not place the arcs correctly.

I noticed the non-0 lines first in about V8 or V9.

I submitted a request a few days ago about a lisp which draws and offsets splines which would not offset.

The reason came back - they snap to a block which is not quite 0-Z. This has lead onto the long existing non-Z-0 problem which had not been specific enough to pin down to submit.

I am fairly sure a non-0 line is at the bottom of it, this offsetting consequence just had not happened before.

It struck me a long time ago that there must be some ultimate inaccuracies, indeed in the computer itself, but it had never actually manifested itself before.