THC Velocity lock and void lock

Recent advice I have is that in the industry, both my method (which was based on earlier work by grijalvap --- Pedro is much easier to write!) and Phil's method are used. The problem historically with my method is it was protected by a patent which has since expired so people did it Phil's way despite it being acknowledged as not as effective. BUt the advice I received confirmed  dv/dt was preferred but the values used may be scaled differently.

I was also advised (as Pedro has discovered) that the settings used vary with the thickness and no doubt material type.

The problem with experimenting with this stuff is that it is time consuming and expensive. Plus in most workflows, we work around it so its rare to use both sides of the kerf in parts. Like Phil, there is little incentive for me to solve this problem. I can see though that someone like Stefan (thefabricator03) could use it to save material and time when he's cutting a full sheet of rectangular parts from 16mm.

As a precursor to solving Pedro's problem, I would like to suggest that the material file be extended to include a fields for:
material type (1 = mild steel, 2 = stainless steel, 3 = Aluminium....)
material thickness (always in millimetres)

I am suggesting that the thickness is always in millimetres becasue most high end plasma systems use that internally so there is no confusion when the values are used in algorithms that control the THC  adjustment. (But I think there is a pin that contains the device units since external offsets is created - for handling similar problems)

If these two values were assigned to pins in Plasmac, it would be up to the user  Integrator to implement a solution as he saw fit.

This would be much easier from my experiments if plasmac also included a pin the user could control that enabled and disabled the THC action. Currently, I think there is only one enable THC pin which is used by plasmac and its hard for the  user  Integrator to integrate additional THC controls.

Adding these fields should have no impact on the average user but it would be very helpful for integrators like Pedro and others. This would allow them to build their own components that would know the material type and quickly incorporate it into Plasmac. Its quite possible as Linuxcnc progresses with plasma that the gcode filter is extended to access databases of cutting parameters and set the environment up for hole cutting and void crossing.

I don't see its the role of the current plasma development team to incorporate all of this into PLasmac but if an intelligent framework was provided, to allow extension of the functionality of Linuxcnc's plasma operations, who knows where the  project could lead to......

 

Seeing as this topic is being discussed, I thought I'd risk mentioning my THEORY on this matter.

When I designed my torch height control I got into thinking about void lock. One thing I started to think was that the THC settings and Void lock settings should both be tied to the material and thus the cut parameters. Example, on thin material you can be cutting at high speed, have material warping relatively fast, and the THC needs to be able to react accordingly.

The normal thought with THC is that a good THC should be able to respond very quickly and adjust the cut height at warp speed in order to maintain Set Volts. Look at the woopee doo videos of a THC maintaining cut height over corrugated sheet for example. That's all fantastic when it's needed.

But now let's imagine this fast reacting THC is cutting thick plate at quite a low feedrate. A void is crossed but the fast acting THC can lower the torch height very quickly and thus the actual volts stays very close to the set volts. As a result you don't get any spike in voltage that would indicate a void and thus lock the THC. So with my THEORY I was predicting that with a fast reacting THC there could be potential of the torch crashing into the plate when a void was crossed on a slow feedrate cut, even with Void Lock enabled.

So I was thinking the answer may be to "dumb down" the THC settings based on how thick the material is and how slow the corresponding feedrate is. Then when a void is crossed the THC simply cannot react fast enough, the volts goes up faster than the Void Lock set level, and THC control is frozen.

Maybe I'm missing something, and very happy to my theory stamped on if I have done. But if my thoughts are correct, then maybe the ultimate system would be able to have THC settings and Void Lock settings programmed for each material/nozzle/feedrate combo.

Keith

Plasmac/QtPlasmaC was never designed for integrators, it was/is intended as an "easy" way for new users to get started with a LinuxCNC plasma config.

Absolutely understood Phill. I was just trying to contribute to the conversation (the brainstorm as I like to think of these discussions) for us all to gain a deeper understanding of the plasma process. Quite interesting things often come out of these type of discussions.

It would indeed be considered advanced setup of a plasma system for each material to have individual THC and Void Lock settings. Not something for beginners at all, and potentially causing a great deal of problems for those that don't know exactly what they are doing.

Keith

Keith, that was in reply to Rod where he mentions integrators, I hadn't seen your post prior to posting it.

beefy wrote:

Absolutely understood Phill. I was just trying to contribute to the conversation (the brainstorm as I like to think of these discussions) for us all to gain a deeper understanding of the plasma process. Quite interesting things often come out of these type of discussions.

It would indeed be considered advanced setup of a plasma system for each material to have individual THC and Void Lock settings. Not something for beginners at all, and potentially causing a great deal of problems for those that don't know exactly what they are doing.

Keith


 

I don't think Linuxcnc has any problem reacting fast enough at 1 ms servo thread to manage any cutting condition, That lets the THC respond as fast as motion parameters change so the THC can be stopped  more or less instantly (as far as Linuxcnc's view of the world.)

Following corrugated iron is well within plasmac's capabilities, its just that the maximum velocity of the Z axis determines the maximum XY velocity because the z axis must be able to follow the contour of the material at the cutting speed. The magic of plasmac, linuxcnc and external offsets will do the rest.

But yes, you are on the right track. There are many cut parameters that could be fine tuned if the system knows the material thickness. I guess it can make a guess at the material thickness based on the cut velocity but with a larger machine that has consumables to cut at 8-9 different amperages and do not communicate the amperage to the plasma controller its probably not possible.

I'll take your comments on board as a vote to include material thickness in the cut files.
 

phillc54 wrote:

Plasmac/QtPlasmaC was never designed for integrators, it was/is intended as an "easy" way for new users to get started with a LinuxCNC plasma config.

Maybe it was a poor choice of words but I wanted to make a distinction between an average user and somebody who builds machines and takes responsibility for integrating the Linuxcnc environment for others. I'm not one of them despite having been sought out by some who might  become one. There are others though. Tommy, Pedro, Bevins and many others. Its these people who can (and should) contribute more than others. But they will demand more of Linuxcnc.

It is a shame when we look back to the amazing developments through the Plasmac lifecycle that have been achieved by taking on board different ideas and user feedback that we now see quite a closed view of what Plasmac should be. I personally don't think we should ever stop that journey.

Don't forget that Pedro contributed the python code to control  the Hypertherm RS485 machines used by Plasmac. He's been building Linuxcnc based  Plasma systems since before Plasmac and has a deep understanding of plasma cutting. Its just we don't hear much from him. It would be good to give something back if he felt it could help him solve his problem.... What I proposed was not really difficult to achieve.

QtPlasmaC/PlasmaC has never been closed to new ideas, where did you get that idea?

Yes, I know the RS485 is loosely based on Pedro's code which was acknowledged. What has that got to do with anything I have posted here?

This is more or less my idea, as I mentioned I tried before but never included the speed and/or material. 
 

Taking a look to your code I see you have  height_per_volt included in the kerf threshold, and this is something I leave the default value.