External homing (in drives)?

I'm changing my 4th axis from steppers to a servo and would like to implement index homing rather than just homing to a proxy (current arrangement).  The proxy accuracy is decent, but I'd really like the repeatability of the encoder index (i.e. no fiddling with a DTI every time I want to use the 4th axis).

I don't have any encoder/index pins available on my 7i76ED, and from what I understand index pulses are usually too short for GPIO pins to catch.

My drive (Allen Bradley Ultra3000) has an internal move to sensor, home to index function. Encoders are incremental, not absolute.

Browsing the forum I see the Ethercat folks have been working through handing off all homing to the drives and LCNC 'plays dumb'.  However, this is not an Ethercat drive - everything I'm doing is bog-standard I/O.

I can see couple possibilities:

• Buy a 7i85 and run the drive's encoder passthrough to it.  LCNC controls homing exclusively. Simple, but then I'd need a 7i85...

OR...

• Connect the homing proxy to LCNC
• Connect LCNC output to drive input (programmed as "start homing")
• Connect LCNC output to drive input (programmed as "home switch")
  • This would simply be a pass-through of the signal LCNC receives
• Connect drive output ("axis homed") to LCNC input
• LCNC is configured to use 'home to sensor" strategy
  • Home axis is commanded in LCNC
  • LCNC drives the servo to the sensor and backs off like usual
  • Once LCNC is satisfied it's homed, the "is-homed" signal is transferred via a one-shot to the drive as a "start homing" signal.
• Drive goes through it's internal homing routine
  • LCNC has no idea the axis is moving as there's no position feedback.
  • Home sensor (proxy) signal is passed through to the drive
  • If the drive faults during homing LCNC sees the fault just like any other drive fault and disables everything.
  • Drive "axis homed" signal is connected to some sort of LCNC axis-enable signal (grey area, TBD)

Anyone have some thoughts on this, or a better way to let the drive take care of homing?

Thx,
R

If this is just for one channel you only need 1 high speed input to implement
stepgen homing to index. A parallel expansion I/O pin can be use for this with appropriate
firmware (and interface protection) If you have a differential index output and you are not
using the serial expansion port, that's another way to input the index signal (on the RX lines).

I really like the idea of using LCNC's onboard homing.  Yes, this is for one channel only.  Just need LCNC to catch a single index pulse.

I'm assuming by 'parallel expansion IO pin' you mean the 25p headers on my 7i76ED?  I'm using the serial interface for my 7i73, so that's not available.

What input/interface protection would be required?

Drive encoder outputs can be buffered or unbuffered.  Unbuffered are not conditioned or filtered.  Here's a snip from the manual regarding encoder outputs:

 

 

I'm assuming here that you have an Ultra3000i drive (the "i" is for indexing) since only those have the homing feature. If this is the case then IMHO this could be both better and easier to let the drive do the heavy lifting.

With the drive 'home type' set via ultraware to 'To sensor/Fwd to marker' or to 'To sensor/Back to marker', according to your hardware configuration you then need only:
- 1 homing sensor connected to the drive input 'home sensor'
- 1 switch connected to the drive input 'start homing' (no need to pass through linuxcnc)

This will take care of the whole homing procedure on the drive/motor side. This will also make the home position repeatable since this will use the index pulse as you wanted.

Now, for linuxcnc you really don't need more than the 'immediate homing' mode which require ...nothing... except a push of the home button.

To avoid to have to press the home button on the display you can connect the drive digital output "Axis homed" to an input of your 7i76 and use HAL to simulate the activation of the 'home button' of the interface.

It is possible to write a custom home component. Refer to this doc in V 2.9 linuxcnc.org/docs/2.9/html/man/man9/homecomp.9.html
Its not trivial...

I also wanted to add that for best repeatability between power up/down it is ideal that the home sensor is positioned in such a way that its triggered right in the middle between 2 index pulses. (eg half a turn before or after the index) Too close to an index pulse create a risk that the signal will be caught 1 turn too late or too soon. I'm mentioning this because I have not seen that written anywhere although I know for a fact that this is how Yamaha robot use to set their 'older' linear drive module (before they started to use absolute encoder). 

Thanks all for the feedback. I really like the idea of letting the drive do everything.

@JPL
Yes, it's a 2098-DSD-010X (indexing).  Was not aware that only the X models had home to sensor, fwd/back to marker.  Although I did find out the sercos models can have the sercos interface disabled which opens up additional IO.

Should be easy enough to adjust the motor-drive coupling to get the index pulse half a rotation from the proxy home switch trigger point.  The whole thing is based on a 50:1 harmonic drive and the proxy is triggered by a flag on the output.

@rodw - 
"nontrivial" = not going to attempt this, but thanks for the reminder.  Not a programmer; maybe some day.

@Andy - 
I don't want the A-axis homing automatically with the X/Y/Z.  I tend to leave a trunnion table on it and there may be interference or a setup on it that needs to be broken down or adjusted before 360 rotation (i.e. tall part that would smack the table at 180 degrees).  But you've prompted me to read the INI file homing section and double-check the basics...

Sanity check...

• Homing proxy only connected to drive
• Drive input "Start homing" connected to LCNC output
  • net A-HOMED <= joint.4.homed
  • net A-HOMED => hm2.something.7i76.output-nn
• INI file
  • A-axis set to immediate homing
  • HOME_SEQUENCE = (blank) so homing is not part of the X/Y/Z sequence
• Home offset, if any, is programmed in drive (Offset Move Distance in A-B speak)
• LCNC zeros the DRO/offsets when the home-A is commanded, and the drive then goes through the homing sequence.  If there's a homing error the drive faults, but LCNC doesn't know anything except fault/no-fault.

Can anyone think of a scenario - user error or hardware failure - that results in Something Very Bad happening? (Other than homing with a tall part on the trunnion, of course, but I'd deserve that one)



 

I made a custom homing component for homing Ultra 3000 drive based on the example provided in linuxcnc.I bench tested it with my drive (2098-DSD-010-SE) and using "To Sensor/Back to Marker" and it's working fine.Linuxcnc wait for the drive to finish homing before moving to the next drive.