Plasma GUI?

Investigating LinuxCNC for a large Plasma table I need to retrofit.

So far I have yet to find a GUI that would appear to work well for a torch table. What am I missing?
Is everyone really creating their own custom one?

Plasma has not really been well supported. The Gmoccapy GUI has a plasma SIM that looks nice but nothing is connected in the rear end so it needs a lot of work. A couple of us have got it going and use it in conjunction with Sheetcam,

There are some significant changes happening that will give very strong plasma support in this development branch.
github.com/LinuxCNC/linuxcnc/tree/dgarr/external_offsets

So if you don't mind living on the bleeding edge of LInuxxCNC development, I would.
1. Install Linux with a preemptive kernel
2. Install Linuxcnc from source
3. Checkout the experimental branch above and compile it. Read all of the instructions
4. Get familiar with the plasma CNC simulator which is included with it
5. Create a copy of that simulator and update it with the actual real velocity and acceleration parameters for your large table
6. Tune the THC PID in the simulator for your actual hardware specs
7. Purchase the appropriate MESA hardware including a THCAD card and get it driving your table
8. Follow the instructions provided in the SIM to move it to your live hardware
9. Check the tuning with live cuts.
10. Move the proven working system to a nice GUI.

If you follow that process, you will have a high performance solution working with PID controlled THC control in the shortest amount of time.

WOW Thanks for that reply, I'm sure it will help others too.

Here I was worried about the GUI and didn't realize (if I understand you correctly), that the release software doesn't have D01, D02 type torch width offsets built into it.

I will follow your directions as I have been a consult programmer in extended gigs, but haven't done much of that for about 10 years.

When you say you have gotten it to work with SheetCAM... Are you say all offsets are being hardcoded by your nesting software? Or are you saying you are using the development branch?

Thanks again

I don't know what you mean by D01/D02.

You have to remember that nothing is built into LinuxCNC unless you build it

There are two existing "bit bang" THC components for LinuxCNC. Here is one for Mesa hardware:
linuxcnc.org/docs/html/man/man9/thc.9.html

The external offsets allow the position of an axis to be "offset" without the trajectory planner knowing about it. This has allowed THC to be embedded right into the internal workings of LinuxCNC. The experimental branch includes a high performance PID based voltage sensing component that tracks a commanded voltage. THe problem is that I'm probably the first to attempt to use it on a live table. Unfortunately, my plasma machine has developed a fault just after I saw enough to know this was going to work well once fully tuned.

Here is a quote from Jim Colt from Hypertherm from another Forum:

Height controls on high end industrial CNC plasma's have been at that point for over 10 years, with most machine operators not even knowing there is a complex height control as the z axis of the machine. Locating the surface accurately before each cut is key to this,

So basically, this module puts LinuxCNC able to compete with high end plasma systems with integrated Z axis control at the trajectory planner level for the cost of USD $69 for a Mesa THCAD board. But there is still a bit to do yet.

My Sheetcam post generates Gcode that sets torch voltage and all other parameters including the torch on/off and THC on/off commands which are processed in real time. I'd like to extend this to the Hypertherm RS485 interface but don't have a machine to play with right now.

My build thread here forum.linuxcnc.org/show-your-stuff/32029...r-build?limitstart=0

There are also several components I've shared in the Plasma section that are designed to be helper applications to support the external offset THC component. They may not be current versions.

And here's my GUI interface based on the gmocappy gui.

By D01, I just mean a way to pass the torch offset to be used by the M41 and M42 commands.

Currently use Radan for sheet nesting and programming on a Whitney combination punch/plasma combination machine. Does a very good job of parts inside of parts cut outs and overall utilization nesting. Haven't investigated what they are going to charge me for another machine and post processor yet.

The Whitney only handles gauge to 3/4" and everything 1/2" and less you punch for the pierce so it just has rollers at this time. (May investigate changing in the future).
This machine will handle all the 5/8 to 2" material. So not even sure what offsets will be needed on the higher end and amps. (Currently has 2 600amp torches most likely not running beyond 450 though)

May have to check out Sheetcam for this large table. But, I'm sure I would miss the powerful automatic nesting.

OK off to checkout the dev stuff and yours so I can talk more intelligently.

scubawarm wrote:

By D01, I just mean a way to pass the torch offset to be used by the M41 and M42 commands.

Hmm, still a foreign language as those commands don't exist in Linuxcnc
linuxcnc.org/docs/html/gcode/m-code.html

The key interface from gcode is M67/M68 analog output control and M64/M65 Digital output control.
We use M67/M68 to send a series of different commands to LinuxCNC's HAL layer and the GUI variables eg. Numbers starting in 5 set torch voltage.

M64/M65 turn the torch on and off.

Sheetcam has an interface to some automated nesting systems. See www.sheetcam.com/plugins

Sound like a pretty serious setup you have. If you have an external THC, you should be able to interface that with LinuxCNC.

Sorry... What I get from relying on my old man fading memory. G41 and G42 not M.

linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g41-g42

I leave all that to sheetcam. It knows if its is an inside or outside cut so it just does it in the post processing.

rodw wrote:

I leave all that to sheetcam. It knows if its is an inside or outside cut so it just does it in the post processing.

I guess that is where I'm getting a little lost. Yes, I agree, I sure don't want to worry about it. I want the post processor to send the dimensions of the part I want to cut with the offset codes and the "controller" (ie LinuxCNC in this case) cuts me a nice part (including square corners) allowing for the width of the torch stream.

Is that being done or isn't it? I'm still trying to get a full install built on my laptop so I can check things out myself, but am darn curious... To me it has to be, given this was a government project originally and the the G codes are listed.

Granted... I'm not sure about the storage of each D or diameter offset yet though. Of how to pass them so they go into a register or something. I'll get there.