I'm doing some artsy tracing stuff in SolidWorks and exporting via DXF to my CAM software. The problem is that splines are being broken into line segments.
I had thought that the problem was one of translation on the CAM software end, but when I open the file from SolidWorks the splines are line segments there as well. I've seen posts on this issue in the past, but have never seen a good solution.
I try to your problem - the file I make from the solidworks have spline in solidworks but no the splines but only the many lines create in dxf.
I perhaps one idea have about the formats r12 who can make no spline but again to try many formats newer and only the many lines comes in.
Upon the usage of word editer to iterogate file of dxf I find no define of spline. So you make idea of bad outputs coming from solidworks is correct idea. Not the reading in but of the writing. What is to be done ? I can you not tell.
By these ways, will not the cnc make the lines anysway for to program with?
I make experiment and find format autocad 2002-2004 format output by the solidworks makes to splines into the dxf and come back in also to solidworks, corel draws and autocad - so maybe version before this one makes it bad. Try maybe make version of the dxf most highest one possible.
May be this can be also to be read by you program cnc.
Thanks for your reply. I don't see an option for output to autocad
2002-2004 format. I should have mentioned that I'm running 04sp0 version of SolidWorks. I see same results in using dwg output.
In answer to your question about cutting the line segments, they are varied in length and as short as .005". Each segment requires a line of gcode and there are thousands of them. For each line of code, the laser head attempts to speed up to max cut speed and then ramp back down before hitting the end of that cut segment and starting the next. Running this code results in what looks like a twitching of the laser head. This can't be good.
I use to run into this problem frequently with drawings done in AutoCAD.
The CAM package I was using at that time was DP Technology Esprit X which had a tool called LCA Conversion. What LCA conversion did was convert the line segments to arcs using a tolerance that could be set by the user (me).
What I ended up with were parts that had a much smoother surface finish. The wire EDM machine (AGIE's) did not jerk like crazy, either.
In my opinion you will either need to recreate the part or use a tool like DP Technology Esprit X had.... LCA Conversion.
You might also want to post your problem in alt.machines.cnc. to get other machinists ideas on this.
Pathetically SolidWorks has absolutely no support for 2D output to IGES and equally pathetic is no 3D output to DXF (although customers need and request this year after year).
I'm sorely amazed that they presume that nobody needs this or even receives or needs to generate these types of files for their less CAD-capable vendors. Sorely amazed, but mostly sore.
My favorite DXF trick is when the detail circles come in as a collection of lines, just like the splines described above. I have to laugh my ass of at this - and then cry, then create a 3 point arc in AutoCAD and then erase the crappy mess then SolidWorks translator made when trying to output a CIRCLE!
Sean, It is the DXF output from other systems that was at issue I think. I understand that IGES is now an added cost option for AutoCad.
As SW is a 3D system why would they want a 2D-only option?
IGES, BTW, IS 3D. And no matter how much jb likes it (LMAO over his problems with it BTW), DXF is controlled by AutoCad and many versions and levels of support by various systems seems to be a problem.
IF the vendor is not 3D capable perhaps a graphics-only file is in order anyway. Send them a picture of the money .
Sounds like most of your problems are from the sending system's end anyway ... like I said, hard to make accurate geometry (circles, splines, etc.) from polylines. Perhaps the sending system has other options (like "DO NOT CONVERT TO POLYLINES")?
In any case, once the sending system has output polylines you cannot blame the system getting the data for not making splines, circles, etc.
Take a look into the DXF files to see exactly what you are getting before placing blame. IGES files (ASCII versions) are man-readable as well.
For drawings, I beleive, which are still widely used by many people (grin).
No arguements there, but I have used a couple "pure 2d" systems that allow an iges output/input of a drawing (anvil-1000 & cadkey if I recall correctly from the anient mid 90's)
This is problematic. After r12 things go to hell rapidly. I think that the post r12 standard was not published and therefore people who had to make translators had more work to do in reading/writing post r12. R12 can't do, as you know, some entities like ellipses and (maybe) splines, mtext, etc.
The sending system is here on my machine and so is the recieveing system. Unfortunately SolidWorks does not have this level of tweakability.
That's 100 per cent correct, but the problem is that the sending system does not output the correct data for a detail circle. I find this highly laugable.
Try it for yourself. Make any solidworks drawing, create a detail view and then write out a dxf file. You will not see a collecton of lines, not a circle.
Are they woman-readable too? LOL!
I'm not adding much useful to this thread.
As delectible as this discussion is, I'm pushing myself away from the table!
I'll be in the vomitorium if you need me Caesar . . .
How do you suggest he do this ??? He admitted in alt.machines.cnc that he has *never used SolidWorks* !
Further, he fails to understand that many CNC machines allow a .dxf file to be imported so a toolpath can be created. Hurco and Bridgeport machines have controls that import .dxf files. Neither allow input of IGES files !
The problem of polylines is so common that better CAD/CAM systems give you tools to fix the problem. I have already mentioned DP Esprit X's LCA conversion tool.
He just learned in alt.machines.cnc that Autocad IGES is an extra add on. Thanks for helping him to understand how SolidWorks often fails to give machinists the needed tools. :>)
Perhaps one day when he upgrades from Windows 95 (which he admits is the only MS OS he has) he might be able to try some of what you suggest. SolidWorks Corp. would probably let him take advantage of the unemployed engineer software deal. Should he actually make the effort, he might be able to see for himself what SolidWorks has to offer instead of being spoon fed on Usenet. Sometime in the future he might actually realize that everyone would not be better off with Unigraphics as he frequently claims.
This is just too funny. I have not laughed this hard in weeks. :>)
interesting. Ive been exporting my own file formats directly from SW views for a few years now (using various API "GetPolyLines" calls), and some of these calls allow for splines.
When first setting up this code, I was unable to find any example splines to 'parse', so I merely put some code in to notify me when it came across a spline, where then i could use the newly found spline to reverse engineer what SW was giving for information.
Its been a few years now, and, like an ugly girl on a Saturday night, Im still 'waiting for a call' .....
There are various things called "splines" with somewhat different mathematical basis behind them. Some are even planar curves. Some have tangency constraints or curvature constraints on their ends, some do not.
All can be represented as polynomial functions but the allowed maximum exponent can vary quite a but .. from about 3 to perhaps
18 or higher. Clearly no (general) degree 18 curve can be exactly represented by a degree 3.
And NURBS curves are rational ... that means that the functions can have a polynomial denominator as well in their terms.
There are some good books on such things listed in the the IGES spec IIRC. And now many places on the Web to get information.
For a good translation between systems to exist the same degree and basis equations must be used by both systems.
A good place to start might be Mike Pratt at NIST or any Pro-E docs you can find.
BTW, If you look at an ASCII IGES file for the curves in question you can see the raw data of the curves. Knot points, polynomial exponents, interval, ....
Still looking for the ultimate solution, but thanks for the help so far. As it turns out, CAM fitting splines is not a good option either. The GCODE produced is about the same in length as using line segments. I really need a simple way to convert splines to arcs. I can start with arcs, but it will be extremely tedious in comarison to using splines. I will find a solution, but it looks to be a long, frustrating road.........