Another plasma component...

I think I may have brought this THC stuff down upon myself. My assumption from seeing there was a THC-Enable in the tool tables that John and Rod posted was that would enable/disable THC. That was why I added it to the plasmac material list and used that for THC control. But it seems that I was wrong.

So where to from here, it seems the current format works but is not attractive to many folk.

One option would be:
In the component:

• Create an extra pin named plasmac.thc-mode in the component for THC mode, being one of on, off or auto. Off and on would be as they say and auto would allow control of THC from the current plasmac.thc-enable pin, 0 for off and 1 for on.

In the config:

• Tie plasmac.thc-enable to motion.digital-out-02, so M62-M65 would control THC when in auto mode.
• Have the GUI output the correct value to plasmac.thc-mode depending on the state of the radiobuttons.
• Remove the THC Enable checkbox and label from the run tab.
• Remove the THC Enable option from the materials file.
• Be able to save the THC mode to the config file so the user could set their own default mode.
• In the monitor panel the THC LED label would indicate one of: OFF ON AUTO.
• The THC LED would be lit only when THC is enabled.

If we are going to make changes now then we need to get it right as I would like to get to a 'release' version soon so I don't really want to keep going over old ground.

Anyhow, if we can all get on the same page (or at least in the same book) that would be great.

Cheers, Phill.

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

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.

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

THC-Enable again...

Would it be viable to have the pin thc-external-enable that Rod has suggested instead be a pin named thc-disable so to disable THC via gcode you would need to set motion.digital-out-02 to 1 and to re-enable THC set the pin to 0. i.e. the default would be enabled.

This would then allow the HAL connection to be in plasmac.hal permanently and would have no effect on configs where the user wants to use the default plasmac THC workflow.

The only alternative if it needs to be a thc-external-enable pin would be to do the connection in postgui.hal and would be something that each user requiring it would need to set up themselves.

Cheers, Phill.

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.

OK, I have pushed an update with the new pin named plasmac.thc-disable.

In the configs this is connected to motion.digital-out-02.

So to disable THC from GCode do either of M62 P2 or M64P2 and to re-enable THC do either of M63 P2 or M65 P2

Note that this is a disabler, it does not enable THC on it's own you also need the correct settings in the Run tab.
i.e. one of:
THC AUTO and THC Enable checked
THC Enabled

The readme.MD in the git directory as well as the first post in this thread have been updated to suit.

Hopefully this will have THC sorted and thanks for all the input I received on this.

Cheers, Phill.

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.

Rod,
I connected an analog pin to the plasmac component to vary the adaptive feed pin and it works great in a sim. I just have to figure out how to integrate it into the config.

Cheers, Phill.