Inaccuracy between lines

[victoria]

Have any of you tried the changing the VIEWRES to maximum? 20,000

[rkmcswain]

Have any of you tried the changing the VIEWRES to maximum? 20,000

VIEWRES only affects visibility, not the accuracy of drawing geometry.

[CADDmanVA]

What leads you to believe that?

Copy+Paste is no different than Wblock+Insert.
No accuracy is lost in either case.

The exception to this is if you are working in an area with very large coordinates since AutoCAD is only accurate to 15 significant digits.

Ref URL: http://www.intelcad.com/pages/autocad/index.htm

I'll argue that till the day I die! Using accelerator keys creates anonymous blocks and will quickly bloat the daylights out of a drawing. I think using them is fine IF AND ONLY IF you purge the block out after the move.

Actually I'm using Imperial units and also having accuracy problems - see my post(s) under the "Strange inaccuracies" thread.

In particular, I've noticed odd behavior in connection with osnaps - AutoCAD "finds" intersections, etc., that are very slightly off where the geometry actually intersects. (Yes, I know about how the limitations of display hardware can make snapping to arcs and circles appear to be off the geometry, but I'm seeing these inaccuracies with lines only.)

I've noticed this problem with OSNAPS too. Another problem I have rather frequently is using the tangent tangent radius routing for circles. According to AutoCAD, the created circle is tangent to both objects, but TRIM says otherwise. I never thought about math errors or accuracy errors before now though..........

[mmccarter]

Flatten does give you inaccurate 'recreated' objects but not the copy and paste. .

I would take issue with this statment.
I have seen the flatten command do wild things with the geometry and position of the contents of a drawing after it has been run. Seen it many many times.

[michael.12445]

I'd be curious to see if anybody else gets the same results with this as I do...try running this on any given file whose line entities are supposed to be exactly vertical or horizontal:

(defun ratout()
(setq a (ssget "X" '( ( 0 . "line" ) ) ))
(setq k 0)
(while (< k (sslength a))
(if (not
(or (eq (caddr (assoc 10 (entget (ssname a k))))
(caddr (assoc 11 (entget (ssname a k))))
) ;y-coordinates match - line is horizontal

(eq (cadr (assoc 10 (entget (ssname a k))))
(cadr (assoc 11 (entget (ssname a k))))
) ;x-coordinates match - line is vertical

(eq (- (caddr (assoc 10 (entget (ssname a k)))) (caddr (assoc 11 (entget (ssname a k)))))
(- (cadr (assoc 10 (entget (ssname a k)))) (cadr (assoc 11 (entget (ssname a k)))))
) ; line is diagonal at 45 degrees

(eq (- (caddr (assoc 10 (entget (ssname a k)))) (caddr (assoc 11 (entget (ssname a k)))))
(- (cadr (assoc 11 (entget (ssname a k)))) (cadr (assoc 10 (entget (ssname a k)))))
) ; line is diagonal at 135 degrees

)
)
(progn
(command "change" (ssname a k) "" "p" "color" "30" "")
)
)
(setq k (+ k 1))
)
)

- to use it, load "ratout.lsp" and then type (ratout) at the command: prompt. If your drawing uses color 30, you should change "30" to another color in the line

(command "change" (ssname a k) "" "p" "color" "30" "")

What this does is find any line that's not either horizontal, vertical, or diagonal at 45 or 135 degrees, and then changes its color to orange (color 30). Of course, this will also flag lines that are intentionally angled, but I'm interested in the ones that are supposed to be orthogonal. I'm finding on files that have been around a while and undergone lots of editing, almost every line is off. I'm also finding that I can produce lines that are off in a new file by using tools that I thought were meant to ensure accuracy, i.e., osnaps, polar snap, etc. (no, I am NOT trying to "eyeball" anything!)

I'd be very curious to see what others come up with...

Thanks,

Michael Evans
Togawa Smith Martin Residential, Inc.

[rkmcswain]

I'll argue that till the day I die! Using accelerator keys creates anonymous blocks and will quickly bloat the daylights out of a drawing. I think using them is fine IF AND ONLY IF you purge the block out after the move.

I wasn't talking about drawing bloat. I was talking about the accuracy of entities copied from drawing to drawing using either wblock/insert or copy/paste. There is no difference.

I've noticed this problem with OSNAPS too. Another problem I have rather frequently is using the tangent tangent radius routing for circles. According to AutoCAD, the created circle is tangent to both objects, but TRIM says otherwise. I never thought about math errors or accuracy errors before now though

It all leads back to the 15 significant digits of accuracy. The more places you use up on the left side, there fewer there are on the right for calculations.

[irneb]

I wasn't talking about drawing bloat. I was talking about the accuracy of entities copied from drawing to drawing using either wblock/insert or copy/paste. There is no difference.

I don't know, I've found that normal copy-n-paste gives me inaccuracies. But when I copy with a base point this doesn't happen. I think the reason may be something to do with the "base point" AutoCAD assigns automatically when you don't explicitly assign one.

It all leads back to the 15 significant digits of accuracy. The more places you use up on the left side, there fewer there are on the right for calculations.

I think this is exactly what's going on ... I've tried looking at each line's x & y values. These start with a fractional (decimal) value - so the 15-16 digits are already used fully. Then since all numbers in computer terms are in binary (base 2), this converts very badly into decimal (base 10) numbers (http://en.wikipedia.org/wiki/Floating_point). So what I've found is that moving all the lines to a round number as base - removes the inaccuracies.

Unfortunately I can't always apply the above fix. Sometimes I've got a site-plan (spanning more than 1km - i.e. 1 000 000mm) which has several sets of grid-lines at different angles. These start very seldom on a round number (because they're at different angles). I usually create a UCS for each set so I can rotate the view to plan & have all my polar angle snaps work with the relevant grid-set. So the fact that I'm using at least 6 digits at the left & then have a gird-set at an angle from WCS, I can see 2 places where that 15-16 digits gets used up.

[irneb]

I'd be curious to see if anybody else gets the same results with this as I do...try running this on any given file whose line entities are supposed to be exactly vertical or horizontal:

I've tried your code, unfortunately it gives me way to much incorrect "error" lines (nearly everything). So I've created a similar LSP (TESTLINES.LSP) attached. When I run this on a ground-floor plan I get:
About to check lines for accuracy or perpendicular with a tollerance of 0.01000000 degrees.
11635 lines found in current drawing.
617 lines found not perpendicular.

And I've checked this, most of those "error" lines are walls (see attached screen capture - Capture_4.jpg). The lines in WHITE are those found as off by 0.01 degrees. They've been created at exactly 0, 90, 180, or 270 of WCS. Then trimmed when creating the windows & recesses. As you can see some of the left-over lines don't give the error.

The extents of the floor plan ranges from (-187000;-35400) to (1335100;803900). The range of the screen capture is (830500;581400) to (848400;592200).

[rkmcswain]

I don't know, I've found that normal copy-n-paste gives me inaccuracies.

But it still shouldn't be any different than wblock/insert.

When you "copyclip" entities, AutoCAD simply blocks them out to a DWG file in your %temp% directory. When you pasteclip into a drawing, it's simply inserting that block.

[irneb]

When you pasteclip into a drawing, it's simply inserting that block.

Yes that's true. Unfortunately when you copyclip (not copybase) AutoCad calculates the insertion point as the left-bottom-most point of the entities you've selected, or if you've zoomed in closer than that then the left-bottom coordinates of the visible screen. This is usually not a point a rounded coordinate distance from the entities (unless you've zoomed-out sufficiently & your left-bottom-most entity has a rounded coordinate for its left-bottom-most point - which it wont if it's an arc or a "skew" line).

Thus everything gets placed in this block at fractional coordinates, even if you haven't drawn them that way - i.e. you get into that 15-16 points of accuracy scenario again.

This is also one of the reasons (not the major one by far) why you should never create a block without explicitly specifying a base point (insertion point).

Another thing about the "bloating" is that wblock & insert does the same thing, as all the current (and standard) styles such as text, dims, tables, layers, etc. are included in that DWG file, even if the entities you've selected to wblock has nothing to do with those styles. The only way (I know of) to "copy" a block from one drawing to another without all that clutter piggy-backing with it is: using DesignCenter, browse to the current open drawings, browse to the blocks in the relevant drawing & drag-n-drop the block you want.