Hiperface DSL Application Note 23, communication quality monitoring

The HIPERFACE DSL technology as a digital protocol offers a single cable connection between motor and servo drive controller. By reason of the protocol robustness it is possible to route the motor feedback wires within the motor energy cable. This simplifies the motor installation and saves costs.

The great advantage of a single cable connection creates some requirements for the communication at the same time when routing the communication wires within the same environment where also the power supply wires for the motor are located.

The HDSL-system provides a lot of information about the status of the connection line conditions and the communication for the assessment of the communication quality. These data can also be used to monitor the communication conditions over the time of utilization to identify changes for preventive maintenance measures.

Within the application note 23 (communication quality monitoring) SICK provides information of the different available data. This document summarizes the various information listed within for a better overview. Furthermore recommendations will be made to assess these information for the according reaction by the drive controller system.

While in here the communication related data are described with the according drive controller reaction recommendations the document: "Application Note 15, HDSL-system_design_assessment" provides further information for a HDSL system assessment.

Beside the actual position data (and velocity data as well) the HDSL-system furthermore supplies a lot of additional information, which can be grouped into the following areas

• position data status
• safety related information
• operation condition information
• line and communication quality status information.

Depending on the actual area these data can be critical errors, warnings or information as well. They can be used to assess the received position data or judge the line status, and carry out the corresponding measures. This finally means not each of these data require an immediate stop of the application. Especially the last two groups of information can be used to monitor the HDSL-system to recognize changes over the time of utilization. The evaluation of these information can be used to schedule maintenance measures to avoid unexpected system stops. Permanent
bad line and communication conditions will finally cause position data or safety related errors, which lead to an application stop.

The following data provide information about the line and communication status and should not be used as a sole reason for an application stop:
DELAY, EDGES, RSSI, SRSSI, QM, QMLW, LINK, SYNC_LOCKED

For a better common understanding the used terms are explained here:

• (HDSL) Frame – it is one complete data package with parts for synchronizing, master request, slave answer and signal round trip delay
• Frame rate – cycle time for HDSL frame transmission
• HDSL Host (Master) IP-core – integrated within the servo drive controller
• HDSL Device (Slave) – encoder
• Cable length – short <10m, medium ~25 m, long >50m
• The wording "encoder" and "MFB" (motor feedback system) are used in here in the same meaning.

The HDSL-system can adjust itself to different connection line lengths by automatically compensating different line delays. Therefore a time period of 13 bits (1,39 μs) is reserved on master side. With internal synchronization and working margin the master expects a slave answer within 12 bit time frame. Beside some minor delays within the interface devices it is mainly for the adjustment of different cable lengths.

During start-up and after protocol reset the system measures the signal round trip delay. The result is presented as 4 bit value within the DELAY-register (0Ah) at bit4:0. Values between 0 … 9 are possible, which changes at DSL-bit-steps (106,67 ns).

This time measurement can be used as a rough estimation for the connected cable length with the assumption of an average signal propagation delay of about 5 ns/m. Please refer to the table at the DELAY-register explanation within. The value can be compared to the actual used cable length.

Values >9 indicate a violation of the HDSL protocol specification. There is a risk that the last transmitted bits conflict with the trailer of the next master message. The communication cannot be established.

• The DELAY-value can be read-out by the drive application (drive interface).
• If DELAY-values >9 are seen cable and connection need to be checked and modified accordingly.
• This information is intended to be used during system design and verification.

During start-up and after reset the HDSL-system checks the signal performance for the definition of the signal reading window and stores the result within the EDGES register (09h). During the time duration of 1 bit (106,67 ns) 8 checks are performed. As soon as the line state (voltage sign) changes within the test period exceeds a threshold the according bit within the EDGES register is set to “1”. The content at the EDGES register is kept until the next start-up/reset of the encoder.

The target shall be to have only one (short cable) to max three “1” (long cables) set at the EDGES-register.

• The EDGES-register content can be read-out by the drive application (drive interface).
• In case of 4 times or more of “1” cable and connections need to be checked and modified accordingly. Multiple “1”-settings should be contiguous; here bit 0 & bit 7 = “1” also means contiguous.
• This information is intended to be used during system design and verification.

The RSSI-value is the Received Signal Strength Indicator on Master side, moving between 0 ... 12., while SRSSI the "same" on SLAVE side, moving between 0 ... 7.

The RSSI-value is based on the same signal evaluation principle as the EDGES information. The resulting bit pattern is transferred into an integer by the help of a Boolean operation. While the content at the EDGES-register does not change until the next start-up/reset the inspection for the RSSI is done continuously at each bit of each received slave answer. The worst value is presented within the DELAY-register
(0Ah) at bit7:4; refreshed with each HDSL-frame.

The max RSSI value is 12, at very short connection lines (<3 m) it might be possible to reach13, too. The actual value depends on the cable length as well, it should be between 12 (short), 10 (medium) and 8 (long) for the different connection lengths.

Beside the actual number this value shall be stable. Oscillating numbers point to an unstable condition within the connection line. This value can be monitored. Changes over the time (oscillation and/or decreasing) indicate changes in the communication line.

The RSSI-value is part of the quality monitoring evaluation (see the Hiperface DSL implementing manual). An RSSI-value <2 decreases the QM-value by 4. In this case several contiguous low RSSI-values can trigger a protocol reset, which is initiated by a QM-value of “0”.

The SRSSI-value is the corresponding number for the received master request at the slave side. The max possible [= best] value is 7. The value is refreshed after each register read-out.

• The RSSI-value can be read-out by the drive application (drive interface).
• The SRSSI-value can be read out via short message (safe 1 interface)
• The RSSI/SRSSI-values do not represent any position validity indication.
• This information is primarily intended to be used during system design and verification.
• These values should be monitored for system changes recognition.

The HDSL-system performs various supervisions to check the communication quality. As soon as the HDSL master detects events that indicate an improvement or degradation of the quality of the data connection, these events are indicated as values higher or lower than the quality monitoring value. The QM-value is a summary of different evaluations and is stored within the QM-register 03h at bit3:0. It can increase with each valid transmitted safety frame (after 8 HDSL-frames) by 1.

The default value at system start-up is 8. The max value is 15.

If the quality monitoring value falls to "0", a forced reset of the protocol is carried out. This is indicated by the PRST error bit in online_status as well as in the ENC_ST0-register bit 0.

• The quality monitoring-value can be read-out by the drive application (drive interface).
• The QM-value does not represent any position validity indication.
• This information is primarily intended to be used during system design and verification.
• This value should be monitored for system changes recognition.

The quality monitoring low-bit indicates a QM-value <14. As soon as the QM-value drops below 14 the QMLW-bit at the online_status low byte is set to 1. An increasing number of QMLW-indications (about a fixed time base, e.g.) indicate changing/unstable conditions at the communication.

• The QMLW-bit does not represent any position validity indication.
• This information is primarily intended to be used during system design and verification.
• This value should be monitored for system changes recognition.

The LINK-bit (within the QM-register 03h, bit 7 or as digital Master IP-core output) is a protocol connection status information. The LINK-bit rises to “1” as soon as the HDSL-protocol is established. No synchronization is required therefore. It is updated with each HDSL-frame.

Two main reasons cause that the LINK-bit drops to “0”:

1. No physical connection at all, in case of a broken or not connected line or there is no power supply to the slave
2. No protocol connection due to protocol reset or the line quality degraded. As soon as the QM-value drops <14 (= QMLW = 1) the LINK-bit drops to “0”.

Case (1) will lead to a permanent drop to LINK = “0”, while at case (2) the LINK-bit can recover as soon as the error disappears/is cleared, i.e. after 1 ms in case of protocol reset.

An increasing number of LINK-bit drops (about a fixed time base, e.g.) indicates changing/unstable conditions at the communication.

• The LINK-bit does not represent any position validity indication.
• This information is primarily intended to be used during system design and verification.
• This value should be monitored for system changes recognition.

For a cyclic communication the HDSL-frame rate can be synchronized with the drive PWM switching frequency. The synchronized mode offers the possibility to adjust the HDSL-cycling to the drive controller cycling. Therefore the drive controller must supply an external sync signal to the IP-core and the number of desired HDSL protocol packages (frames) per drive cycle time needs to be entered at the SYNC_CTRL-register (01h). For detailed information and limitations please refer to Hiperface DSL integration manual.

Generally, the working synchronization is indicated by the digital IP-core output signal SYNC_LOCKED, which is set to “1”.

When the SYNC-edge is distorted more than 26 ns (e.g. sync signal jitter) it is indicated by the SYNC_LOCKED-signal, which drops to “0”. For the first time synchronization is not necessarily lost. In case of the SYNC-signal don’t recover or is missing a fixed HDSL-frame rate of around 13 μs takes place.

In case of frequent or longer lasting SYNC_LOCKED-signal drops the drive sync signal needs to be checked.

• The SYNC_LOCKED-signal status does not effect the position validity nor change any estimator_on-status.
• This information is primarily intended to be used during system design and verification.
• This signal should be monitored for system changes recognition.

The full application note is attached