Homing process for 5i25/7i76 with 5 axes

I'm configuring a 5i25/7i76 mesa board combo with logic power from the parallel port and 24V field power from an external supply.

I want to home at least three of five axes using a combination of home switches and encoder index pulses, such that the homing routine stops at the first index pulse after it trips the home switch.

I have seen this thread: fail-to-homing-mechanical-switch--index-pulse , but it doesn't adequately explain the process of connecting the pins. The issue here is that the 7i76 only has space for 2 encoders by default, so I need to use a field input pin as an index input.

I have successfully generated a signal to the input-02 port on TB6, but I don't know which pin to connect to in order for the homing routine to catch the signal. I had assumed that axis.0.index-enable was the right one, but there is also the index-enable pin in the encoder HAL component, and the phase-Z pin. In any case, the goal is to home 3 axes to index pulses independently.

On a side note, I'd also like to autostart the homing process - is there an easy way to get the HAL to start it when I start up the GUI from the pncconf-generated link on the desktop?

It may be possible to do what you are attempting but it has some difficulties
One is that the encoder index pulse will be very short and may be missed by
a field input that's scanned at the servo thread rate, unless you are moving very slowly.

The other difficulty is that the index enable signal is a bit complex: it is a bidirectional signal
that is set true by LinuxCNCs motion module when a index search is desired and set false by
the index detection logic when the index is detected. This logic would have to be re-created somehow
if the index signal is just a normal HAL pin. One possible solution is to use the index logic of the software encoder
component to supply this logic (leaving the other pins unconnected)

Also using field inputs will likely require level shifters for standard (5V) encoder signals

If you want to home to index in the usual sense, you probably want real index inputs
(part of the encoder logic) and the 7I76 only has one encoder input so is not really
suited for this, a 7I85S/7I84combination is more suited to step/dir/encoder combos.

If you want to home to index on a step/dir machine with encoder feedback
you will also have to set up the step/dir like a velocity mode servo with per axis
PID loops that have commanded position and encoder feedback as inputs
and stepgen velocity commands as outputs.

I'd like to use the software encoder, but I don't know what pins drive the encoder logic. I also don't know if I need to use encoder A+ and A-, or if I can take a single pulse, and call that sufficient.

A level shifter shouldn't be a problem, so that's the least of my worries as the moment. Can you indicate what pins drive the software encoder?

Many thanks for the quick reply, by the way.

to use the software encoder component just for handling the encoder enable
you only need the encoder.N.phase-Z and encoder.N.index-enable pins

(since you are only using using the index enable/index edge detect function)

Alright, so:

We have five Sanyo Denki P5 servo motors, connected to Ultra3000 drives with the sercos system off, and we're using a 5i25/7i76 combo.

The combo was purchased for a CNC rebuild, but we're actually building two systems - a CNC, and some custom manufacturing equipment. Both will use the same drives, but we haven't purchased the second set of Mesa cards yet, and the motors will be different in the manufacturing equipment. Still servos though.

We want to use the servos without needing to mess with the LinuxCNC PID loops - the Ultra3000s will take care of that. However, the homing process still needs to happen on the LinuxCNC side, meaning that we have to get the index pulse out of the Ultra3000, and back to the computer. In the CNC, that will mean 3 encoders, and in the automation, that will mean 4 encoders, with a fifth 'low accuracy' motor used to turn the part in the machine.

The drives will be using step/dir inputs, and they are homing to optical sensors (the Omron ee-sx671). We want each drive to hit the sensor (as a home switch), and then reverse to the first encoder pulse, which we will call the real home location. The Ultra3000s still use the encoders to make accurate movements, but the LinuxCNC implementation doesn't need to worry about it if it's all step/dir. I'm open to anything that will work within the bounds of what I've said thus far. I can do rudimentary HAL code through comp, I know how to mod the INI files and the custom.hal file, and I can work with the more advanced (macro-enabled) g-code implementation that LinuxCNC uses. Beyond that though, I'm only a week into LinuxCNC, so I don't have a very thorough knowledge of the specialized functions/pins that I'm guess I'll need to work with to get this working properly. Open to learning though!

Thanks again!

In order to home to the encoder index with the 7i76 you would probably be best off letting the drives home themselves. A short look at the drives manuals online seem to indicate they are capable of doing it them selves. The home switches would be wired directly to the drives, then Linuxcnc would have to send a home signal to the drive, that would start the homing sequence programed into the drive. Once the drive is finished homing it could send a "I'm homed" signal from one of it's digital outputs to Linuxcnc, which would then set that point where the drive stopped as the home position.

It's true - the drives have a built-in homing sequence. The problem is that we then need to program and synchronize 5 different drives with different homing sequences. While that might get us to a 'working product' faster, the end result will be very difficult to modify or tune. We would also then need to write our own homing logic to coordinate all five axes. If we change drives, the same problem applies. My ideal solution would be:

1. Boost the encoder signal into a digital input to get encoder info back from the drive.
2. Connect the signal to the pin of the encoder software component.
3. Rely on the built-in homing interface so that the machinist doesn't have to worry about custom homing sequences or parameters.

I've been fussing around with different variations on this process, but I have never been able to connect to the correct pin combination that will recognize the encoder pulse. There seems to be some issue surrounding the i/o bit (index-enable), and some issue surrounding the connection of the software component to the hardware pins. I'd very much appreciate any insight into this mess that any of you may have.

BTW you have 3 line driver/TTL inputs on the 7I76 if you dont use the encoder
These may avoid level shifters