plasma arc goes out mid cut.... how to pause program, reprobe, and restart?

is their a list of all the available functions? i feel like im missing half of them in the basic documentation. e.g flipflops

If Jimmy looks over here : dot.py he can do his own visual hal with this piece of python code.
I think i will integrate this code to my git, before it is gone.

The hal style programming is way more difficult then programming in C.

But in the beginning i started just the same as Jimmy. If i look back, the beginning fase of linuxcnc was a hell of a job for me to learn.

On the other side i want to do a little google advertising at this time :
The Dutch Goverment. They provide the IS extrimist's weapon's. It was on the news here in Holland, about 2 weeks ago.
A shame for the Dutch Goverment. I am a Dutch tax payer all my life, do you know how i feel?
I feel like i am shitted over trough the Dutch Goverment.

Look at the second post of dot.py, i am still waiting.

Okey it's uploaded to the GIT : github.com/michelwijnja/visual_hal/blob/master/README.md

tommylight wrote:

I think Rodw uses gmoccapy on his now gone plasma machine, as he sold it not long ago.
Rodw, did i recall that correctly ?

Tommy, I'm still here. Just that I had the opportunity to sell my Everlast plasma cutter with the intention of upgrading to a Hypertherm on my table. At the same time, somebody made a good offer on my manual lathe which is also gone and up for an upgrade (and I kept all of the tooling). Then, I've been thinking about leasing some commercial premises for my business (With a corner for my Plasma and lathe). Crazy thing is that neither machine was for sale. So all in all, its been very confusing here. Plus I'm about to embark on a $100k project for work so toys that will cost me $9k are taking a back seat!

As far as the Gmocappy plasma SIM goes, it seems it was designed by somebody who had a vision but there is nothing connected in the back end. Both Islander261 and I found it needed a lot of changes to make it serviceable because we wanted to control the key parameters form both the GUI and from Gcode. (it can be done) There is still a few settings that remain unused in my config but they would be useful for somebody like Grotius. The other problem with Gmocappy is that it is not really good with widescreen monitors. Yes it scales OK, but moving around a touch screen is not fun. I think Grotius has done a better job of it.

tommylight wrote:

rodw wrote:

Tommy, I'm still here.

I thought you sold your table, my bad.
Good luck with whatever you do. Just got an order for nearly 4 times that sum! Cr@p, just when i though i might have some spare time.

It will take more than selling my plasma power supply to get rid of me!
The lathe will really become a toy as the simple parts I used to make on it, I'm getting made in China as we speak. Originally, I started talking to them becasue I could not get continuity of supply of the material in Australia and they offered to make the parts for me.

im having a hard time finding your code on github Grotius and the link above seems to have died. hopefully im not missing something simple. Id like to see the custom hal components you wrote, i much prefer c/c++ to python/hal so if i can do things that way i wouldnt complain.

@Jimmy,

At the moment i am finishing the Grotius Plasma Gui.
If you wait a few day's it is finished. Maybe i reupload it then.

Tomorrow i will make picture. I am now programming a brand new machine with the first Grotius Plasma Gui.
The previous machine was a milling machine, also with Linuxcnc. Customer is happy. He say's the software is stable.

I have one thing to mention for the linuxcnc developper's :

When using a gcode cutspeed variable i mentioned something.
We start a gcode program with loaded cutspeed parameter from user gui. The cutspeed parameter is for example 2800 mm/min.
The parameter is passed trough hal into the gcode.
The parameter is only loaded at the begin (loading / reloading) of the program. So when i change the parameter during cutting, nothing happens.
The parameter is updated 10 times a second in the user gui. Halmeter is updating correctly.
I don't like this. Why is the gcode variable not in a loop or is it possible to loop a gcode variable every second?

Oke i can solve this issue with the THC2.component.
I take the master machine speed as input, cutspeed as input, pierce speed etc.
Then when reading a M3 it now go's to pierce speed. Only the G1 is as variable left in gcode at the moment.

The code looks like inkscape :

Begin program.
G0 X.. Y..
M3 (start torch)
G1 ..
G2 ..
G3 ..
M5 (stop torch)
G0 X.. Y..

So very simple. I like this.

When start procedure is completed i go to cutspeed. So input is max machine speed in fact a G0, and output is the screen
parameter CUTSPEED, active between M3 and M5.
This wil solve a lot. And it will give the user more power !!!

Grotius wrote:

@Jimmy,

We start a gcode program with loaded cutspeed parameter from user gui. The cutspeed parameter is for example 2800 mm/min.
The parameter is passed trough hal into the gcode.
The parameter is only loaded at the begin of the program. So when i change the parameter during cutting, nothing happens.

Grotius, unfortunately, there is no way extract the original cut speed (S command value) from anywhere in the LinuxCNC kernel. Once the S command is received, the only public variable is current velocity from the trajectory planner and this can be well less than the S command for a given cut segment. I trawled through the EMC code to see if it could be done. Everything is modular and each is protected from each module. eg. The code that knows the S command cannot set a variable in a public area. The devs confirmed my conclusion.

There is a solution I devised though!

You can remap the S command to always send a copy of the cut command to one of the motion.analog-out-nn pins. There is a SIM for remapping that includes a simple example that can be easily modified to do this. Some of the plasma guys are doing this with success.