Hey,
Im working on a project in which we want to export curves from Rhino (Baked from Grasshopper) to DWG format for laser cutting. In doing this I’ve been following this guide from McNeal Wiki: https://wiki.mcneel.com/rhino/exporttolaser
But I’m still having some pretty troubling issues in exporting the curves. When I follow the guide (convert command => export R12 Natural), it is as if some vertexes in the DWG point lists have gone missing. Also some curves end up open, and if it weren’t for that (manufacturer complained about this), chances are that we wouldn’t have discovered this rather serious issue until we got the parts delivered.
The file is large (in total around 86k curves before convertion), but the problem persists when when I’m only exporting portions of the file, so size alone does not seem to be the villan here.
My workaround for now is to export as “R12 lines and arcs” instead of “R12 Natural” and then join all of the curves in AutoCAD, which seems to work but takes time.
Please help me figure out why this is happening, and how I can make sure my future DWG exports end up correct.
EDIT
After exporting the curves with the same settings (R12 Natural) again, the issue with missing vertexes occured in some other curves than for the previous export (but also some similar). Also the latter export had 7 open curves and the earlier had 5. The first 5 open curves are also all open in the second export, but closed in the .3dm file.
See pictures below for problem description:
Here are my original converted Rhino-curves (lines and arcs):
Hello Jakob
A few months ago I had to create a complex file in Rhino for dwg which was full of splines (autocad is rubbish when it comes to editing splines). Like you, I was unable to get a satisfactory export. My solution was to export as ai (Illustrator) open the file in Illustrator and export as dwg. It worked. The file was all 2D, this solution won’t work for 3D. Part of this image below
Dropped vertices on very subtle curves is a problem I discovered when making sails for my race boat.
The only accurate solution I have managed to come up with is to force a very high point count and export as polylines. that stops our CNC cutter controller from missing bits. It’s a bit of a brute force solution.
I’ve attached our setup for Polyline export to DXF which seems to work very well.
First, I’d recommend you try exporting from Rhino to IGES if you’re going to CAM.
If you need to use DWG/DXF, then use the ConvertToArcs tool on all the wiggly, higher order NURBS curves. Circles, arcs, and straight lines are file as they are supported objects in DWG/DXF. NURBS curves are not.
Use the Rhino Convert command.
Use these command option settings:
Output=Arcs
SimplifyInput=No
DeleteInput=Yes
AngleTolerance=0
Tolerance=0.01mm or 0.002"
MinLength=0
MaxLength=0
OutputLayer=Current
The tolerance controls how far the arcs will pull away from your NURBS curves. Your machining process and project will determine how much is OK. The distance is in current model units.
Then when you Export to DXF, use the “CAM Imperial” export scheme for inches and “CAM Metric” for millimeters.
Always check your DXF file by opening it in Rhino before you send it for cutting to make sure it looks good.
@Tone & @Steve_Howden Thanks for sharing your solutions this issue. I ended up with these settings in the end, for some reason, it seemed to work out when I changed the maximum angle to 1 instead of 2 and unchecked “simplify lines & arcs”, altough the angle where the missing points are located in the image above, is much larger than that. That way curves came out joined and ready to use.
@John_Brock Thanks for the tip of IGES, I will consider that next time around!
Other than that I more or less did what you suggest (convert command => export) when I exported both the faulty and correct curves (I used tolerance of 0.001 and tried several different export schemes). When I unchecked “simplify lines & arc” and put the maximum angle to 1 instead of 2 (R12 Natural default) it all seems to work for some reason, even though the angle at the missing points is much larger than 2.
I found this discussion and was interested to know if there are any recommended updates. I experienced a tragic fail on a project recently. I upgraded to AutoCAD 2017, then 2018 and now 2019 (I hate subscription software but AutoCAD forces it). I am also now running Rhino v6. I had a significant number of cuts on a larger project deviate from the original geometry, as much as .36".
Similar as explained above, I export an unrolled surface as a DWG and then import it into AutoCAD to produce lofting and nesting files to be CNC cut. This particular customer was so upset, he insisted I refund $15k worth of work. I complied but really want to prevent this from ever happening again. I have been using Rhino and AutoCAD in this setup for many years on hundreds of projects. I recently sent out another project and the initial response was similar. Slight deviations from my original geometry.
Most customers can deal with small amounts of deviation from fit-up, but some rely 100% on a perfect cut. I am not sure this is even possible. Is using Rhino to AutoCAD to CAD/CAM no longer reliable enough to result in a very tight tolerance? The recent refund could have funded the purchase of a lot of software but I am not sure this is a direction that will bring value.
Converting from a Rhino 3D to AutoCAD 2D to CNC is my bread and butter. I don’t want to risk ruining my reputation if my software package is not going to result in an acceptable product. I have no control of what software the cutters use to open my files and produce their cut files but I can control what I send out.
I am very interested to know if there is anyone else out there that has had similar experiences with the newest versions of this software combo. If so, were you able to come up with a solution or did you abandon this combo and move up to a more robust software package?
Hello - can you send us an example - Rhino file, dwg export settings, and resulting dwg file, that shows the problem? The smaller/simpler the better for troubleshooting purposes but whatever you have will do as well.
I create a lot of files for laser cutting. I always run Convert to lines and arcs. Then export as a dwg with these settings. The Default Dwg settings are terrible.
Splines. All of my projects are marine vessels, which result in many splines for shell plates etc. To result in geometry that make actual arcs is rare. If I convert splines to to arcs, I end up with a whole bunch of them stacked up to make a single cut. Cutters complain about this as well. If I join arcs to make it one continuous cut mark, AutoCAD converts it to a polyline.
I have used so many different combinations of export options I am not sure which one I used on the last job that went belly-up. I was going back-and-forth with the cutters to try and get geometry that they could open and manipulate. They said the first versions crashed their computer. I tried several variables and they finally said they got it to open. I am now in the habit of verifying geometry with a cutter before sending them nested files. Still waiting for feedback on the next one that is ready for cutting. It slows things down on delivery of material to the job site but is better than plates cut wrong.
I am working feverishly to wrap up another 30k pounds of steel to cut for a job. Once I wrap this up, I will come back to this topic. It may take me a few more days before I can dedicate more time to this.
Are you indicating the cutting service has complained about arcs?
It is my understanding that very few CNC machines even now actually use spline entities in g-code. I have seen problems arise due to spline to arc conversion. For that reason I have always converted splines to arcs myself, and checked the conversion against the original spline to confirm the deviation was within tolerance.
Another complication is that “spline” is a term used very loosely for many types of curves that may be generated by different math. Converting from one “spline” type to another is not precise, similar to converting a spline to a series of arcs.
We also export for Marine vessels. Although the theoretical ideal would be exporting splines, it’s much more error prone than exporting polylines.
If you make sure you set the DWG export setting “Chord height” to an acceptable tolerance (say 0.1mm) and make sure the Angle tolerance is not too tight 5deg might already be enough. You export polylines that are barely visibily faceted when cut.
A polyline is easy interpret, It’s a series of connected points. Whereas splines need to be converted/interpreted once upon export and again at import. With probably multiple flavours of spline descriptions and reconstruction algorithms.
Note that many (if not all) non-Autodesk software use reverse engineered import and export libraries. This adds another layer of “uncertainty”.
I always need to keep the shipyard in the back of my mind when developing. Think of the way these parts are handled how they are formed, put in place and get welded. Relate that to the fidelity you need your export to have.
I just uploaded a 3DM and DWG file. The 3DM contains a surface that represents the side shell stiffener of a marine vessel at the XYZ coordinates as it exists in relation to the vessel. Also in the file is the surface “unrolled”. This unrolled surface was then exported using 9 different setting options. I have included a snapshot of this test DWG into this posting. I have also sent this test DWG and a DXF version to a large scale steel supplier in Seattle for feedback. The results of this test have been enlightening and appear to both agree with and contradict some of the feedback here. The fact that others get different results, using similar settings, is in itself unsettling. Just for information purposes, I am running Rhino v6 and AutoCAD 2019.
Hello Jhuff,
I work with MecSoft Corporation, the developer of RhinoCAM. Running a CAM plug-in for Rhino will eliminate translation issues by having to export the file as DWG. We could also offer an online demo if you are open to it. You can also send us your part file. Further, to ensure RhinoCAM will solve this issue, we can provide a sample g-code to verify on your CNC. Feel free to contact us via this webform and attach any significant files: https://mecsoft.com/scheduleonlinedem/
Thank you, Quelly del Mundo
Also in the marine vessel industry and this comment is odd to me, we never export surfaces. We dupborder the unrolled surfaces and export the resulting curves (whatever they are in rhino, splines, polylines, arcs) as polylines with low chord height tolerance (to stay close to the original), limit the length for each line segment (50mm or so to catch any abnormal mistakes and keep the curves rather smooth), and keep angle tolerance low. Never any issues.
@Ncik
Consider converting your curves to chains of arcs instead. Use the convert command. Set the angle tolerance to 0, simplify=no, delete=yes, and the tolerance as you described above. The curves will be far simpler, are directly usable for G-Code, will be much “lighter”, and will probably run faster.
Can you elaborate in the issues with arcs. I have seen a few problems in both software and in machining with large radii, just wondering if your issue is similar, or if there is something else I need to watch out for?
