![background image](http://html.mh-extra.com/html/phoenix/ds-series/ds-series_instruction-manual_1551179017.webp)
3-4
MODBUS RTV PROTOCAL DESCRIPTION
registers are to be read. If the master writes to a
group of registers in the slave (function code 10
hexadecimal), the data field specifies the starting
register, how many registers to write, the count of
data bytes to follow in the data field, and the data to
be written into the registers.
If no error occurs, the data field of a response from a
slave to a master contains the data requested. If an
error occurs, the field contains and exception code
that the master application can use to determine the
next action to be taken.
The data field can be nonexistent (of zero length) in
certain kinds of messages. For example, in a request
from a master device for a slave to respond with its
communications event log (function code 0B
hexadecimal), the slave does not require any
additional information. The function code alone
specifies the action.
3.3.6 Contents of the Error Checking
Field
RTU Mode
When RTU mode is used for character framing, the
error checking field contains a 16-bit value
implemented as two eight-bit bytes. The error check
value is the result of a Cyclical Redundancy Check
calculation performed on the message contents.
The CRC field is appended to message as the last field
in the message. When this is done, the low-order
byte of the field is appended first, followed by the
high-order byte. The CRC high-order byte is the last
byte to be sent in the message.
3.3.7 How Characters are Transmitted
Serially
With RTU character framing, the bit sequence is:
With Parity Checking
Start
1 2 3 4 5 6 7 8 Par
Stop
Start
1 2 3 4 5 6 7 8 Stop
Stop
Bit Order (RTU)
3.4 Error Checking Methods
Standard Modbus serial networks use two kinds of
error checking. Parity checking (even or odd) can be
optionally applied to each character. Frame checking
(LRC or CRC) is applied to the entire message. Both
the character check and message frame check are
generated in the master device and applied to the
message content before transmission. The slave
checks each character and the entire message frame
during receipt.
The master is configured by the used to wait for a
predetermined timeout interval before aborting the
transaction. This interval is set to be long enough for
any slave to respond normally. If the slave detects a
transmission error, the message will not be acted
upon. The slave will not construct a response to the
master. Thus the timeout will expire and allow the
master’s program to handle the error.
3.4.1 Parity Checking
Users can configure Phoenix AC drives for Even or Odd
Parity checking, or for No Parity checking. This will
determine how the parity bit will be set in each
character.
If either Even or Odd Parity is specified, the quantity
of 1 bit will be counted in the data portion of each
character (eight for RTU). The parity bit will then be
set to a 0 or 1 to result in an Even or Odd total of 1
bits. For example, these eight data bits are contained
in an RTU character frame:
1100 0101
The total quantity of 1 bits in the frame is four. If
Even Parity is used, the frame’s parity bit will be a 0,
making the total quantity of 1 bits still an even
number (four). If Odd Parity is used, the parity bit will
be a 1, making an odd quantity (five).
When the message is transmitted, the parity bit is
calculated and applied to the frame of each character.
The receiving device counts the quantity of 1 bits and
sets an error if they are not the same as configured
for that device (all devices on the Modbus network
must be configured to use the same parity check
method).
Note that Parity Checking can only detect an error if
an odd number of bits are picked up or dropped in a
character frame during transmission. For example, if
Odd Parity checking is employed, and two 1 bits are
dropped form a character containing three 1 bits, the
result is still an odd count of 1 bits.
Without Parity Checking
Summary of Contents for DS Series
Page 5: ...1 2 INTRODUCTION END OF INTRODUCTION SECTION ...
Page 8: ...HARDWARE INTERFACE 2 3 Figure 2 3 Figure 2 2 Figure 2 1 ...
Page 13: ...2 8 HARDWARE INTERFACE END OF HARDWARE INTERFACE ...
Page 19: ...3 6 MODBUS RTV PROTOCAL DESCRIPTION END OF MODBUS RTU PROTOCAL DESCRIPTION ...
Page 23: ...5 2 MODBUS FUNCTION FORMATS END OF MODBUS FUNCTION FORMATS ...
Page 29: ...6 6 PHOENIX AC DRIVE FUNCTION FORMATS END OF PHOENIX AC DRIVE FUNCTION FORMATS ...
Page 31: ...7 2 EXCEPTION RESPONSE END OF EXCEPTION RESPONSE ...
Page 37: ...9 2 PARAMETER CONVERSION END OF PARAMETER CONVERSION ...
Page 43: ...A 6 APPENDIX BASIC TCP IP DESCRIPTION THIS PAGE INTENTIONALLY LEFT BLANK ...