C coded dxf to g-code converter, the building process...
17 Feb 2019 19:53 - 17 Feb 2019 20:13 #126687
by Grotius
Replied by Grotius on topic C coded dxf to g-code converter, the building process...
Hi Tom,
The code does not look nice...
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.
The code does not look nice...
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.
Attachments:
Last edit: 17 Feb 2019 20:13 by Grotius.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
Less
More
- Posts: 19106
- Thank you received: 6398
17 Feb 2019 20:58 #126691
by tommylight
Replied by tommylight on topic C coded dxf to g-code converter, the building process...
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.
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.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
Less
More
- Posts: 19106
- Thank you received: 6398
17 Feb 2019 21:01 #126692
by tommylight
Replied by tommylight on topic C coded dxf to g-code converter, the building process...
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.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
18 Feb 2019 01:21 #126700
by rodw
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....
Replied by rodw on topic C coded dxf to g-code converter, the building process...
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:
dxfdecode infile outfile --units:mm --feed:1350 --small:50 --large:100 --skiparc:5
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:
movingup = (last_dvdt < dvdt ? 1 : 0)
So what does this mean? HINT: it is C's ternary operator at work....
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
18 Feb 2019 19:04 - 18 Feb 2019 19:23 #126722
by Grotius
Replied by Grotius on topic C coded dxf to g-code converter, the building process...
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. 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.
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. 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.
Last edit: 18 Feb 2019 19:23 by Grotius.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
18 Feb 2019 20:33 - 18 Feb 2019 20:37 #126724
by Grotius
Replied by Grotius on topic C coded dxf to g-code converter, the building process...
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.
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.
Last edit: 18 Feb 2019 20:37 by Grotius.
The following user(s) said Thank You: chimeno, tommylight
Please Log in or Create an account to join the conversation.
18 Feb 2019 20:53 - 18 Feb 2019 20:58 #126726
by rodw
Replied by rodw on topic C coded dxf to g-code converter, the building process...
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:
}
}
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:
}
}
Last edit: 18 Feb 2019 20:58 by rodw.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
18 Feb 2019 21:01 #126727
by rodw
Replied by rodw on topic C coded dxf to g-code converter, the building process...
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
You should also study malloc() and free() although in c++ these are kinda old hat
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
Less
More
- Posts: 19106
- Thank you received: 6398
19 Feb 2019 00:40 #126739
by tommylight
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.
Replied by tommylight on topic C coded dxf to g-code converter, the building process...
That is for sure from your UP/DOWN THC comp and it should be:I thought of you when I wrote this over the weekend:
movingup = (last_dvdt < dvdt ? 1 : 0)
So what does this mean? HINT: it is C's ternary operator at work....
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.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
19 Feb 2019 01:45 #126744
by rodw
Replied by rodw on topic C coded dxf to g-code converter, the building process...
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
Its a very compact way of saying
if(last_dvt < dvt){
movingup = 1;
}
else{
movingup = 0;
}
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
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
Moderators: Skullworks
Time to create page: 0.135 seconds