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

Hi Tom,

The code does not look nice... :woohoo:
But i think when everything is working and code is at the stage to be finalized, it still looks the same for the most people.
A gui say's more then only straight boring c code.

But thanks for your reply. At least two members are interested in what i want to try.

The beginning code i wrote has no gui at the moment. So people can be confused how it will work in the future.
But i have thought about that.

Soon i will make connection's for automated linuxcnc input. It has 2 user option's.

1 -->
Now i say something technically :
It can be used and integrated with terminal commando's with linuxcnc for loading a dxf right into the gremlin !!
( see how gphoto2 works...) Its almost the same.

2. -->
Users can load a dxf straight into the axis gui or gscreen, maybe it even will be adapted to the gmocappy gui if i ask Norbert.
Trough the terminal command's it's for Mr. Morley, Mr. Gmocappy a kind of diamont to integrate.

Later on i will make a Opengl connenction, but first let's code for a few weeks. I like autonesting. So i am thinking about that option.

Tonight i made some progress. I can now read in a Y value of a certain g-code line. That's the start checking the biggest object's of the dxf drawing for automated inner and outside contours.

Coding takes much time.... But if there is progess and the programm is stable.... It's fun. I now have used *pointers for the first time.
It's like magic. If you want to see the picture, focus on character_delete and *pointer. This was my work for tonight. Output was perfect.



I forgot to say. When you use it staight into the gremlin gui, like gscreen, you can add a user button for kerf width, speed, spindlespeed etc. Lead in or lead out, Outside offset or inside offset or no offset, Every possible parameter of the program is related to a button cq terminal commando behind the screen. Ethercat is working principle in the same way.

While you're at it, can we make some requests? Since we are not helping you, at least we can bother you with such nuisances, right ?
As RodW pointed out in another thread, as we use plasma cutters ( i do not use them much to do actual cutting ), we know that there is an inherent drawback to cutting small circles and radius's, so if you can think of a way to put lower feed rates for such instances, that would be very usable. That is supposedly what Hypertherm refers to as TruHole technology and they do use much better torches, for sure.
My idea is anything smaller than 50mm should be done at half the speed, from 50 to 100mm at 75% of the speed, and above that it is all good.
Thank you,
Tom.

Another idea, regarding gremlin: do not use it for dxf, instead i would prefer if it sits as another tab in the Axis or Gmoccapy gui.

tommylight wrote: As RodW pointed out in another thread, as we use plasma cutters ( i do not use them much to do actual cutting ), we know that there is an inherent drawback to cutting small circles and radius's, so if you can think of a way to put lower feed rates for such instances, that would be very usable. That is supposedly what Hypertherm refers to as TruHole technology and they do use much better torches, for sure.
My idea is anything smaller than 50mm should be done at half the speed, from 50 to 100mm at 75% of the speed, and above that it is all good.
Thank you,
Tom.

That would be very cool as would drag and drop onto the gremlin preview to commence processing. I'm sure Grotius has the data to do that. I'm not sure of what the thresholds might need to be and it could change with material thickness but I'm sure you guys will work it out.

I almost think it would be good for now to just keep this as a separate command line program that accepts a few command line parameters and switches that can be called from the GUI to do its thing. Maybe something like this: I think there needs to be an exclusion on arcs to skip chamfers applied to corners as I think this is handled OK just with a velocity hold/cornerlock feature. This would support Tommy's suggestion but I think it might also need to know the thickness of the material to set the hole/arc diameter rules.

Grotius, well done on mastering C pointers you are rapidly becoming stronger and stronger with your skills! So now study up on structures and how you can use them with pointers with -> very cool!

Then once you master structures, take the time to understand unions (where you can overlay data on top of each other eg a char over a byte or a byte over a bitmap.)

I thought of you when I wrote this over the weekend:
So what does this mean? HINT: it is C's ternary operator at work....

While you're at it, can we make some requests?
Feel free to make any request.
The request's are placed into the c file intro todo list.

My idea is anything smaller than 50mm should be done at half the speed, from 50 to 100mm at 75% of the speed, and above that it is all good.

Hi Tom, the path rules for a circle are very easy to adapt. The circle is the most easy shape to isolate from a dxf file. Also adding feed parameters to the circle value's are easy.

In the c-code i will provide a few parameters to add this path rules related to diameter.

Also i will add something extra to circle shapes. Circle Lead In Correction for small circle's.
If you have a file with different part's of 10mm steel and the lead in programmed let's say 10mm. And the smalles circle is 15mm, the function automaticly does the lead in for the 15mm hole setting at 7.5mm. :woohoo: So it repair's the lead in without you are noticing.

Rodw,

dxfdecode infile.dxf outfile.ngc --units:mm --feed:1350 --small:50 --large:100 --skiparc:5
Very good !!

I think it can be like that with using terminal window commands.

If you use a glade add on screen the linuxcnc python program line for using terminal commands should be looking similar to :
os.system ("dxfdecode -p {0}".format(self.widgets.INFILE.get_text()) + ... next item to load.
Above line sets the INFILE name in the terminal command line...

I don't know what your hint mean's, maybe next year i can say it directly.

First i will work on the inside and outside offsets. Find the biggest contours, compare them with smaller contours inside.

Rod, please think also about a nesting technique.
How we can rotate objects in a g-code file and do some plate optimalisation calculations.

The basic autonesting begin's with taking the oject's min and max dimension's in square form and compare them until it fits in a steel plate of a certain dimension in relation to most minimum mm2 area.

Okey i am little futher in proces.

Tonight i had to store an x,y or z value of a certain g-code line into memory to compare the biggest objects.
I had to converse a character to a float. This week i must make a compare function for comparing all the value's within one g-code file.

I have used a new funtion called memorycopy. memcpy.
This is handy for copy the first 10 characters after X.. instead of copy a whole line into the memory. I need only a X value of type float.
So the atof function converses the string into a float value.

Later on i must make a kind of array i think to compare all the value's inside the g-code file.

For now it works so far.

You probably do not need to copy stuff into the static buffer at all. If you use a pointer , you can point to any position in the string you are copying from so you can access it directly.

I'd probably consume each character in the line

while(pointer++){
switch(*pointer){
case 'x':
case 'X':
pointer++; // skip the letter
// convert the number into a structure
axis->x = atof(pointer);
break;
default:
}
}

Sorry I accidentally completed the post before finishing. You don't need an array. You need to define a structure for each axis value so that you can define another pointer to the structure and uses axis->x notation to access the value for x.

You should also study malloc() and free() although in c++ these are kinda old hat

rodw wrote: I thought of you when I wrote this over the weekend:

Code:

movingup = (last_dvdt < dvdt ? 1 : 0)

So what does this mean? HINT: it is C's ternary operator at work....

That is for sure from your UP/DOWN THC comp and it should be:
MoveUp only if last difference in voltage over time is smaller than the actual difference in voltage over time.
Otherwise the movingup pin stays 0.

Yes, tommy

Its a very compact way of saying

Very cool. and a great way to save memory if you have constraints but those days are mostly long gone.
But hopefully it is for kerf/void sensing