Gmoccapy - A new screen for linuxcnc

marius,

i'm looking at Plasma to at the moment so , this work interests me , i'm looking at monitoring the tip voltage , and using this to control the torch height
for autostart and in part to control the height , as well as flame out monitoring so the machine can stop is this the better option over all , as against using gcode .

or is their other items to think about , from within a component aspect ,

Dave

Dave
I use a number of components to control the plasma functions. It depends on how you measure the tip voltage. I found that using and old fashioned analog circuit with a window comparator to determine the torch height to be the best solution. I have a circuit that takes a pwm signal form linuxcnc and compares that to the tip voltage. A up or down signal is given to a port input and the component reacts to that. I used a arduino circuit before but found the USB connection to be unreliable so I steer clear from that for now.

The information provided by the plasma screen is more than what you need to control any plasma application.
How to handle flame out is a very debatable point. I stop the machine as flame out is normally due to consumable problems and you want the operator to pay attention to the problem.
If you want to wait a while I will make the component available once I have it tested properly.

I am also working on a 5 axis plasma for early in the new year.

Thanks Marius ,
thanks for the comments , i was also looking at going the USB route and adding a analog out to the plasma torch , so i'll heed your advice and forget the usb
yes i'll look forward to the component , if you need any testing just shout .

yes regarding flameout , as you say once the flames gone you have lost it either way and machine needs to reset and operator intervention of course
i had thought of the flame out triggering a position save and disable the amps , so that after the problem is rectified the position could be used to restart .

and sorry for hijacking the thread , yes 5 axis is on my list to

Dave
The flame out is detected by the absence of an ARC_GOOD signal from the THC hardware. The component will use that signal. At the moment I will only use it to retry the pierce arc for several times and then just stop the gcode as there is probably something wrong with the earth connection or consumables.

It does not mean that one cannot do some clever deductions and do a restart on flame out while cutting. The reason I am not looking at it for now is because it is thin ice area. Lets say the torch travels over a hole, you will get flame out unless the plasma cutter is capable of continuous arc without having material below. Now how do you decide when to restart and when not. What if the flame out occurred while cutting an arc? how do you handle a partial arc if you only have Gcode to work with. That is why I insist that the operator has to intervene. I would rather spend the effort in getting a decent restart procedure going.

gmoccapy 0.9.9.6.2 - the new plasma operation panel

The design has been adapted to Marius needs.
The new plasma.py and plasma.glade files will offer the following hal pin:

The Out pin may control the machine, i.e. plasma.Target-Voltage will give the programmed voltage, while plasma.hal_lbl_cur_volt will display the real measured voltage.

Marius, if you only want to display the out values, we can make the GUI easier, because we can delete some hal pin labels. So I need to get your comments.

Please note, that Dewey Carret moved the gmoccapy_plasma files as a subfolder to the normal gmoccapy config folder. I do not like that, because it makes it more complicated to see what files are needed, but it has been done without my knowledge.

Please see the new INI file values for plasma, you can control each out pin by this values, if max or min are reached, the corresponding buttons will be disabled, one push will advance the value by the increment given in the INI file.

I have not implemented the state save and restore feature, as I want to know first your comments, As the hal pin are only connected without an auto update function, you will have to push a button ones to update the labels, This should not be necessary on a real machine.

Norbert

Hi Norbert

Looking good so far. I will test. Pity about the files moved. That means that the test environment that we are using will have to be redone. Files should remain in the locations as they are created unless there is a very good logical reason to move them elsewhere.

Marius, if you only want to display the out values, we can make the GUI easier, because we can delete some hal pin labels. So I need to get your comments.

The only value that we need to display from the component is the Actual Tip Voltage. The rest can remain internal.

There is one thing that we have not addressed yet and that is the actual THC correction figure. I will put the min and max correction values in the INI file but one should have an indicator if the limit has been reached. I dont know if this is required but it would be nice to see if the limit is reached.
How it works is this. One sets the maximum correction travel in both positive and negative directions. If the THC correction has reached this limit, THC will stop until the next pierce. On machines with limited travel this becomes an issue. Putting a limit on the correction also help to save a runaway process. Things like torch in hole etc.

Maybe a led for limit positive and limit negative.