Rods "Spaceship" Scratch built Plasma Cutter build

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....

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.

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.

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.

Keep up the good work !!

That's cool.

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.

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?

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.

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