B&B Electronics MODSCAN32 User Manual

WinTECH Software

Industrial Automation Suite of Applications

for the Windows O.S.

I. Introduction A. Purpose of this manual B. Software Distribution Method C. Basic Software License D. How to contact WinTECH Software

II. The Modbus Protocol A. Message Formatting B. Error Detection C. modbus/TCP extensions

III. Software Descriptions A. Application Overviews B. ModScan C. ModSim D. MNetSvr E. MNetMon F. Modbus Master ActiveX Control G. Modbus Slave ActiveX Control

IV. Individual Application User Manuals A. ModScan B. ModSim C. MNetSvr D. MNetMon E. Modbus Master ActiveX Control F. Modbus Slave ActiveX Control

Purpose of this manual

This manual represents a composite technical description of the applications offered by WinTECH Software to support data acquisition and manipulation using the modbus communications protocol. Topics covered

include the distribution and licensing methods utilized to market the software as well as detailed user’s

manuals for each application.

Software Distribution Method

The WinTECH Software suite of Industrial Automation products is distributed primarily via the internet. Fully-functional demo applications are available from the following Web-Site:

http://www.win-tech.com

Each software application may be downloaded for evaluation and freely distributed among potential users without cost or obligation. Each application is in some fashion time-limited, allowing free and unrestricted use for a pre-defined period of time. This is usually about 3 minutes after establishing communication with a connected modbus device. After the demo-time elapses, the software will cease to function and the application must be restarted to continue

If the software proves useful, and a user wishes to remove the time-limit from its operation, he must purchase an access code from WinTECH Software. For WinTECH Applications, this access code must be entered into the initial sign-on dialog box to register the software, (one-time only). Evaluation versions of the software are identical to commercial, (registered), versions with the exception of the access code which removes all time-limits and other registration incentives which may be included/excluded from the evaluation copy. Once registered, the software may no longer be distributed and must remain on a single machine, (PC). The user must conform to the software license included with the registration access code and protect the confidentiality of the application.

ActiveX controls are protected somewhat differently. The evaluation versions of the modbus OCX controls allow full operation in Visual Basic Design Mode for up to 30 minutes. During this time, the user may exercise a control without restriction. Upon purchase of the control, the user will receive two licensing files from WinTECH Software which removes the 30-minute restriction. ActiveX controls are licensed to be installed on one machine only to be used in a development environment. There are no additional payments or royalty fees required to include the control in a user design to be distributed, (run-time operation), in object form.

WinTECH Software License Agreement

YOU SHOULD CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE USING THE ACCESS CODES SUPPLIED HEREIN. USING THE SUPPLIED ACCESS CODES TO REGISTER A WINTECH SOFTWARE APPLICATION INDICATES YOUR ACCEPTANCE OF THESE TERMS AND CONDITIONS. IF YOU DO NOT AGREE WITH THEM, YOU SHOULD PROMPTLY RETURN THE ACCESS CODES TO WINTECH SOFTWARE WITHIN FIFTEEN DAYS OF ACQUISITION AND THE REGISTRATION LICENSE FEE PAID WILL BE REFUNDED.

WinTECH Software provides computer programs contained on diskettes and/or electronic distribution

services, (the “Applications”) and associated help files and documentation, (the “Documentation”). Each

Application requires the use of an encryption string, (the “Access Code”), to remove certain operational restrictions contained within the Application. WinTECH Software licenses the use of the Applications, Documentation and Access Codes according to the terms and conditions set forth herein. You assume responsibility for the selection of the Applications to achieve your intended results, and for the installation, use and result obtained from the Applications.

LICENSE

1. You are granted a personal, non-transferable and non-exclusive license to use one copy of the software contained with the Application on a single personal computer and to use the documentation and Access Code under the terms stated in this Agreement. Title and ownership of the Applications and Documentation remain with WinTECH Software

2. You, your employees and/or agents are required to protect the confidentiality of the Applications and Documentation. You may not distribute or otherwise make the Access Codes available to any third party.

3. You may not assign, sublicense or transfer this license and may not decompile, reverse engineer, modify, or copy the Application or Documentation for any purpose, except you may copy the Application and Access Code into machine readable or printed form for backup purposes in support of your use of the Application on a single machine.

4. The Applications, Access Codes, and Documentation are copyrighted by WinTECH Software. You agree to respect and not to remove or conceal from view any copyright, trademark, or confidentiality notices appearing on the Application or Documentation, and to reproduce any such copyright, trademark or confidentiality notices on all copies of the Application and Documentation or any portion thereof made by you as permitted hereunder.

YOU MAY NOT USE, COPY, MODIFY, OR TRANSFER THE APPLICATIONS, DOCUMENTATION, OR ACCESS CODES IN WHOLE OR IN PART, EXCEPT AS EXPRESSLY PROVIDED FOR IN THIS LICENSE.

IF YOU TRANSFER POSSESSION OF ANY COPY OF THE ACCESS CODES TO ANOTHER PARTY, YOUR LICENSE IS AUTOMATICALLY TERMINATED.

TERM

This license is effective until terminated. You may terminate it at any time by destroying the Applications, Documentation and Access Codes along with all copies in any form. It will also terminate upon conditions set forth elsewhere in this Agreement if you fail to comply with any term or condition of this Agreement. You agree upon such termination to destroy the Applications, Documentation, and Access Codes together with all copies in any form.

LIMITED WARRANTY

During the first 90 days after delivery of the Access Codes to you, as evidenced by a copy of your receipt,

invoice or other proof of purchase, (the “Warranty Period”), WinTECH Software warrants that the

Application will perform substantially in accordance with the Documentation and that the diskettes on which the Applications are furnished, (if supplied), are free from defects in materials and workmanship under normal use. EXCEPT AS PROVIDED N THIS SECTION, THE APPLICATIONS AND DOCUMENTATION ARE PROVIDED WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

SOME STATES DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS, AND YOU MAY HAVE OTHER RIGHTS WHICH VARY FROM STATE TO STATE.

LIMITATION OF REMEDIES

1. WinTECH Software shall use commercially reasonable efforts to correct any failure of the Applications of which it is given written notice by you during the Warranty Period to perform substantially in accordance with the Documentation, provided such a failure can be recreated by WinTECH Software in an unmodified version of the Application or, if WinTECH Software is unable to correct such failure you may terminate the Agreement by returning the Application, Documentation, and Access Code and the License Fee paid will be refunded.

2. WinTECH Software shall replace any diskette not meeting WinTECH Software’s “Limited

Warranty” and which is returned to WinTECH Software with a copy of your receipt, invoice, or

other proof of purchase or, if WinTECH Software is unable to deliver a replacement diskette which is free from defects in materials or workmanship, you may terminate this Agreement by returning the Application, Documentation and Access Code and the License Fee paid will be refunded.

IN NO EVENT WILL WINTECH SOFTWARE BE LIABLE TO YOU FOR ANY DAMAGES, INCLUDING ANY LOST PROFITS, LOST SAVINGS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE APPLICATIONS EVEN IF WINTECH SOFTWARE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY.

SOME STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU.

GENERAL

This Agreement will be goverened by the internal laws of the State of West Virginia.

YOU UNDERSTAND THAT YOU HAVE READ THIS AGREEMENT, UNDERSTAND IT AND AGREE TO BE BOUND BY ITS TERMS AND CONDITIONS. YOU FURTHER AGREE THAT IT IS THE COMPLETE AND EXCLUSIVE STATEMENT OF THE AGREEMENT BETWEEN YOU AND WINTECH SOFTWARE WHICH SUPERSEDES ANY PROPOSAL, PRIOR OR CONTEMPORANEOUS AGREEMENT, ORAL OR WRITTEN, AND ANY OTHER COMMUNICATIONS BETWEEN US RELATING TO THE SUBJECT MATTER OF THIS AGREEMENT.

How to contact WinTECH Software

The most expediant method for contacting WinTECH Software is via e-mail using the following addresses:

Sales support:

sales@win-tech.com

Technical support:

support@win-tech.com

WinTECH Software is located in the Eastern Time Zone of the United States and may be reached via phone or fax at the following number:

(304) 645-5966

The postal address is:

WinTECH Software

P.O. Box 907

Lewisburg, WV 24901

USA

Modbus Message Formatting

Characteristic

ASCII (7-bit)

RTU (8-bit)

Coding System

hexadecimal (uses ASCII printable characters (0-9, A-F)

8-bit binary Number of bits per character:

start bits

data bits (least significant first)

parity (optional) 1 1

(1-bit sent for even or odd parity, no bits for no parity)

stop bits

1 or 2

Error Checking

LRC (Longitudinal Redundancy Check)

CRC (Cyclical Redundancy Check)

The MODBUS protocol describes an industrial communications and distributed control system developed by Gould-Modicon to integrate PLC’s, computers, terminals, and other monitoring, sensing, and control devices. MODBUS is a Master/Slave communications protocol, whereby one device, (the Master), controls all serial activity by selectively polling one or more slave devices. The protocol provides for one master device and up to 247 slave devices on a common line. Each device is assigned an address to distinguish it from all other connected devices.

Only the master initiates a transaction. Transactions are either a query/response type, (only a single slave is address), or a broadcast/no response type, (all slaves are addressed). A transaction comprises a single query and single response frame or a single broadcast frame.

Certain characteristics of the MODBUS protocol are fixed, such as the frame format, frame sequences, handling of communications errors and exception conditions, and the functions performed.

Other characteristics are user selectable. These include a choice of transmission media, baud rate, character parity, number of stop bits, and the transmission modes, (RTU or ASCII). The user selected parameters are set, (hardwired or programmed), at each station. These parameters cannot be changed while the system is running.

Modes of Transmission

The mode of transmission is the structure of the individual units of information within a message, and the numbering system used to transmit the data. Two modes of transmission are available for use in a MODBUS system. Both modes provide the same capabilities for communicating with PLC slaves; the mode is selected depending on the equipment used as a MODBUS Master. One mode must be used per MODBUS system; mixing of modes is not allowed. The modes are ASCII (American Standard Code for Information Interchange), and RTU, (Remote Terminal Unit.) The characteristics of the two transmission modes are defined below:

ASCII printable characters are easy to view when troubleshooting and this mode is suited to computer masters programmed in a high level language, such as FORTRAN, as well as PLC masters. RTU is suited to computer masters programmed in a machine language, as well as PLC masters.

In the RTU mode, data is sent in 8-bit binary characters. In the ASCII mode, each RTU character is first divided into two 4-bit parts, (high order and low order), and then represented by the hexadecimal equivalent. The ASCII characters representing the hexadecimal characters are used to construct the

message. The ASCII mode uses twice as many characters as the RTU mode, but decoding handling the ASCII data is easier. Additionally, in the RTU mode, message characters must be transmitted in a continuous stream. In the ASCII mode, breaks of up to one second can occur between characters to allow for a relatively slower master.

Error Detection

There are two types of errors which may occur in a communications system: transmission errors and programming errors. The MODBUS system has specific methods for dealing with either type of error.

Communications errors usually consist of a changed bit or bits within a message. The most frequent cause of communications errors is noise: unwanted electrical signals in a communications channel. These signals occur because of electrical interference from machinery, damage to the communications channel, impulse noise, (spikes), etc. Communications errors are detected by character framing, a parity check, and a redundancy check.

When the character framing, parity, or redundancy checks detect a communications error, processing of the message stops. A PLC slave will not act on or respond to the message. (The same occurs if a non-existent slave address is used.)

When a communications error occurs, the message is unreliable. The PLC slave cannot know for sure if this message was intended for it. So the CPU might be answering a message which was not its message to begin with. It is essential to program the MODBUS Master to assume a communications error has occurred if there is no response in a reasonable time. The length of this time depends upon the baud rate, type of message, and scan time of the PLC slave. Once this time is determined, the master may be programmed to automatically retransmit the message.

The MODBUS system provides several levels of error checking to assure the quality of the data transmission. To detect multibit errors where the parity has not changed, the system uses redundancy checks: Cyclical Redundancy Check, (CRC), for the RTU mode and Longitudinal Redundancy Check, (LRC), for the ASCII mode.

CRC-16 Cyclic Redundancy Check

The CRC-16 error check sequence is implemented as described in the following paragraphs.

The message, (data bits only, disregarding start/stop and parity bits), is considered as one continuous binary number whose most significant bit, (MSB), is transmitted first. The message is pre-multiplied by X**16, (shifted left 16 bits), then divided by X**16 + X**15 + X**2 + 1 expressed as a binary number (11000000000000101). The integer quotient digits are ignored and the 16-bit remainder (initialized to all ones at the start to avoid the case where all zeroes being an accepted message), is appended to the message, (MSB first), as the two CRC check bytes. The resulting message including the CRC, when divided by the same polynomial (X**16 + X**15 + X**2 + 1), at the receiver will give a zero remainder if no errors have occurred. (The receiving unit recalculates the CRC and compares it to the transmitted CRC). All arithmetic is performed modulo two, (no carries). An example of the CRC-16 error check for message HEX 0207, (address 2, function 7 or a status request to slave number 2) follows:

The device used to serialize the data for transmission will send the conventional LSB or right-most bit of each character first. In generating the CRC, the first bit transmitted is defined as the MSB of the dividend.

For convenience then, and since there are no carries used in arithmetic, let’s assume while computing the

CRC that the MSB is on the right. To be consistent, the bit order of the generating polynomial must be reversed. The MSB of the polynomial is dropped since it affects only the quotient and not the remainder. This yields 1010 0000 0000 0001, (HEX A001).. Note that this reversal of the bit order will have no effect whatever on the interpretation or the bit order of characters external to the CRC calculations.

The step by step procedure to form the CRC-16 is as follows:

16-BIT REGISTER

MSB

Flag

(Exclusive OR)

1111

0000

0010

1111

1101

Shift 1

0111

1111

1110

Polynomial

1010

0000

0001

1101

1111

Shift 2

0110

1111

Polynomial

1010

0000

0001

1100

1111

1110

Shift 3

0110

0111

1111

Shift 4

0011

1111

Polynomial

1010

0000

0001

1001

0011

1111

1110

Shift 5

0100

1001

1111

Shift 6

0010

0100

1111

Polynomial

1010

0000

0001

1000

0100

1111

1110

Shift 7

0100

0010

0111

1111

Shift 8

0010

0001

0011

1111

Polynomial

1010

0000

0001

1000

0001

0011

1110

0000

0111

1000

0001

0011

1001

1. Load a 16-bit register with all 1’s.

2. Exclusive OR the first 8-bit byte with the high order byte of the 16-bit register, putting the result in the 16-bit register.

3. Shift the 16-bit register one bit to the right.

4a. If the bit shifted out to the right is one, exclusive OR the generating polynomial 1010 0000 0000 0001 with the 16-bit register.

4b. If the bit shifted out to the right is zero; return to step 3.

5. Repeat steps 3 and 4 until 8 shifts have been performed.

6. Exclusive OR the next 8-bit byte with the 16-bit register.

7. Repeat step 3 through 6 until all bytes of the message have been exclusive OR’rd with the 16-bit register and shifted 8 times.

8. The contents of the 16-bit register are the 2 byte CRC error check and is added to the message most significant bits first.

Shift 1

0100

0000

1001

1100

Polynomial

1010

0000

0001

1110

0000

1001

1101

Shift 2

0111

0000

0100

1110

Polynomial

1010

0000

0001

1101

0000

0010

1111

Shift 3

0110

1000

0010

0111

Polynommial

1010

0000

0001

1100

1000

0010

0110

Shift 4

0110

0100

0001

0011

Shift 5

0011

0010

0000

1001

Polynomial

1010

0000

0001

1001

0010

0000

1000

Shift 6

0100

1001

0000

0100

Shift 7

0010

0100

1000

0010

Shift 8

0001

0010

0100

0001

HEX 12

HEX 41

TRANSMITTED MESSAGE WITH CRC-16

(MESSAGE SHIFTED TO RIGHT TO TRANSMIT)

12 41 07 02

0001 0010 0100 0001 0000 0111 0000 0010

LRC (Longitudinal Redundancy Check)

Address

02 0000 0010

Function

01 0000 0001

Start Add H.O.

00 0000 0000

Start Add L.O.

00 0000 0000

Quantity of Pts

00 0000 0000

08 0000 1000

Sum

0000 1011

1’s complement

1111 0100

0000 0001

Error Check

2’s complement

1111 0101

The error check sequence for the ASCII mode is LRC. The error check is an 8-bit binary number represented and transmitted as two ASCII hexadecimal (hex) characters. The error check is produced by

converting the hex characters to binary, adding the binary characters without wraparound carry, and two’s

complementing the result. At the received end the LRC is recalculated and compared to the sent LRC. The colon, CR, LF, and any imbedded non-ASCII hex characters are ignored in calculating the LRC.

MODBUS Message Types

BEGIN FRAME

ADDRESS

FUNCTION

DATA

ERROR CHECK

EOF

READY TO RECEIVE

2-CHAR 16BIT

2-CHAR 16BITS

N X 4-CHAR N X 16-BITS

2-CHAR 16-BITS

T1,T2,T3

ADDRESS

FUNCTION

DATA

CHECK

T1,T2,T3

8-BITS

N X 8-BITS

16-BITS

ASCII Framing

Framing in ASCII Transmission mode is accomplished by the use of the unique colon, (:), character to indicate the beginning of frame and carriage return/line feed, (CRLF), to delineate end of frame. The line feed character also serves as a synchronizing character which indicates that the transmitting station is ready to receive an immediate reply.

RTU Framing

Frame synchronization can be maintained in RTU transmission mode only by simulating a synchronous message. The receiving device monitors the elapsed time between receipt of characters. If three and onehalf character times elapse without a new character or completion of the frame, then the device flushes the frame and assumes that the next byte received will be an address.

Address Field

The address field immediately follows the beginning of frame and consists of 8-bits, (RTU), or 2 characters, (ASCII). These bits indicate the user assigned address of the slave device that is to receive the message sent by the attached master.

Each slave must be assigned a unique address and only the addressed slave will respond to a query that contains its address. When the slave sends a response, the slave address informs the master which slave is communicating. In a broadcast message, an address of 0 is used. All slaves interpret this as an instruction to read and take action on the message, but not to issue a response message.

Function Field

CODE

MEANING

ACTION

READ COIL STATUS

Obtains current status, (ON/OFF), of a group of logic coils.

READ INPUT STATUS

Obtains current status, (ON/OFF), of a group of discrete inputs.

READ HOLDING REGISTER

Obtains current binary value in one or more holding registers.

READ INPUT REGISTER

Obtains current binary value in one or more input registers.

FORCE SINGLE COIL

Force logic coil to a state of ON or OFF.

PRESET SINGLE REGISTER

Place a specific binary value into a holding register.

WRITE MULTIPLE COILS

Force a group of logic coils to a defined state.

PRESET MULTIPLE REGISTERS

Place specific binary values into a group of holding registers.

The Function Code field tells the addressed slave what function to perform. MODBUS function codes are specifically designed for interacting with a PLC on the MODBUS industrial communications system. The high order bit in this field is set by the slave device to indicate an exception condition in the response message. If no exceptions exist, the high-order bit is maintained as zero in the response message.

The following table lists those functions supported by various WinTECH Software Applications:

Data Field

The data field contains information needed by the slave to perform the specific function or it contains data collected by the slave in response to a query. This information may be values, address references, or limits. For example, the function code tells the slave to read a holding register, and the data field is needed to indicate which register to start at and how many to read. The imbedded address and data information varies with the type and capacity of the PLC associated with the slave.

Error Check Field

This field allows the master and slave devices to check a message for errors in transmission. Sometimes, because of electrical noise or other interference, a message may be changed slightly while its on its way from one device to another. The error checking assures hat the slave or master does not react to messages that have changed during transmission. This increases the safety and the efficiency of the MODBUS system.

The error check field uses a Longitudinal Redundancy Check, (LRC), in the ASCII mode of transmission, and a CRC-16 check in the RTU mode.

Exception Responses

CODE

NAME

MEANING

ILLEGAL FUNCTION

The message function received is not an allowable action for the addressed slave.

ILLEGAL DATA ADDRESS

The address referenced in the data field is not an allowable address for the addressed slave device.

ILLEGAL DATA VALUE

The value referenced in the data field is not allowable in the addressed slave location.

FAILURE IN ASSOCIATED DEVICE

The slave’s PC has failed to respond to a message or an

abortive error occurred.

ACKNOWLEDGE

The slave PLC has accepted and is processing the long duration program command.

BUSY, REJECTED MESSAGE

The message was received without error, but the PLC is engaged in processing a long duration program command.

NAK-NEGATIVE ACKNOWLEDGMENT

The PROGRAM function just requested could not be performed.

Programming or operation errors are those involving illegal data in a message, no response from the PLC to its interface unit, or difficulty in communicating with a slave. These errors result in an exception response from either the master computer software or the PLC slave, depending on the type of error. The exception response codes are listed below. When a PLC slave detects one of these errors, it sends a response message to the master consisting of the slave address, function code, error code, and error check fields. To indicate that the response is a notification of an error, the high-order bit of the function code is set to one.

READ OUTPUT STATUS (FUNCTION CODE 01)

ADDR

FUNC

DATA START PT HO

DATA START PT LO

DATA # OF PTS HO

DATA # OF PTS LO

ERROR CHECK FIELD

ADDR

FUNC

BYTE COUNT

DATA COIL STATUS 20-27

DATA COIL STATUS 28-35

DATA COIL STATUS 36-43

DATA COIL STATUS 44-51

DATA COIL STATUS 52-56

ERROR CHECK FIELD

This function allows the user to obtain the ON/OFF status of logic coils used to control discrete outputs from the addressed slave only. Broadcast mode is not supported with this function code. In addition to the slave address and function fields, the message requires that the information field contain the initial coil address to be read, (Starting Address), and the number of locations that will be interrogated to obtain status data.

The addressing allows up to 2000 coils to be obtained at each request; however, the specific slave device may have restrictions that lower the maximum quantity. The coils are numbered from zero; (coil number 1 is address 0000, coil number 2 is address 0001, etc.)

The following is an example of a message to Read Output Status Coils 20-56 from slave device number 17.

An example response to Read Output Status is shown below. The data is packed one bit for each coil. The response includes the slave address, function code, quantity of data characters, and error checking. Data will be packed with one bit with one bit for each coil, (1 = ON, 0 = OFF). The low order bit of the first character contains the addressed coil, and the remainder follow. For coil quantities that are not even multiples of eight, the last characters will be filled in with zeroes at the high end. The quantity of data characters is always specified as the quantity of RTU characters, i.e., the number is the same whether RTU or ASCII is used.

The status of coils 20-27 is shown as CD(HEX) = 1100 1101(Binary). Reading left to right, this shows that coils 27,26,23,22, and 20 are all on. The other coil data bytes are decoded similarly.

READ INPUT STATUS (FUNCTION CODE 02)

ADDR

FUNC

DATA START PT HO

DATA START PT LO

DATA # OF PTS HO

DATA # OF PTS LO

ERROR CHECK FIELD

ADDR

FUNC

BYTE COUNT

DATA DISCRETE INPUT 10197-10204

DATA DISCRETE INPUT 10205-10212

DATA DISCRETE INPUT 10213-10218

ERROR CHECK FIELD 11

LRC

This function allows the user to obtain the ON/OFF status of discrete inputs in the addressed slave. Broadcast mode is not supported. In addition to the slave address and function code fields, this message requires that the information field contain the initial input address to be read, (Starting Address) and the number of locations that will be interrogated to obtain the status data.

The following is an example of a message to Read Input Status Coils 10197-10218 from slave device number 17.

An example response to Read Input Status is shown below. The data is packed one bit for each coil. The response includes the slave address, function code, quantity of data characters, and error checking. Data will be packed with one bit with one bit for each coil, (1 = ON, 0 = OFF). The low order bit of the first character contains the addressed coil, and the remainder follow. For coil quantities that are not even multiples of eight, the last characters will be filled in with zeroes at the high end. The quantity of data characters is always specified as the quantity of RTU characters, i.e., the number is the same whether RTU or ASCII is used.

The status of inputs 10197-10204 is shown as AC (HEX) = 1010 1100 (Binary). Reading left to right, this shows that inputs 10204, 10202, 10200 and 10099 are all on. The other input data bytes are decoded similarly.

READ OUTPUT REGISTERS (FUNCTION CODE 03)

ADDR

FUNC

DATA START PT HO

DATA START PT LO

DATA # OF REGS HO

DATA # OF REGS LO

ERROR CHECK FIELD

ADDR

FUNC

BYTE COUNT

DATA OUTPUT REG H.O. 40108

DATA OUTPUT REG L.O. 40108

DATA OUTPUT REG H.O. 40109

DATA OUTPUT REG L.O. 40109

DATA OUTPUT REG H.O. 40110

DATA OUTPUT REG L.O. 40110

ERROR CHECK FIELD

Read Output Registers allows the user to obtain the binary contents of holding registers in the addressed slave.

These registers can store the numerical values of associated timers and counters which can be driven to external devices.

The addressing allows up to 125 registers to be obtained at each request; however, the specified slave device may have restrictions that lower this maximum quantity. The registers are numbered from zero, broadcast mode is not allowed.

The following example reads registers 40108 through 40110 from slave number 17.

The addresses slave responds with its address and the function code, followed by the information field. The information field contains 2 bytes describing the quantity of data bytes to be returned. The contents of the registers requested (DATA), are two bytes each, with the binary content right justified within each pair of characters. The first byte includes the high order bits and the second, low order bits.

In the example below, the registers 40108-40110 have the decimal contents 555, 0, and 100 respectively.

READ INPUT REGISTERS (FUNCTION CODE 04)

ADDR

FUNC

DATA START PT HO

DATA START PT LO

DATA # OF REGS HO

DATA # OF REGS LO

ERROR CHECK FIELD

ADDR

FUNC

BYTE COUNT

DATA INPUT REG HO 30009

DATA INPUT REG LO 30009

ERROR CHECK FIELD 11

Function Code 04 obtains the contents of the controllers input registers. These locations receive their vales from devices connected to the I/O structure and can only be referenced, not altered from within the controller nor via MODBUS.

The example below requests the contents of register 30009 in slave number 17.

In the response message, the contents of register 30009 is decimal value 0.

FORCE SINGLE COIL (FUNCTION CODE 05)

ADDR

FUNC

DATA COIL HO

DATA COIL LO

DATA # ON/OFF

DATA

ERROR CHECK FIELD

ADDR

FUNC

DATA COIL HO

DATA COIL LO

DATA # ON/OFF

DATA

ERROR CHECK FIELD

This message forces a single coil either On of OFF. Any coil that exists within the controller can be forced to either state, (ON or OFF). Coils are numbered from zero (i.e. coil 1 is address 0000, coil 2 is address 0001, etc.). The data value 65,280, (FF00 HEX) will set the coil ON and the value zero will turn it off. All other values are illegal and will not effect the coil. The use of slave address 00, (Broadcast mode), will force all attached slaves to modify the desired coil.

The example below requests slave number 17 to turn coil number 0173 ON.

The normal response to the command request is to retransmit the message as received, after the coil state has been altered.

PRESET SINGLE REGISTER (FUNCTION CODE 06)

ADDR

FUNC

DATA REG HO

DATA REG LO

DATA VALUE HO

DATA VALUE LO

ERROR CHECK FIELD

ADDR

FUNC

DATA REG HO

DATA REG LO

DATA VALUE HO

DATA VALUE LO

ERROR CHECK FIELD

Function 06 allows the user to modify the contents of a holding register. Any holding register that exists within the controller can have its contents changed by this message. The values are provided in binary up to the maximum capacity of the controller. Unused high-order bits must be set to zero. When used with slave address 00, all slave controllers will load the specified register with the contents specified.

The normal response to a preset single register request is to retransmit the query message after the register has been altered.

FORCE MULTIPLE COILS (FUNCTION CODE 15)

ADDR

FUNC H.O. ADDR

L.O. ADDR

QUANTITY

BYTE CNT

DATA COIL STATUS

ERROR CHECK FIELD

ADDR

FUNC

H.O. ADDR

L.O. ADDR

QUANTITY

ERROR CHECK FIELD

Function 15 allows the user to modify the contents of a group of consecutively addressed coils. The following example forces 10 coils starting at address 20, (13 HEX). The two data fields, CD = 1100 1101 and 00 = 0000 0000, indicate that coils 27, 26, 23, 22 and 20 are to be forced on.

The normal response to a FORCE MULTIPLE COILS request is to echo the slave address, function code, starting address, and quantity of coils set.

PRESET MULTIPLE REGISTERS (FUNCTION CODE 16)

ADDR

FUNC H.O. ADDR

L.O. ADDR

QUANTITY

BYTE CNT

H.O. DATA

L.O. DATA

etc.

ERROR CHECK FIELD

0A ??

ADDR

FUNC

H.O. ADDR

L.O. ADDR

QUANTITY

ERROR CHECK FIELD

Holding registers existing within the controller can have their contents changed via function code 16. Sixteen bits of data for each register is contained within the message.

The normal response to a PRESET MULTIPLE REGISTERS request is to echo the slave address, function code, starting address, and quantity of registers set.

modbus/TCP Extensions

The Modbus Applications Programming Interface for Network Communications, (MBAP), was developed by Modicon to allow traditional serial modbus communiactions to occur over a TCP/IP network. It

basically defines a “wrapper” around the modbus protocol to accomidate routing data packets between two

network nodes. The same master/slave messaging protocol is used, however the network aspect allows multiple master devices to access data from the same or different slave devices connected to the network. Using the Client/Server approach, a modbus/TCP slave device represents the server side of the communications model, accepting and responding to queires from one or more network client master applications.

WinTECH Software Application Overviews

The WinTECH Software suite of applications for Industrial Automation was designed to provide a costeffective solution to interface data from modbus devices into the PC Windows environment. Without the overhead associated with a full featured MMI, these products provide an easy to use interface to remote devices. Primarily used for simulation and verification of the protocol, WinTECH Software applications

are inexpensive tools which should be included in every test and commissioning engineer’s arsenal. In

addition, these tools support Windows OLE, which allows quick development of testing applications via Visual Basic for customizing operation, (such as the case for production testing).

Each application supports physical connections to modbus devices via direct serial, modem, or TCP/IP network. Standard Win32 drivers are used through-out the designs, allowing for their efficient operation on Windows 95/98 as well as Windows NT.

ModScan

ModScan is a modbus master application, designed to read data from one or more connected slave devices. The original 16-bit version of the application supports both RTU and ASCII transmission modes and allows register data to be displayed in a variety of formats including decimal, hexadecimal, and floating-point notation. ModScan also supports custom, (user generated), modbus commands and provides a scripting facility for automated testing of modbus slave devices.

ModScan32 is an upgraded version of ModScan which takes full advantage of the Win32 platform. ModScan32 is a multi-document design, allowing you to open and actively scan multiple arrays of data points from an attached slave. The same formatting and scripting features as the 16-bit version are supported, as well as OLE Automation and direct database access via the Microsoft JET database engine. A recent addition to ModScan32 provides basic MMI capability which allows you to generate custom displays of modbus data using various graphical interfaces.

ModScan(16) supports direct serial connections only, while ModScan32 may be used with modems and network connections.

ModSim

ModSim represents the slave end of the communications protocol. This application may be used to simulate data from one or more modbus slave devices for access by a modbus master. Display of data is comparable to ModScan, in that register data may be displayed as decimal, hex, floating-point, etc.

Available as either a 16 or 32-bit design, ModSim supports multiple direct serial connections. ModSim32 may also be configured to operate as a modbus/TCP network server application for simulation of slave data via network connections. OLE Automation is also supported by the Win32 version.

MNetSvr

MNetSvr is a Win32 application designed to bridge serial modbus devices to a network environment. This application operates as a modbus/TCP network server, accepting requests from atached clients, collecting the data via a serial port, and responding via the network connection. MNetSvr supports multiple asynchronous network connections and is fully compatible with the modbus/TCP protocol as defined by Modicon.

MNetMon

MNetMon is a Win32 Application designed to unintrusively monitor an active modbus communications link by tapping into the RS-232 Transmit signals via two separate PC comm ports. As MNetMon recognizes data passed between the master and slave devices, it mirrows the data points to a local database, and makes this data accessible to other network devices operating as modbus/TCP clients. MNetMon operates as a modbus network server application, similar to MNetSvr but without actually polling the slave devices. MNetMon may be used with any existing RS-232 modbus communications link to seamlessly integrate the data with a PC network without impacting the integrity of the data exchanged between the master and slave devices.

Modbus Master ActiveX Control

The WinTECH Software Modbuss OCX is a custom control which supports drag and drop functionality into the Visual Basic devlopment workbench. The OCX is a modbus master control, which provides access to modbus data from your VBA application. The OCX contains a basic series of properties defining the connection, slave adress, point type, and point addresses to scan. Data from the defined slave is automatically collected and presented to your application as an array of data points. Multiple controls may be utilized within the same VBA application for accessing data of different types or data from different slave devices. The modbus master control supports direct serial, modem, or network connections.

Modbus Slave ActiveX Control

The WinTECH Software Modbus Slave OCX is a custom control which supports drag and drop functionality into the Visual Basic devlopment workbench. This very simple slave control allows your Visual Basic application to define an array of data points to be made instantly available to any connected modbus master device. Providing support for direct serial or network connections, this control is the quickest way for a developer to interface his custom data to a modbus network.

Driver DLL’s

WinTECH Software can also supply source code to support custom development of modbus designs. Both master and slave drivers are available for the Window’s platform in either 16 or 32-bit form factors. These drivers are the same ones used by the above applications and are available at very reasonable prices. Each

driver is written in straight ‘C’ code and comes complete with an example Windows application, (source

form), written using the Microsoft MFC. The modbus slave dlls are compatible with Visual Basic, and provide a very easy mechanism for desiging customized solutions.

+ 65 hidden pages