Enable and Disable THC in Gcode

Hi,
I'm setting up my post processor to activate and deactivate the THC throughout the Gcode file.
I am considering to use M64 and M65.
In the documentation I read (M64 & M65 happen immediately as they are received by the motion controller. They are not synchronized with movement, and they will break blending.)
Will that affect my G64 P- <Q- > blending tolerances I set at the beginning of my file?
Must I program a G64 P- <Q- > after each M64 THC activation?
Thanks,
EW

I think it will probably be OK as we have used M68 which also carries the same caveat about blending
forum.linuxcnc.org/plasma-laser/32700-co...hc-from-within-gcode

Guys

Might I suggest using the all ready established M67 & M68 codes that are used in existing PPs and deployments. I believe you have a set of these already. These are what I am using and the overhead to decode them is minimal. Saves from eating up a bunch of motion digital pins. One analog pin can control many functions. I know this is ancient history left over from Mach3 but it works.

John

I used your suggestions, and did some cutting using M67 E1 Q20 THC on and M67 E1 Q10 THC off. I am using it with gcodehold.comp by rodw forum.linuxcnc.org/plasma-laser/32700-co...hc-from-within-gcode works as intended!
Now I have uncovered an existing problem that I already had previously. When my THC enables and disables it doesn't always remove the THC offsets. With it turning on and off many times throughout a file, the offset multiplies and gets worse.
When the THC turns off close to the end of the cut the torch rises to a high Z position to finish the cut. The first few cuts it appears to remove offsets at the beginning of the next cut when the torch is on and it moves to Z cutting height after piercing height, but then the offset (might be?) greater than the Z move and it doesn't remove the offset. It quickly multiplies. In the thc.comp component I noticed it shows the line "if(!torch_on){ // remove any offset". Does this mean it will only remove offsets with the torch on?
To remove an offset, does the THC need a Z move with the torch on?
Do I have a problem with my g code torch touchoff?
I am using Hypertherm Powermax 85 with THCAD to control torch height.
EW

flamecutter

It is well known that there can be problems when using that component, especially when cutting many parts out consecutively. One brute force solution has been to always raise the torch above any offset between cuts effectively causing the Z height to synchronize. The problem is the correction is a velocity command and not a position command. Go up if the voltage is too low or go down if the voltage is too high and go faster the longer the error is present. At the end of the cut the offset is removed the same way. If the THC.comp doesn't stay enabled for enough servo periods for the z axis to correct for the offset you will be left with an accumulating offset between consecutive cuts.

Actually the line you are referring to is only evaluated as true when the torch is off (! = not or negation). Because the THC.comp must be enabled for this line to be run it equals NOT torch_on AND enable.

One way to help with this is to insert a small delay between disabling the torch (M5?) and disabling the THC.comp before making the Z move to G0 (traverse) height. Use a G4 P0.2 block there (right after M5), that should give 200 servo periods which should be more than enough.

This is one of the early working ways to use the THCAD for arc voltage feedback and THC. There is newer work done by rodw and myself that uses external offsets branch. I have also figured out a way that you do not need the external offsets branch but do need to re-synchronize the Z position at the end of the cut. You can see the jist of my work in my answers to Grotius in this thread:
forum.linuxcnc.org/38-general-linuxcnc-q...fset-to-real-machine

A good working fast THC is not a simple task if you are not using an external THC. I now have a solution that works but is messy and rodw is very close and has a much cleaner solution. I am not sure where Grotius is right now, he is working with the external offsets branch (to track Z position when under THC control) as well but is still using an external THC I think.

John

John,
I used your input and added the delay G4 P0.2 after torch off with THC on. It solved my problem! This morning I cut a job with over 70 cuts and it always removed the offsets.
At this point I am not ready to tackle a newer setup, because I don't have the programing knowledge that you have. I will keep tabs on the work with plasma that you and rodw and others are doing. I appreciate your time and effort!
My plasma setup is fairly basic and is working ok, but there is always room for improvement. Some of the changes I just made recently are;
I changed the THC Z direction indicators using rodw's showzdir.comp forum.linuxcnc.org/plasma-laser/32657-th...-indicator-component. Thanks.
I added a M68 to read the Volt settings from Gcode, and added an offset to adjust the THC Voltage + or - from the Gcode setting.
Now I also added the M67 to enable and disable the THC from Gcode.
My configuration files are attached.
EW

Flamecutter, Great work! I learnt a lot from islander261's last post about the offset issue.

I'm also excited to see you incorporated a couple of my components in your config!

So your next challenge is to incorporate the cornerlock component I shared. This will disable the THC if the velocity falls below a certain fraction of the commanded voltage. (try 0.8 or 0.9)

You could send these parameters from gcode either by extending the gcode hold component or quick and dirty just use a M68 P1 and M68 P2.

Whilst its been designed to be used with the external offsets branch, you could use it with your config

This might be easier if you add an extra pin "is-not-active" which is the inverse of "is_active" in the code so that would be a good exercise for you to try.

This should be able to let you and2 the new pin with the signal that enables your THC and use the output to enable THCAD
Alternatively, use the invert component to get a is-not-active output using HAL.

eg in psuedo code you would do something like this

Let us know how you get on. This has the makings of a really easy to implement plasma config using the thc component.

Guys

As Rod knows I am just a hacker at best. I am glad you have found something useful in my ramblings.

The THC.comp does have velocity hold built in. Use it by setting the vel_tol pin, I usually use between 85% to 95% of requested velocity. This should do away with the need for a corner hold command. You will still need to be able to height hold for small circles etc. from gcode.

John

islander261 wrote:

Guys
As Rod knows I am just a hacker at best. I am glad you have found something useful in my ramblings.

I think you sell yourself short there John. You've done some amazing things with your hacking methodical approach.

Guys

I got too caught up in the moment. There is a problem with the component code.

pin in float vel_tol "Velocity Tolerance (Corner Lock)";
...
float min_velocity = requested_vel -(requested_vel*(velocity_tol*0.01));

Sorry I missed this earlier. So to make this work correctly you need to change the variable name in one place or the other. Then recompile using halcompile.

sudo halcompile -install thc.comp

If you running a RIP system then you need to copy the thc.so from usr/lib/linuxcnc/modules/ to your ~/linuxcnc-dev/rtlib directory.

John