Browse All Articles > Quickly joining segments into polylines, using AutoCAD.
If, like me, you find yourself repeatedly and tediously joining many segments (lines, arcs) in other people's drawings back into polylines that can be used more effectively in Computer Aided Machining and Laser Cutting, then this article is for you!
I have personally scoured the blogs for hours and hours, and given up ever having hope of finding an easy way to join segments into polylines. Finally, I found a solution that is both obvious and hidden. Obvious because you've probably seen it before. Hidden because you probably ignored it, like me and the seemingly hundreds of others who are stumped or who have settled for the limited capacity of the boundary function.
(Apparently the newest version of AutoCAD, 2011, actually gives you an indication as to why a "valid hatch boundary cannot be found," but this isn't a panacea for those of us who are stuck with older software because of the recession.)
If you're like me, early on you discovered the Boundary function. However, using boundary to create a polyline has it's limits, and frustratingly creates a polyline over existing lines so that one must still go behind and clean up after the leftover lines. This can be tedious, especially since the boundary function frequently only works on portions of the drawing.
When looking in blogs to solve another problem, I haphazardly came upon a solution to this problem posted in a thread that had gone hopelessly off topic.
Pedit> Multiple!
When you type in Pedit, notice that the command line prompt gives you and option to click on a polyline or to type "m" for multiple. If you type 'm', you can select the entire drawing with a window crossing function, ask ACAD to make all segments into polylines, and choose join. The last part is the most important, though, because at the very last step ACAD gives you the choice to enter in a "Fuzz Distance." A small fuzz distance of, say, 0.5 mm will allow the multitude of lines that just barely end at different points to be automatically joined. Those segments that are grossly skew will not be joined by this method, and you may end up joining three or four by the other polyline method. (Sometimes after I've used polyline>m to join several hundred segments at one go I spend a few minutes using Pedit the non-multiple way).
The only things that cannot be joined using this method are ellipses, spline curves, and those strange lines that seem to always be under the influence of Ortho mode. I have learned that if I move the end point of a line and it moves like a rook on a chess board to simply delete it and redraw a polyline segment in it's place. There are several ellipse tracing LISP scripts available for free on the net for eager seekers, however, I have found them to be wanting. They seem to want to close ellipse and spline segments into curly-cues, thereby adding complexity instead of reducing it. I intend to write my own tracing code in the near future that will avoid this pitfall. Look for an update in the next several months!
I hope you found this short article useful. Please write me if you have questions.
I have personally scoured the blogs for hours and hours, and given up ever having hope of finding an easy way to join segments into polylines. Finally, I found a solution that is both obvious and hidden. Obvious because you've probably seen it before. Hidden because you probably ignored it, like me and the seemingly hundreds of others who are stumped or who have settled for the limited capacity of the boundary function.
(Apparently the newest version of AutoCAD, 2011, actually gives you an indication as to why a "valid hatch boundary cannot be found," but this isn't a panacea for those of us who are stuck with older software because of the recession.)
If you're like me, early on you discovered the Boundary function. However, using boundary to create a polyline has it's limits, and frustratingly creates a polyline over existing lines so that one must still go behind and clean up after the leftover lines. This can be tedious, especially since the boundary function frequently only works on portions of the drawing.
When looking in blogs to solve another problem, I haphazardly came upon a solution to this problem posted in a thread that had gone hopelessly off topic.
Pedit> Multiple!
When you type in Pedit, notice that the command line prompt gives you and option to click on a polyline or to type "m" for multiple. If you type 'm', you can select the entire drawing with a window crossing function, ask ACAD to make all segments into polylines, and choose join. The last part is the most important, though, because at the very last step ACAD gives you the choice to enter in a "Fuzz Distance." A small fuzz distance of, say, 0.5 mm will allow the multitude of lines that just barely end at different points to be automatically joined. Those segments that are grossly skew will not be joined by this method, and you may end up joining three or four by the other polyline method. (Sometimes after I've used polyline>m to join several hundred segments at one go I spend a few minutes using Pedit the non-multiple way).
The only things that cannot be joined using this method are ellipses, spline curves, and those strange lines that seem to always be under the influence of Ortho mode. I have learned that if I move the end point of a line and it moves like a rook on a chess board to simply delete it and redraw a polyline segment in it's place. There are several ellipse tracing LISP scripts available for free on the net for eager seekers, however, I have found them to be wanting. They seem to want to close ellipse and spline segments into curly-cues, thereby adding complexity instead of reducing it. I intend to write my own tracing code in the near future that will avoid this pitfall. Look for an update in the next several months!
I hope you found this short article useful. Please write me if you have questions.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)