To get this, a Rhino user currently needs to convert degree 3 and higher wiggly curves into chains of arcs. Then export to DWG/DXF using the CAM Imperial (for inches) or CAM metric (for mm).
No one figures this out on their own. Typically we hear about it when they donāt convert their curves to arcs and use the default export scheme which results in chunky faceted polyline replacements for smooth curves in the DWG/DXF file.
What can we do to improve this workflow and make it easy to discover?
Maybe the CAM exporter should just do it automatically, assuming that the target CAM program will just convert it back to faceted polylines if the target machine controller doesnāt handle arcs.
It canāt be purely automatic since mills, routers, laser cutters, water jets, etc. all need different arc conversion settings. The prudent user will save their NURBS curves for future editing but still need to inspect the conversion to see if everything will work down process.
as a long time mastercam user i did this all the time, mostly because you had to in the old days of slow controls and small files.
even using a modern cam program that can handle tiny lines, i would still opt to break into arcs. i have not done much of it in rhino so i canāt even think off the top of my head what the command is.
in mastercam it was a simple break into arcs, then called for chordal deviation. that was easy to use and became second nature. would welcome that if it is really not there already.
The command in Rhino is Convert.
I set the angle tolerance to 0 to disable it since the arcs are all coming from a smooth curve,
Then set the tolerance to the cutting resolution of the machine that will run the curves in model units.
Iāll continue tangent to the original topic (using DXF for CAM) and ask where the conversion to CW and CCW arcs and simple lines takes place when you use IGES.
In my simple mind, modern drivers (or converters to G-code) that are specific to the āprinterā / process should be able to perform that on whatever file they get in. Of course, the Rhino user should then know not to use an export format that will cut up a smooth curve into tiny line segments.
What about making a toolbar called, say, CAMConvert to run the Convert command with most options already set to convert curves for CAM programs ?
There may be a few buttons with different settings for tolerances ā¦
And maybe some button to export the curves too ā¦
Also ( Iām not expert about the Covert command ), I tried Convert and am somewhat confused about it ā¦
If I set AngleTolerance to zero itās all fine, but if I set it to a different value, the number of arcs becomes pretty high.
I think if you use CurvatureGraph with too tight of an AngleTolerance,
youāll not only get lots of arcs but the resulting chain of arcs will
wobble or wiggle like a snake.
Setting the AngleTolerance to zero disables it.
I was not aware that IGES could even be used for this. Do most NC programs
accept IGES file in addition to G-code and DXF?
I used to work with (3D) CAM programs until a few years ago.
The 3D CAM programs I knew about, which could also be used for 2D, and were regularly used that way too, could read Iges and Step.
That is, they read Iges,Step etc. and wrote G-code.
Donāt know about 2D-only programs, sorry.
Iām always amazed at how this discussion comes up repeatedly. In my (admittedly biased and elitist) opinion, there are only two scenarios where one needs to convert splines into tangent arcs (or worse polyline segments) before exporting to CAM:
One: The person operating the CAM system is unaware that their software can actually deal with splines directly. This occurs more often than you might think, as manufacturing people are sometimes so set in their ways that they havenāt learned any new functions of their CAM program in the last 10 years. They continue to do things the way they have done them since the beginning of CAM, as itās always āworked for themā. There are many mechanical shops that are only used to making things that are defined by pure lines and arcs, because the whole chain of production from design to fabrication is using software and people who only understand those.
CAM systems have been able to import splines via IGES or DXF since before I started using them in the mid-90ās. Once the spline is imported, the CAM system converts the toolpath into line segments according to the tolerance determined by the toolpath programmer at the moment the toolpath is created. This is a huge advantage over pre-export conversion as you can choose the tolerance desired at the time of production and never need to ask for a new file with tighter or looser tolerances. However, this is not always possible due to either choice of CAM software (not all can deal with splines) or scenario #2 below:
Two: The machine control is simply not able to handle the copious data in the G-Code file fast enough, either because it has an old communications link with limited rate, an old processor that can cannot calculate the blocks and accelerations fast enough, limited memory, or all of the aboveā¦ In that case, there is no other choice besides pre-conversion.
IMO, if one is in the business of designing parts that are defined by free-form curves and surfaces, one should seek out suppliers who are equipped with software and hardware that can produce those parts, and not jump through hoops to try and accommodate those who canāt. Therefore both scenarios above should be considered as exceptions rather than āthe ruleāā¦
Here in technical support, this is the common scenario we hear regularly:
āI exported my file to DXF for CAM and the curves came out all chunky. It cost me a lot of money and time. How come Rhino canāt export good curves for CAM?ā
Clearly, thereās a lot of ignorance and misconceptions packed into that.
Hereās what we need:
What can we do in Rhino so these people that are ignorant of the process details, have a better chance of success out of the chute? What can we do that is discoverable by most users that will make them successful?
Dunno - aside from forcing people to educate themselves on how CAM worksā¦
It doesnāt help that the default export scheme automatically tessellates splines at a fixed value (which is also pretty coarse) and explodes all polycurves. In this day and age, Iām wondering if thatās still really necessary. At least if itās not checked, Rhino will export an āaccurateā (untessellated) version of the original file. The question remains what the importing program will actually do with that.
The problem is most people donāt ever go beyond just hitting OK to accept the default scheme, and on top of that have no idea what their supplier expects.
Hi John,
I agree with Mitch, that CAM software now should accept splines as they were made and will convert them to toolpaths according to the tolerances and options entered into the CAM program.
However I can imagine your frustration. the only thing that I can think of would be to actually create a highly discoverable wizard to take people through step by step. The people complaining obviously donāt know about the varieties of dxf/igs export, so that you have to do the same thing by more overt means.
Nick
I struggle with machine shuttering at higher speeds and have converted and not converted lines to arcs. IGES seems to work best for my cam program. A save as CAM would be useful in the process of elimination, when diagnosing feed/speed motor tuning setup issues vs cad vs cam.
I donāt ever use DXF/DWG so bear with meā¦
I would also think that people donāt go beyond using the default scheme as it is but doesnāt the Default scheme export curves and polycurves as splines? I.e. that there isnāt any tessellation going on?
It almost sounds like if you remove all the other presets and allow editing of copies of the default scheme, only people that know what they are doing will turn curves into lines. I almost suspect that since there are schemes that are called CAM Metric and CAM Imperial, users exporting to CAM will select these and thereby turning their splines into garbage. Or?
One way to minimise the pain would be to have the ādefaultā scheme settings better reflect the average shop requirement. Common sense suggests ādefaultā the scheme to use but, from experience of using this setting by mistake once, there are 4 default settings which may be worth a rethink:
The full layer path checked can result in a messy and akward to read output - chances are the cnc layers will be hidden away in the layer hierarchy of the original and the output to cam will consist of just a few relevant layers so the layer path prefix just gets in the way.
The color by RGB can result in the operator being faced with a blank, black screen if the geometry is black in Rhino - this causes a bit of head-scratching when the operator complains of a blank file and you donāt realise youāve used defaultā¦
The chord height being unchecked in default is the one which causes expensive grief - large, curved parts a pretty well guaranteed not to fit accurately. The shop floor will probably make them fit which causes even more expensive grief and heartache!
Exploding polycurves by default, well that is a mystery to me, does anyone know which cam operations require exploded line segments?
If you were to analyse the reports you are getting in tech support, that may tell which settings are causing trouble. An unchecked or un-noticed setting can be a massive problem in the world of manufacture.
Actually no.
We only hear about a few of the ones that are problems. When the default works we never hear about it.
I donāt have good statistics to measure this but I suspect the number of people using DXF export for CAM is a very small percentage of the people using DXF in Rhino.
If we change something like what ādefaultā means so it works better from one group, we run a huge risk of breaking a trouble-free workflow for a much larger group of users.
In earlier versions of Rhino, there were no named export schemes. You were presented with the export options every time you used the tool. People complained so we made a way to save and name the settings. We shipped Rhino with a few schemes expecting users would make their own using the examples. Boy were we wrong. We added the two CAM schemes later on to minimize the trauma. They helped a little but very few people even see that is a drop-down list with choices.
Working with different manufactures over the years Iāve learned there is no standard for various machining. Itās a pool of variables within the different software, machines and human operators.
With new manufactures itās always been a trail and error process to find the export scheme that works for them. Than there is the occasional soft- or hard-ware update (at the clients side) and we need to start over as now splines are no longer in tolerance or whatever.
So in short I do not think there is a one shot solution and the best is to educate as much as possible. If McNeel could compose a CAM-faq webpage much like with booleans and meshes it might be the most effective solution to not be bothered with repeated questions. (Linking to that page from a CAM export dialog)
It will also be a good tool for Rhino users to educate their suppliers and learn about the various types of geometry involved in CAM .
