Plasma Questions

One other thought is that if the Ohmic sensor is shorted when entering the procedure, maybe it should attempt to move up to clear the error or a timeout occurs before throwing an error. If the short clears, reset the starting time and continue with probing.

Here is JT's touch off routine...

gnipsel.com/shop/plasma/files/touchoff.ngc

Rick G

Hello

Thank you for the responses.

Well I didn't explain things well enough. My new Z axis mechanics actually cause the float switch to be actuated just before (.2") the mechanical Z- stop. So I can use the float switch as a Z- limit switch if there is nothing under the torch. Actually one should have the torch either mechanically connected so that at the extreme Z- position the tip is not below the slats or grating on the table (helps to save on broken torch heads, don't ask me how I know this) or the Z- soft limits set to do the same thing. This is in combination with some kind of break away torch mount. My present stand alone THC requires that you mechanically set the torch up correctly in the mount because it doesn't have any Z- limits. Now I do have a question for the lcnc gurus, when the probing cycles are active (G38.X) are the soft and hard limits ignored? I can't find anything about this in the documentation. I think this is a problem unique to Mach 3.

I have been using conductive probing for several years now. I think I have a good handle on the failure modes. The most common failure I have is most likely unique to the Hypertherm Finecut consumables I use. The nozzle on the Finecuts is very exposed compared to the usual consumables. What happens is small piece of dross or slag gets caught between the nozzle and the shield shorting them together. This usually requires removing the shield to clean out the offending crude. The system response to a shorted contact sensor error at the beginning of the probe cycle should be to force the code execution to stop and the torch to raise to the Z home position (just below the Z+ soft limit) so it can be cleaned before resuming cutting. A much rarer error is water getting blown up into the space between the nozzle and shield. The anti corrosion water treatment makes it conductive enough to short the nozzle to the shield. This is much less of a problem because the post cutting cooling air flow usually cleans this out.

Now I am thinking that I want to use o subs to do my probing and torch firing unless there is better method. The best way I have found to use all the HAL pin values that get set from my modified Gmocappy Plasma GUI into my G code is to use this method:

linuxcnc.org/docs/devel/html/remap/remap...ap:referto-hal-items

If this isn't the correct method please point me to the right way. Along the same lines the only other way I can find to read and write to HAL pins is to use the M62-M65 digital I/O controls for bit types and M67 & M68 analog I/O controls for float types along with their associated motion.XXXXXX-XXX-XX HAL pins.

linuxcnc.org/docs/devel/html/gcode/m-code.html#mcode:m62-m65

linuxcnc.org/docs/devel/html/gcode/m-code.html#mcode:m67

I think these are also the same methods I need to use is I want to pass a value through the G code from my CAM SW (Sheetcam).

TIA

John

when the probing cycles are active (G38.X) are the soft and hard limits ignored?

No.
G38 can error if the probe is already in the target state. So if already triggered will not probe. You also set the maximum probe distance so you could set this to stay above the slats.
linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G38-probe

I use a ngcgui sub to store all my cutting settings to numbered parameters that are saved in the parameter file, so they are easy to use in the torch light sub or g code where needed and as I do not use Gmocappy Plasma GUI so can't comment there.
forum.linuxcnc.org/plasma-subroutines-li...0376-plasma-settings

Rick G

Rick G

Thank you for the clarification. This makes things much easier.

Anyone

Now I have a new problem. I am trying to use parameters from the .ini and .hal files in o code subroutines. The instructions for accessing them are here:

linuxcnc.org/docs/devel/html/remap/remap...to-inifile-variables

My code looks like this:
My .ini file stanza looks like this:

My problem is that the o code subroutine can't find the .ini file parameter, all I get is the failure message. Where is my error in how I am trying to access these parameters? I haven't been able to test the parts the use parameters from the .hal files yet because they require working hardware (next few days). I think I am doing the correct thing by the docs. I am using 2.8.0-pre1-2771-gdc2ff49 and PREEMPT-RT.
TIA

John

Hello

The documents say that the interpreter converts all chars to upper case. I have tried both cases with the same results.I was just trying to keep like source parameters together. Machine hardware related parameters coming from the .ini, GUI related parameters coming from the .hal files and the part related parameters coming in on the G code file.

John

Andy

Thank you, my bad for not reading the entire instructions. Having the FEATURES = 12 in my .ini file fixed this.

John

hi do you think it is possible to make a THC using the analog to digital card from mesa

store.mesanet.com/index.php?route=produc...83_88&product_id=126

can it be more accurate?