Future Design MCT-MC 4.3, User Manual

Page: 148 / 186

MCT-MC
4.3
FDC MCT-MC - 148 - Appendix
A.1.6 Creating Your Own Modbus Application
Listed below are a few of the more common software packages that claim to support Modbus RTU protocol.
This list is provided as informational only. Contact the software manufacturer for more information on applying
their software.
LabView by National Instruments Wonderware by Wonderware
SpecView by SpecView Corporation
11500 N Mopac Expwy 26561 Rancho Pkwy. South 13409 53 rd Ave NW
Austin, TX 78759-3504 Lake Forest, CA 92630 Gig Harbor, WA 98332
Phone 800-683-8411 Phone 949-727-3200 Phone 253-853-3199
http://www.natinst.com http://www.wonderware.com http://www.specview.com
If you already have a software application that uses Modbus RTU, you can simply skip to the MC parameter
table in Section A.8 for the information your program requires. The rest of this section provides information on
writing a software application that uses Modbus RTU.
1. You must code messages in eight-bit bytes, with even parity, one stop bit (8, even, 1). The MC has its
parity set to even as default from the factory.
2. Negative parameter values must be written in twos' complement format. Parameters are stored in two-byte
registers accessed with read and write commands to a relative address.
3. Messages are sent in packets that must be delimited by a pause at least as long as the time it takes to send
28 bits (3.5 characters). To determine this time in seconds, divide 28 by the baud rate. In the case of the
MC communications at 9600 baud, this calculates to a minimum period of ~3ms.
In addition, the MC timeout period must be added to that in order to properly time the send and receive
messages between the host computer and multiple MC controllers on the serial link. With a default timeout
period in the MC of 135ms, it makes a total pause of 138ms minimum. Thus, after you receive a response
from an MC controller at your PC, you must wait a minimum of 138ms before sending the next command.
4. Values containing decimal points such as process values and set points, have the decimal point implied,
i.e., the data exchange can only be performed using whole numbers. Thus, the value must be scaled
appropriately in order to exchange the data correctly. For example, a setpoint of 78.4 degrees must be
sent as a value of 784 in order for the MC
to be set correctly. Likewise, a process value read from the MC
with a value of 827 is actually 82.7 degrees. Consult the parameter table for the proper format and allowable
range of each value.
5. When monitoring a process, try to keep the number of read and write commands to a minimum of 500ms
between exchanges to a single controller. Continuously reading data at a faster rate consumes an excess
amount of the controller’s processor time and does not provided any additional benefits in process
monitoring.
Handling Communication Errors
Messages with the wrong format or illegal values will receive an exception response. Messages with the wrong
CRC or timing will receive no response. It is the user’s responsibility to handle the error appropriately within
their own software and determine whether to resend the message or halt for operator intervention.
User Responsibility
Refrain from reading or writing from/to a register that does not exist or is currently disabled. Writing values to
unassigned registers could cause system instability, malfunction or failure. Care must also be taken in that the
process can not cause damage to property or injury to personnel if the wrong commands are sent due to
operator error or equipment malfunction.