THC2

John, Its great to see we have a dedicated section for plasma stuff. Maybe these topics could be moved to this section.
forum.linuxcnc.org/10-advanced-configura...190-thc-experimental
forum.linuxcnc.org/38-general-linuxcnc-q...010-plasma-questions
forum.linuxcnc.org/49-basic-configuratio...hc-config-that-works
forum.linuxcnc.org/10-advanced-configura...t=6&st=&limitstart=0
I'm sure there are more

Anyway, I am keenly watching your progress.

Hello

I returned from my winter break to AZ last month to a stack of work. I figured that my forays into using LinuxCNC where finished for the season until my work load reduced. Well I am back cursing at my poor height control and lousy cut quality it produces sometimes. So I am going to have to find time to finish changing my plasma table control over to LinuxCNC. I am making the bold assumption that this is the best place for new THC discussions.

I have LinuxCNC running on a desk top right now using my new Z axis mechanics, sensors and the MESA THCad & 7i76E boards. All seams to be playing well with LMDE-2, Preempt RT, Master 2.8.1 PRE with a modified GMOCCAPY GUI. I haven't had any of the homing issues others have had because I haven't tried to use X & Y axis hardware yet. I still need to add a pendant of some type because I can't see the laser pointer from my control station and I need this for getting part zero on sheets.

I want to try and use Dewey's branch that gives offset pins to the joint controls so I can use it for THC on the Z axis. I am up against my limited knowledge of dealing with the Linux world. If I download and build Dewey's branch will that work with my present setup? Do I need to do something special to use it with my current setup? Do I need to wait for it to be merged with the master branch? TIA for any pointers anyone may have.

John

John good to see you are back. Assuming you've compiled from source, getting Deweys code is super simple. There is a couple of pointers on my Page 8 of my build thread here

forum.linuxcnc.org/show-your-stuff/32029...utter-build?start=70

So its
Then just compile as normal. I found doing a make clean forced a complete recompile of everything so its something like
To go back to master you just do "git checkout master" and run make again as above

There is also a complete example of using the Mesa 7i76e MPG jog wheels on my build thread. I think you could get something like this running from the 7i76e MPG as the official docs how to shows how to add axis selection as well as scale.I think BigJohnT's site has an example as well

www.ebay.com.au/itm/Hand-Wheel-Pulse-Enc...2:g:0KsAAOSwImRYW42E

Hello

I have been working slowly on getting my linuxcnc control system working between actual working jobs. After much tearing of my hair (precious little left) I have managed to get Dewey's external offsets branch installed and working. This ultimately required me to remove my existing linuxcnc-dev directory and start with a fresh clone from git. My present running installation was done using Synaptic pointing to Master 2.8 pre 1 so I hadn't had the joy of building linuxcnc from source before. A big thanks to cncnoob1979 for his excellent instructions. I can get this to run using my existing configurations if I rip from the correct directory. I really don't know enough about linuxcnc and linux in general to know why things work the way they do. I haven't tried to run any sims yet, I really don't know how or should say I never have before.

My present commercial THC and others react to a height hold situation, torch speed below set point, kerf crossing, end of cut, etc, by holding the torch height at its present Z position , not returning the torch to its initial Z position when the condition becomes true. In my reading of the source for the eoffset_pid.comp it is unclear to me that this is actually what will happen. Can someone with a better understanding of how this all works together look at the code and the response to an internal or external hold condition?

John

John, glad to see that someone else is playing with external offsets
If you bust your git there is a command something like this which throws everything away and revertsbut please research it in case I got this wrong.

In my spaceship plasma build thread I recently posted a series of git commands that rebases the external offset branch with master to pickup the changes Norbert has made to gmocappy. You will probably need to do this. Norbert still has a bug I found to fix. I wish there was a nice simple tutorial on how to use git.

I've got some spurious noise issues on my setup that have crept in so while I am running the eoffset code, I reverted back to not using the pid for now until I sort them. I think it was after a dead short on the gantry that melted a cable or something.

Now back to the eoffset-pid code. Dewey has provided some sims which appear under axis/external_offsets in the linuxcnc chooser. (ie when you run linuxcnc with no command line parameters). I think you are looking for hpid from memory. I had to drill down to the source folder to find the source as it did not appear to be copied to my config folder.

From my reading of the code, the experimental hold pin is the one that holds position for corner lock. Could John T or Dewey confirm this?

My approach to get this all working together is to write a series of HAL components which link together. I have written 2 now.
One simply provides z axis up and down indicators for gmocappy becasue the pin I used in your plasma questions thread no longer exists. I have posted it in my build thread this week and will post it in the plasma section once I get a chance.

The other published in the plasma section cleans up the HAL file for use with the THCAD becasue things got complicated using a THCAD-10 due to the additional scaling. It also has an output which converts the target voltage to a target velocity that I was going to use in the eoffset-pid against the actual THCAD spindle value so there were no intermediate calculations for processing speed in the servo thread..

The third component will be corner lock and I started by writing down a list of pins it needed last night. The outputs will be two pins something like hold-is-on and hold-is-off which will be the inverse of each other. One of these will feed to the external offset hold pin (or one of its a,b,c inputs.). Now I know that someone else is on the case, I will post up these pins as some discussion on the values and defaults will be great!

Finally, I think the 4th component I write will be a touchoff component that does everything in the component before enabling the motion.spindle_at_speed which will eventually turn on torch height control via one of the enable pins, possibly after a delay while auto height sensing is being performed.

I may come up with other components along the way.

Hope that helps...

Rod

I think we are all traveling nearly the same path. I am quite excited about about everyone's solutions to the plasma control problem.

I have started one of the external offset sims but didn't get anything meaningful done before being interrupted for the rest of the day.

I have found the process around GIT to be rather non intuitive for a non linux person. I will want to rebase or what ever it is called so the latest Gmoccapy code is included. I am far away from this being a requirement right now. For production work touch off eats a huge amount of time. My present THC does a touch off for each cut, 4 seconds lost if they are close together. I will be modifying my post so I can adjust the distance between pierces that require a new touch off.

I am using the plain old scale component for scaling my THCad output to volts, works and is already part of linuxcnc. I have actual tested it against JT's original THC component and is perfect. Yes, I am using the 10V full scale version of the THCad with an external divider/filter in the plasma box. I use a 9V battery and a voltage divider/pot on my desk for testing.

I am using Gcode subroutines right now for touch off and cut starting. This may not be the ideal method but it is easy to do and tune for more optimal results. The subroutines are easily modified to adjust the process.

Linuxcnc has good access to the cartesian speed through the motion.current-vel pin. This gives me great confidence that a speed hold as implemented in JT's THC comp or the eoffset_pid comp should work well. I can tell you from much cutting experience that if this works as well as I think it will good cut quality will follow. This really is a big deal and most of the external THCs and some of the internal cobbled together ones for MACH don't work really well.

The start of a cut has the arc voltage varying quite a bit until some time after the torch reaches programmed velocity. This is why most of the commercial offerings have a programmable delay between the assertions of the arc ok or ok to move signal from the plasma power supply and the start of the THC arc voltage servo. I am using the simple timedelay comp for this with the time set from the GUI. My present less than ideal THC needs about 1.5 to 2 seconds delay to get out of pierce and acceleration jitters.

The higher end THCs have a kerf crossing hold to help prevent torch diving when crossing a kerf. This is just a dv/dt threshold detector following the arc voltage. This doesn't have much value for me because all of my cuts are planned to avoid this.

A feature most of the high end THCs have is the ability to choose between your screen or Gcode set arc voltage or a sample of the arc voltage taken after the pierce delay while the torch is moving at programmed velocity and at initial cut height. I call this arc sampling mode and have my GUI setup for it. This is supposed to help by more or less automatically compensation for consumable wear. The arc voltage at a given torch velocity and cut height does change as the consumables (electrode and nozzle) wear. I am usually trying to get more than 2000 pierces out of each electrode and over 1000 out of each nozzle.

I also plan on have a GUI adjustable lowpass filter that can be used if desired. The amount of 50/60hz, power supply switching frequency noise on the arc voltage signal is amazing. A plasma power supply is not a precision low ripple lab grade one.

I will be away from working on this until the weekend now that boat with construction materials is in.

John


John

John, I think there is enough of us on this to get it working. We are clearly on the same path! A couple of things.

motion.current-vel pin gives XYZ velocity. I intend to calculate the XY velocity. (you can use the HYP component to do this now).

I have a thread trying to sort out a gcode override to the GUI target voltage. Andy came up with an idea this morning so I will look at it as well. It will be bundled into my THCAD10 module.

The Gmocappy GUI has a check box for Auto volt sampling (thats what I believe it is meant to do anyway.) If checked the GUI target and Gcode voltage should be disabled.

I think the main problem in the past is people say Torch Height Control but fail to realise it is a number of discrete components that work together. When you think of it that way, the modular based HAL model is a perfect fit! And yes, touch off should be the last one done as there is a gcode solution for now.

I will come back to you about the dv/dt threshold detector but lets agree on the pins required first.

Hmm, I think Dewey left a pin out of the eoffset_pid.comp.
github.com/LinuxCNC/linuxcnc/blob/dgarr/...nts/eoffset_pid.comp

In the description he says
But the pin minimum-vel does not exist.

EDIT: Sorry I am an idiot, I found it now.I'm excited now!