Do we need a Plasma Touch Off HAL component ?

I have not done a complete compare yet, but the thc_toma.zip from the thread you liked to seem to be what I started with. I pulled it down from the Proma website. I have everything wired up I think, but when I do rapid movements over 300 inch/min I get following errors. If I increase the FERROR values. then we start losing steps. I have reviewed the timings of our drivers with the linuxcnc docs as I can find them, and we have things correct.

When running a straight stepconfig project we can do rapids up 500in/min with out any errors or lost steps as far as I can tell from our testing so far.

That is why I moved to the gmoccapy+thcud component to resolve the following errors and improve the movement speed.

This was all with 2.7 stock install. I have went back and tried the thc_toma config with the dgarr/external_offsets branch yet. We are currently transitioning our control panel from prototype hair ball to a permanent layout, so I can't test anything at the moment.

I do not want to hijack this thread too much. I can post these concerns on the other thread.

Tom

Tom, don't worry too much about the hijack.

The external offsets won't help you as you have an external THC. External offsets will only help if Linuxcnc is controlling the z axis totally. it offers a PID based control that uses the torch voltage (usually read by a Mesa THCAD daughter card) as a feedback signal.

Its so new I don't think anyone has actually tried it on a real machine yet

Tommylight is the expert with the config I linked to as well as Proma and steppers in general. I'm sure he'll chime in

hi
I have been working on a component for THC control, it is similar to external offset controller, however, the component does not include PID.
Attached are the code and the state machine diagram.

I'm not a very good programmer but the component is working I like to know your feedback about.

Looks great on first glance. Well done!I will go through it when I have some time in the next few days.

The only thing I saw programming wise is that is not normally good practice to run a for() loop in an interrupt service routine but I did not look at what was doing. But hey if its working thats a great achievement!

Could you post some example G code for it?

hi
I have tested this component manually in the past and it works ok, however, today I tried it with a g code as RODW suggested.
and I found a problem the g-code executes correctly until M03, the start command is properly sent to the thcsm component and the component start the sequence and it works properly and return the move on command for the g-code to continue but it never continues, I tested the set up with other configuration and it works well.

there is any restriction to use a step generator as stand-alone.
any clue?

Its a bit of a long shot but to you set spindle at speed?

In my plasma setup, I do it like this so its on all the time.See: linuxcnc.org/docs/html/man/man9/motion.9.html

In a component such as this one, I envisaged this pin would be set true when the touch off routine is completed and it is good to move off.

You get the target.
I set the motion.spindle-at-speed pin to true and it is working, thanks a lot for your help
Tomorrow I will post the G-Code and configuration files.
Thanks again.

Great. The other Gotcha I found was that you need to tie M3/M5 into the arc enable otherwise if you have an estop or crash the torch, the torch will still be firing. (Which is a bit of a worry when it falls off its magnetic breakaway and the plasma power switch is in the other side of the table!

I think the right pin is motion.enable

I am hoping to have some time to play with your config this week.

As i mentioned here you have the files
I have included 3 inputs for crash sensors, these sensors can also be used as floating switch.

I will double check the code regarding estop.

hi
did you have some chance to test the comp?