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 shortcircuit 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
Figure2.2
Figure2.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 errorchecking 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
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.