B) I would say, though C) would also be ok. Basically - in order to prep this for CNC you would need a polyline for each group of geometry that share a height (Z).
How can you configure the CNC to do the passthrough hole with choice B ?
Polyline is an open or close polygon, but as far as I know it can’t represent several disjointed polygons, only a layer can groups them.
You know what? I might as well be wrong. It’s been ages, since I did this myself… I need to check with my team tomorrow. Let me get back to you on that.
I just send you and some of my colleagues an email to get this process started. Nothing for the forum, but we should report the results back here…
Nice, what does the yellow line mean ?
Else, to answer to your colleague, in “orange” is what OpenCutList will detect as “arcs”.
Unfortunatly this doesn’t work directly with his example. Because of a small edge that cut the curve. Those edges should be removed and top a bottom edges of the face recreated.
My algorithm convert segments to arc if at least 6 consecutive points are located on the same ellipse.
As you can see, the result DXF is no longer polyline (because polylines can’t contains ellipses). It just successive lines and portions of ellipses.
table-top.dxf (10,1 Ko)
@boris.beaulant I’ve been following your open source project for a while now. Looks like something worth doing. Here’s a few thoughts that come from a long history of dxf usage.
I’ve been working with DXFs for 35 years, initially using DOS AutoCAD with Lisp routines to find node points on a closed shape to generate code for wire EDM machines. It was simple back then, and remains simple today when you get down to the basics of what we need in manufacturing.
When I was generating code for wire EDM machines that was 2d drawings. After that work I switched to 3D DXFs because cabinet design software generated 3D DXFs. However, I later realized that 3D DXFs add non-value add complexity to the software that generates parts and to software used to create G-code.
At the cad level as you already understand @boris.beaulant closed polylines are still the best way to efficiently represent a single part boundary destined for a DXF with the exception of circles. Each machining detail must be individually identifiable within the closed boundary of a part. CAD entities such as blocks, components, and groups are used to hold each part and each machining detail on a part as a single entity.
SketchUp is the fastest cad program available when it comes to creating custom part geometry and also for editing existing part geometry that comes from other sources in the form of a dxf or dwg file. Having used Windows versions of AutoCad and TurboCad I can say that from experience.
SketchUp lets you do either components or groups for identifying parts and their geometry that will be passed to other programs for writing g-code. Components are more complex and offer no value add to the proposition.
If you want to include details such as a short part name or part number, you can include that in a dxf via a layer name. In an Optimizer Post Processor package I used for 23 years, there was all sorts of non-machining part data that we passed by putting this text information on a specific layer name. The post would parse this information when it appeared on a piece of text within the part boundary and would be displayed in a table format on the printed pattern page. For custom parts that are not generated by a program like a cabinet design package, how much more complicated does it need to be?
Those expensive packages of optimization and g-code writing software keep adding complexity for the purpose of automating the software process, and the outcome makes it harder to do the “custom” work we all want to do.
Two years ago I started switching from one of those expensive software packages that does optimization and g-code writing to the inexpensive program offered by Vectric called Vcarve Pro. For flat work like cabinet parts Vectric offers an even less expensive version called Cut2D Pro that works great.
Vectric has done a good job of presenting all of those many complex details required to write accurate g-code and they do this for a huge variety of cnc equipment. Using template job files to write template tool files you accomplish the same thing using Vectric programs as expensive packages. The difference beyond much lower cost is this information is more granular making it much more flexible for what we do.
When you keep dxfs as simple as possible using layer names that clearly convey the most basic information, (the tool name\number), you can easily keep track of all the important machining information in one central location and attached to the most important item in the process: the tool used for machining.
Trying to convey z cutting depth using 3d dxfs sounds like the best approach, but this requires working in 3D when you want to do something odd. If you don’t need a 3d representation of the part for presentation purposes, it’s easier to create an odd item from scratch in 2d rather than with 3d geometry.
If automating the process of writing g-code is your top priority, then 3d dxfs might be the way to go, but consider the associated costs required to maintain these programs over time and the complexity these program add to an already complex process.
Vectric’s Vcarve Pro cost a one-time fee of $700.00 or Cut2dPro cost $450.00.
The SimpleDXF plugin for SketchUp that cost $29.00 us dollars and it allows you to quickly extract part data from solid models generated in SketchUp, and write this data out per part.
For those doing a lot of custom parts then additional work to gather other part data that isn’t necessary for G-code generation is something to work on. This information needs to be presented in a format similar to what we get with part data in a table format on the same printed page with the optimized pattern graphic.
If you are wanting to write out multiple parts at once then use a part border representative of the sheet size you will be cutting from. This sheet border becomes a part and each part’s individual geometry becomes machining elements within the larger sheet\part. That sheet boundary\part is on a layer that the post processor will ignore.
You could spend a lot of time trying come up with automation to speed this process up and what you come up with might be the greatest piece of software ever written. If you do, I’ll be the first to buy a copy. That said, SimpleDXF is ready to begin using right now and has been the best tool I’ve found for custom parts since I started working with DXFs years ago.
Here’s a link to a short video that shows the process of taking one of @napperkt’s samples and converting it to a dxf. I realize this is not exactly a true representation of what would be needed due to those varying z values but that type of detail has to be handled no matter how this happens when you create the original geometry. You can also see how dealing with that is easier in 2d rather than 3d.
Thank you very much @mpoole32 for your detailed feedbacks !
The main goal of this feature is to export a useful DXF file for CNC owners with the minimal of click. But not to create G-Code directly in SketchUp. Because target user of OpenCutList is larger.
I don’t want to go to Simple DXF approach that consists of editing the model in SketchUp to integrate DXF meta data.
Currently, my code analyzes the geometry and export a 2D projection. Then it know what polygon is at what depth.
The question is what is the best way to keep this kind of data in DXF ?
I can create a BLOC for each part, that contains a BLOC for each depth (maybe better to use layers for depth … ?) :
@napperkt could this hierarchical structure suit your needs?
In your screenshot I see that you embed the depth information into the Layer-Name - I think that’s absolutely sufficient. As long as it is readible we can work with it. It would of course be awesome to add the part name as DXF text onto a layer “ignore” or something, especially if you export an entire nested sheet.
For us getting individual dxf files (for each part one file) named after the component name would be very nice.
@boris.beaulant how you store this data in the dxf is based on what post processing programs like AlphaCam, MasterCam, Cadcode, Vcarve and many others need for the purpose of writing g-code. Is that how you see it?
It is also based on what users need as a final product for use with their cnc equipment and on their shop floor.
I could never use Vcarve as a complete solution because they don’t provide for the most basic of data about a part. There’s more to a single part than its size and machining features. So the question is what do users want out of this project you are working on?
More to think about @boris.beaulant
One important detail about working in SketchUp is having the discipline to create groups for organizing individual features. Failure to do so quickly leads to a bowl of spaghetti with no manufacturing value.
Layer or Tag names will also be an important next discipline if manufacturing is your goal and layer names go hand-in-hand with the process of creating groups.
Groups and layer names work with 2d entities and 3d entities. With proper groups and layer names why spend time trying to figure out z values, just flatten everything to 2d and let the user deal with z in their post?
Mainly because it’s more a tweak than a feature and layer can say “depth = 10” event if geometry is something else.
The more I explore the DXF file format, the more I understand how poor this proprietary standard is for properly defining a simple 2D projection. And how bad its effectiveness is. With the latest version, you need 300kb of data to define a simple cube.
Ok, nice, even if writing qualified data in versatile field like layer ou bloc name is not my dream
What I try to do with OpenCutList is to stay in a general solution that fully adapts to various needs.
By avoiding tinkering as much as possible.
I’d rather not include a feature than make it wonky.
In my opinion, they don’t know. They mainly want a magic button and don’t care if the solution doesn’t work in all cases it’s designed for. Since 2-3 years users ask us to add this kind of feature without to be able to clearly answer to this question . This is why we postponed.
Instead of nothing I decided to walk step by step and add feature that stay in general case to get more feedbacks.
The main problem I want to solve is to reduce the number of teams redrawing everything by hand from SketchUp to their CAM software…
I think you nailed it. Why do we want OpenCutList to do this? Because Sketchup has such a lacking export in house. Boris manages to get something done with a microteam that should have been included natively years ago.
Creating things in Sketchup is fun. Getting this out of Sketchup not so much. Enter OpenCutList.
DXF is an old an clunky format but it is understood by many machines / software programs. So - basically don’t worry about writing the most elegant DXF possible. You are already light-years ahead of Sketchup itself in the way you set up the lines in different height layers etc. I remember spending quite a few hours trying to figure out how to export these very simple contours (the parts I that I sent you to test) into something that would work on the machine and in the end I actually did redraw them one by one in AutoCAD after all. These days might be numbered!
@boris.beaulant I would disagree. What we do is a mostly visual thing first and once the part is made it is 100 percent visual. Is the latest and greatest dxf spec crazy, yes.
Using only those dxf details we need for manufacturing you get exactly what we need and that comes in the form of relatively small dxf files. This generates the visual representation we need for the work we do and is the least complicated method for conveying information headed for cnc machine controls, g-code.
People have taken what was once a great concept and tried to do things they probably should not have. You can pick and choose what you want to write into your dxf file and the most important thing is decide you don’t want to do anything beyond what the dxf spec said in the year 2000.
I’ve watched as people attempted to move this basic geometry we need for manufacturing to XML data and .json file format for the additional non-machining data we need for what we do in woodworking. Those are examples of making things more complex for no value add.
Basic dxf and csv data keeps things simple but you can overly complicate things with a few misguided steps.
I just opened a medium sized kitchen project that has 614 parts with 4 types of sheet material.
These 614 parts optimized in 0.047 seconds and created 614 DXF files - configured as 1 part per dxf instead of nesting which is faster. The 614 DXF files took 0.922 seconds to generated and resulted in a total of 1.28 MB. That averages out to around 2 K per file.
No one says you must use the most current DXF file format. However do realize that Auto Cad is the most picky CAD system and won’t import files that aren’t completely to spec.
DXF has been around for decades and is still the format most used by CAM software and is very stable.
Just for fun I configured the DXF’s for nesting. 46 sheets in 0.687 seconds resulting in 843 K.
Perfeito, sou Dono de Marcenaria e desenvolvedor de uma Plataforma que integra com Sketchup e tenho alguns Clientes que já solicitaram esse recurso para não ter que utilizar programas externos fora da modelagem, parabéns pela iniciativa e com certeza vai ser sucesso. Espero poder integrar o OpenCut List com minha Plataforma.
I try an other strategy. Exporting drawing under DXF blocks tree and layers.
- keep a good support to edit the drawing (move, duplicate parts)
- group what need to be grouped
- keep some useful data (like depth, part identifier)
sheet_001.dxf (18,5 Ko)
Unfortunately, no DXF reader uses the blocks and layers combination in the exact same way. Even AutoCAD doesn’t get the same result as Autodesk DXF Viewer when hiding layer in a block…
If anyone with CAM software can tell me if this proposal makes sense, I’ll listen
No, but R14 is certainly a minimal to get some basic improvements.
Thank you, but note that it is mainly a question here of exporting to machine softwares and not of completely replace them. It would be an other job.
Hmm, then bad idea to use DXF Blocks …
And everything will stay totally flat.
Blocks in Autocad were for 2 purposes. Group things together and to save resources so you could have one set of data for a group of cad entities used multiple times in a single drawing.
Xrefs were another Autocad thing to store groups of items in a file for reference in other drawings. Xrefs and Blocks were from the early days of computing when memory and resources were scarce.
You could think of Xrefs as a dumb version of Components in SketchUp.
For woodworking and for me cabinetmaking specifically, memory is no longer scare so groups is all we need. You can group 3d items that will have z values just as easy as you can group 2d items.
Early in those CNC software days Autocad was one of the few cad tools being used so software companies wrote their programs specifically for using Autocad DXFs with Blocks. At some point at least a couple of the machinery makers thought they would try their hand at software and they copied software developers that were using DXFs with blocks.
As more cad programs and specialized cabinet design programs became available the use of block went away.