Another plasma component...

John, I dug a bit further and found this note about external offsets
linuxcnc.org/docs/devel/html/motion/exte...-offsets.html#_notes
"If an axis.L.eoffset-enable hal pin is reset when its offset is non-zero, the offset is maintained."

Thats what was worrying me. I thought maybe the offsets would unwind if this pin was deasserted but it does not.. This is exactly what we want.
So looking at the plasmac pins there is
So I think you could safely and2 plasmac.offset.enable and motion.digital-out-00 and connect the and2.out to axis.z.eoffset-enable
So that would let you control it from gcode. (M65 P0 would hold THC and M64 P0 would enable it). Make sure your post sends an M64 otherwise you will never have THC

I would recommend you create a new hal file and use unlinkp to remove this linked pin set and reestablish it. That way plasmac stays intact and make your life and Phills easier. (this unlinkp approach is how Dewey wanted people to work with his config) and it really is a good idea for future maintenance.

Have you tried auto volts? I can't see any reason why you should not use it (other than archaic habits developed in your Mach3 days)

Rod
I presently have a working external THC enable from Gcode working just fine. It works no fail, I don't change in the middle of a cut. I am sure that Phill will get around to including it in Plasmac as it was there before. I actually use an OR2 component and and don't select the THC enable from the GUI.

Actually I am not ready to try the auto volts yet. The ohmic probing has about .010" error when physically measured on my system right now. The good news is the error is on the plus side so I am not burning up consumables. For people cutting thicker material (< 6mm) and using a well calibrated float switch I say try it. Right now I get over 3,000 pierces out of a Copper Plus electrode so the whole compensate for electrode wear thing is in the noise for me.

John

John, thanks for clarifying.

Phill, I think plasmac needs an two input pins for external-thc-hold-a and external-thc-hold-b.
And these together in the component and if output true, hold the THC. Permanently connect hold-a in your config to motion.digital-00 so there is a mechanism to enable/disable the THC from gcode.
That would leave hold-b for user defined requirements.

I might then be able to experiment with my external kerf crossing module and once its confirmed as working, the core code could be fed back into plasmac. I severed some sheets yesterday and I did see a bit of a dive at the end of the cut with the current algorithm.

islander261 wrote: The Plasmac branch is really so good now that I don't want to go polluting it with my hacking. This has the potential to kill a Texas loud mouth as soon as someone releases a pre built ISO with a schematic/wiring directions to use the Mesa hardware.
John

Sorry I glossed over the bit about the loudmouth. The penny just dropped. :lol: :lol: :lol:

I'd like to think this will find its way into Master branch shortly. The only change to the core code is the reverse run and there should be enough test data to confirm that works from this group alone to satisfy the most demanding skeptic!

islander261 wrote: Last I checked the plasmac branch uses both EO (now incorporated in the master) and reverse run.

Without working .hal and .ini files we can only get to all of the copying that will be needed to start building a working configuration. To start with make a new directory, say myplasmac or what ever you want, under ~/plasmac/configs/ using either a terminal or your distros file manager program. So by my example you will need a directory ~/plasmac/configs/myplasmac. Then copy all files and subdirectories from ~/plasmac/configs/sim/gmoccapy/plasmac/ to the directory you just created. Now you can cut the work in 1/2 if you are only going to use imperial or metric measures and not both. Delete all the imperial... or metric... files and links from your new directory and leave the system you want to use or leave both. The next part is a little tricky. Many of what you thought are files that you copied are actually just links to the real file and they are broken. I find it is easier to use your distros file manager program to make new links and replace the broken ones( they will usually have some sort of broken symbol if you use the icon view). Most of the files you will need to link to will be in the ~/plasmac/configs/sim/axis/plasmac/native/ folder. Once you have all the files copied and the broken links fixed we will be ready to make your working configuration.

My crystal ball is a little foggy lately so I really need you to post working examples of your .hal that has everything for your machine motion and physical I/O in it and the .ini file that calls it. I can post mine if you want to work it all out yourself but it is very confusing because of my pendant, gantry mechanics and hacks to allow limited control from Gcode.

John

Ok, I started to fallow your instructions and got the new folder created and the files copied over from the sim area. But i don't see any broken links. I tried opening each "file" and thy seamed to open fine by just double clicking on them. Am I missing something? Here is a shot of the new folder with the copied files. Also i do have working .hal and .ini file that moves my machine. I think I still need to tweak them to get proper dimensional moment, acceleration and what not.

Rod just started a Plasmac how to thread last week look here:

forum.linuxcnc.org/plasma-laser/36410-in...her-plasma-component

John