How it Works
Schneider Electric
Loading...
LUFP9
User Manual
118 pgs3.93 Mb0

Schneider Electric LUFP9 User Manual

User’s manual
LUFP9 Telemecanique

Gateway

DeviceNet / Modbus RTU
LUFP9
Gateway DeviceNet / Modbus RTU Page 4
3
The characteristics and operation of the products and additives presented in this document may change at any time. The description is in no way contractually binding.
4
Table of contents
1. Introduction............................................................6
1.1. Introduction to the user guide................................................. 6
1.2. Introduction to the LUFP9 Gateway ....................................... 7
1.3. Terminology............................................................................ 7
1.4. Notational Conventions .......................................................... 8
1.5. Additional Documentation ......................................................8
1.6. Introduction to the Communication “System” Architecture ..... 9
1.7. Principle Used to Configure and Operate the LUFP9 Gateway 10
2. Hardware Implementation of the LUFP9
Gateway ........................................................... 13
2.1. On Receipt ...........................................................................13
2.2. Introduction to the LUFP9 Gateway ..................................... 13
2.3. Mounting the Gateway on a DIN Rail ................................... 14
2.4. Powering the gateway .......................................................... 14
2.5. Connecting the Gateway to the Modbus Network ................ 15
2.5.1. Examples of Modbus connection topologies.................. 15
2.5.2. Pin outs .......................................................................... 17
2.5.3. Wiring recommendations for the Modbus network......... 18
2.6. Connecting the LUFP9 gateway to the DeviceNet network .19
2.7. Configuring DeviceNet Communication Features ................ 20
2.7.1. Encoding DeviceNet Speed ........................................... 20
2.7.2. Encoding the Gateway Address..................................... 21
2.7.3. Sample Gateway Configurations.................................... 21
6.8.1. Replacing a Periodic Input Data Element.......................48
6.8.2. Replacing an Output Periodic Data Element ..................49
6.8.3. Increasing the Amount of Periodic Input Data ................50
6.8.4. Increasing the amount of periodic output data ...............53
6.9. Deleting Aperiodic Parameter Data ......................................58
6.10. Changing a Modbus slave Configuration............................60
6.10.1. Changing the Name of a Modbus Slave.......................60
6.10.2. Changing the Address of a Modbus Slave ...................61
6.11. Adding and Setting Up a Modbus Command .....................62
6.11.1. With TeSys U Motor Starters........................................62
6.11.2. With a Generic Modbus Slave ......................................63
6.11.2.1. Managing Degraded Modes ...................................65
6.11.2.2. Configuring the Query ............................................66
6.11.2.3. Configuring the Response......................................69
6.11.2.4. Configuring the Content of the Query Frame .........70
6.11.2.5. Configuring the Content of the Response Frame...72
6.11.3. Adding a Special Modbus Command ...........................73
6.11.3.1. Modbus Commands Based on Standard Commands
...............................................................................73
6.11.3.2. Modbus Commands which Can Be Completely
Changed by the User.............................................74
6.12. Configuring the General Characteristics of the Gateway....75
6.12.1. “Fieldbus” element........................................................75
6.12.2. “ABC” Element..............................................................76
6.12.3. “Sub-Network” Element ................................................77
6.13. Adding a Broadcaster Node................................................79
3. Signalling ............................................................ 22
7. Appendix A: Technical Characteristics............ 80
4. Software Implementation of the Gateway........ 23
4.1. Introduction........................................................................... 23
4.1.1. System Architecture ....................................................... 23
4.1.2. Configuring the Motor Starters ....................................... 24
4.1.3. Modbus cycle time .........................................................24
4.1.4. Managing degraded modes ...........................................24
4.2. Configuring the Gateway in RsNetWorx............................... 25
4.2.1. Selecting and adding the master PLC’s DeviceNet
scanner........................................................................... 25
4.2.2. Installing the Gateway Description File.......................... 25
4.2.3. Selecting and Adding the Gateway to the DeviceNet
Network ..........................................................................26
4.2.4. Editing gateway parameters........................................... 26
4.2.5. Configuring the DeviceNet Scanner............................... 28
4.2.6. Configuring Inputs from the Gateway............................. 29
4.2.7. Configuring Outputs Intended for the Gateway.............. 30
4.2.8. Description of Services Assigned to Gateway
Inputs/Outputs ................................................................ 31
4.2.9. Transferring the DeviceNet Scanner Configuration .......32
4.2.10. Developing a DeviceNet Application............................ 32
5. Gateway Initialization and Diagnostics............ 33
5.1. Full Management.................................................................. 33
5.1.1. DeviceNet Master Command Word ...............................33
5.1.2. Gateway Status Word ....................................................35
5.2. Diagnostic only ..................................................................... 37
5.2.1. Gateway Status Word ....................................................37
5.2.2. DeviceNet Master Command Word ...............................38
5.3. Simplified Operation ............................................................. 39
6. Configuring the Gateway................................... 40
6.1. Connecting the Gateway to the Configuration PC ............... 40
6.1.1. Pin Outs .........................................................................41
6.1.2. RS-232 link protocol....................................................... 41
6.2. Installing AbcConf ................................................................42
6.3. Importing the Gateway Configuration................................... 42
6.4. Transferring a Configuration to the Gateway ......................43
6.5. Monitoring the Content of the Gateway’s Memory ............... 43
6.6. Deleting a Modbus Slave .....................................................45
6.7. Adding a Modbus Slave .......................................................46
6.8. Changing the Periodic Data Exchanged With a Modbus Slave
.............................................................................................. 48
7.1. Environment..........................................................................80
7.2. Communication Characteristics ............................................80
8. Appendix B: Default Configuration................... 83
8.1. Configuring Modbus exchanges ...........................................83
8.2. Content of the Gateway’s DPRAM Memory .........................84
8.2.1. Input Data Memory Area ................................................84
8.2.2. Output Data Memory Area..............................................85
8.2.3. Total Number of Modbus Queries and Responses ........85
9. Appendix C: Practical Example (RSLogix 500) 86
9.1. Main Program: “LAD 2 - MAIN_LUFP9” ...............................86
9.2. Controlling/Monitoring Sub-Program for a TeSys U Motor
Starter: “LAD 3 - CMD_MON” ...............................................87
9.3. Sub-Program for Reading a Parameter in all TeSys U Motor
Starters: “LAD 4 - RD_PAR”..................................................89
9.4. Sub-Program for Writing a Parameter on a Single TeSys U
Motor Starter: “LAD 5 - WR_PAR” ........................................91
9.5. Reserves relating to the RSLogix 500 example....................93
10. Appendix D: DeviceNet Objects...................... 94
10.1. Introduction to the Gateway’s DeviceNet Objects ..............94
10.2. List of the Gateway’s DeviceNet Objects............................94
10.3. Graphical Representation of the Gateway’s DeviceNet
Objects ..................................................................................95
10.4. Identity Object (class 16#01) ..............................................95
10.5. Message Router Object (class 16#02) ...............................97
10.6. DeviceNet Object (class 16#03) .........................................97
10.7. Assembly Objects (Class 16#04)........................................98
10.8. Connection Object (Class 16#05).......................................99
10.9. Acknowledge Handler Object (class 16#2B) ....................106
10.10. I/O Data Input Mapping Object (Class 16#A0) ...............108
10.11. I/O Data Output Mapping Object (Class 16#A1).............109
10.12. Diagnostic Object (Class 16#AA) ...................................110
11. Appendix E: Modbus Commands ................. 113
11.1. “Read Holding Registers” Command (16#03) ..................114
11.2. “Preset Single Register” command (16#06) .....................114
11.3. “Preset Multiple Registers” Command (16#10) ................115
11.4. Modbus Protocol Exception Responses ...........................115
5
1. Introduction
1.1. Introduction to the user guide
Chapter 1 Introduction (page 6) describes the gateway, the user guide that comes with it and the terms used in it.
Chapter 2 Hardware Implementation of the LUFP9 Gateway (page 13) gives an introduction to the gateway
and describes all the items used when setting it up, both inside (thumb wheels) and outside (cables and connectors) the gateway.
Chapter 3 Signalling (page 22) describes the six LEDs on the front of the gateway.
Chapter 4 Software Implementation of the Gateway (page 23) describes the successive steps for setting the
gateway up with its default configuration, with a PLC using DeviceNet. LUFP9 gateways are shipped pre­configured to allow you to interface a DeviceNet master with 8 predefined Modbus slaves (TeSys U motor starters).
Chapter 5 Gateway Initialization and Diagnostics (page 33) describes two registers in the gateway’s memory reserved for initializing and carrying out diagnostics on the gateway. They are only exchanged between the DeviceNet master and the gateway.
Chapter 6 Configuring the Gateway (page 40) describes how to use the “ABC-LUFP Configurator” software application, which allows you to modify or create a new configuration for the gateway and shows the various features of this software (add or remove a Modbus slave, add or change a Modbus command, etc.).
This chapter also shows the changes to be made to software implementation operations in RsNetWorx.
Appendix A: Technical Characteristics (chapter 7, page 80) describes the technical aspects of both the gateway and the DeviceNet and Modbus RTU networks it is interfaced with.
Appendix B: Default Configuration (chapter 8, page 83) describes the main features of the default configuration of the LUFP9 gateway. However, it does not go into AbcConf in detail.
Appendix C: Practical Example (RSLogix 500) (chapter 9, page 86) gives a simple example using the LUFP9 gateway’s default configuration. This example exploits the command and monitoring registers for 8 TeSys U motor starters and uses the aperiodic read and write services used to acces the value of any motor starter parameter.
Appendix D: DeviceNet Objects (chapter 10, page 94) describes both the generic DeviceNet objects and the DeviceNet objects specific to the LUFP9 gateway. The values of the attributes of these objects are also given.
Appendix E: Modbus Commands (chapter 11, page 113) describes the content of the Modbus command frames supported by the LUFP9 gateway.
6
1. Introduction
1.2. Introduction to the LUFP9 Gateway
The LUFP9 gateway allows a master located on a DeviceNet network to enter into a dialogue with the slaves on a Modbus RTU network. This is a generic protocol converter operating in a way which is transparent to the user.
This gateway allows you to interface many products marketed by Schneider Electric with a DeviceNet network. These include TeSys U motor starters, Altivar drives and Altistart soft start- soft stop units.
1.3. Terminology
Throughout this document, the term “user” refers to any person or persons who may need to handle or use the gateway.
The term “RTU”, which refers to the Modbus RTU communication protocol, will be omitted most of the time. As a result, the simple term “Modbus” will be used to refer to the Modbus RTU communication protocol.
As is still the case with all communication systems, the terms “input” and “output” are somewhat ambiguous. To avoid any confusion, we use a single convention throughout this document. So the notions of “input” and “output” are always as seen from the PLC, or the DeviceNet master / scanner.
Hence, an “output” is a command signal sent to a Modbus slave, whereas an “input” is a monitoring signal generated by this same Modbus slave.
The diagram below shows the flows of “inputs” and “outputs” exchanged between a DeviceNet master and Modbus RTU slaves via the LUFP9 gateway:
DeviceNet master
OUTPUTS
LUFP9
Gateway
INPUTS
Altistart 48
Modbus RTU Slaves
7
1. Introduction
1.4. Notational Conventions
16#•••• ..............Value expressed in hexadecimal, which is equivalent to the H••••, ••••h and 0x•••• notations,
sometimes used in other documents. N.B. The AbcConf software uses the 0x•••• notation.
E.g. 16#0100 = 0x0100 = 256.
02#•••• •••• ........Value expressed in binary. The number of ‘•’ digits depends on the size of the item of data
represented. Each nibble (group of 4 bits) is separated from the other nibbles by a space.
Examples: byte 2#0010 0111 = 39, word 2#0110 1001 1101 0001 = 16#69D1 = 27089.
AbcConf ...........Abbreviation that refers to the tool used to configure and implement the LUFP9 gateway: “ABC-
LUFP Configurator”.
ATS ..................Abbreviation of “Altistart” (soft start- soft stop unit).
ATV ..................Abbreviation of “Altivar” (drive).
CRC .................Cyclical Redundancy Check.
LED ..................Light-Emitting Diode.
EDS..................Electronic Data Sheet. Refers to the file format (“.eds” extension) which allow a tool used for
configuring and preparing DeviceNet masters to configure their exchanges using this same protocol.
Fieldbus ...........A term referring to the upstream DeviceNet network in AbcConf.
Handshake.......An old term referring to the two registers used for initializing and carrying out diagnostics of the
LUFP9 gateway. This term has been replaced by the expression “Control/Status Byte”.
LRC..................Longitudinal Redundancy Check.
Node ................A term referring to the connection point of a Modbus slave under AbcConf.
ODVA...............Open DeviceNet Vendor Association, Inc.
LSB: .................Least significant byte in a 16-bit word.
MSB: ................Most significant byte in a 16-bit word.
Sub-Network ....A term referring to the downstream Modbus network under AbcConf.
XML..................EXtensive Markup Language. The language used by AbcConf to import/export the configuration
of a Modbus slave.
1.5. Additional Documentation
In the case of Modbus slaves, the features, services and adjustment of the Modbus communications are not dealt with in this document.
8
1. Introduction
A
(
)
1.6. Introduction to the Communication “System” Architecture
DeviceNet
Master
Upstream network (DeviceNet)
Downstream
network no.1
(Modbus)
Total of 16
motor starters
(TeSys U model)
Downstream
network no.2
Modbus
ATS48
VW33-A48
VW3-G46301
Downstream network no.3 (Modbus)
TS46
9
1. Introduction
Each LUFP9 DeviceNet / Modbus RTU gateway allows a PLC on the DeviceNet network to command, control and configure up to 8 Modbus slaves. If there are more than 8 Modbus slaves, you will need to use an appropriate number of LUFP9 gateways. In the same way, if the exchanges with the Modbus slaves require more than 25 Modbus commands (that is to say more than 50 queries and responses), you will have to distribute the Modbus slaves over several gateways.
The LUFP9 gateway behaves both as a DeviceNet slave on the upstream network and as a Modbus RTU master on the downstream network.
See chapter 7.2 Communication Characteristics, page 80, if you would like to read about the technical communication characteristics of the LUFP9 gateway.
The gateway can carry out its data exchanges (inputs and outputs of all types) with the Modbus slaves cyclically, aperiodically or in an event-driven way. All of these Modbus exchanges make up the gateway’s “Modbus scanner” and we use the “ABC-LUFP Configurator” software application to configure this scanner’s exchanges. Each item of data exchanged in this way is made available to the DeviceNet master, which can gain access to it in a number of ways (cyclical, aperiodic or event-driven exchanges).
N.B. If, for example, a communication is periodic on the Modbus network, the corresponding data does not have to be exchanged periodically on the DeviceNet network and vice versa.
The diagram on the page to the left illustrates the distribution of several slaves over three downstream Modbus RTU networks, each of these networks being interfaced with the DeviceNet master PLC using an LUFP9 gateway.
1.7. Principle Used to Configure and Operate the LUFP9 Gateway
The gateway is part of a family of products (referred to as LUFPz) designed to meet generic needs for connection between two networks using different communication protocols.
The software elements common to all these gateways (a configuration tool known as “ABC-LUFP Configurator” and the on-board Modbus software) cohabit with the specific features of the network upstream of each of them (DeviceNet in the case of the LUFP9 gateway) generically. This is one of the reasons why the interfacing between the upstream network and the Modbus network is carried out entirely via the gateway’s physical memory.
Ö The exchanges between the gateway (which operates as a Modbus master) and the Modbus slaves are
wholly configured using the “ABC-LUFP Configurator”. This configuration tool goes into great detail (setting timers for exchanges, communication modes, frame content, etc.), which makes it all the more delicate to use. So a whole chapter in this guide (chapter 6 Configuring the Gateway, page 40) has been devoted to this tool.
By configuring the queries and responses for Modbus commands via this tool the user can create links between a part of the content of the corresponding Modbus frames and the content of the gateway’s physical memory (input memory for the content of the Modbus responses and output memory for the content of the queries).
Ö The exchanges between the DeviceNet master PLC and the LUFP9 gateway should be configured in such a
way that the DeviceNet master can read the input data and write the output data from the gateway, but only the data used for the Modbus exchanges (see previous point).
10
1. Introduction
A
y
)
)
y
)
)
–––––––
–
Ö Each LUFP9 gateway is shipped pre-configured so as to make it easier to operate and the factory settings
can be used as a basis for a configuration which will best meet the user’s expectations. The typical operations applicable to this default configuration are described in chapter 6 Configuring the Gateway, page 40.
The DeviceNet network is totally separate from the Modbus network. The frames on a network are not directly “translated” by the gateway to generate frames on the other network. Instead, the exchanges between the content of the gateway’s memory and the Modbus slaves make up a system which is independent of the one which is entrusted with managing the exchanges between this same memory and the DeviceNet master.
So the user must ensure that the size of the DeviceNet data corresponds to the size of the memory used for the Modbus exchanges, because the gateway configures its DeviceNet exchanges on the basis of the memory used by the Modbus frames.
The two synopses which follow illustrate the independent management of each of the two networks:
— Managing Gateway ↔ Modbus slaves exchanges —
ABC Configurator
Slave
Command A1
A1RQ
Quer
Frame
→
• • • Data (Out
Response A1AQ
Frame
→
• • • Data (In
Slave B
Command B1
B1RQ
Quer
Frame →
Response B1AQ
Frame
Slave A Slave B
• • • Data (Out
→
• • • Data (In
Configuration of Modbus exchanges by the user
• • •
• • •
• • •
• • •
Transfer of the configuration
LUFP9 gateway
0x0000
:
Input
memory
:
0x01FF
:
0x0200
:
Output
memory
:
0x03FF
Managing
exchanges with the
Modbus slaves
Modbus network
11
1. Introduction
— Managing Gateway ↔ DeviceNet master exchanges —
LUFP9 gateway
0x0000
: : : :
0x01FF
:
0x0200
: : : :
0x03FF
Management of
exchanges with the
DeviceNet master
Input
Modbus
data
Free
memory
locations
:
Output
Modbus
Data
Free
memory
locations
DeviceNet
network
Configuration of the DeviceNet exchanges for the master PLC by the user (excluding programming)
RSNetWorx
Configuration of DeviceNet exchanges :
♦ Type and address of the LUFP9 gateway
♦ Size of the input DeviceNet data
♦ Size of the output DeviceNet data
Export of the configuration
RSLogix 500
Direct transposition of the content of the gateway’s memory into programming objects:
• Input Modbus data → I:x.y Objects
• Output Modbus data → O:x.y Objects
Transfer of the configuration
DeviceNet
master PLC
12
2. Hardware Implementation of the LUFP9 Gateway
2.1. On Receipt
After opening the packaging, check that the following element is there:
• One LUFP9 DeviceNet / Modbus RTU gateway.
2.2. Introduction to the LUFP9 Gateway
The cables and other accessories for connecting to DeviceNet and Modbus networks need to be ordered separately.
f
g
h
cde
Modbus RTUConfiguration
Legend:
c Detachable power connector for the
gateway (
24V ±10%).
d Female RJ45 connector to a PC
running AbcConf configuration software.
e Female RJ45 connector for the
downstream Modbus RTU network.
f Six diagnostic LEDs.
g Removable cover for the selector
switches used to configure the gateway, shown and described in chapter 2.7 Configuring DeviceNet Communication Features, page 20. The label describing the LEDs is stuck onto this cover.
h Detachable female DeviceNet
connector.
13
2. Hardware Implementation of the LUFP9 Gateway
2.3. Mounting the Gateway on a DIN Rail
Mounting the gateway
1
2
Start by fitting the rear base of the gateway to the upper part of the rail, pushing downwards (1) to compress the gateway’s spring. Then push the gateway against the DIN rail (2) until the base of the gateway box fits onto the rail.
Dismounting the gateway
1
2
Start by pushing the gateway downwards (1) to compress the gateway’s spring. Then pull the bottom of the gateway box forwards (2) until the box comes away from the rail.
N.B. The spring is also used to earth the gateway (Protective Earth).
2.4. Powering the gateway
DeviceNet / Modbus RTU gateway – View from underneath
–
+
Power supply
24V isolated (±10%)
95 mA max.
We do not recommend powering the gateway using the 24V power voltage on the DeviceNet network. It is better to use a separate power supply, because the gateway needs to be powered using a stabilised voltage, which is not necessarily the case with the power voltage on the DeviceNet network.
N.B. The negative 24V power supply terminal earth.
should be connected to the installation’s
14
2. Hardware Implementation of the LUFP9 Gateway
2.5. Connecting the Gateway to the Modbus Network
Three typical examples of Modbus connection for the gateway and its slaves are shown below. There are many other possible Modbus connections, but they are not covered in this document.
2.5.1. Examples of Modbus connection topologies
• “Star” topology: This topology uses LU9GC03 Modbus hubs, which have 8 female RJ45 connectors. These hubs should be placed close to the Modbus slaves to which they are connected using VW3 A8 306 R•• cables. On the other hand, the nature of the cable connecting the LUFP9 gateway to one of these hubs will depend on the network architecture, so long as there is a male RJ45 connector at each end. If necessary, one or two line terminations may be directly connected to the hubs.
The connections are shown below:
LUFP9 gateway
Modbus
Modbus
VW3 A8 306 R••
Line
termination
Modbus hubs
LU9GC03
Line
termination
Towards 8 Modbus slaves
15
2. Hardware Implementation of the LUFP9 Gateway
• “Bus” topology with VW3 A8 306 TF3 drop boxes: This topology uses VW3 A8 306 TF3 drop boxes to connect each of the Modbus slaves to the main section of the Modbus network. Each box should be placed in the immediate vicinity of the Modbus slave it is associated with. The cable for the main section of the Modbus network must have male RJ45 connectors (like the VW3 A8 306 R•• cable used for the “star” topology). The lead between the drop box and the slave or the Modbus gateway is an integral part of this box. The connections are shown below:
LUFP9 gateway
Modbus
VW3 A8 306 TF3
Line
termination
Towards 2 Modbus slaves
Towards 3 Modbus slaves
Towards 3 Modbus slaves
Line
termination
16
2. Hardware Implementation of the LUFP9 Gateway
• “Bus” topology with tap boxes: This topology is similar to the previous one, except that it uses TSXSCA62 subscriber connectors and/or TSXCA50 subscriber connectors. We recommend using a VW3 A68 306 connection cable and the TSXCSA•00 Modbus cables. Connect the RJ45 connector on the VW3 A68 306 cable to the Modbus connector on the LUFP9 gateway.
The connections are shown below:
VW3 A68 306
Modbus
TSXSCA62
LUFP9 gateway
TSXCSA•00
2.5.2. Pin outs
In addition to the pin out for the connector on the gateway, the one on the VW3 A68 306 cable is also shown below, as it is the only Modbus cable which does not exclusively use RJ45 connections.
— LUFP9 connector —
Female RJ45 Male RJ45 Male 15-point SUB-D
11
2
3
D(B) 4
D(A) 5
6
7
0 V 8
———— VW3 A68 306 cable for TSXSCA62 box ————
2
3
D(B) 4 14 D(B)
D(A) 5 7 D(A)
6
7
0 V 8 15 0V
17
2. Hardware Implementation of the LUFP9 Gateway
r
r
2.5.3. Wiring recommendations for the Modbus network
• Use a shielded cable with 2 pairs of twisted conductors,
• connect the reference potentials to one another,
• maximum length of line: 1,000 metres
• maximum length of drop line / tap-off: 20 metres
• do not connect more than 9 stations to a bus (slaves and one LUFP9 gateway),
• cable routing: keep the bus away from power cables (at least 30 cm), make crossings at right angles if necessary, and connect the cable shielding to the earth on each unit,
• adapt the line at both ends using a line terminator (see diagram and VW3 A8 306 RC termination below).
D(B)
D(A)
— Line termination recommended at both ends of the line — — VW3 A8 306 RC line termination —
To make it easier to connect the units using the topologies described in chapter 2.5.1 Examples of Modbus connection topologies, page 15, various accessories are available in the Schneider Electric catalogue:
1) Hubs, drops, taps, and line terminations:
LU9GC03 hub.....................
(“star” topology)
VW3 A8 306 TF3 drop box......................
(“bus” topology with VW3 A8 306 TF3 drop boxes)
2-way TSXSCA62 subscriber connector .
(“bus” topology with branch boxes)
4
120 Ω
1 nF
5
This passive box has 8 female RJ45 connectors. Each of these connectors can be connected to a Modbus slave, to a Modbus master, to another Modbus hub, or to a line termination.
This passive box includes a short lead with a male RJ45 connecto allowing it to be connected directly to a Modbus slave, without having to use a different cable. It is fitted with 2 female RJ45 connectors for the connection of two Modbus cables of the VW3 A8 306 R•• type.
This passive box has a printed circuit fitted with screw terminals and allows the connection of 2 subscribers to the bus (2 female 15 point SUB-D connectors). It includes the line termination when the connector is located at the end. It is fitted with 2 screw terminals for the connection of two double twisted pair Modbus cables.
TSXCA50 tap box....................................
(“bus” topology with tap boxes)
VW3 A8 306 RC double termination .......
(all topologies)
18
This passive box allows a Modbus unit to be connected to a screw terminal. It includes the line termination when the connector is located at the end. It is fitted with 2 screw terminals for the connection of two double twisted pair Modbus cables.
Each of these two red passive boxes is a male RJ45 connecto 3 cm long containing an RC line termination (see diagram and illustration above). Only the abbreviation “RC” is shown on these boxes.
2. Hardware Implementation of the LUFP9 Gateway
2) Cables:
VW3 A8 306 R•• Modbus cable ...................................
(“star” topology / “bus” topology with tap boxes)
VW3 A68 306 Modbus cable........................................
(“bus” topology with tap boxes)
Shielded double twisted pair Modbus cable.................
(“bus” topology with branch boxes)
Shielded cable with a male RJ45 connector at each end.
Shielded cable with a male RJ45 connector and a male 15-point SUB-D connector. It is used to connect a Modbus subscriber (slave or master) to a TSXSCA62 or TSXCA50 box.
Bare cable (without connectors) used to make up the main section of the Modbus network. There are three items available: TSXCSA100 (100 m), TSXCSA200 (200 m), and TSXCSA500 (500 m).
2.6. Connecting the LUFP9 gateway to the DeviceNet network
If the LUFP9 gateway is physically located either end of the DeviceNet network, you will need to connect a line termination to the terminals on its DeviceNet connector.
The resistance of this line termination should be equal to 121 Ω and it should be connected between pins 2 and 4 on the gateway connector, that is to say between the CAN_L and CAN_H signals.
LUFP9
Gateway
Detachable female
connector
DeviceNet cable
Modbus
Pinouts
Pin Name Wire colour
1GNDBlack 2 CAN_L Blue 3 SHIELD None (bare wire) 4CAN_HWhite 5V+Red
19
2. Hardware Implementation of the LUFP9 Gateway
A
)
A
)
2.7. Configuring DeviceNet Communication Features
This configuration should be carried out when the gateway is powered off.
The block of selector switches allowing you to configure the DeviceNet communication functions is hidden behind the gateway cover remove this cover, all you have to do is slide the end of a small screwdriver between the top of the cover and the gateway box, then carefully remove it.
The power supply of the gateway must be turned off before opening the cover.
Once the cover has been removed, make sure that you touch neither the electrical circuits nor the electronic components.
The block of selector switches is shown in the diagram below, each switch being shown in its factory set position:
(see illustration in chapter 2.2 Introduction to the LUFP9 Gateway, page 13). To
g
Speed
2 3 4 5 6 8
1 7
ON
2.7.1. Encoding DeviceNet Speed
The gateway’s communication speed on the DeviceNet network must be identical to that of the DeviceNet master.
The factory setting is 500 kbits/s.
This speed value depends on the position of selector switches 1 and 2.
Speed
1 7
ON
ddress (Mac ID
ddress (Mac ID
2 3 4 5 6 8
A selector switch is in the 0 state when it is in the OFF position and in the 1 state when it is in the ON position.
Any change to the gateway’s communication functions will not be effective until the next time that the gateway is powered on.
Selector
switches
1 2 3 4 5 6 7 8
0 0 x x x x x x 125 kbits/s
0 1 x x x x x x 250 kbits/s
1 0 x x x x x x 500 kbits/s
1 1 x x x x x x Invalid configuration
DeviceNet speed
20
2. Hardware Implementation of the LUFP9 Gateway
(
)
A
)
A
)
2.7.2. Encoding the Gateway Address
The LUFP9 gateway is identified on the DeviceNet bus by its address (or “Mac ID”), which is between 0 and 63.
Speed
1 7
Address
2 3 4 5 6 8
Mac ID
The gateway’s DeviceNet address depends on the position of selector switches 3 to 8. It corresponds to the binary number given by the ON (1) or OFF (0) position of these 6 selector switches.
ON
Selector
switches
1 2 3 4 5 6 7 8
x x 0 0 0 0 0 0 0 x x 0 1 0 1 1 0 22 x x 1 0 1 1 0 0 44 x x 0 0 0 0 0 1 1 x x 0 1 0 1 1 1 23 x x 1 0 1 1 0 1 45 x x 0 0 0 0 1 0 2 x x 0 1 1 0 0 0 24 x x 1 0 1 1 1 0 46 x x 0 0 0 0 1 1 3 x x 0 1 1 0 0 1 25 x x 1 0 1 1 1 1 47 x x 0 0 0 1 0 0 4 x x 0 1 1 0 1 0 26 x x 1 1 0 0 0 0 48 x x 0 0 0 1 0 1 5 x x 0 1 1 0 1 1 27 x x 1 1 0 0 0 1 49 x x 0 0 0 1 1 0 6 x x 0 1 1 1 0 0 28 x x 1 1 0 0 1 0 50 x x 0 0 0 1 1 1 7 x x 0 1 1 1 0 1 29 x x 1 1 0 0 1 1 51 x x 0 0 1 0 0 0 8 x x 0 1 1 1 1 0 30 x x 1 1 0 1 0 0 52 x x 0 0 1 0 0 1 9 x x 0 1 1 1 1 1 31 x x 1 1 0 1 0 1 53 x x 0 0 1 0 1 0 10 x x 1 0 0 0 0 0 32 x x 1 1 0 1 1 0 54 x x 0 0 1 0 1 1 11 x x 1 0 0 0 0 1 33 x x 1 1 0 1 1 1 55 x x 0 0 1 1 0 0 12 x x 1 0 0 0 1 0 34 x x 1 1 1 0 0 0 56 x x 0 0 1 1 0 1 13 x x 1 0 0 0 1 1 35 x x 1 1 1 0 0 1 57 x x 0 0 1 1 1 0 14 x x 1 0 0 1 0 0 36 x x 1 1 1 0 1 0 58 x x 0 0 1 1 1 1 15 x x 1 0 0 1 0 1 37 x x 1 1 1 0 1 1 59 x x 0 1 0 0 0 0 16 x x 1 0 0 1 1 0 38 x x 1 1 1 1 0 0 60 x x 0 1 0 0 0 1 17 x x 1 0 0 1 1 1 39 x x 1 1 1 1 0 1 61 x x 0 1 0 0 1 0 18 x x 1 0 1 0 0 0 40 x x 1 1 1 1 1 0 62 x x 0 1 0 0 1 1 19 x x 1 0 1 0 0 1 41 x x 1 1 1 1 1 1 63 x x 0 1 0 1 0 0 20 x x 1 0 1 0 1 0 42 x x 0 1 0 1 0 1 21 x x 1 0 1 0 1 1 43
DeviceNet
address
Selector
switches
1 2 3 4 5 6 7 8
DeviceNet
address
Selector
switches
1 2 3 4 5 6 7 8
DeviceNet
address
2.7.3. Sample Gateway Configurations
Speed = 250 kbits/s
Address = 12
Speed
1 3 4 6
2 7 85
ddress (Mac ID
ON
Speed = 500 kbits/s
Address = 5
Speed
2 3 4 5 8
1 7
ddress (Mac ID
ON
6
21
3. Signalling
The gateway’s 6 LEDs and the descriptive label on the removable cover which hides its block of selector switches allow you to diagnose the status of the gateway:
d
c
f
e
h
g
telm
LUFP9
n
o
p
q
r
s
ETWORK STATUS
1 N
ODULE STATUS
2 M
OT USED
3 N
OT USED
4 N
ODBUS
5 M
TEWAY
6 GA
Net
Device
™
LED LED Æ Gateway state
Off: Gateway not connected to the DeviceNet bus
Green: Gateway connected to the DeviceNet bus: Connection established
Red: Fatal error on connection
n
p
r
NETWORK STATUS
NOT USED
MODBUS
to the DeviceNet bus Flashing (green): Gateway
connected to the DeviceNet bus: Connection not established
Flashing (red):Timeout in connection to the DeviceNet bus
The length of this timeout is defined by the DeviceNet master
Off: —
Off: No power
Flashing (green): No Modbus communications
Green: Modbus communications OK
Red: Loss of communication with at least one Modbus slave (1)
LED LED Æ Gateway state
Off: No power
Red: Unrecoverable failure
MODULE
o
STATUS
Green: Gateway is operational
Flashing (red): Minor fault
q
s
NOT USED
GATEWAY
Off: —
Off: No power Flashing (red/green):
Configuration absent / not valid
Use AbcConf to load a valid configuration
Green: Gateway currently being initialized and configured
Flashing (green): Gateway is in running order: Configuration OK
(1) The LED r MODBUS becomes red whenever you use incorrect values in the outputs corresponding to the queries
of the two aperiodic services designed to read/write the value of any parameter of a Modbus slave (see chapter 4.2.8 Description of Services Assigned to Gateway Inputs/Outputs, page 31). This LED will only revert to its former green state if you reuse these very same services, but with correct values. More generally, this LED becomes red, then reverts to a green state, on loss and recovery of the communications with any Modbus slave.
N.B. If the DEVICE STATUS LED s is flashing following a sequence beginning with one or more red flashes, we advise that you note down the order of this sequence and give this
information to the Schneider Electric support service.
In some cases, all you need to do is power the gateway off then back on again to solve the problem.
22
4. Software Implementation of the Gateway
y
4.1. Introduction
This chapter gives an introduction to a quick implementation of the LUFP9 gateway, using its default configuration. All LUFP9 gateways ship pre-configured.
This pre-configuration means that the user does not have to configure the LUFP9 gateway using AbcConf. This configuration is described in order to allow the gateway to be used with a configuration tool for DeviceNet master PLCs. As an example this implementation will use RsNetWorx, the PLC configuration tool marketed by Allen Bradley (e.g. SLC500).
4.1.1. System Architecture
The default configuration for an LUFP9 gateway allows it to control, monitor and configure 8 TeSys U motor starters:
DeviceNet
master PLC
(SLC500)
DeviceNet (upstream network)
Modbus
addresses
LUFP9
Gatewa
Total of 8
motor starters
(TeSys U model)
cde fghij
Modbus (downstream network)
Line
termination
Please see chapter 2 Hardware Implementation of the LUFP9 Gateway, page 13, for the hardware implementation of the default configuration.
If you are using fewer than 8 TeSys U motor starters, you will need to adapt the gateway configuration using the “ABC-LUFP Configurator” software (see chapter 6 Configuring the Gateway, page 40, and chapter 6.6 Deleting a Modbus Slave, page 45).
Connection
boxes
23
4. Software Implementation of the Gateway
4.1.2. Configuring the Motor Starters
Each motor starter should be configured as follows:
Protocol: Modbus RTU slave Start bits 1 Modbus address 1 to 8 Parity None Bitrate 19,200 bits/s Parity bit 0 Data bits 8 Stop bits 1
When using a TeSys U motor starter with a Modbus communication module (LULC031 module), the configuration parameters for the RS485 connection are automatically detected, only the Modbus address needs to be configured.
4.1.3. Modbus cycle time
The LUFP9 gateway’s default configuration sets a cycle time of 300 ms on Modbus commands for each of the 8 TeSys U motor starters.
4.1.4. Managing degraded modes
The default management for degraded modes is described below, but it takes no account of the PLC used or of the DeviceNet scanner. Please see chapter 6.11.2.1 Managing Degraded Modes, page 65, if you would like to change the way that degraded modes for one or more Modbus commands are managed.
Event
Desired behaviour
Reset
Outputs
Hold
Reset
Inputs
Hold
(1) The desired behaviour with regard to the outputs should be directly configured on each of the TeSys U motor starters.
DeviceNet PLC:
CPU stop or failure
Depending on the
configuration
of the DeviceNet
master
——
Disconnection of
the upstream
DeviceNet network
Yes
——
Depending on the configuration
of the DeviceNet master
LUFP9 gateway
Depending on the configuration of the
Failure of the
TeSys U motor starters (1)
Disconnection
of the downstream
Modbus RTU
network
Yes
——
You can also read the user manuals for your master and your DeviceNet scanner to obtain further details about how to process degraded modes.
24
4. Software Implementation of the Gateway
4.2. Configuring the Gateway in RsNetWorx
The DeviceNet master PLC must be configured so that it has access to all of the data described in chapters 8.2.1 Input Data Memory Area, page 84 et 8.2.2 Output Data Memory Area, page 85.
The following chapters describe the steps in RsNetWorx which you will need to go through so that the gateway is correctly recognised by the DeviceNet master PLC.
The DeviceNet network which is described in the following chapters only includes one master and one slave (LUFP9 gateway). So you will need to adapt the addressing of the inputs and outputs shown below (%IW and %QW) according to any other slaves on the DeviceNet network which you need to configure.
4.2.1. Selecting and adding the master PLC’s DeviceNet scanner
In RsNetWorx, select the type of scanner you have and add it to the DeviceNet network topology.
In our example, this scanner is a “1747-SDN Scanner Module (4)” and its Mac ID address is set to 00.
4.2.2. Installing the Gateway Description File
The EDS file describing the gateway must be placed on the PC’s hard disk so that RsNetWorx has access to it at all times. The best thing is to place this file in the directory which holds all of the EDS files used by RsNetWorx.
This file can be found on the CD LUF9CD1 : “LUFP9_100.eds”.
Î Once you are inside RsNetWorx, see the documentation to read how to import an EDS file. This procedure
should then be applied to the file “LUFP9_100.eds”. It uses the “EDS wizard”, which is accessible from the “Tools” menu.
The following two entries are then added to the tree structure for recognised DeviceNet products:
• DeviceNet / Category / Communication Adapter / LUFP9
• DeviceNet / Vendor / Schneider Automation / LUFP9
25
4. Software Implementation of the Gateway
4.2.3. Selecting and Adding the Gateway to the DeviceNet Network
Select “LUFP9” from the list on the left, then add it to the DeviceNet network topology.
In our example, we have assigned the Mac ID address 04 to the gateway (the configuration of the address for a gateway is described in chapter 2.7.2 Encoding the Gateway Address, page 21).
4.2.4. Editing gateway parameters
Double-click on the icon which corresponds to the gateway, in the frame on the right.
In the window which then appears, select the “Device Parameters” tab and check that the values for the parameters correspond to those for the parameters shown below. If necessary, change them (only parameters 1 to 5 are accessible to the user in write mode), then click on the “Download To Device” button to send these changes to the gateway.
26
4. Software Implementation of the Gateway
If you are in any doubt over what is displayed, click on the “Upload From Device” button, then on “Start Monitor”. The RsNetWorx application then starts to read from the gateway the values of the parameters currently displayed. Click on the “Stop Monitor” button to stop this reading process.
The most important parameters, in the case of the default gateway configuration, are parameters 1 and 2 (periodic transfers between the PLC and the gateway via a periodic connection known as “polled”), 6 and 7 (offset and size of the input data area in the gateway’s input memory), and 18 and 19 (offset and size of the output data area in the gateway‘s output memory).
If you create or change a configuration using AbcConf (see chapter 6 Configuring the Gateway, page 40), you should be aware that the values of these parameters should correspond to the configuration of the data in the gateway’s memory, as defined in AbcConf. This data corresponds to all of the bytes exchanged with the Modbus slaves via the “Data” or “Preset Data” fields in the Modbus frames.
You should only check the parameters related to “Input1” and “Output1” areas. The other parameters, related to “Input2” to “Input6” or to “Output2” to “Output6” areas, are intended for an advanced use of the gateway, and Schneider Electric refuses to accept responsability for their use. The operations needed to set the values of these parameters will not be described in the current guide.
N.B. If a connection is not used, the corresponding EDS parameters are not used by the gateway. This is the case with “Strobed” and “COS” connections (and EDS parameters nos. 3 to 5) when the default gateway configuration is used. You can then retain the initial assignment of parameters nos. 1 to 5 to the two default input and output areas (areas no. 1), because only the “Polled” connection (parameters nos. 1 and 2) will be activated by the DeviceNet master.
N.B. The value of each “offset” type parameter refers to an offset from the start of the gateway’s input data memory area or from the start of its output data memory area and not from the start of its physical memory.
27
4. Software Implementation of the Gateway
4.2.5. Configuring the DeviceNet Scanner
Double-click on the icon which corresponds to the DeviceNet scanner.
A window then appears allowing you to configure the exchanges carried out by the scanner. Select the “Scanlist” tab and add the “LUFP9” gateway to the “Scanlist” ( list, the “Edit I/O Parameters…” button becomes accessible.
> or >> buttons). After selecting the gateway from this
Click on the “Edit I/O Parameters…” button.
In the window that appears, check the “Polled:” box, then configure the size of the data received (Rx = 32 bytes) and the size of the data transmitted (Tx = 32 bytes) by the scanner.
With the LUFP9 gateway’s default configuration, these values allow you to exchange all of the data shown in chapters 8.2.1 Input Data Memory Area, page 84, et 8.2.2 Output Data Memory Area, page 85.
If you create or change a configuration using AbcConf (see chapter 6 Configuring the Gateway, page 40), the sizes of the data exchanged via one of these connections must correspond to the sizes of the “Input1” and “Output1” areas which have been assigned to it using EDS parameters nos. 1 to 5 (see previous chapter).
Please see chapter 10.8 Connection Object (Class 16#05), page 99 for further information about DeviceNet connections for the LUFP9 gateway. Please also see the documentation that came with your DeviceNet master PLC.
28
4. Software Implementation of the Gateway
4.2.6. Configuring Inputs from the Gateway
On the “Input” tab, select the “LUFP9” gateway, then click on the “AutoMap” button. RsNetWorx then automatically establishes the correspondence between the 32 data bytes (8-bit format) from the gateway and the corresponding 16 PLC inputs “I:1.1” to “I:1.16” (16-bit format).
Please check that a correspondence between all of the data from the gateway and the PLC inputs “I:1.1” to “I:1.16” has been established.
The correspondence between the contents of the gateway’s input memory (see chapter 8.2.1 Input Data Memory Area, page 84) and PLC inputs “I:1.1” to “I:1.16” is given in the following table:
Service PLC input
Managing the downstream
Modbus network
Periodic communications
—
Monitoring of
TeSys U motor starters
Aperiodic communications
—
Reading the value of a
motor starter parameter (
Aperiodic communications
—
Writing the value of a
motor starter parameter (
Aperiodic communications
(“Trigger bytes” for the responses)
RESPONSE)
RESPONSE)
I:1.1
I:1.2 I:1.3 I:1.4 I:1.5 I:1.6 I:1.7 I:1.8 I:1.9
I:1.10
I:1.11
I:1.12
I:1.13
I:1.14
I:1.15
I:1.16
Bit 0......................Bit 7 Bit 8 ...................Bit 15
LUFP9 gateway status word
(MSB Æ 16#xx••) (LSB Æ 16#••xx)
Value of the motor starter c status register Value of the motor starter d status register Value of the motor starter e status register Value of the motor starter f status register Value of the motor starter g status register Value of the motor starter h status register Value of the motor starter i status register Value of the motor starter j status register
Memory location free Slave no. (16#01-16#08)
Function number (16#03)
Value of the parameter read
(MSB Æ 16#xx••) (LSB Æ 16#••xx)
Slave no. (16#01-16#08) Function no. (16#06)
Address of the parameter written
(MSB Æ 16#xx••) (LSB Æ 16#••xx)
Value of the parameter written
(MSB Æ 16#xx••) (LSB Æ 16#••xx)
Read parameter
response counter
Description
Number of bytes
read (16#02)
Write parameter
response counter
29
4. Software Implementation of the Gateway
4.2.7. Configuring Outputs Intended for the Gateway
On the “Output” tab, select the “LUFP9” gateway, then click on the “AutoMap” button. RsNetWorx then automatically establishes the correspondence between the 32 data bytes (8-bit format) to be sent to the gateway and the corresponding 16 PLC outputs “O:1.1” to “O:1.16” (16-bit format).
Please check that a correspondence between all of the data sent to the gateway and the PLC outputs “O:1.1” to “O:1.16” has been established.
The correspondence between the contents of the gateway’s output memory (see chapter 8.2.2 Output Data Memory Area, page 85) and PLC outputs “O:1.1” to “O:1.16” is given in the following table:
Service PLC output
Managing the downstream
Modbus network
Periodic communications
—
Controlling
TeSys U motor starters
Aperiodic communications
—
Reading the value of a
motor starter parameter (Q
Aperiodic communications
—
Writing the value of a
motor starter parameter (Q
Aperiodic communications
(“Trigger bytes” for the queries)
UERY)
UERY)
O:1.1
O:1.2 O:1.3 O:1.4 O:1.5 O:1.6 O:1.7 O:1.8 O:1.9
O:1.10
O:1.11
O:1.12
O:1.13
O:1.14
O:1.15
O:1.16
Bit 0 ..................... Bit 7 Bit 8....................Bit 15
DeviceNet master command word
(MSB Æ 16#xx••) (LSB Æ 16#••xx)
Value of the motor starter c command register Value of the motor starter d command register Value of the motor starter e command register Value of the motor starter f command register Value of the motor starter g command register Value of the motor starter h command register Value of the motor starter i command register Value of the motor starter j command register
Slave no. (16#01-16#08) Function no. (16#03)
Address of the parameter to be read
(MSB Æ 16#xx••) (LSB Æ 16#••xx)
Number of parameters to be read
(MSB Æ 16#00••) (LSB Æ 16#••01)
Slave no. (16#01-16#08) Function no. (16#06)
Address of the parameter to be written
(MSB Æ 16#xx••) (LSB Æ 16#••xx)
Value of the parameter to be written
(MSB Æ 16#xx••) (LSB Æ 16#••xx)
Read parameter
query counter
Description
Write parameter
query counter
30
Loading...
+ 88 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use