Useful Plasma Thread

We got a bit of topic on this thread and now it full of useful plasma info
forum.linuxcnc.org/38-general-linuxcnc-q...-for-linuxcnc-motion

So I thought I'd create a link to it in the plasma section here becasue it covers how to fix gremlin displays and also how to sense if you lose the arc while cutting and pause the running program.

Hi Rodw,

Good idea to split off the topic !!

I am filosofying about the best plasma, laser and waterjet solution for the future of linuxcnc.
A solution that is usefull for starting and experienced users.

The most usefull way is maybe to write one good component that is suitable for all plasma, laser and waterjet machines.
The thcud / thcad / thc components are outdated at this moment to my opinion and not usable for all machines,
but are usefull to rewrite so they can be suited with the external offset branche. This branche is the perfect basis for machine's that need a correction at the z axis during operation.

I think a new component can interact with the external offset branche without doing one thing in your hal config. So i will do a
test to interact directly coming week starting with the simplest signal : axis.z.eoffset-enable

I think there are two ways to look at the THC component. One is to keep it modular so there are several components that do just one thing (eg cornerlock/velocity hold). This is more in keeping with the philosophy of Linuxcnc. and much easier to debug but probably more complex to install in hal. This will also result in a more robust solution as each small piece can be compartmentalised.

The other way is to build one big component that includes everything as grijavap has done. Harder to program but easier to install

The problem with the first approach is that there is some parts of the algorithm that can be shared among components (average torch volts for example for torch sampling and kerf crossing). Actually, maybe Average Torch volts should be a separate component.

I think that the first approach is probably the better way to go initially as you can add one piece of the puzzle at a time and then once its all understood, consider folding it into one component.

Hi Rodw,

I was thinking about your view related to the do and don'ts.

This will also result in a more robust solution as each small piece can be compartmentalised.

It's the way you write the code cq. component. A component can do 5 or more independent tasks if you write it that way.

The other way is to build one big component that includes everything as grijavap has done. Harder to program but easier to install

The only need of a component is the real time function. It is possible to load multiple components in linuxcnc without doing 1 line of postgui hal signal connection code. The component's are written to connect themselfs. This can only be done if the signal names are always the same related to their purpose. The uniform names are close to the linuxcnc program style.

In considering is the following :
If new users want to use linuxcnc plasma, at this moment it is almost a no go area. Even with mesa hardware i think it is to difficult to start up within a few hours. If you use axis with toma thc, you are limited and outdated, with my respect for the Toma code.

So if we want to change that, we can make 2 configurations. One for Parport and one for Mesa, configurations that are ready to go.
This will change the whole linuxcnc plasma useage exponential.

Hi Tommy,

I did your Toma config in the first beginning, and it worked fine for me on the plasma, no problem. It only takes time to understand
how linuxcnc is working. You can not do this in a few hours as newby, if you only have windows experience.

then again you are using a version of heavily modified Axis.

It has nothing more to do with a Axis source code. This is completely different written. The axis source code is very outdated if you look at this type of coding. In that day's they coded like pyvcp (xml) code's to fill the screen.

I also use inkscape. Very nice program. Mostly for converting google pictures into dxf.

Bottom line is, talking about things that do not work does not help Linuxcnc,

I think if you say something is not working, the github linuxcnc experts can help maybe to solve the problem?
Most problem's are coming out of update's that are not tested.....

As usual, Admins if you think this is inappropriate do delete this post, i just can not put get any milder. Thank you.

In all the time i have been member on this forum, i never saw one modification by an admin. This forum is also very outdated in options and possibilities. But i don't care about that, i only say it.

Tommy, the goal is to get a nice linuxcnc plasma configuration. Without doing this together, it can take much more time.

Yesterday, on an A3 sheet of paper, I started to sketch out the beginnings of a multi component plamsa version which would pull together all of my components. Just about all of these I have written code for but it would need some rearrangement to make discrete components. The could be tied together in a standard Hal library in the same way Dewey has done with his standardised eoffset-pid sim example. The User would not need to delve into it at all done this way.

Here is the list of proposed Plasma components:
THCAD parser - simple way to connect and calibrate the Mesa THCAD cards
UP-DOWN LED - A convenience function that displays LED's for up and down movement on the Z axis
AVERAGE VOLTS - a function that determines a moving average of the torch volts (for torch sampling and kerf crossing)
CORNER LOCK - A velocity hold function that senses when THC should be disabled on velocity slow down
GCODE ENABLE - Receives and acts on a Gcode to enable and disable THC
ARC FAIL - sets motion.feed-inhibit when ArcOK is lost while cutting
TORCHSAMPLE - samples average volts after THC servo delay expires and enables THC
KERF CROSSING - Senses dV/dT change in torch voltage over time and disables THC when crossing a void
PROBE-SENSE - disable the probe signal when cutting so it can be used for error sensing while cutting. (today's idea)
THC - Does the actual height adjustments

THC will have 4 enable signals (a,b,c,d), all of which need to be enabled to function
a. Torch Sample/THC Servo Delay
b. M3 enable (required to turn torch off on estop)
c. Gcode enable
d. GUI enable

Additional Gcode modifications required.
Remap F code to send original cutting speed to an analog input
Reverse adaptive feed (needs to be included in master branch)

Will use the External offsets somehow
Requires a dedicated GUI

Many thanks to all who have had input on all of this (Islander261, Grivaljap, Grotius, Tommylight, Samco, PCW and others)

So I still don't really know what the THC looks like but by keeping all of the support functions separate is a big step forward in simplifying the design of it.
But I will be working through the list of code.

And here is my sketch

@Tommy,

Very good !
How did you write the Toma code? Making this code is almost impossible to do without being a expert. So that's why
i have repect for you. Even proma has used your code.

This item : THC speed has to have some attention with using the external offset branche.

The external offset branche uses a ini-vel and a ini-accel parameter to control the speed of the z-axis reaction speed.
The THCUD and THCAD components are written with 2 speed parameters..
1. Thc(ud).velocity-tol
2. Thc(ud).correction-vel

So in my opinion the Thc(ud) component speed value's can better be removed in the component and only use the external offset ini-vel and ini-accel as parameter for THC. This will improve the quality of movement of the motors. At this moment there are more calculation's running around actually needed.

I like also the thc has a parameter for upper limit and lower limit. for example upper limit : 10mm, lower limit -10mm.

The probe function is indeed the easyest when using a on screen button. Then you have nothing to do with choosing a different
post processor. Is it acceptable to do the probe function with a M130 for probe on and a M131 for probe off in g-code ?
In mach i always use M300 for this. But i must test if we can use higher then M199 in linuxcnc.

In code :
M130 ( Probe function, is on or off through screen button, standard off )
M3 ( Plasma start )

Cutting current will be difficult to add in this startup process. Mostly Hypertherm uses modbuss for this.
I think in later stadium we must make a modbuss component for Hypertherm just like the vdf component.
Thermal dynamics uses 0-10Volt input on your pwm output, but pwm signal must be boosted up a little bit in amps.

@Rowd,
Nice sketch, this morning it did not load, but that is solved now i see.

There are a few things i have questions for.
The kerf krossing is only readable if you have a divided voltage input trough a mesa card,
or a modbuss i/o module? So it is possible to not use this signal without error's...

Is it handy to make a basic sketch with only the basic signals. After that make a division sketch for extra optional signals?
Just an idea..

It looks like the THC function finally gets a boost !

A tip : if you modify a component, it's handy to do the extension at .c instead of .comp
This will change your programming interface into c. It will look much easyer to understand.
When you are ready, change it back to .comp and give it a go.