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

More
08 Jul 2021 11:52 - 08 Jul 2021 15:29 #214023 by evengravy
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.
Last edit: 08 Jul 2021 15:29 by evengravy.

Please Log in or Create an account to join the conversation.

More
08 Jul 2021 12:51 #214026 by rodw
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

 
The following user(s) said Thank You: evengravy

Please Log in or Create an account to join the conversation.

More
08 Jul 2021 13:01 - 08 Jul 2021 15:31 #214029 by evengravy
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?
Last edit: 08 Jul 2021 15:31 by evengravy.

Please Log in or Create an account to join the conversation.

More
08 Jul 2021 17:08 #214037 by PCW
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
The following user(s) said Thank You: evengravy

Please Log in or Create an account to join the conversation.

More
08 Jul 2021 21:24 - 08 Jul 2021 21:26 #214049 by evengravy
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)
Last edit: 08 Jul 2021 21:26 by evengravy.

Please Log in or Create an account to join the conversation.

More
09 Jul 2021 00:15 #214054 by PCW
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)
The following user(s) said Thank You: evengravy

Please Log in or Create an account to join the conversation.

More
09 Jul 2021 09:17 #214070 by evengravy
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?

Please Log in or Create an account to join the conversation.

More
09 Jul 2021 12:58 #214092 by andypugh
The way that index homing works is:

LinuxCNC sets index-enable
The encoder counter or stepgen starts to wait for an index pulse on an index hardware pin.
When the index is seen on the input, the counter resets itself to zero, sets index-enable false, and carries on counting.
Some short time later LinuxCNC sees that index-enable has gone false, and then knows that whatever counts it sees in the counter are the current position relative to the index.

So, it does no good to connect the physical index pulse in to index-enable, that needs to go to the index pin of the counter. I haven't seen a Mesa firmware with stepgen index, so I don't know where that index pin ends up. (I am assuming that you don't have encoders?)
The following user(s) said Thank You: evengravy

Please Log in or Create an account to join the conversation.

More
09 Jul 2021 13:53 - 09 Jul 2021 14:03 #214107 by evengravy
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
Last edit: 09 Jul 2021 14:03 by evengravy.

Please Log in or Create an account to join the conversation.

More
09 Jul 2021 14:40 #214113 by andypugh
I think that you might need FeralEngineer to explain what he did.

One easy option, which might even work, would be to simply combine switch and index using "and2". But that does rather rely on the machine being able to stop inside the index pulse width.
Or, you could use "flipflop" so that the home-switch input is set when the system hits the switch, then it backs off and resets on the index for the final home position. That would not use index-enable, it is using HAL logic to manipulate the normal home-sw-in pin value.
The following user(s) said Thank You: evengravy

Please Log in or Create an account to join the conversation.

Time to create page: 0.107 seconds
Powered by Kunena Forum