Useful Plasma Thread

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

Nice sketch !
Am throwing this in just in case:
- Probe function - that would be initialised whenever an M3 is issued, so user does not have to do any post processor/ gcode modifications ( it can be done, it is include in the thc_toma config)
- Ignore Z values in gcode while cutting - (also included in thc_toma config)
- Cut height - user settable value based on the THC voltage ( simple THC do that when setting the voltage on them )
- Pierce height - user settable value needed for a lot of reasons, used often
- Probe switch travel - user settable value to offset the distance the switch has to travel when probing to trip ( included in thc_toma) used once when setting up the machine.
- Pierce delay - user settable value needed for piercing thicker metal plates, used whenever cutting anything over 5 or 6mm thick (included in thc_toma)
=== optional ====
- THC speed - user settable value for how fast should the reaction should be when the voltage changes
Not sure about the last one but it is included in the thc_toma and used to prevent "bunny hopping" of the torch while cutting thinner sheets, it is very useful for stepper systems, do not know about the PID controlled system as this one has much more control over the torch and is much faster.
- Output current -- see below for explanation
As a side note:
Adding another panel with pre-sets to choose some of the often used settings for cutting based on metal thickness and adjust the settings below according to that
- Feed speed - set the cutting speed for chosen thickness
- pierce height -
- pierce delay -
- cut height -
- cutting current - if there are provisions for that ( some hypertherms do, on some it can be wired from the built in potentiometer to the electronics so it is settable from Linuxcnc, on some adding relays can change cutting current controlled from Linuxcnc etc ).
The potentiometer types can be controlled using a single PWM output from parallel port or Mesa card or many other cards and an optocoupler with some simple electronics, or from one of the servo outputs from 7i77 or spindle out on 7i76 or 7i77.
The manual switch ones can be controlled using any output and a darlington transistor wired to a big relay, one or more as needed.

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

I was thinking about the structure.



If you have a component written. It has the in and output signals we need.
It can interact directly with M codes, user interfaces, etc real time.
So better is to work around the to make M code list, this list is a user friendly list and also reduces the comp file code, a Macro does not have to be compiled, and simplyfies the structure in drastic way. Also users can make a quick modification to a existing Macro and don't have to worry about learning the whole process how to be a top c programmer.

This is how you can do a Macro :

It first looks if the THC is enabled.
It triggers if the arc okey signal is not lost during the cutting process. This real time interrupt model is only done by the component.
So the component handles only the real time interrupts. Logic parts can be programmed in the Macro's themself.

Thanks guys. the sketch is far from complete. and has a few more annotations on it now! I just wanted to focus on the core components that compartmentalise each THC function so it does not include pierce delay etc at this stage.

I am very comfortable programming in C and have had previously written Interrupt Service Routines (which is what the servo thread really is). By breaking it up into components, it should be more robust and easier to read as each components source should mostly fit in < 100 lines of code.

Some comments.
1. This will be designed so all torch height control is done internally within Linuxcnc and will not accommodate an external THC such as Proma ot the current THCUD/THC components. LinuxCNC is better than that!
2. It will require a method to read torch voltage (eg. Mesa THCAD at $69 becomes a very cheap THC).
3. Using internal code and PID based control should eliminate the need for a THC response speed setting.
4. Islander261 and I have experimented with using a standard M67/M68 command to allow multiple GUI settings to be set from within Gcode using just one analog pin (with an appropriate python screen handler) so you can change settings on screen and within Gcode. So I don't want to be too prescriptive about what Gcode does what, Just that every required Gcode function is supported.
5. Grivalajp has already shared some python code that uses modbus to talk to the Hypertherm RS485 port. Eventually, I would like to replace this with a hardware module so that there is no need to have a USB connection back to the PC. It would be much nicer if there was only on ethernet connection to the control box. This should be able to be supported using the smart serial port on a Mesa card and the right firmware (available for the 7i76e).
6. I have often wondered about writing a seperate touch off component that enables motion.spindle-at-speed when Arc is on, back at cut height after pierce delay so that there is no Gcode pierce routine required.. I've added it to the list.

Thanks for all the feedback. As I said most of this has been written so if I can stay motivated, it might not take long.