I've been getting this error on and off for about a year now, and I'm getting real sick of constantly erasing and re-drawing objects. So I'm wondering if anyone else has encountered this.
I sometimes will try to join two polylines (LWPOLYLINES) and it won't work. If I then try to fillet them with a radius of zero, I get the error that the two entities are non-coplanar. But they are. I've tried changing the elevation of both to something else (like 1) with no luck. I've tried the _FLATTEN express tool, with no luck. I've tried exploding, setting all the z-points to zero and then trying again, either by filleting with radius 0, or by converting them back to polylines and joining. Also no luck. I've tried purging (including purging DGN linetypes), auditing and even copying the objects into a new drawing.
The only thing I've been able to do that works is erase the object and re-draw it. For some reason, even if I put points at the ends of the line (or ends and middle for arcs), erase it then redraw using those points, it works. So the points are definitely coming in at z=0. I just can't figure out what's going on. One thing I've noticed is that this only ever seems to happen with drawings we get from outside our office. It never seems to happen on drawings made here.
Any help would be greatly appreciated.
Solved! Go to Solution.
" So the points are definitely coming in at z=0."
Not necessarily...
Lets say in the original file you get from the other office, there is a vertical line from 0,0,0 to 0,2,0.0000000001.
If your precision setting is .0000, and the original is .0000000000, and you place a POINT at each end of the line, your Points will be placed at the ends of the line at 0.0000,0.0000,0.0000 and 0.0000,2.0000,0.0000. When you redraw the line using those points it will be coplanar in the Z axis at elevation 0.0000.
Not coplanar if one point is at elevation 0.0000000001.
Polylines store with them the UCS that was active when they were created. If different UCSs were used for the two lines you may get the non-coplanar error message.
Assuming that you want all your geometry to lie on the WCS XY plane, set the UCS to World then give the list command. It will show a statement something like "Extrusion direction relative to UCS: X= 0.3420 Y= 0.0000 Z= -0.9397" for lines that were created when the World UCS was not active even if the line lies exactly on the world XY plane. If you do not see "Extrusion direction..." for a selected line then it was create on the true XY plane.
This problem is a holdover from the intial AutoCAD release in the 70's when it was considered a 2 1/2 D system. That is you had full control in two dimensions and limted control in the third.
I think the easiest solution is to set the UCS to World and trace over all relevant geometry using OSNAP on a separate layer.
~Lee
I've found that when I have this problem (often) I create a new ucs at an object snap where the lines and splines appear to join, then check the location of the snap or node first on one line or spline then the other. Positioning the ucs here ensures that one node is 0,0,0 and it is easy to detect a difference at the other objects snap or node. Often this is 0.00000001 or slightly more. I've tried setting tolerances higher, using grid snap and only snapping to object snap points but I still find most of my time is used investigating why commands like join, region, boundary loft etc do not work and this is the only way I've found to progress.
It is also frustrating to draw an object including a spline with three non linear points to be told the object is non plannar. I assume the spline curves in 3 dimensions but I can not understand why this should happen if the spline is defined with only one start and on end point.
Thanks for all the advice, but as I mentioned above, I've already tried setting a new elevation on the lines, which would get around the problem of the difference in elevations being less than my precision (which is turned all the way up, anyways).
Hell, I even tried a lisp routine to round off any floating point errors, but it didn't help either. I presume because there were no floating point errors.
I will definitely try the trick with the UCS, however. I'll mark as a solution if it works tomorrow.
Here's a much easier solution. Since polylines store the coordinate system with them and lines do not, simply explode the polylines into lines , add the fillet then use pedit if you want to convert them back into polylines.
~Lee
Here's a much easier solution. Since polylines store the coordinate system with them and lines do not, simply explode the polylines into lines , add the fillet then use pedit if you want to convert them back into polylines.
~Lee
Yeah, I tried that too, and they still won't join. The two points where they meet have the same coordinates, but I'm still told they're non-coplanar.
I tried the UCS trick and that worked. It seems like there might be some floating point errors involved, but I'll be damned if I can think of a way to fix it that can be automated and easily repeated. If I do, I'll post it here. In the meantime, thanks for all the help, guys!
Using UNITS change the displayed precision to the maximum number of decimal places (0.00000000). Using OSNAP END and the DIST command find the distnce from the end of one of the lines (not polylines) to the end of the adjacent lines. It should be 0.00000000. Also use LIST to check that all the z values are 0.00000000 with the world UCS active.
Using UNITS change the displayed precision to the maximum number of decimal places (0.00000000).
Or just use this simple lisp code to see the maximum precision, beyond 8 places
(rtos (getdist) 2 20)
I find the properties box works well. If you don't care what the elevations of your plines are, select "all" and then choose pline on the properties entity type pulldown. Change the elevation value from Varies to 0. Now all the plines can be fillet.
The suggestion to explode the non-coplanar polylines actuallly can work (but usefuleness of the result may still vary) - but it requires another step.
The procedure is:-
There may still be issues with the resulting polyline though even if AutoCAD happily created a single polyline from the resulting pile of lines.
For example, lets say that you wish to hatch the resulting polyline (if it is closed) - AutoCAD may allow you to select the closed polyline as a hatch boundary, but may refuse to display the resulting hatch when you try and preview the hatch or if you just accept the result and complete the hatch command.
This may be a result of using PEDIT>Multiple followed by the Join option to recreate the polyline as this allows the specification of a 'fuzz' precision which implies that the resulting polyline might be acceptable enough to have its closed property set to TRUE, but may not be good enough for the Hatch method to actually fill the resulting boundary.
I discovered this when trying to form up a hatched area from polylines that were originally created in Civil 3D from sections through surfaces so use this method with a bit of caveat emptor.
Regards,
Glenn
How on earth do lines become non coplaner when i am only working in 2d ????
I'm also having this problem (and I'm also working in 2D). In the past, I've found that one or the other polyline has somehow gotten an elevation besides "0" ... don't ask how, I don't know.
But now, this "Two entities are non coplanar" thing. Changing the elevation of both to "1" (just for kicks) doesn't do a thing.
Woohoo!!! Solution!!!
My overall UCS somehow got "out of whack" ... I fixed the UCS issue but the polylines still complained about being non coplanar ... but when I redrew the new polylines (with the correct UCS), the polyline fillet now works!
How can i set my drawing that it is only 2d ? Never should a line with an elevation in the z axis exist in my house ?
How do i set that ?!
🙂
Ben
@blfreilich wrote:
How can i set my drawing that it is only 2d ? Never should a line with an elevation in the z axis exist in my house ?
How do i set that ?!
....
You can force all points that you get by Object-Snapping to have a Z coordinate of zero by setting the OSNAPZ System Variable to 1 [on]. But that is only of any value if there are already things in the drawing with non-zero Z coordinates to Osnap to -- if there are not, there should be no need to set it. And that setting affects only Osnapped locations -- you would still be able to get non-zero Z coordinates in things in other ways, for example if a location or a Move or Copy displacement is typed in with a third coordinate number included, or if something gets Rotated or Moved or Copied under a non-World UCS. I don't know of a way to prevent those possibilities, other than being careful and conscious in drawing.
Can't find what you're looking for? Ask the community or share your knowledge.