C coded dxf to g-code converter, the building process...

For info.

I made a study for the past 2 day's to try to converse a dxf file into a g-code file with C programming language.
At this moment a few thing's are working. See my comments inside the read.c file for more info.

I have good hope, when the project is some time ahead, we can make great profit of this code.
Trough the compiling the code works really fast. Python scripting is not my thing, so that's why i started in C.

Feel free to make suggestion's about my coding style. I am just learning C.

Here a drawing of type dxf, also attached :


Informative terminal output during file conversion :


G-code ouput example :


** the attached read.txt has to be renamed to read. It is the executable file. Terminal command : ./read

To test this code, see intro section of read.c
Be sure all files are in the same directory.
Be sure all file names are : read.c read.dxf

Have fun !

There is a DXF2Gcode Plugin for Linuxcnc

I know

Okey,

Tonight i have tested some cosinus and sinus functions in c for converting dxf arc's to g-code arc's.
I did not know the c language is working standard with radian's.
I expected normal degrees. Even my linux on board calculator was set in radian's.
Okey i must make a conversion strike for cosinus and sinus in C.

When the arc section is finished, it hopely can be called a very powerfull arc/polyline tool. I do not segmentate polylines into short lines. So the import is 1:1 without segmentation. Full arc's !!

Hi,

I have good new's about arc's to g-code.

In this dxf drawing there are 8 arc's with different position's and shapes.


G-code output for arc's :


I had to add -lm to the geany compiler to connect the math.h library.

I used only cosinus and sinus function's to calculate the x,y start and x,y end point's of the arc.
Autocad works with circle centerpoint, radius, start angle and end angle. So i had to calculate it to
x,y start and x,y end of the arc. And that is done now. It's currently only for G02 movements.

The code for calculating dxf arc's to g-code output :


Next thing to do is to look about arc's that form a closed contour and what do do with that.

I can use some advise.

Is it wisely to use a 2 stage methode for converting a dxf file to g-code?

1. First stage : read in the dxf and output g-code, oke this works for line, circle, arc etc now.
-- The output is it's a raw g-code file without optimalisation.
2. Second stage :
-- Make g-code optimalisation by checking closed contours, user input for inner or outside or no offset's etc.
(this one is the most difficult, i maybe must make a 2d-6d array to check all invidual correspondenting start and end points.)
-- Add line numbers, optional.
-- Add tools, Add G40, G41 & G42.
-- Later on make a cut sequence input direction or maybe a idea for automated optimalisation start points.

Input is welcome !

At what point are you better off just using an actual CAM package?

Only the idea of making a powerfull open source C coded G-code converter gives me a boost.
I never thought i could make this. If i look at a 2-5mb dxf file, i think where to start making a converter....
Dxf2gcode can not do this because it's written in a very slow coding style i think. Or it is a problem of python.
C coding is so super fast. Wow.. Python is written in C. And don't have to be compiled, therefor it's too slow i think.
If the linuxcnc gui was written in c, it was problably to difficult to start with to make your own user gui. In python 1 line can do 1000 lines of C-code. Look at Opencv. A powerfull based python code.

Dxf2gcode is not good enough to use for me. So i want to make much faster program, Rod told me how to add terminal command's into the c program. So the linux gui can open a dxf instead of a ngc. User can do some hal commando's (connected buttons) to optimize cam.

You will see when it's finished, it get's around the world. I hope to make a fully integrated c coded linuxcnc cam package.
The goal is to connect the gremlin screen to it (opengl) then user can click on the line to edit start point's.

If you look at the richest companies of the world. Autodesk is one of them. The only reason to provide Draftsight for free is to stop development. They are smart. But it's what Mr. Musk of Tesla told us. Open source patent's. Let distubing high priced health care medecine's be available for everyone around.

Hi,

It looks like there is no interest for a C coded Dxf to G-code converter. The only input i got is why do you do it? And there is a python coded dxf2gcode already. I think people undervalue the power of this program. When it's finished it goes around the world.

I made some progress. Had to solve a difficult item. Recognize open en closed contours. But i solved it. It took me 2 day's.
This step is the step to make the G40, G41 & G42 module possible and it's the first step for autonesting. Autonesting i will try also in C when my program is almost finished.

I have a example below of how the C code works to recognize open en closed contours cleared with a few pictures, and how the program flow works. First I started at the wrong way.

The dxf drawing. File type is R2013 ASCII type. It has open en closed contours, and it contain's an arc for the fun.
If you look at the drawing you can see 7 objects. In a dxf text file you can not see this. There is no logic about closed or open contours in a raw dxf file. So we have to find it ourselfs.


Okey in previous post i made a converter for a raw dxf file to a raw g-code output. The file "read.ngc" is the raw g-code output file.
This function works nice. This is the first piece of the program flow diagram.


Now comes the difficult part. Recognize open and closed contours. Output file "group_closed_contours" makes profit of a
function that read's in 5 text lines into 5 linebuffers. After that the pointer shift's the line buffer 1 one line and compare's the previous buffers to the new one's. There is also a logic adapted to compare the 5 different line's to find the open or closed contour. This code tooks me 2 day's include testing. But after all i am happy with this output.


Okey in this file we have double lines... We delete them easy with a small function. Output file "clean_double_lines" is the
file without double g-code lines.


The function to recognize closed or open contours :


The function to delete double g-code lines :


Okey at this moment i will try to see for automatic outside and inside offset recognize. So then i can add the G40, G41 & G42
to the g-code output file.


This is my start for coding the outside contour recognize. It's for now just a flow diagram in red text how i will code the stuff.
I think and write down about how i think it would be working.

If you not have a plan, like a flow diagram, it could be working for a simple function.

With a flow diagram you can concentrate yourself on your todo programming step's.

I learned this myself in about 2 weeks. Without this it's for some people very difficult to code your next few line's, in fact you are thinking about your target, but you problably you will miss a crusial step, or your program has a bug in the end.