Plasma Questions

Hello

I am still in the rather extended process of retro fitting my existing plasma table to a LinuxCNC control. I use my machine for production on an almost daily basis so I have not actually connected the new control to the table yet. I want to get all of my coding finished before taking my table out of service for the connection. I now have a hacked version of the Gmoccapy Plasma GUI that has all the controls I want for the present time. I have a thread on the modification here:

forum.linuxcnc.org/gmoccapy/31896-gui-modification-plasma?

I have some plasma specific questions that I hope those of you with with experience in using a LinuxCNC controlled plasma tables can help with. I want to incorporate torch height control with all the features found in the Hypertherm industrial units minus the network connections to an external motion controller (after all that is what we use LinuxCNC for).

1. I plan on using conductive sensing for sensing the plate top surface during probing. My present setup uses this and is very good at finding the top surface of thin plate (almost all of my work is on plate .5mm to 3mm thick) without deflecting it. I have incorporated the hardware to do this into my controller and on the bench it works at least as well as on my present system. I also have a floating torch holder with switch to act as a Z- limit switch for those rare occasions that the conductive sensing fails to find the plate. I haven't found any examples of this here so I am looking for guidance on the best way to pursue probing the plate top surface. I can come up with three possible ways to do this. One is to use a Gcode subroutine, another is to code the probing in the HAL someway, and the last is to modify an existing G38.x routine with all the conductive probing actions. What methods have those of you with experience in doing this have used and why did you choose that method?

2. I want to incorporate a kerf crossing protection (this may also be called a "Tip Saver" on some controls) into my THC control. This is to prevent the torch from being driven into the plate when the torch crosses a gap (usually a kerf from the current or previous cut) in the plate while cutting. I am using a THCad for arc voltage measuring and reading it at the servo thread rate (I think). My present system does not have this feature but it is in most industrial controls marketed in the US.I believe they work by tracking the rate of change in the arc voltage and locking the torch height when the rate of change exceeds a set point. Has anyone here done a control function like this? Any suggestions on the best way to monitor the rate of change of the arc voltage?

3. The present THC component starts servoing the torch height to the arc voltage as soon as the XY plane velocity is greater than the corner hold velocity if enabled or immediately upon receiving the Ok to Move signal from the plasma power supply. This may work well in a LinuxCNC system because of the close coupling of all the control functions, I haven't used mine yet so I don't know. My present torch height control and most industrial ones have an adjustable delay between the start of XY plane motion and the start of the THC servoing of the torch height to the arc voltage. The torch is held at the initial cut height during this period. I do know that the length of this delay does have an effect on the cut quality near the start of each cut. On the crude system I have it needs to be quite long, in the order of 1 to 2 seconds, on the industrial controls this is usually set to slightly longer than the time it takes the torch to reach the commanded speed in the XY plane. Do I need this with LinuxCNC ? Has anyone here incorporated this feature?

4. The current THC component works in what I call a voltage set point method to determine the torch height. Most all "hobby or small shop" THCs use this method. Most of the industrial controllers add a second method that I call arc voltage sampling that can be selected by the user. The arc voltage sampling method works by reading the arc voltage at the end of the THC servo delay or when the torch reaches the command XY plane velocity and the torch is still at the initial cut height. This sampled voltage is then used as the set point for servoing the torch height to the arc voltage. It is claimed that this method is self compensating for consumable wear and variances in material composition. My present controller doesn't have this feature, I have to manually adjust the arc voltage set point as the consumables wear. Has anyone done this with LinuxCNC?

I really want to get items one and three above working before I switch my table over to the new LinuxCNC control.

TIA

John

I'll be following with interest.

I know you say you have the ohmic sensing built but there is a DIY approach here.

www.plasmaspider.com/viewtopic.php?f=3&t...sing+circuit#p108969

I don't think incorporating the conductive sensor circuit will be hard to achieve at all. It is just another switch so OR the signal from it with your torch float switch before sending the output to the THC component. I did this with my torch breakaway sensor so it and the external estop switch both trigger an estop on the weekend and it was very easy to do.

I would have thought the existing documented THC methods will then deal with the sensing.

I think your other features will need to be incorporated into the THC HAL component. There was a recent thread about this so I will try to find it. I think in the case of the Mesa THCAD the voltage is sampled and remembered.

Maybe I should not be wading in as I don't yet have a working plasma table but I am trying to understand what LCNC is doing with THC control.

I relation to 3, isn't THC usually used in conjunction with a touchoff gcode subroutine? This subroutine has a pierce delay. So with a pierce delay that exceeds the time to establish an arc and enable the ARC_OK signal, won't this delay then achieve what you want? Granted it is a rather crude control but if you modified something, you'd want to make sure the 2 parts of the process are not fighting each other.

The HAL methodology might be to modify the THC component. Maybe add an extra THC parameter "dwelltime" and a variable that records the system time when Arc OK is first set. (starttime) so then when the time reaches starttime + dwelltime, sample the voltage and save it in a global variable which the THC should then target.

The other idea discussed recently in a thread that eludes me was to use THC PID control. From what I'm seeing in the source
github.com/LinuxCNC/linuxcnc/blob/master.../components/thc.comp

the THC seems to overrides velocity, not move the height up or down. I'm still struggling to understand the context in which the THC operates and still don't understand a lot of this internal stuff.

All

Thank you for your replies.

I have modified my existing old Torchmate AVHC to work with conductive sensing using both the CandCNC Feather Touch box and a home rolled one using a relay and an Opto-22 input module (cheap on Ebay) for isolation. Both work well. The key to making them, both work really well was in the software hack I did for the Smart Motor. Unfortunately there is no way to get the firmware out of the main controller so I can't make changes there. I am not sure that the relay is even needed, the Feather Touch doesn't use one, but the ThermoDynamics customer support feels it is required to prevent some torch problems from having the sensing voltage applied while not probing.

I am using the relay/Opto-22 module approach with my new LinuxCNC controller. All the hardware is finished and working well.

I don't really understand the HAL lines below. I get the nets and pins but don't understand the operators. This is from JT's plasma examples.and
I think I have my head around the THC component that JT has published. I almost certainly will make changes to it at some point. The old Torchmate AVHC I have uses Proportional and Integral terms in the control loop unlike the velocity command of the THC component. I think the Hypertherm industrial units at least use a proportional term and maybe full PID. Right now I haven't had good luck trying to use halcompile, every attempt sends the terminal off to never never land. And yes I do have linuxcnc-dev installed with build-essentials.

I am still really interested in hearing from all of the plasma table builders/operators here. I am trying to avoid plowing old ground and chasing my tail with unneeded modifications.

John

Hello

I have another question for all you lcnc gurus. I am sorry for the newby questions but I still don't fully understand how the various parts of lcnc work together and what the real time impacts are of doing something in one place vs another.

I want to implement an adjustable delay between the Ok to Move signal or the start of motion in the XY plane (don't know what variable or pin this is) and the start of the arc voltage height servoing. I presently have have the setpoint adjustment working in the GUI and available to the HAL. Now I want to know the best way to implement this timer. Should I use a modified time component that give out elapse time from start of trigger and read this value into the THC component. Or should I implement a counter inside of the THC component that is incremented every time the THC component is run (servo period?)? Is there an existing timer with at least .01 second resolution that I should use? TIA

John

islander261 wrote:

Hello

I want to implement an adjustable delay between the Ok to Move signal or the start of motion in the XY plane (don't know what variable or pin this is) and the start of the arc voltage height servoing.

Maybe the timedelay Hal component?
linuxcnc.org/docs/html/man/man9/timedelay.9.html
Looks like it does exactly what you want to do.

I use a sub to probe for the top surface with G38.3 and G38.5 and then light the torch. In my case a proximity sensor is mounted on a pneumatic cylinder next to the torch.
To start a cut...
Go to cut X Y location.
Move probe to X Y location.
Lower probe with pneumatic cylinder to probe position.
Lower Z axis until probe triggers.
Slowly raise Z axis to find top of material.
Set height.
Retract probe.
Go to safe z height.
Move torch to X Y location.
Move torch to pierce height.
Light torch.
Delay for pierce.
Move torch to cut height.
Return from light torch sub to main program.

It seems to me that a proper lead in to the cut will allow the THC to be stabilized without a further delay.
I am experimenting with a modified version of JT's THC with proportion height corrections based on voltage changes.
I will be running it by JT in the next week or two and if all well will post it.
To avoid problems when crossing previous cuts or air you can try limit2.
linuxcnc.org/docs/html/man/man9/limit2.9.html
So you could use limit2 plus lowpass to feed the signal to the THC comp.

Rick G

Hello

Thank you for the replies.

Rick G

I have looked over the work you posted in the Plasma section of the O codes thread and found it very informative. I have seen other examples of using a low force snap action switch instead of a prox for probing material surface. There is a thread over on Plasmaspider where a guy in the UK did it and posted complete O codes for the probing, he was running Mach 3 for control SW. I have been hoping to not add more items to my Z axis stage as I consider it heavy now for my gantry structure and drive. I do like your approach from a reliability stand point and would use your method if I was starting from scratch with the structure and drives.

rodw

Yes it sure looks like the timedelay component will do what I need without modifying the thc component.

Can anyone shed any light on the lines from JT's plasma HAL example I posted previously.

Does anyone have any thoughts about using the ddt component using the arc voltage as an input for detecting kerf crossings?

linuxcnc.org/docs/devel/html/man/man9/ddt.9.html

Can one use the pid component to process the arc voltage error for THC? I am assuming that the two components are linked through HAL nets. Does it cause a problem that such an approach can conceivably have a one or more servo cycle delay? It seems to me that by using the pid.N.enable pin the pid comp can be easily controlled.

Now I want to keep track of the distance I cut with a set of consumables. I all ready have the display for in one my Glade tabs. The only built in function I have found for getting cut distance is to use the motion.distance-to-go pin and capture the value on the zero to non zero transition at the beginning of the cut. Am I missing and easier way? I also found the motion.motion-type pin to parse for the type of motion. This is a debug pin and the docs say not to use it, is there a better way?

TIA

John