Phoenix DX Series, EX Series, ES Series, DS Series Instruction Manual

PHOENIX AC DRIVE
MODBUS PROTOCOL
3 TO 3500 HP
MODBUS RTU PROTOCOL
MODBUS TCP PROTOCOL
MODBUS USD PROTOCOL
SECTION TITLE PAGE
1.0 INTRODUCTION 1-1
2.0 HARDWARE INTERFACE 2-1
2.1 RS-485 4 Wire Operation 2-1
2.2 RS-422 4 Wire Operation 2-1
2.3 RS-232 Operation 2-1
2.3.1 RS-232C-to-RS-422 Interface 2-1 Adapter
2.3.2 Direct RS-232 Wiring 2-1
2.3.3 RS-232 Isolated Communications Interface 2-2
2.4 Ethernet Operation 2-2
3.0 MODBUS RTU PROTOCOL 3-1
DESCRIPTION
3.1 Introduction Modbus Protocol 3-1
3.1.1 Transaction on Modbus Networks 3-1
3.1.2 The Query-Response Cycle 3-1
3.2 Two Serial Transmission Modes 3-1
3.2.1 RTU Mode 3-2
3.2.2 ASCII Mode 3-2
3.3 Modbus Message Framing 3-2
3.3.1 RTU Framing 3-2
3.3.2 ASCII Framing 3-3
3.3.3 How the Address Field is Handled 3-3
3.3.4 How the Function Field is Handled 3-3
3.3.5 Contents of the Data Field 3-3
3.3.6 Contents of the Error Checking Field 3-4
3.3.7 How Characters are Transmitted 3-4 Serially
3.4 Error Checking Methods 3-4
3.4.1 Parity Checking 3-4
3.4.2 CRC Checking 3-5
4.0 MODBUS TCP PROTOCOL
DESCRIPTIONS 4-1
4.1 Ethernet Frame 4-1
4.2 Modbus TCP Message Framing 4-1
4.3 Modbus TCP Header Description 4-1
4.4 Ethernet TCP Message Framing 4-2
5.0 MODBUS FUNCTION FORMATS 5-1
5.1 Field Contents in Modbus Messages 5-1
5.2 Function Codes 5-1
6.0 PHOENIX AC DRIVE FUNCTION 6-1
6.1 MODBUS USD Function Formats 6-1
6.2 MODBUS RTU Function Formats 6-3
6.3 MODBUS USD Alternate Function Format 6-4
FORMATS
TABLE OF CONTENTS i
SECTION TITLE PAGE
7.0 EXCEPTION RESPONSE 7-1
7.1 Exception Codes 7-1
8.0 CRC GENERATION 8-1
9.0 PARAMETER CONVERSION 9-1
9.1 Parameter Coding Format 9-1
9.2 Parameter to Register Address Conversion 9-1
APPENDIX PAGE
1.0 INTRODUCTION A-1
1.1 Introduction A-1
1.2 Layering A-1
2.0 NETWORK LAYER A-2
2.1 IP A-2
2.2 IP Address A-2
2.3 IP Address Classes A-3
2.4 Netmasks A-3
2.5 Subnet Address A-3
2.6 Directed Broadcast Address A-3
2.7 Limited Broadcast Address A-3
2.8 ICMP A-3
3.0 LINK LAYER A-3
3.1 ARP A-3
4.0 THE TRANSPORT LAYER A-4
4.1 UDP A-4
4.2 TCP A-4
5.0 THE APPLICATION LAYER A-4
5.1 DNS A-4
6.0 ETHERNET FRAME A-4
6.1 Ethernet Frame A-4
6.2 Encapsulation A-4
LIST OF FIGURES AND TABLES
ii
FIGURE TITLE PAGE
2.1 RS-485 4-Wire Multi Drop Hookup 2-3
2.2 RS-422 4-Wire Point-to-Point Hookup 2-3
2.3 Quasi – RS 232 Hookup 2-3
2.4 Installation of Isolated RS-422/485 Board 2-4
2.5 Installation of Removable RS-232 Isolated
Communication Interface with Cable 2-5
2.6 Installation of Isolated RS-422/485 Board 2-6
2.7 Installation of Removable USB-RS-485
Isolated Communications Interface 2-7
4.1 Ethernet Frame 4-1
4.2 Encapsulation of Modbus RTU Frame 4-1
4.3 Encapsulation of Modbus RTU Frame
In Ethernet Frame 4-2
APPENDIX FIGURES TITLE PAGE
A-1 The Four Layers of the TCP/IP Protocol Suite A-1 A-2 Two Hosts on a LAN Running TCP A-2 A-3 Various Protocols at Different Layers In the TCP/IP Protocol Suite A-2 A-4 Ethernet Frame (RFC 894) A-4 A-5 Encapsulation of Data as it goes down The Protocol Stack Page A-5

1.0 INTRODUCTION

The US DRIVES PHOENIX digital AC drive has an optional isolated enables the user to control and setup the drive using a host computer, such as an IBM compatible PC. The drive’s serial interface may be configured to support either the RS-422 or RS-485 interconnect standard. In addition, schematics shown in this document show a simple hookup that permits an RS-232 interface (this hookup does not meet EIA standards, due to noise immunity levels, but will work with most host computers). The PHOENIX Modbus USD protocol is loosely based on the MODBUS RTU Protocol and features full CRC (Cyclical Redundancy Check) protection in both directions. The Phoenix drive defaults to 9600 Baud Rate, No Parity, 8-Bit Data and 2 Stop Bits.
Using an RS-485 serial interconnect, up to 32 drives can be party-lined to permit the host computer to setup and query any one of them. With using the Ethernet Communications Card, any host computer on a network can communicate to the Phoenix AC Drives.
The PHOENIX AC drive contains an onboard database of over 282 parameters that define and describe drive setups and operating conditions. In essence, a user armed with a printout of the drive’s parameters can configure and operate the drive with a simple read and write command to the desired parameter.
For those users wishing to develop their own host computer drive control software, the following sections of this manual describe the Modbus USD, Modbus RTU, and Modbus TCP Protocols that are used.
serial communication interface that
INTRODUCTION 1-1
1-2 INTRODUCTION
END OF INTRODUCTION SECTION

2.0 HARDWARE INTERFACE

2.1 RS-485 4-Wire Operation
RS-485 and RS-422 interfaces use differential transceivers for increased noise immunity, since any noise induced in one wire will usually be induced in the other wire and thus will be canceled out at the differential receiver.
RS-485 4-Wire operation allows 32 drivers and 32 receivers to be party-lined together at distances up to 4000 feet. This allows a host computer to talk to 31 drives. The host computer has its transmitter and receiver enabled at all times. The drives always have their receivers enabled but only one drive transmitter on the party-line can be enabled at any one time.
The host computer transmits a query to a specific drive (queries have an address field that identifies the destination drive). Even though all drives on the party-line or network receive the query and decode it, only one drive will prepare and transmit a response. The destination drive enables its transmitter during its response and disables it immediately after transmission is complete. This sequencing of the drive transmitters is built into the PHOENIX drive software. The host software requires no special hand-shaking since the transmitter and receiver are enabled at all times.
There are a number of electrical supply houses that offer RS-485 interface cards for IBM-compatible PCs. US Drives has decided to only support 4-Wire RS-485 and RS-422 operation because standard MS-DOS serial device drivers may be used without modification. The proper hookup for 4-Wire RS-485 Multi-Drop between a host PC and a number of PHOENIX drives is shown in Figure 2-1.
2.2 RS-422 4-Wire Operation
RS-422 4-Wire operation is similar to RS-485 4-Wire operation except that the wiring is “point-to-point” with no other drives party-lined. This mode works at full duplex and is illustrated in Figure 2-2.
2.3 RS-232 Operation
The PHOENIX drive permits a direct RS-232 interface. It is felt, however, that the differential transmission scheme offered by the RS-422/485 standard is much more suitable for an industrial environment. Direct connection to a PC using the RS-232 scheme is not
HARDWARE INTERFACE 2-1
recommended for drives operating on the factory floor.
Those users that still wish to use a RS-232 interface have the following alternatives.
2.3.1 RS-232C-to-RS-422 Interface Adapter
Users who wish to use the PC’s RS-232C serial port can install a RS-232C-to-RS-422 converter that is readily available from a number of electrical suppliers. It need not be isolated, as the PHOENIX user serial port is already electrically isolated from the rest of the drive. These converters typically look much like a “25 pin gender changer” plug with the conversion circuits built into the plug. Power is normally supplied to the converter by an AC-DC adapter that plugs into an 110vac duplex outlet.
2.3.2 Direct RS-232 Wiring
The following “scheme” is not recommended for permanent use. By connecting the +RXD and +TXD pins to the PC RS-232 ground, a quasi-single ended RS-232 interface can be accomplished.
Normal RS-232C signals bounce between +10 volts and –10 volts (the positive rail voltage can be between the values of +3 volts and +25 volts – likewise for the negative rail). Thus, +10 volts is interpreted as a logic “0” while -10 volts is interpreted as a logic “1”. Most RS-232C receivers will detect zero volts as a logic “1” due to hysteresis effects which allows the wiring scheme shown in Figure 2-3 to work (usually!).
This direct connection generates RS-232C levels of approximately +3.7 volts to -3.7 volts. Note that the isolated RS-422/485 common on the PHOENIX control board (TB6-5) must not be grounded or it will short­circuit the +TXD line if the PC is grounded. This direct RS-232 wiring scheme, if it must be done, is most appropriate when using a laptop PC that is floating from earth ground.
2-2 HARDWARE INTERFACE
INTERNET/INTRANET
PLC PC ETHERNET
ETHERNET PATCH
NETWORK HUB
PHOENIX
PHOENIX
PHOENIX
SERIAL RS
-
485 4 WIRE
2.3.3 RS-232 Isolated Communication
Interface
Using the Removable RS-232 Isolated Communication Interface, user’s can use the PC’s RS-232C serial port. The Communication Interface isolates the PC from the Phoenix AC Drive and no external power supply is needed. This comes with D9 female connector, 10’ cable, and removable RS-232 Isolated Communication interface. Figure 2.6 shows the installation of the removable RS-232 Isolated Communication card.
2.4 Ethernet Operation
Ethernet is a local area network technology that transmits information between devices at speeds of 10 and 100 mbps. The word Ethernet refers to hardware called out in IEEE specification 802.3 and has become an increasingly popular medium for communication in industrial environments. The protocols are implementation of TCP and UDP transport used with Ethernet hardware. This allows many different applications to run over the same network and the same cables. Thus, webservers and email run on the same physical connection courtesy of TCP/IP.
The Ethernet Gateway Device is used to interface Phoenix AC Drives to Ethernet Network. The figure below shows a typical network connection of the Phoenix AC Drives using a Ethernet Gateway Device.
OR
SWITCH
CABLE
GATEWAY
DEVICE
AC
DRIVE
#1
AC
DRIVE
#2
AC
DRIVE
#2
HARDWARE INTERFACE 2-3
Figure
2.3
Figure 2.2
Figure 2.1
2-4 HARDWARE INTERFACE
Isolated Communication Card 3000-4135-1
Installation of Isolated RS-422/485 Board
(with Control Board 3000-4100 & 3000-4130)
Figure 2.4
HARDWARE INTERFACE 2-5
Removable USB/RS-485 Isolated Communications Interface with Cable
P/N: 3000-4226-USB
Installation of Removable USB-RS-485 Isolated Communications Interface with Cable
P/N: 3000-4226-USB (with Control Board 3000-4100 & 3000-4130)
Figure 2.5
2-6 HARDWARE INTERFACE
Isolated Communication Card 3000-4135
Installation of Isolated RS-422/485 Board
(with Control Board 3000-4101 & 3000-4131)
Figure 2.6
HARDWARE INTERFACE 2-7
Removable USB/RS-485 Isolated Communications Interface with Cable
P/N: 3000-4226-USB
Installation of Removable USB/RS-485 Isolated Communications Interface with Cable
P/N: 3000-4226-USB (with Control Board 3000-4101 & 3000-4131)
Figure 2.7
2-8 HARDWARE INTERFACE
E
ND OF HARDWARE INTERFACE
MODBUS RTV PROTOCAL DESCRIPTION 3- 1
3.0 MODBUS RTU PROTOCOL
DESCRIPTION
3.1 Introduction Modbus Protocol
The common language used by Phoenix AC Drives is the Modbus protocol. This protocol defines a message structure that Phoenix AC Drives will recognize and use.
The Modbus protocol provides the internal standard that the Phoenix AC Drives use for parsing messages. During communications on a Modbus network, the protocol determines how each drive will know its device address, recognize a message addressed to it, determine the kind of action to be taken, and extract any data or other information contained in the message. If a reply is required, the drive will construct the reply message and send it using Modbus protocol.
3.1.1 Transaction on Modbus Networks
Controllers communicate using a master-slave technique, in which only one device (the master) can initiate transactions (queries). The other devices (the slaves) respond by supplying the requested data to the master, or by taking the action requested in the query. Typical master devices include host processors. Typical slaves include Phoenix AC Drives.
The master can address individual slaves, or can initiate a broadcast message to all slaves. Slaves return a message (response) to queries that are addressed to them individually. Responses are not returned to broadcast queries from the master.
The Modbus protocol establishes the format for the master’s query by placing into it the device (or broadcast) address, a function code defining the requested action, any data to be sent, and an error­checking field. The slave’s response message is also constructed using Modbus protocol. It contains fields confirming the action taken, any data to be returned, and an error-checking field. If an error occurred in receipt of the message, or if the slave is unable to perform the requested action, the slave will construct an error message and send it as its response.
3.1.2 The Query-Response Cycle
Query message from master
Device Address
Function Code
Eight-Bit
Data Bytes
Error Check
Device Address
Function Code
Eight-Bit
Data Bytes
Error Check
Response message from slave
Master-Slave Query-Response Cycle
The Query
The function code in the query tells the addressed slave device what kind of action to perform. The data bytes contain any additional information that the slave will need to perform the function. For example, function code 03 will query the slave to read holding registers and respond with their contents. The data field must contain the information telling the slave which register to start at and how many registers to read. The error check field provides a method for the slave to validate the integrity of the message contents.
The Response
If the slave makes a normal response, the function code in the response is an echo of the function code in the query. The data bytes contain the data collected by the slave, such as register values or status. If an error occurs, the function code is modified to indicate that the response is an error response, and the data bytes contain a code that describes the error. The error check field allows the master to confirm that the message contents are valid.
3.2 Two Serial Transmission Modes
Devices communicate on standard Modbus networks using either of two transmission modes: ASCII or RTU. Phoenix AC drives use RTU mode, but select the serial port communication parameters (baud rate, parity mode, etc.), during configuration of each drive. The mode and serial parameters must be the same for all devices on a Modbus network.
Loading...
+ 30 hidden pages