THC Kerfcrossing Component (UNTESTED)

Hi guys,

Here is a component to sense kerf crossing and disable (hold) THC corrections. From what I could find, kerf crossing senses a rapid increase in voltage over time (when the torch is crossing a void) which is a level of magnitude higher than normal corrections. (In other words, it stands out like a sore thumb). For simplicity, this component works on the number of passes through the servo thread.

Based on what info I could find, the defaults are set as follows. If the the torch voltage changes by 1 volt in 2 servo thread counts, it will hold the THC for 10 servo thread counts. All of these defaults can be changed.

John (Islander261) has reviewed this code and we both think it should work but neither of us have yet got a working plasma system to test this on. Try it and see, then report back.

The active signal is intended to be sent to the eoffset_pid hold-request pin. In my configuration, it shares this pin with the cornerlock component I have shared on the forum previously by using an or2 component.

To enable the kerf crossing component, I have used the gmoccapy enable cornerlock check box so that the one GUI element enables both corner lock and kerf crossing.

In addition to the component file, I have also attached a text file that contains the man page for this component. It contains a complete example based on the gmoccapy plasma interface.

It sounds good, is similar to the anti-dive function on other systems.

grijalvap wrote:

It sounds good, is similar to the anti-dive function on other systems.

Yes, this feature has a few names. I am closer to testing but life has got in the way so won't have much time to finish this off for a week or so.

I can test this soon. One question... Wouldn't you only want to lock hight if the voltage is climbing at a rate -and- the sampled voltage is above the set voltage?

I did test this briefly but found it a bit buggy. I think we need to intentionally run it off the sheet and measure the voltage change over time with Halscope but I have never got around to try that.

You could try adding the condition you mentioned. What I read indicated that the change in voltage was several magnitudes higher than normal surface tracking so it may not be necessary.

Are you using the external offsets branch for torch height control?. I really would like some feedback about the PID settings you are using if you are.

No - I am not using exteranl offset branch yet. I am sticking with 2.7 currently. (can't wait to get time to try it though...) I threw some hal components together to get a feel for a PID loop voltage control. I don't know how my setup compares to the eoffset_pid setup in the external offset branch. Currently P=750 and I=10000 iirc. (I can look tonight) My thought is DDT'ing the voltage and seeing if something looks possible. (getting v/s)

This is basically hypertherm powermax 45 -> mesa thcad -> lowpass -> pid -> limit3 -> offset -> zaxis. Getting around +/-1v ish you can see from the halscope. The plate is set at an angle for testing - the rise is 2 inches over 10 inches. You can see from the offset trace. The end of the run gets a little noisy because the Z axis has a bit of backlash on that end. Obviously not the right setting for the steel I am cutting. Have not really tuned it in yet.

And yes - currently P=750 I=10000

Using the normal .004 per volt scaling. (a lot more hacking and testing to do)