Rods "Spaceship" Scratch built Plasma Cutter build

More
11 Feb 2019 11:29 #126196 by rodw

racedirector wrote: Wow you guys, I never knew plasma was so hard. Was thinking of building one in the future, no so sure now.

Great work getting yours running Rod, mighty impressed!!!


Thanks for that. With the amazing benefit of hindsight, plasma is not really the right project for your first CNC build.... In fairness though, we are trying to take LinuxCNC to the next level with plasma cutting. However, I'm sure you can handle it!

Anyway, back on topic. Fellow Aussie seanp has some cutting rules I will try before my next cut tomorrow
www.plasmaspider.com/viewtopic.php?t=21037

And some stuff about gcode I don't really understand. When we touch off, we use a G92 Z0. Then before a cut,ai do a G92 X0Y0 but I get a felling that is wrong. I also seem to remember we need to cancel the g92 to stop the staircase in the preview. So can someone explain to me the correct way to set the machine up at the origin of the cut? I do remember it being discussed but I'm sorry I've forgotten....

Please Log in or Create an account to join the conversation.

More
11 Feb 2019 13:13 - 11 Feb 2019 13:18 #126198 by Grotius
Hi Rod,

Sheetcam is always choosing a start where you don't want it to be. To edit your startpoint's click on the S+ button (edit startpoints)
then you can click your new startpoint quite easy. Dxf2Gcode is better coded in choosing a standard startpoint. :)

Your parts look fantastic.

Rod, about height measuring. I only use my component to trigger the height sensor. I do it only in C, without any use of G92.
So the G-code is flat and only has a M3 and M5. The rest is done by the component. This works the best, because it behaves real time, also when restart is needed, no additional G codes have to be loaded first.
Last edit: 11 Feb 2019 13:18 by Grotius.
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
11 Feb 2019 20:40 #126217 by rodw
Grotius, thanks for the feedback. Funny, when I once asked if we needed a touchoff component, no one was really interested.

forum.linuxcnc.org/plasma-laser/32555-do...al-component?start=0

Its still on my todo list but at this time, I'm trying to keep as close as possible to the original external offsets examples and get a working config.

I do think your approach is by far the cleanest method and I will eventually implement it.

I think I have to add one more component to allow the torch to be disabled from Gcode. Either that or use another digital output pin which would require reworking my sheetcam post.

Please Log in or Create an account to join the conversation.

More
11 Feb 2019 21:53 - 11 Feb 2019 21:58 #126221 by Grotius
Hi Rod,

I'm trying to keep as close as possible to the original external offsets examples and get a working config.
The linux version i send you is more powerfull. It really makes life easyer when you don't have to select a restart line.

Either that or use another digital output pin which would require reworking my sheetcam post.
Hmm. It's quite easy to eliminate this. Use G40, G41 and G42. Then you are done. A tool or g-code reload is enough, and select a tool from your gui will reload your parameter's within one second. This would be my final setup. (but i have to change the tool parameters in Gremlin, the tool is invisible with kerf 1mm. Andy can solve this.) But first i am building a conversion tool now.
I am at the point i must make a algoritme for closed contours. Everything load's fine now, Arc, Polyline, Circle, Line etc.
So i did'nt expect it was working after one day programming in C. After the algoritme is finished i can make also a nesting module, because i can make a algoritme for area's and coordinates, i will try to use vector's related effienciency for shapes, but that is one step ahead. Maybe when the ngc output files are okey, i will try to make a nesting module my way. :silly:

Keep up the good work !!
Last edit: 11 Feb 2019 21:58 by Grotius.
The following user(s) said Thank You: tommylight, rodw

Please Log in or Create an account to join the conversation.

More
11 Feb 2019 22:38 #126226 by Leon82
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
11 Feb 2019 22:42 #126227 by tommylight

rodw wrote: Funny, when I once asked if we needed a touchoff component, no one was really interested.

I did read that at that time and i did agree ( to that or some other component you did ) as i did like the idea of having separate component so they can be used as needed.
I personally do not need it as i have everything implemented in hal, so no need for touch off, or remap, or subroutines, or post processing, nothing but an M3.
The thing that has to be decided on is do we go for separate everything or do we bundle all the components for THC into one? There are pros and cons for both versions, but it would be easier for new users to have it bundeled, or edit the ini file to choose what they need. One such example is Phils config that has provisions to chose the THC mode in the ini file. And this brings us back to having separate everything and just loading them in the hal file.
You spin round and round like a merry-go-round ........ was an old song that i am sure Grotius will find on youtube promptly ! :)
Of to bed, trying to switch my brain off !
Greetings and salutations to all !
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
11 Feb 2019 23:28 #126234 by rodw
Strrewth! How is a man supposed to get work done when everybody is talking to him! :)

Grotius, yes, I am keen to try some other methods but if I can nail this,we might be able to get something into master branch.

Tommy, There are positives for either the single component or the multiple component approach. Either way there still needs to be a THC component if only just to collect all of the signals. By working with separate components, its easier to develop a system and I think it is more in keeping with the LinuxCNC HAL paradigm. Some of the standard components are only 3-4 lines long... Plus its easier to debug and less likely to go wrong. The downside is there are many more pins to manage. Dewey's approach to this was to have a custom hal file as a library component that made all of the boiler plate connections for you automatically and just leave half a dozen or so, maybe less the user needed to connect. Thats what I will try to do.

Please Log in or Create an account to join the conversation.

More
12 Feb 2019 08:13 #126254 by rodw
Well, I got my prototyping done.


I've got so much clearance between the swaybar and the braces, I'm going to redesign them!

I did get some Sheetcam cut rules done and found they made a huge difference. I also got caught with the digital outputs staying sticky between different G code files so I just need to tweak the POST one more time. I've been caught with this before. To me its buggy behaviour as to my mind, a gcode program should start from a known state and if you use digital outputs it doesn't!

Are the g codes included in the INI file under RS274NGC_STARTUP_CODE sent every time a gcode file is opened or only on linuxcnc startup?

Please Log in or Create an account to join the conversation.

More
12 Feb 2019 09:33 #126256 by Clive s

Are the g codes included in the INI file under RS274NGC_STARTUP_CODE sent every time a gcode file is opened or only on linuxcnc startup?


I believe that is a one time read and that you should put the preamble at the top of every gcode file.
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
12 Feb 2019 10:04 #126257 by rodw
Thanks Clive, I suspected as much. I'm not a machinist but it seems poor form to me to not restore the state to what it was in the beginning

Please Log in or Create an account to join the conversation.

Time to create page: 0.110 seconds
Powered by Kunena Forum