Application Notes

Introduction

Most servo applications use a relative (incremental) encoder as feedback for the controller and servo drive. Incremental encoders are relatively low cost, easy to use and they have high resolution. However, they do not provide any information regarding the absolute position of the system (the position of the moving parts of the machine in relation to the static parts) after power up, even though most applications require this information. A sequence of predefined motions is normally required in order to locate the system’s absolute position after power up. This sequence is generally referred to as homing. The homing phase is carried out by searching for an absolute known sensor along the mechanical travel, and updating the internal’s position accordingly. Once the absolute position has been registered in the drive, the incremental (relative) information of the encoder can be used to measure motion relative to this absolute position.

This application note describes a number of implementation methods for performing the homing sequence with Elmo’s digital drives. This Application Note focuses on the special HM[n] command that is related to this procedure, and a number of examples show how to implement it in a user program.

Homing in SimplIQ:

Configuring the Home Command HM[n]

Step 1: Configure the Home Trigger Event HM[3]The Home event can be configured to be triggered in one of the following ways:

1. Home Sensor*: HM[3] = 1..2
   Configures the homing function to be triggered on the Home sensor. This option can only be used if the Home sensor has already been defined by the IL[n] command. Note that only input 5 can be defined as the Home Sensor.
2. Encoder Index: HM[3] = 3..4
   Configures the homing function to be triggered by the Index.
3. Limit switch: HM[3] = 5..8
   Configures the homing function to be triggered by the Limit switch (RLS or FLS). This option can only be used if the Limit switch has already been defined by the IL[n] command.
4. General Purpose In: HM[3] = 9..28
   Defines one of the general purpose inputs as the Home event trigger.

For a detailed table and more information on the HM[n] command, refer to the SimplIQ Command Reference Manual which is available on Elmo’s web site.

Step 2: Configure How the PX Counter will be Changed

When the home event has been triggered, there are a number of possibilities regarding the PX position counter. The options are governed by HM[5]:

1. M[5] = 0: The PX counter will be set to a predefined constant number HM[2] (PX = HM[2]) – sets an absolute number.
2. HM[5] = 1: The PX counter will be subtracted by a constant number (PX = PX - HM[2]) – sets a relative number.
3. HM[5] = 2: The PX counter is not changed.

Step 3: Configure the Post Homing Action

Configuring the post homing action is carried out via the HM[4] parameter.
Besides capturing the value of the PX and PY counters, the homing function can be defined to initiate a Stop or to set a general purpose output when triggered.

1. HM[4] = 0: Stop motion after homing. This is only applicable in the following modes:
   1. Position mode UM = 4, UM = 5
   2. Velocity mode UM = 2
   3. Stepper mode UM = 3.
2. HM[4] = 1: Set digital output equivalent to HM[6] (OP = HM[6]).
3. HM[4] = 2: Take no action.

Step 4: Start the Homing Function HM[1]=1

Setting HM[1] will arm the homing function according to the way it was configured in Steps 1–3 above. When the event has been triggered HM[1] is cleared automatically.

Response Time Considerations

The HM[n] command response time can be divided into two cases, depending on the source of the Homing trigger and the method used by the drive to capture the position at the Homing event:
Asynchronous Homing: The main encoder position is captured by hardware immediately, when the Homing event occurs. This is when the trigger is set to Index/Reference mark, or Home sensor (0 < HM[3] < 5).
Synchronous Homing: The capture is performed by the drive’s real time software, so it is synchronized with the next position loop sampling. This is when the trigger is set to General Purpose Input, or to RLS/FLS (4 < HM[3] < 29).

When the Homing trigger is set to Index, or Home sensor, the capture is executed immediately. The only delay is the hardware interface delay, which is less than 5 µs  for the Home sensor and negligible for the Index.

Synchronous Capture (Software Based Capturing)

When the homing trigger is set to GP Input, or Limit Switch (RLS/FLS) the total delay is a combination of the following:

The capture delay is calculated according to the following formula:

where
d is the input response time delay, in milliseconds
TS is the torque controller sampling time, in microseconds
IF[N] is the input filter width, in milliseconds.

The delay, d, will affect the trigger accuracy by missing a few counts.
The maximum number of missed counts can be estimated by the formula:

where
MissCount is the number of missed counts
VX is the velocity, in counts/second.

An example of calculating the number of missed counts appears below:

When homing on digital input #1, the expected number of misses is calculated as follows:

Homing Examples

Example 1: Homing with the Home Switch and Index

The following homing algorithm may be used for this very common switch arrangement:

The position setting is taken by the index because in many applications the index is much more accurate than the Home switch. The main purpose of the Home switch is to resolve index ambiguity, as many index pulses may occur along the path of travel, especially when using rotary motors.
In normal operation the FLS and RLS serve as emergency indicators, and the motor is not expected to reach them. RLS is visited during the homing process in order to determine the direction where the Home switch can be located.
The following user program performs the homing algorithm:

Click to download the above code: [with annotations] [no annotations, compact file]

Note that this function uses MI to prevent RLS and Home from activating the AUTO_RLS and AUTO_HM routines respectively. Another possible approach would be to use IL[N] to change the functionality of the switch to GPI (general purpose input) and then home on the GPI. However, with the latter approach, the programmer must know which connector pin is programmed as RLS.
The following auxiliary functions were used with the algorithm:

Click to download the above code: [with annotations] [no annotations, compact file]

Note: These files are identical to the files that can be downloaded above, as the code for both examples is in the same file. After opening the downloaded file, scroll down to view the code in this example.

Example 2: Double Homing Corrects Backlash Offsets

This example demonstrates homing on the Home switch without using the Index. In many gear systems, the Index signal cannot be used for homing for the following reasons:

1. Motor or gear repairs may require tuning of the index position. When a motor or gear are replaced, the absolute position of the index is changed and needs to be “re-learned” in the field.
2. Backlash and gear compliance prevent accurate mapping of the motor position to the load.

In order to prevent compliance and timing errors, the position of the Home switch is captured twice, with alternating movement directions. The two captured results are averaged in order to cancel out error sources.
If PX = 10,000 is the absolute position of the middle of the Home switch, the homing formula is:
PX = (PX  - 0.5 * (PX at right home edge + PX at left home edge)) + 10,000.
The following user program executes this routine, using the auxiliary functions of the previous example:

Click to download the above code: [with annotations] [no annotations, compact file]

On-the-fly Position Counter Updates

Updating a position sensor during the homing process has no effect on motion in UM=1, 2 or 3 because these modes do not use position feedback. The effects of a position sensor update (PY in UM=4 and PX in UM=5) on the homing process depend on the mode.
In PTP motions, the remaining motion to target becomes longer or shorter (refer to the example below). If the home correction is made in a constant speed range of the PTP motion, the redesign of the motion path may be hardly visible. This mechanism enables registration and final motion corrections on-the-fly.
In jog motions, the position command is jumped according to the position feedback, so that the motion is unaffected by the position counter update.
If the software position reference generator stops or has already stopped, the software position command is corrected according to the position feedback. The motion is unaffected by the position counter update.
In PVT or PT motions, an on-the-fly position counter update may lead to an immediate high position error, and the motor may abort with an excessive position tracking error exception.
For UM=5, if the auxiliary encoder counter is modified, and the following are true:

then the software position reference will be modified so that the motion is not affected. In PTP mode, the PA parameter will change automatically to reflect the modification.

Example

A PTP motion starts with PA = PX = 0. After setting PA = 1000; BG, a motion 1000 counts long is expected. If at PX = 500 the position has been reset to zero through homing, there should be 1000 counts remaining immediately after the homing. The total length of the motion becomes 1500.