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

2

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.

3

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.

4

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.

5

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.

6

How to contact WinTECH Software

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

Sales support:

[e-mail]

Technical support:

[e-mail]

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:

[phone]

The postal address is:

WinTECH Software

P.O. Box 907

Lewisburg, WV 24901

USA

7

8

Modbus Message Formatting

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:

Characteristic	ASCII (7-bit)	RTU (8-bit)
Coding System	hexadecimal (uses ASCII	8-bit binary
	printable characters (0-9, A-F)
Number of bits per character:
start bits	1	1
data bits (least significant first)	7	8
parity (optional)	1	1
	(1-bit sent for even or odd parity,	(1-bit sent for even or odd parity,
	no bits for no parity)	no bits for no parity)
stop bits	1 or 2	1 or 2
Error Checking	LRC (Longitudinal Redundancy	CRC (Cyclical Redundancy
	Check)	Check)

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

9

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.

10

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

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.

	16-BIT REGISTER			MSB	Flag
(Exclusive OR)	1111	1111	1111	1111
02			0000	0010
	1111	1111	1111	1101
Shift 1	0111	1111	1111	1110	1
Polynomial	1010	0000	0000	0001
	1101	1111	1111	1111
Shift 2	0110	1111	1111	1111	1
Polynomial	1010	0000	0000	0001
	1100	1111	1111	1110
Shift 3	0110	0111	1111	1111	0
Shift 4	0011	0011	1111	1111	1
Polynomial	1010	0000	0000	0001
	1001	0011	1111	1110
Shift 5	0100	1001	1111	1111	0
Shift 6	0010	0100	1111	1111	1
Polynomial	1010	0000	0000	0001
	1000	0100	1111	1110
Shift 7	0100	0010	0111	1111	0
Shift 8	0010	0001	0011	1111	1
Polynomial	1010	0000	0000	0001
	1000	0001	0011	1110
07			0000	0111
	1000	0001	0011	1001

11

Shift 1	0100	0000	1001	1100	1
Polynomial	1010	0000	0000	0001
	1110	0000	1001	1101
Shift 2	0111	0000	0100	1110	1
Polynomial	1010	0000	0000	0001
	1101	0000	0010	1111
Shift 3	0110	1000	0010	0111	1
Polynommial	1010	0000	0000	0001
	1100	1000	0010	0110
Shift 4	0110	0100	0001	0011	0
Shift 5	0011	0010	0000	1001	1
Polynomial	1010	0000	0000	0001
	1001	0010	0000	1000
Shift 6	0100	1001	0000	0100	0
Shift 7	0010	0100	1000	0010	0
Shift 8	0001	0010	0100	0001	0

					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

12

LRC (Longitudinal Redundancy Check)

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.

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
		+1	0000 0001
Error Check	F5	2’s complement	1111 0101

13

MODBUS Message Types

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.

BEGIN	ADDRESS	FUNCTION	DATA	ERROR	EOF	READY
FRAME				CHECK		TO
						RECEIVE
:	2-CHAR 16-	2-CHAR 16-	N X 4-CHAR	2-CHAR	CR	LF
	BIT	BITS	N X 16-BITS	16-BITS

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.

T1,T2,T3	ADDRESS	FUNCTION	DATA	CHECK	T1,T2,T3
	8-BITS	8-BITS	N X 8-BITS	16-BITS

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.

14

Function Field

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:

CODE	MEANING	ACTION
01	READ COIL STATUS	Obtains current status, (ON/OFF), of a
		group of logic coils.
02	READ INPUT STATUS	Obtains current status, (ON/OFF), of a
		group of discrete inputs.
03	READ HOLDING REGISTER	Obtains current binary value in one or
		more holding registers.
04	READ INPUT REGISTER	Obtains current binary value in one or
		more input registers.
05	FORCE SINGLE COIL	Force logic coil to a state of ON or
		OFF.
06	PRESET SINGLE REGISTER	Place a specific binary value into a
		holding register.
15	WRITE MULTIPLE COILS	Force a group of logic coils to a
		defined state.
16	PRESET MULTIPLE REGISTERS	Place specific binary values into a
		group of holding registers.

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.

15

Exception Responses

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.

CODE	NAME	MEANING
01	ILLEGAL FUNCTION	The message function received is not an allowable
		action for the addressed slave.
02	ILLEGAL DATA ADDRESS	The address referenced in the data field is not an
		allowable address for the addressed slave device.
03	ILLEGAL DATA VALUE	The value referenced in the data field is not allowable
		in the addressed slave location.
04	FAILURE IN ASSOCIATED	The slave’s PC has failed to respond to a message or an
	DEVICE	abortive error occurred.
05	ACKNOWLEDGE	The slave PLC has accepted and is processing the long
		duration program command.
06	BUSY, REJECTED	The message was received without error, but the PLC is
	MESSAGE	engaged in processing a long duration program
		command.
07	NAK-NEGATIVE	The PROGRAM function just requested could not be
	ACKNOWLEDGMENT	performed.

16

READ OUTPUT STATUS (FUNCTION CODE 01)

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.

ADDR	FUNC	DATA	DATA	DATA #	DATA #	ERROR
		START	START	OF PTS	OF PTS	CHECK
		PT HO	PT LO	HO	LO	FIELD
11	01	00	13	00	25	B6

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.

ADDR	FUNC	BYTE	DATA	DATA	DATA	DATA	DATA	ERROR
		COUNT	COIL	COIL	COIL	COIL	COIL	CHECK
			STATUS	STATUS	STATUS	STATUS	STATUS	FIELD
			20-27	28-35	36-43	44-51	52-56
11	01	05	CD	6B	B2	0E	1B	D6

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.

17

READ INPUT STATUS (FUNCTION CODE 02)

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.

ADDR	FUNC	DATA	DATA	DATA #	DATA #	ERROR
		START	START	OF PTS	OF PTS	CHECK
		PT HO	PT LO	HO	LO	FIELD
11	02	00	C4	00	16	13

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.

ADDR	FUNC	BYTE	DATA	DATA	DATA	ERROR
		COUNT	DISCRETE	DISCRETE	DISCRETE	CHECK
			INPUT	INPUT	INPUT	FIELD
			10197-10204	10205-10212	10213-10218
11	02	03	AC	DB	35	2E	LRC

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.

18

READ OUTPUT REGISTERS (FUNCTION CODE 03)

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.

ADDR	FUNC	DATA	DATA	DATA #	DATA #	ERROR
		START	START	OF REGS	OF REGS	CHECK
		PT HO	PT LO	HO	LO	FIELD
11	03	00	6B	00	03	7E

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.

ADDR	FUNC	BYTE	DATA	DATA	DATA	DATA	DATA	DATA	ERROR
		COUNT	OUTPUT	OUTPUT	OUTPUT	OUTPUT	OUTPUT	OUTPUT	CHECK
			REG	REG	REG	REG	REG	REG	FIELD
			H.O.	L.O.	H.O.	L.O.	H.O.	L.O.
			40108	40108	40109	40109	40110	40110
11	03	06	02	2B	00	00	00	64	55

19

READ INPUT REGISTERS (FUNCTION CODE 04)

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.

ADDR	FUNC	DATA	DATA	DATA #	DATA #	ERROR
		START	START	OF REGS	OF REGS	CHECK
		PT HO	PT LO	HO	LO	FIELD
11	04	00	08	00	01	E2

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

ADDR	FUNC	BYTE	DATA	DATA	ERROR
		COUNT	INPUT	INPUT	CHECK
			REG HO	REG LO	FIELD
			30009	30009
11	04	02	00	00	E9

20

FORCE SINGLE COIL (FUNCTION CODE 05)

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.

ADDR	FUNC	DATA	DATA	DATA #	DATA	ERROR
		COIL	COIL	ON/OFF		CHECK
		HO	LO			FIELD
11	05	00	AC	FF	00	3F

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

ADDR	FUNC	DATA	DATA	DATA #	DATA	ERROR
		COIL	COIL	ON/OFF		CHECK
		HO	LO			FIELD
11	05	00	AC	FF	00	3F

21

PRESET SINGLE REGISTER (FUNCTION CODE 06)

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.

ADDR	FUNC	DATA	DATA	DATA	DATA	ERROR
		REG	REG	VALUE	VALUE	CHECK
		HO	LO	HO	LO	FIELD
11	06	00	87	03	9E	C1

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

ADDR	FUNC	DATA	DATA	DATA	DATA	ERROR
		REG	REG	VALUE	VALUE	CHECK
		HO	LO	HO	LO	FIELD
11	06	00	87	03	9E	C1

22

FORCE MULTIPLE COILS (FUNCTION CODE 15)

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.

ADDR	FUN	H.O.	L.O.	QUANTITY		BYTE	DATA	DATA	ERROR
	C	ADDR	ADDR			CNT	COIL	COIL	CHECK
							STATUS	STATUS	FIELD
11	0F	00	13	00	0A	02	CD	00	F4

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

ADDR	FUNC	H.O.	L.O.	QUANTITY		ERROR
		ADDR	ADDR			CHECK
						FIELD
11	0F	00	13	00	0A	C3

23

PRESET MULTIPLE REGISTERS (FUNCTION CODE 16)

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.

ADDR	FUN	H.O.	L.O.	QUANTITY		BYTE	H.O.	L.O.	etc.	ERROR
	C	ADDR	ADDR			CNT	DATA	DATA		CHECK
										FIELD
11	10	00	87	00	02	04	00	0A		??

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

ADDR	FUNC	H.O.	L.O.	QUANTITY		ERROR
		ADDR	ADDR			CHECK
						FIELD
11	10	00	87	00	02	56

24

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.

25

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.

26

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.

27

28