additional probe inputs or configuration for tool height sensor ???

pnconf only appears to allow configuration of a single probe input. I had 2 devices that operate different, one is NO and the other is NC. Additionally I would prefer to simply not have to remove and add devices from the machine as this is time consuming So given those constraints and a bunch of RTFM , I am completely baffled as to how I would create a probe_1 channel for use with my tool height sensor, or any other additional IO type devices. 

Is the pnconf limit on the total numbers of probes a fixed value or are there ways to work around it while using Probebasic etc , and yes, tool changes are manual, but I do have a nice magazine of quick switch 200 holders and 2 machines running the same software and hardware etc. 

Thanks in advance 


 

If I remember correctly, linuxcnc internally uses exactly one probe signal to be accessed by G38.2 and this is motion.probe-input. That is the internal side.
Given that you have two physical probes with different behavior, you can of course connect them to two separate inputs, possibly negate one input (so that both are NO or NC) and use - in the simplest manner - an or component to merge the two physical inputs into one signal that is then fed into motion.probe-input.

There should really be a separate class of action for tool height sensors, and pnconf will only allow the configuration single input pin for probe. I suppose the only thing to do is file a bug ticket

Not sure if I understand you correctly. All probing happens through G38.2, regardless of to height or touch probe for part measurement. From a motion and logic point of view, these are identical. Since, to the best of my knowledge, there is no "motion.tool-height-probe" or similar input, hence there is no bug in pncconf.

I would tie the probes into regular digital signals and and2 both of them into motion.probe-input. If erroneous trips of the probe not in use would give you issues, I would disable each signal until activated by an M code.

I'm not sure you understand what

Broken by design

would mean here.

The tool height and probe are 2 entirely separate devices with entirely separate functions, and while they might both use a probe cycles to determine the actual position of x y z, they have different uses entirely.

the tool height setter should work in the following manner.

Use probe to determine height of sensor relative to Z travel

Insert tool, probe tool on height sensor to determine OFFSET from PROBE, store offset

Use probe to find work piece Z zero/touchoff

save data for each individual tool, for instance if you have a ATC or even quick change tool holders.

Tool height should be a completely separate input from probe. It can obviously use probing cycles to find depth, but beyond that, it is a entirely separate function.

SHARING the input is problematic, the touch probe is not the tool height sensor and should not be treated as such, it is not a spindle mounted tool. It's also much easier to keep the tool height sensor in the same place at all times, so once the data is stored for the offset, it never changes, this reduces ERRORS and stack up tolerances. Adding a new cutter, touch of the tool off on the height sensor and the offset are handled for you

I suppose I could wade my way through the EMC2 code, but without having any familiarity with the code base that looks problematic. I assume it's all written in C ?