Date: 2021-08-17
Copyright of the European Union is effective (Copyright EU) (c) 2021 GENEREX Systems GmbH, Hamburg, Germany, All rights reserved
TEL +49(40)22692910 - EMAIL [email protected] - WEB www.generex.de (This and all other product datasheets are available for download.)
35
Modbus via RS232 and Modbus over IP
As mentioned, all devices of the CS141 family can handle MODBUS -
there are some differences how to handle Modbus queries:
While the CS141 Modbus adapter can be integrated into a bus with the RS485 interface, Modbus over IP uses a point-to-point
connection via RS232. The RS232 Modbus port is commonly used when transferring Modbus data from the UPS to another
system or monitoring software. When using Modbus over IP, no terminating resistors are necessary.
Accordingly, the hardware layout of the boards differs
CS141 Modbus
CS141 Professional
In direct comparison, the visual inspection of the CS141 Modbus can be differentiated from the CS141 professional or budget.
Both, the CS141 Modbus and the CS141 Professional, comply with RFC1628 standards. If required, the MIB can be
downloaded from www.generex.de in the download area.
Modbus function codes
The CS141 supports the following function codes:
01H
-
Read Coils
02H
-
Read Discrete Inputs
03H
-
Read Holding Registers
04H
-
Read Input Registers
05H
-
Write Single Coil
Please note a UPS must support this type of commands - the currently available function codes depend on the connected UPS.
In general, standard UPS systems provide the functions 03H and 04H. The CS141 is designed not to distinct between these two
functions.
Furthermore, the CS141 supports a query speed up to 38400 baud to allow a flexible integration into existing IT environments.
Modbus error codes
Excepted broadcast messages, where the master device sends requests to the slave device, the master expects a clear and
valid response from the slave he queried. If the answer does not match with expected specifications, the packet wil be discarded
with a corresponding error message.
There are several possible events that may occur when a slave answers to a master's request:
1.
The slave responds accordingly with a data packet that is both, correct and valid.
The master will handle it accordingly.
2.
The slave unit does not receive the request the master device sends.
This event occurs, for example, in case of a communication error. from the point of view of the master the request was
not answered. As a consequence, the master will assume an appropriate timeout incident.
3.
Master or slave will send invalid queries / answers
Such a phenomenon can occur if the termination resistors are not set up correctly: Although data is being sent, there
are clear parity, LRC, or CRC errors within the data packet. Since invalid packets are discarded, the slave will usually
ignore an invalid request without answering. However, the master's reaction will differ: In general, he will handle a
faulty slave response with a corresponding timeout message.
