Advanced Search

Yes, if the touch probe uses a contact to ground you can use a pull-up
resistor as Andy suggested.

For 7I76XX inputs this needs to be fairly stiff, say 2.2K 1/2W

This is because the 7I76XX input resistance is 11K and needs an input > 14.4V
for a high level at 24V Vfield, and a 10K resistor will not do this.

Do you want to replace like-for-like or swap out for a LinuxCNC conversion?

not currently, but its on the list

yup, from memory the probe led is a good example, forgot about that one

M62 and friends need connections in HAL to have any effect. Do these connections exist? (motion.digital-out-NN etc)

As far as I know nobody has done this yet, but the change that allowed one to use a custom homing component was put in to support this type of scale.

How's your C coding?

www.linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html

github.com/LinuxCNC/linuxcnc/blob/07cee8...nts/homecomp.comp#L4

However, I don't know if that is strictly necessary. I think that it _might_ be possible to craft a custom HAL component that outputs an encoder position and handles index_enable. This would take the encoder counts as input, and also manipulate the index_enable pin of the encoder counter. (I think it would be necessary to use the position-latching facility of the software or Mesa encoder. I _think_ you can set index-enable, which will zero the counts when the first index is seen, then re-enable index-enable and look at the counts-latched pin when index-enable resets on the second index. But I have not tried this.)

The component would then reset the index-enable that the homing system sees, and pass the correct position into the system. (Note that the "correct" position might be the inverse of the actual position, in some way. The position-after-index-enable is used by the system to calculate how far the current position is from the home position.

component inputs:
index-enable - to / from motion system
encoder position - from encoder counter
position-latched - from encoder counter

outputs:
index-enable - to manipulate the encoder counter
encoder-position - an offset version of the encoder position input

I do have a Heidenhain scale, but i have never done anything with it, and don't know if its a type with encoded index marks.

andypugh wrote:

Yes, it's probably best to turn off CSS when threading. 

Andy,

I wasn't using CSS when threading.  Multiple attempts at tapping the same thread at different speeds resulted in different start points.

What I discovered (through @Aciera's help) was that caxis.comp interfered with threading/tapping, and that LCNC has a bug in G33.1 and G76.

forum.linuxcnc.org/38-general-linuxcnc-q...peed?start=30#317931

One way to use a sinking input with a switch-to-ground sensor is to put a resitstor (I would probably try a 10k, choose something that can handle the current that flows when connected between 24V and gnd, anything over 2.5k @ 1/4 W size will be OK). Put one leg of the resistor in the 7i76 input, and connect the other to 24V, The connect the leg of the resistor that is in the input terminal to your switch-to-gnd.
With the switch closed the voltage at the input will be zero, with it open the resistor will pull-up the input and set it true in HAL.

You can invert the sense of the input in the HAL layer to get the right polarity,

spumco wrote:

There is still an issue with threading in LCNC - thread start point varies with RPM - but that's not related to caxis.comp.

Yes, it's probably best to turn off CSS when threading. 

You are right, this does seem odd.

It might help to log the motion type and the probe input in Halscope, to see if there is some dither in the probe input. Is the stated 0.2s enough time for the target to leave the sense area?

If a couple of ms delay is acceptable then you could potentially add a software debounce to the probe input signal, if noise on the input is the problem.