1-8
LIN Installation
LIN/ALIN Installation & User Guide HA 082 429 U005 Issue 2
If you suspect that your network is malfunctioning you can refer to Chapter 4 of this hand-
book, LIN/ALIN fault-finding. This details how to pinpoint cable and connector faults, and
gives some outline guidance on tracing higher-level software problems. Some instructions
for using TDR are also given in §6.4 of Chapter 4.
§5.1 following presents a trouble-shooting and ‘fault-avoidance’ checklist that should be
observed when installing/checking LINs.
5.1 LIN installation: trouble-shooting checklist
❏ The LIN redundancy algorithm works by detecting differences between the signals on
the two LIN cables. Thus, if redundant cables are being used it is essential that both
are connected to all instruments.
❏ The LIN cabling must be carefully and correctly made with approved components and
with a 75Ω terminator fitted to each end of the cable. If terminators are not fitted, the
instruments may communicate only intermittently.
❏ Each instrument must have a unique node address on the LIN, and no address must be
set to 00 or FF (hex). If an instrument is connected to the LIN with a non-unique ad-
dress, one or other of the instruments concerned will show a permanently illuminated
Comms Fail light.
❏ After an instrument’s node address has been changed, the instrument must be powered
off and on, and if possible, all instruments on the LIN segment which ‘know’ about it
should also be reset.
❏ When a database name is changed after being run in an instrument, or a new database
with a different name is run, reset all other instruments on the LIN segment that
‘knew’ about the previous database. This allows them to forget the old database name
and associate the new name with that node.
❏ The root block name (e.g. T100 or T640 block) in a database defines the database
name and must be unique across a network. Any reference to this database from a re-
mote instrument must match the database name and node address exactly.
❏ Connections between real blocks must not be duplicated in their cached images. Do
not forget to delete duplicated connections if a database is copied and cached.
❏ Although you can connect between either real blocks or their cached images, faster
comms are achieved by connecting between the real blocks. It is also more efficient to
connect from a cached block into a real block than the other way round.
❏ Ensure that cached block types match the real block types exactly. E.g. if the real
block is a PID, ensure that the cached block is also a PID.
❏ Ensure that cached block names match the real block names exactly. This type of mis-
match is the usual cause of software alarms.
❏ Do not leave cached blocks existing without their matching real blocks, e.g. after de-
leting a database. This slows down communications as well as causing software
alarms.
Ch1 §5.1