DISTRIBUTED I/O
EN0B-0090
26
Regardless of which of these two methods is employed,
assignment requires that the modules' rotary HEX switches
be set according to the CARE terminal assignment.
Priority of Distributed I/O Module Assignments
Assignments made via an MMI always have priority over
assignments made using CARE. Thus, in the event of a con-
flict (e.g. when the Neuron ID entered using CARE differs
from the Neuron ID entered via the MMI), the assignment
carried out using the MMI will have priority.
Flashing of Distributed I/O Module Assignment
The Distributed I/O module assignment that was made in
CARE or via the controller MMI has to be saved to Flash
memory manually. When Distributed I/O module assignment
has been made during the test mode, the assignments are
saved in Flash memory automatically. These assignments
can be reused for the application after the application has
been downloaded.
Controller Reset
IMPORTANT:
Resetting a controller will erase the Distributed I/O
module assignment. After a reset, one of the
following procedures must be performed.
—
Restore the application (including the assignments) from
Flash (this is the simplest method).
—
Restore the assignments during the "start-up" sequence
(this requires somewhat more effort).
—
Download the application and re-assign the Distributed
I/O modules (this method requires the most effort).
Manual Binding
There are several cases in which it is necessary to manually
bind the NVs of the Distributed I/O modules to their
respective controller(s). This is done using a L
ON
W
ORKS
network management tool (e.g. LonMaker).
More than 16 modules per Excel 50/500
Autobinding can be used to bind the NVs of a maximum of 16
Distributed I/O modules per controller, only. If the application
requires more than 16 Distributed I/O modules per controller,
you must use CARE to allocate those additional NVs
requiring mapping with data points, and you will also have to
use a L
ON
W
ORKS
network management tool to bind the NVs
of the additional modules to the controller.
Binding of NVs of other devices to Distributed I/O modules
(Using XFL52xB Modules as 3
rd
-Party Devices)
When the NVs of other devices on the L
ON
W
ORKS
bus (other
than the host Excel 50/500 controller) require binding to
Distributed I/O modules, autobinding cannot be used. A
L
ON
W
ORKS
network management tool (e.g. LonMaker) is
required to (manually) bind all of the Distributed I/O modules'
NVs.
Double-mapping a data point
It is possible to preserve the autobinding by mapping the
data point with a second NV. However, the second NV must
then be bound (using a L
ON
W
ORKS
network management
tool) to another L
ON
W
ORKS
device. While this method
preserves autobinding, it does require one controller NV
more than if all binding is performed using a L
ON
W
ORKS
network management tool (e.g. LonMaker).
Troubleshooting (Autobinding, only)
Wiring Check
Beginning with controller firmware V2.04.x, Distributed I/O
modules can be checked out without even having an
application loaded in the controller using a special test mode
previously active only for internal I/O modules. This test
mode, accessible through the “Data Point Wiring Check”
option on the second screen of the Start-up sequence, allows
manually setting outputs and reading inputs to verify the I/O
wiring. The procedure is described in detail in the XI581/582
User Guide, EN2B-0126.
Figure 36. Distributed I/O module faceplate and LEDs.
Each Distributed I/O module has a green Power ON LED (L1)
and a red L
ON
W
ORKS
service LED (L2) at the upper left of the
faceplate. The L
ON
W
ORKS
service LED (L2) is used for
diagnosing the state of the Distributed I/O module (see
below).
Figure 37. Distributed I/O module troubleshooting
example.
If you have more than one module connected to one XSL511,
you should check the modules to the left and to the right of
the defect module (status of green power LED L1 and red
L
ON
W
ORKS
status LED L2). A module is "working" in Table 15
if L1 illuminates green and if the L
ON
W
ORKS
communication
is working.
