0% found this document useful (0 votes)
4 views4 pages

Modbus Source Code Libraries

Triangle MicroWorks Inc. offers Modbus source code libraries that facilitate master-slave communication between devices using the Modbus protocol, which was developed in 1979. The libraries are compliant with Modbus Application Protocol Specification V1.1, support various communication networks, and include features such as extensive diagnostics and easy integration into target applications. Additionally, the libraries provide tools for testing and diagnostics, including a built-in protocol analyzer and a communication protocol test harness.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views4 pages

Modbus Source Code Libraries

Triangle MicroWorks Inc. offers Modbus source code libraries that facilitate master-slave communication between devices using the Modbus protocol, which was developed in 1979. The libraries are compliant with Modbus Application Protocol Specification V1.1, support various communication networks, and include features such as extensive diagnostics and easy integration into target applications. Additionally, the libraries provide tools for testing and diagnostics, including a built-in protocol analyzer and a communication protocol test harness.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Triangle MicroWorks Inc.

Modbus Product Highlights

Features of Modbus Source Code Libraries

What is Modbus Protocol?


The Modbus Protocol messaging structure was developed by Modicon in 1979 to establish master-slave/client-
server communication between intelligent devices. It has since become an open protocol. The Modbus
Organization has been formed to provide users and suppliers an opportunity to obtain and share information
about the Modbus communication protocol. In addition, the Modbus TCP protocol specification has been recently
submitted to the Internet Engineering Task Force (IETF).
Modbus is an application layer messaging protocol, positioned at level 7 of the OSI model that provides
client/server communication between devices connected on different types of buses or networks. Modbus is a
request/reply protocol and offers services specified by function codes. Modbus function codes are elements of
Modbus request/reply PDUs.
Several implementations of Modbus are available. The Modbus Serial ASCII implementation is readable on a
standard terminal window. The Modbus Serial RTU implementation is a more compact, binary protocol. Modbus
Plus uses a proprietary high-speed token passing network, while Modbus TCP uses standard, inexpensive Ethernet
cards.

Features Common to All of Our Modbus Source Code Libraries


• Conforms to Modbus Application Protocol Specification V1.1.
• Written in ANSI Standard C Source Code, under a strict corporate coding standard.
• Easy installation through “Triangle” Source Code Library to Target Application interface. (See Design Details
for Implementation and Technical Details for each specific product).
• Supports any physical communication network including RS 232/485 (for RTU and ASCII), Modbus Plus, and
TCP.
• Can be used in event-driven or non-event-driven environments (with or without a Real Time Operating
System).
• Supports binary data (coils and discrete inputs) and analog data (holding registers and input registers).
• Supports function codes for read, write, and read/write multiple registers.
• Simple configuration for byte-order: most-significant-first (Motorola) or least-significant-first (Intel).
• Extensive, built-in (but removable) diagnostics including a protocol analyzer used to visually decipher
protocol messages. The diagnostic and analyzer strings can be directed to any target system display device,
even a serial port or RAM buffer. See the back of this page for sample protocol analyzer output.
• Records communication protocol errors such as "Unsupported function code", “Data base errors”, “Address
range errors”, “Exception response, FC = xxx, Exception Code = xxx”.
• No royalty fees per unit sold.
• Typical product integration times are less than 3 weeks.
Modbus Slave Source Code Library Features
• Multiple examples of simulated Database Interface implementations are provided for testing, illustration, and
as templates to be used for developing final Database Interface.
• Built-in (but removable) ASCII terminal command interface may be used to change configuration parameters
or to simulate input data changes during testing.

— Continued on back of this page — 010002030908000


Modbus Master Source Code Library Features
• An unlimited number of remote devices can be configured on an unlimited number of communication ports,
and new remote devices can be added at runtime.
• Multiple devices can be assigned to the same communication port to support multiple network communication
topologies.
• ASCII terminal based SCADA Man Machine Interface (MMI) can be used to initiate Modbus commands, read
requests, write requests, etc.
• Database manager maps received Modbus data into Target Application data points (binaries, controls, integers,
floats, etc.).

Protocol Analyzer Display created by Modbus Source Code Library

The following symbols are used to denote data from each layer of the protocol:

==== User Layer Operations


<~~~ Application Transmit
~~~> Application Receive
<--- Link Transmit
---> Link Receive
<... Physical Transmit
...> Physical Receive

15:47:48.578: <+++ master Insert request in queue: Read Holding Registers


15:47:48.578: <=== master Application Header, Read Holding Registers
15:47:48.578: Starting Register=5, Quantity=10
15:47:48.578: 03 00 05 00 0a

15:47:48.578: <--- master Modbus TCP Link Header


15:47:48.578: TransID=0, ProtoID=0, DataLength=6, Dest=1
15:47:48.578: 00 00 00 00 00 06 01 03 00 05 00 0a

15:47:48.578: <... master 00 00 00 00 00 06 01 03 00 05 00 0a

15:47:48.687: ...> master 00 00 00 00 00 17 01 03 14 79 d7 58 f0 e3 7d d0


15:47:48.687: ec bd 91 2c 35 da 17 b4 66 82 63 4d 2f

15:47:48.687: ---> master Modbus TCP Link Header


15:47:48.687: TransID=0, ProtoID=0, DataLength=23, Dest=1
15:47:48.687: 00 00 00 00 00 17 01 03 14 79 d7 58 f0 e3 7d d0
15:47:48.687: ec bd 91 2c 35 da 17 b4 66 82 63 4d 2f

15:47:48.687: ===> master Application Header, Read Holding Registers


15:47:48.687: Byte Count=20
15:47:48.687: 03 14 79 d7 58 f0 e3 7d d0 ec bd 91 2c 35 da 17
15:47:48.687: b4 66 82 63 4d 2f
15:47:48.687: Holding Register 000005 = 31191
15:47:48.687: Holding Register 000006 = 22768
15:47:48.687: Holding Register 000007 = 58237
15:47:48.687: Holding Register 000008 = 53484
15:47:48.687: Holding Register 000009 = 48529
15:47:48.687: Holding Register 000010 = 11317
15:47:48.687: Holding Register 000011 = 55831
15:47:48.687: Holding Register 000012 = 46182
15:47:48.687: Holding Register 000013 = 33379
15:47:48.687: Holding Register 000014 = 19759

2840 PLAZA PLACE, SUITE 205 • RALEIGH, NC 27612 • PH: 919.870.5101


FAX: 919.870.6692 • WEB SITE: www.TriangleMicroWorks.com
Triangle MicroWorks, Inc. Design Details for Implementation

Efficient Installation, Testing, and Verification

Design Objective:
Our primary design objective is to provide our customers with an ANSI Standard C Source Code Library (SCL)
with a Target Application (TA) Interface that can be implemented in less than three man weeks. To accomplish
this, our design divides the interface into “entry-points” from TA-to-SCL, and “calls” back into the TA from the
SCL.

The “Triangle” Approach to Interfacing between the SCL and TA:


The interface between the SCL and TA can be viewed as a three-sided, or “triangle” interface. Two sides
represent calls back into the TA from the SCL Interface. Each of these sides is organized into individual, well-
documented modules or header files. These files are the only recommended customer-editable (or platform-
specific) files. All other files are protocol-specific and should not need to be modified by the customer.
The three sides of the interface are shown in the diagram below:
1) TA-to-SCL Entry Points: The entry points are limited to a few SCL initialization functions and a single
process function; the process function can be called regularly as part of a Target Application main loop,
or as an event-driven task in a real-time operating system environment. Master Source Code Libraries
also provide C function calls to build and send request messages to remote Slave devices.
2) Low-Level Target Interface: Provides access to hardware components such as communication channels,
timers, and clocks.
3) Database Interface: Provides customized fit to TA data, and allows extraction and insertion of individual
database profiles, including any of our included simulated database profiles used for testing.

Example flow diagram for an installation of the DNP3 Slave Source Code Library

Low-Level Target Interface Database Interface


(to your hardware) (to your data)
example calls from SCL:
example calls from SCL:
Triangle sdnpdata_binInRead()
tmwtarg_receive()
tmwtarg_transmit() MicroWorks, Inc. sdnpdata_anlgOutOperate()
Source Code Library (SCL)

Target Application (TA)


(your mainline software)
tmwappl_initApplication() /* initialize all configuration structures to defaults */
tmwtarg_initConfig();
dnpchnl_initConfig();
sdnpsesn_initConfig();
... /* overwrite default config values with user settings */
tmwtimer_initialize(); /* initialize polled timer (if used) */
dnpchnl_openChannel(); /* open channel */
sdnpsesn_openSession(); /* open session */
...
while(1) /* begin main loop or task */
{
...
tmwpltmr_checkTimer(); /* if using SCL in polled mode, check timer and */
tmwappl_checkForInput(); /* check for received data. These lines are not */
... /* required if using SCL in event-driven mode */
}

— Continued on back of this page — 000715000003


Typical Installation Sequence for All Source Code Libraries
We strongly recommend that before you develop any communications protocol, whether or not you use our
Libraries, you should create a Configuration/Interoperability (C/I) Guide that conforms to standard “device
profile” documents for each protocol. The C/I Guide specifies how to configure the protocol operation of the
device; for interoperability, it specifies the objects, variations, and protocol functions that will be implemented.
Our Source Code Libraries come with C/I Guide templates, with much of the information already filled in.
After completing the C/I Guide, a typical sequence to install one of our Source Code Libraries is:
1) Edit low-level target interface file to attach serial port receive and transmit functions, add access to a
free-running millisecond timer/counter, and to configure byte-order (most or least significant first).
2) Add TA-to-SCL entry point functions in Target Application software (as in the DNP3 example above).
3) Conduct initial testing, which verifies operation of the Source Code Library on the target hardware. Initial
testing consists of comparing results of requests and polls with known values from either a simulated
database (for Slave Libraries), or from a known slave device (for Master Libraries). Slave Libraries include
simulated database profiles with pre-set initial values of database objects; no modification of the database
interface is necessary for initial testing.
4) Attach SCL-to-TA calls to your database design by simple replacement of simulated database calls.
5) For Slave Libraries, install report-by-exception processing by adding access to a date/time clock, and
configuring scan periods and event buffer sizes.
6) For Master Libraries, install Target Application request messaging by adding calls to build request message
entry points from Target Application software.
7) Make final adjustments of the configuration interface to ensure that all user settable configuration
parameters are mapped to SCL configuration structures.
8) Conduct final testing.

Testing and Diagnostics


For testing Source Code Library installations, we provide the following tools:
• A built-in protocol analyzer allows you to visually decipher protocol messages to or from both Master
and Slave devices.
Sample Protocol Analyzer display
15:28:37.506: ...> slave 05 64 14 c4 04 00 03 00 c7 17

15:28:37.506: ...> slave ca c9 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 f8


15:28:37.506: ae

15:28:37.506: ---> slave Primary Frame - Unconfirmed User Data


15:28:37.506: LEN(20) DIR(1) PRM(1) FCV(0) FCB(0) DEST(4) SRC(3)
15:28:37.506: 05 64 14 c4 04 00 03 00 c7 17
15:28:37.506: ca c9 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 f8 ae

15:28:37.506: ~~~> slave Transport Header


15:28:37.506: FIR(1) FIN(1) SEQ# 10
15:28:37.506: ca c9 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06

15:28:37.506: ===> slave Application Header, Read Request


15:28:37.506: FIR(1) FIN(1) CON(0) UNS(0) SEQ# 9
15:28:37.506: c9 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06

15:28:37.506: Object 60(Class Data), variation 2, qualifier 0x06(All Points)

15:28:37.506: Object 60(Class Data), variation 3, qualifier 0x06(All Points)

15:28:37.506: Object 60(Class Data), variation 4, qualifier 0x06(All Points)

• Triangle MicroWorks also offers a Communication Protocol Test Harness to facilitate version release
testing of your Source Code Library implementation. The Test Harness acts as a simple Master or Slave
device and can also be programmed with automated test sequence scripts. Conformance Test Scripts are
also available to perform the conformance test procedures published by the technical committees of each
protocol. Please contact us for more information on this product or download a full 21-day evaluation
from our website at http://www.TriangleMicroWorks.com/downloads.htm.

2840 PLAZA PLACE, SUITE 205 • RALEIGH, NC 27612 • PH: 919.870.5101


FAX: 919.870.6692 • WEB SITE: www.TriangleMicroWorks.com

You might also like