Stepper - homing plus index encoder v2.9 no encoder reset ini flag

Hi All,

I'm rebuilding a Emco lathe that has stepper drives on X and Z and I am trying to tie off the homing. The system uses a minimum home/limit switch plus a proximity sensor for single count encoder on each stepper.

I want to utilise both for the homing proceedure and there is some great information in the video here, from 3.00 minute mark roughly: 



According to the video the INI should have;

HOME_USE_INDEX = YES
and the ini flag:
HOME_INDEX_NO_ENCODER_RESET = YES

The latter isn't documented as far as I could find, as a new feature in 2.9. 

This all seems simple enough but could someone explain what is required on the HAL side to make the relevant connections?

I have Mesa 7i96 and have the X and Z proximity sensors coming in on inputs 4 and 5 respectively (active high).

hm2_7i96.0.gpio.004.in and hm2_7i96.0.gpio.005.in

The documentation notes that connections should be made to  joint.n.index-enable from the encoder.n.index-enable. Could someone give me a basic example of the HAL net structure in this case?

Thanks in advance.

You need to be careful which documentation you read. (And install)
That missing feature is only in V 2.9
See section 2.13 here
linuxcnc.org/docs/devel/html/config/ini-config.html

 

Thanks for this rodw, I was clearly looking at the wrong documentation from 2.8.

In terms of net connections in HAL, is there an example somewhere that I could look at in terms of connecting the proximity sensor inputs correctly to the relevant nets?

#Is it as simple as:
net hm2_7i96.0.gpio.004.in =>  joint.0.index-enable
#and
net hm2_7i96.0.gpio.005.in =>  joint.1.index-enable
#?

..or do I need to connect to/through encoder.n.index.enable in HAL as mentioned in the documentation. What is throwing me here is that I'm not using encoder inputs on the hardware as it is only a single count per revolution and I am using regular gpio inputs. I'm assuming that the documentation is assuming encoder.n.index-enable is the hardware input. Is that right?

Actually its likely the best way to do this is with normal index operation (count cleared on index) but using firmware that supports index on the stepgens.

For homing, Index enable comes from LinuxCNC, not an external source

I think I'm with you. I'm confused a little about the index enable coming from internally though. Section 6.5 of manual has a note linuxcnc.org/docs/2.8/html/config/ini-ho...html#_home_use_index

Note: HOME_USE_INDEX requires connections in your hal file to joint.n.index-enable from the encoder.n.index-enable.

Are you saying those are both internal nets? I was of the assumption the proximity input would feed into either or both.

I get what you mean on firmware option (I think) although I'd like to understand what the nets would be to repeat the above if I can. Sometimes it's tricky to wrap my head around the internal structure of nets in this system.

(ps I know I've linked the 2.8 manual again above, but this line is the same in 2.9 but I can't seem to dig it out on the phone for some reason)

By internal I mean that index_enable is not expected to come from
and external input.

Index_enable is normally asserted by LinuxCNC's motion component, telling the low level hardware (encoder or stepgen) to wait for the hardware index pulse, then, when a index pulse is detected by the hardware, the encoder or stepgen hardware/driver clears the position, and clears index enable to signal LinuxCNCs motion component that the index has been detected (and that the position has been zeroed)

Okay. I see what you mean, thanks. So in this case above we are creating an additionl net which resets the zero position by clearing index enable from an external input, leaving internal nets as is. What you are also saying is that a more refined solution would be to do this on the firmware level by interacting with the stepgen index pos on the hardware? That sounds better but am I correct in thinking such firmware doesn't exist? I don't want anyone to have to go to that level to help out, I'm sure you guys have enough to do and I'm happy enough to get it working the simplest way. Appreciate you clearing that up pcw. So if i net my input to the joint.n.index-enable that should do the trick, albeit in not the most efficient way. Is that correct?

Hi Andy, thanks for the info. I'm coming at this from the wrong angle then clearly.

I don't have encoders per se no.

The setup is stepper driven on X and Z and on the homing it has a regular switch per axis (negative side). In addition there is a single pulse per revolution signal that is used in homing sequence only (but is triggered once per revolution regardless). Essentially, on the hardware end, it is a NPN proximity switch that is triggered once per revolution of the screw.

The idea from functional point of view is that it would move to home, trigger the regular home switch then move to the proximity/index trigger before zeroing for more accurate homing. Screw is 2.5mm per revolution.

Feral engineer in the video above implemented this successfully on his lathe (which is almost identical to my own) and the changes to the ini he has used are simple but I can't quite figure out how he connected this together in terms of HAL.

I have the proximity/index sensors working and can read the inputs in Hal Show just fine. But am a bit lost as to where to net these to in order to replicate the above (I have contacted him directly but no joy in getting a look at his HAL yet).

If I'm reading you right I need to feed into the counter to reset it. I've been digging in Halshow to see if I could figure it out but so far no joy.

If it's useful I can share my config