Another plasma component...

I think you are doing an admirable job Phill, putting the code together
Its even more admirable that you have dealt with all of our rabble and different viewpoints.
What is even better, I think is the recent discussion has just been around usability of the software, not bug reports and fixes.

Its also exciting to see how many are using you baby and with different backgrounds and hardware. We even have Proma users on board now!

Remove the THC Enable checkbox and label from the run tab.

Personally, I think this needs to stay. There will be times when times when you will want to disable this just like you can disable the torch. One example might be if you are doing a series of test cuts and you want to know the actual height you set.
Having the external enable pin is a better way as I coded it. The earlier component by Dewey Garrett actually had 3 of them tied together.

Also if you go back to your Hypertherm bible document, it has the same ability to disable the THC from Gcode.

I think what became clear over the last couple of days is that users wanted two features:
1. the ability to turn the THC on and off from Gcode
2. the ability to control the cut speed during a cut.
And:
3. I wanted to make sure these were both implemented in a plasmac friendly way so it remains the master.

Being able to control cutting speed with adaptive feed can be implemented in HAL as I suggested (if it ends up working OK). This will be powerful if we end up getting the state tags branch into V2.9, this would become very powerful as a plasma controller would know the commanded cut speed from F code and any other changes in cutting speed could be implemented using adaptive feed commands from within gcode that do not alter the F rate recorded in state tags. The need to retrieve the plasmac feed rate will be removed. Then, the need to turn the THC on and off from within gcode would be vastly diminished as the corner lock will do it for us.

agree to rod
i got parts with real tiny short cuts and i like to disable the thc there in gcode

on cut speed i may be not deepth to the system plasmac but i can override it by linuxcnc keypad

phillc54 wrote:

Thanks Rod,

Remove the THC Enable checkbox and label from the run tab.

Personally, I think this needs to stay. There will be times when times when you will want to disable this just like you can disable the torch.

But you can do this from the radiobuttons.

Then, the need to turn the THC on and off from within gcode would be vastly diminished as the corner lock will do it for us.

That is the case now, if your actual cut feed rate is less then 99.9% of the materials cut feed rate then THC will not be enabled.

Being able to control cutting speed with adaptive feed can be implemented in HAL as I suggested (if it ends up working OK).

What is the intended purpose of using adaptive feed to change the feed rate?


Cheers, Phill.

My bad, I had never noticed the radio buttons.Happy now!

Agreed re the thc enable via the corner lock but people still want/need the ability to disable the thc when it suits them from g code. Stefan quoted an example where he needed to disable the THC well before the end of the cut (which was due to how far behind the arc trails behind on the lower side of the material).

Re the adaptive feed, you caught me at a good time so I could grab a sheetcam screen dump.There are fairly standard rules that apply for holes and other small shapes automoatically and are in use by many people.


So if you apply these to a cutting operation, it will be used for all shapes. These features are not in the post processor but are in rules the user defines.

Granted that the corner lock probably makes the thc irrelevant codes in most situations.

However Sheetcam will use its feedrate to reduce the cutting speed with these rules. The big risk I see is that is if we are using the plasmac feedrate and it gets out of step with the sheetcam feedrate, you won't get the expected results. There is no doubt this WILL happen.

So here is where the adaptive feed comes in. If implemented, We can insert a code snippet here that will reduce the cutting speed by the appropriate percentage of the plasmac feed rate. That way there is no dependence on Sheetcam and you will always have the cutting speed based on plasmac settings. This will eliminate the risk of a major stuff up.

I hope that clears it up

That sounds fine to me Phill. It pretty much achieves what I suggested. Its probably safer as the way I did it with the inverted state to your proposal , you had to explicitly add a M64 to the gcode somewhere or you had no THC.

Thanks for that Phill,

I cant wait to test it out, I should be up and running hardware wise tomorrow and as long as I can get my Hal and INI files sorted should be cutting on the weekend.