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 ?

The way I look at it, the probe input is for LinuxCNC's G38.X probe cycle
regardless of how its used. (there are more than just 2 ways) Since the input
is always handled by G38.X the same way, one input makes sense at that level.

Multiple probe inputs can be handled in hal, either by OR'ing them together
or by using a mux component and selecting the input with gcode.

If there were G38.X codes to select an alternate probe input, that
would make an  alternate probe input  to motion make more sense.

I've installed dozens of Renishaw probes on Fanuc controlled machines using a single input with a relay to swap which probe input reaches the control, and it works perfectly fine and is not "problematic". Hook one probe input to a NC contact (I do this to the tool setter since tool breakage is quickest) and the other to a NO contact. For using the tool setter, add an M code to the macros to turn the relay off. For using the spindle probe, add an M code to turn the relay on. With the NO and NC contacts, you only have one probe active at a time and you have different macros you call for the tool setter and spindle probe.

This is a entirely backwards way of thinking, fix the damn software. Probe and tool height are separate entity, and it's not as if the cards are short for IO pins, they are not.

Life is much easier if you live within the linuxcnc paradigm. If it only has one probe, live with it.
ts not necessary to use hardware, for multiple probes'
You have the power to fix the damn software in hal as PCW suggested. Its not hard.
Or as Linuxcnc is open source, you could add the G38.x to the interpreter to provide multiple probe support. That would be hard by comparison.