Post Processor for LinuxCNC and PlasmaC

I've emailed Phil a revised copy of the plasmac component. Hopefully you guys can see this video

This has added an additional pin to plasmac for external hold which can be enabled with M64/M65 or M62/M63

So vote up guys. Should plasmac support thc enable/disable in gcode?

photos.app.goo.gl/e1vf1xncKNjK2kwt5

Note this has not been tested in cutting, but the hal show pins tell the story. It will work.

I'm not suggesting you use the attached code as I'm a few versions behind. to use this, you need to add this to your plasmac hal file
and make sure you add a M64 P1 to your start up code. If you do that it should not interfere with any existing configs.

I vote for THC to be enabled or disabled via G-Code,

Having that feature will ensure Plasmac is capable of high end control.

i voter for having it as we here use it since years now and are very happy to enable thc first after piercing
so the thc internal got a 1sec space and i got a very nice cut after entry
no Hopping

phillc54 wrote:

This discussion leads me to ask what is the point of the THC entry in SheetCam tool tables, I am obviously missing something.

Cheers, Phill.

This was always messy. I think the setting you observed may have been as a result of John sharing you a post processor originally from CandCNC which had this feature. I've carried these settings into my POST but I think they all could be deleted now. I thought about it at the time but left them in in case we needed them.

In reality, the THC is a data entity belonging to the machine not a material so it should be in the machine and not in the material config. Including it there explains Stephan's concerns about hundreds of materials he would need.

Mind you plasmac is a vastly more sophisticated controller than any of the others out there in the entry level air plasma scene so it has the ability to store settings other systems can't...

I'm sorry, I've designed so many databases I just think in terms of data entities and the fields that belong to them and the relationships that join them. Sorry If I sound a bit high level. (eg. single point of truth, data redundancy, data entity etc)

phillc54 wrote:

pl7i92 wrote:

i voter for having it as we here use it since years now and are very happy to enable thc first after piercing
so the thc internal got a 1sec space and i got a very nice cut after entry
no Hopping

If THC is enabled there is already a delay for THC after piercing.

Cheers, Phill.

What about at the end of a cut?

I have had problems cutting 20mm plate where the lead in was 10mm and when the torch came around to the lead in of the part the THC caused it to dive into the sheet because it had already been cut because there was no steel left. When I disabled THC 15mm before the end of the part I did not have any problems.

It really is a powerful tool to be able to control the THC with code.

Also off topic but those who say that 6mm plate up to 20mm plates does not need THC obviously has not done much cutting themselves with those thicknesses. I have seen 16mm plate buckle up like the sheet in Rods THC video. I had a batch of 16mm plate come in that was bowed in the middle, I needed the parts at the time so I used it but it was when I first started plasma cutting and it really tested my Sheetcam settings.

thefabricator03 wrote:

What about at the end of a cut?

I have had problems cutting 20mm plate where the lead in was 10mm and when the torch came around to the lead in of the part the THC caused it to dive into the sheet because it had already been cut because there was no steel left. When I disabled THC 15mm before the end of the part I did not have any problems.

It really is a powerful tool to be able to control the THC with code.

Also off topic but those who say that 6mm plate up to 20mm plates does not need THC obviously has not done much cutting themselves with those thicknesses. I have seen 16mm plate buckle up like the sheet in Rods THC video. I had a batch of 16mm plate come in that was bowed in the middle, I needed the parts at the time so I used it but it was when I first started plasma cutting and it really tested my Sheetcam settings.

Yes, I had some pretty brutal learnings from the little bit of 16mm I cut but that was before plasmac. I just wish I had a bit more time to play. This is where the kerf crossing should come into play as when a slug drops away, there is a violent dive at the end of an inside cut which motivated me to look harder at the kerf/void sensing. In fact now I think of it, I might add a second external disable pin to plasmac so I can hook up my almost working void sensing component..... if we could get that right, you might not need to insert the THC disable codes.

Rod,

Your void sensing component sounds interesting, I am just worried that adding all of these components will add a lot of complexity to in my humble opinion is a system that doesn't need to be so complex.

Just from my experience to get good cutting results from air plasma you need one main thing and that is full control of the torch height control. If we can do that with some simple G-code I believe that would be the best way forward until such a time when we have working components to take care of that.

At the end of the day if the codes are placed in Plasmac and they are not needed by the user I do not see any downside to having them added,especially when Plasmac gets added to the main Linuxcnc release.

And I imagine it wont effect Phills original plan to be able to use the branch without a CAM program.

My experience with plasma is quite big over the years.

If you have a g-code with top level info, a m3 and m5 for torch on-off, a S number for plasma power and eventually a tool number, and later on a M30 is the most simple way, and direct compatible with all kind of program's like inkcsape. This will result in a very clean g-code.

The component has to do all the work !

I prefer to extend the G-code only with the usage of G40 and G41 and G42 kerf width offsets. This way is used at the python
coded dxf2gcode program, wich is a perfect solution. Even a better solution then the actual Sheetcam g-code output.

I made a short list of how a component should work :

- Auto enable the component on program start, Auto disable the component on program stop.
- Arc oke simulate button is a must. Otherwise you can not simulate the program.
- Torch restart button (included a 1sec pat'h reverse run logic, connected inside the component to program pause inhibited).
- Pierce height input.
- Pierce speed input.
- Pierce delay input.
- Cutheight input, standard = 0.
- Torch height control correction speed input.
- Probe on-off button.
- Probe search limit input.
- Float switch offset input.
- Probe over distance input.
- Probe speed.
- Divided voltage input (digital 0-10V) - or up-down signal input for the proma version.
- Target voltage input.
- Torch on-off button, for cutting manual ( outside the component, no thc needed, 90% edge start )
- Modified "Adaptive Feed speedbutton" from -1 to 1.
- Optional : Plasma power input.
- And so on.

Attached to give GPL2 code back, my latest component THC2. Used on my latest Ethercat machine.
It has all the option's that i find usefull. Tested on a plate and rotary cutter. The component comment's need to be updated, all todo comment's are integrated and tested.

The nice think about the usage of a component is, you don't have to connect all the i/o signals to it.
A few connected signals are enough to make it working.