Modbus Us
Modbus Us
Filename Modbus.dll
Manufacturer Modicon
Devices Any device compatible with Modbus protocol v1.1b
Protocol Modbus v1.1b
Version 4.0.11
Last Update 08/30/2023
Introduction
This Driver implements the Modbus protocol, which allows an Elipse Software application to communicate with any slave
device that implements this protocol in ASCII, RTU, or TCP modes.
This Driver always works as a master of a Modbus network. If users want to to communicate with master devices, then
Elipse Software's Modbus Slave Driver must be used, which can be downloaded at company's website.
This Driver, starting with version 2.0, was developed using Elipse Software's IOKit library. This library is responsible for
implementing the physical layer access (Serial, Ethernet, Modem, or RAS). For more information about IOKit library
configuration, please check topic Documentation of I/O Interfaces.
It is recommended to start by reading topic Quick Configuration Guide if the device is fully compliant with standard
Modbus protocol, defined by the Modbus Organization (modbus.org), and if users only want to read or write bits and
registers, without using more advanced features of this Driver.
For a complete understanding of all this Driver's functionality, it is recommended to start reading, in this order, chapters
Adding a Driver to an Elipse Software Application and Configuration.
To create large scale applications, it is also recommended to read topic Optimization Tips.
If users are not familiar with the protocol, please check topics The Modbus Protocol, Recommended Websites,
Supported Functions, and Special Functions.
If a device is fully compliant with the standard protocol, and users only want to read or write registers or bits, the topics
Inserting a Driver, Configuring a Driver, and Configuring I/O Tags are probably sufficient to configure this Driver.
Inserting a Driver
If using E3 or Elipse Power, please check topic Adding a Driver to an Elipse Software Application - E3 or Elipse Power.
If using Elipse SCADA, please check topic Adding a Driver to an Elipse Software Application - Elipse SCADA.
E3 or Elipse Power
On Organizer, right-click the Server Objects - Drivers and OPC item, select the Insert I/O Driver in option, and then
select a project.
On the window that opens, select a Driver (this file must be extracted to a folder on the computer in use) and click Open.
The configuration window of this Driver opens automatically, as shown on the next figure.
This Driver's configuration window can also be opened, later, by clicking Driver settings , as shown on the next figure.
After configuring this Driver's properties, click OK to open Tag Browser window, allowing to insert pre-defined Tags in the
application, based on the most used settings. The next figure shows Tag Browser's window. To add Tags, drag them from
the list Tags available from driver to the list Current project tags.
Tags available in Tag Browser are Tags configured using Strings, a new method that does not use the old concept of
operations. Insert the most adequate ones to the application, editing their fields as needed. Tag Browser window can be
opened later by clicking Tag Browser .
Elipse SCADA
On Organizer, select the Drivers item and click New.
On the window that opens, select a Driver (this file must be extracted to a folder on the computer in use) and click Open.
Selecting a Driver
For this Driver to work correctly, users still need to configured it on its configuration window. To open this window,
showed on the next figure, click Extra.
The second step of topic Quick Configuration Guide shows how to configure this Driver for the most common usages,
for devices complying to default Modbus protocol requirements. On topic Properties that configuration is described in
details, including advanced configuration resources.
Configuring a Driver
After inserting this Driver in an application, users must open Driver's configuration window, as explained on topics E3 or
Elipse Power or Elipse SCADA. With this configuration window open, follow these steps:
a. On the Setup tab, select a physical layer (Serial, Ethernet, Modem, or RAS) to use when connecting with a device.
b. Configure the selected physical layer on its corresponding tab (Serial, Ethernet, Modem, or RAS).
c. For more information about configuring a physical layer, please check topic Documentation of I/O Interfaces.
2. On the Modbus tab, select the protocol mode (RTU, ASCII, or TCP) used by the device. As a general rule, users must
select RTU or ASC (for most devices it is RTU) for Serial or Modem physical layers, or TCP for Ethernet or RAS
physical layers. The other options usually can be kept with their default configurations. For more information about all
options on this tab, please check topic Modbus Tab.
NOTE
For new applications, it is strongly recommended to avoid using ModbusRTU (RTU mode) encapsulated in an Ethernet
TCP/IP layer. However, if by any reason, for legacy applications, users must use ModbusRTU encapsulated in TCP/IP,
please do not forget to enable the Reconnect after Timeout option, described on topic Modbus Tab.
4. If users still need to use the old numerical configuration (N/B parameters), used by Elipse SCADA, it is important to
check the Operations tab. There are default operations already pre-configured on this Driver. Operations are
configurations of functions and data formats that later are referenced by application's Tags. These default operations,
already available when this Driver is loaded for the first time, are the most common ones. Evaluate all reading and
writing functions and the data types used for each operation, and check which ones are needed for the application. If
these pre-defined operations do not fit the application needs, users must edit them or even create new operations. If
this is the case, please check topic Operations Tab. The next table lists all pre-defined operations.
Pre-defined operations
NOTE
These default operations are configured assuming that a device complies with Modbus' default byte order, big endian, in
which the most significant bytes come first. If a device does not comply with that standard, please check topic
Operations Tab for more information about configuring operations for different byte orders.
For more information about configuring this Driver, please check topic Configuration.
The next step demonstrates how to configure I/O Tags based on pre-defined operations.
Next there is a description of the recommended procedures for String configuration and also for the old numerical
configuration, if it is needed for legacy applications.
String Configuration
To add String-configured Tags, users have an option to import Tag Browser's pre-defined models, as explained on topic
Adding a Driver to an Elipse Software Application. To do so, users must keep the Show Operations in Tag Browser
option disabled on the Operations tab and then open Tag Browser by clicking Tag Browser .
To add a new Tag to an application without using Tag Browser, follow these steps:
1. On Organizer, double-click this Driver, select the Design tab, click Add , and then select the I/O Tag item, according
to the next figure.
2. On the Adding IOTag window, configure the Quantity field with value 1 (one) and specify a name for this Tag in the
Name field. Click OK to create a new Tag.
3. On the Device column, type the numerical value of device's Slave Id to communicate, followed by a colon, such as "1:"
for a Slave Id equal to 1 (one). Notice that, in an Ethernet TCP/IP layer, this value is sometimes ignored, and only the
IP address is used and the TCP/IP port configured on the Ethernet tab, which must be declared on device's
documentation.
4. On the Item column, specify a mnemonic for the address space (a set of reading and writing Modbus functions)
followed by the register's or bit's address. For Holding Registers, the address space is "hr" or "shr", and this last one
does not allow writing in blocks, because it uses the writing function 06 (Write Single Register), while the "hr" address
space uses the writing function 16 (Write Multiple Registers). Both use the reading function 03 (Read Holding Registers).
For Coils use "cl" or "scl". Again, the difference is that the last one, which uses function 05 (Force Single Coil), does not
write to blocks. Next, there are some examples of configurations for the Item column.
a. Reading or writing Holding Register 150 using functions 03 and 16 (writing multiple registers): Item must be equal
to "hr150".
b. Reading or writing Holding Register 150 using functions 03 and 06 (writing simple registers): Item must be equal to
"shr150".
c. Reading or writing a Coil with address FFF0h (65520) using functions 01 and 15 (writing multiple bits): Item must be
equal to "cl65520" or "cl&hFFF0" (prefix "&h" can be used to provide addresses in hexadecimal format).
d. Reading or writing a Coil with address FFF0h (65520) using functions 01 and 05 (writing simple bits, one by one):
Item must be equal to "scl65520" or "scl&hFFF0" (prefix "&h" can be used to provide addresses in hexadecimal
format).
6. Tag addressing must correspond to the Modbus address map on the device, which must be declared on
manufacturer's documentation. When in doubt, please check topic Addressing Tips (Modbus Convention).
Prefer simple Tags, called PLC Tags in Elipse SCADA, rather than Block Tags, keeping the Superblock feature enabled,
that is, the EnableReadGrouping property set to True, leaving group optimization to the application and to this Driver.
For more details, please check topic Superblock Reading (Grouping).
Numerical Configuration
For E3 or Elipse Power, users can use Tag Browser to create Tags with pre-defined operations, numerically configured.
To do so, select the Show Operations in Tag Browser option on the Operations tab.
Tag Browser's window, shown on the next figure, is opened when clicking OK on this Driver's configuration window.
2. Close Tag Browser and configure the N4/B4 parameter of each Tag with the register or bit address to read or write,
according to device's register map. This address map must be described on manufacturer's documentation. When in
doubt, please check topic Addressing Tips (Modbus Convention).
3. Also configure the N1/B1 parameter of each Tag with device's address (Slave Id) to access in each case. This
parameter is usually configured on the device and, to determine it, please check manufacturer's documentation or
technical support when in doubt.
4. Rename all Tags, if needed, with a more significant name for the application.
Configure simple Tags, called PLC Tags in old Elipse SCADA, rather than Block Tags, keeping the Superblock feature
enabled, that is, the EnableReadGrouping property set to True, leaving group optimization to the application and to this
Driver. For more information, please check topic Superblock Reading (Grouping).
Elipse SCADA does not support Tag Browser, thus it is necessary to configure I/O Tags manually. Users must create Tags
with the following configuration:
Notice that, for this Driver, simple Tag's N parameters have the same meaning as Block Tag's B parameters, so they are
described together.
When in doubt about which value to configure in the N4/B4 parameter, please check topic Addressing Tips (Modbus
Convention).
As Elipse SCADA does not support Superblocks, it is recommended to create Block Tags, grouping adjacent or close
registers, to read the maximum number of registers in the smallest number of protocol requests.
Also notice that, once a device supports default protocol limits for the size of a communication frame, due to
Automatic Block Partition feature, there is no need to worry about exceeding the maximum block size supported by this
protocol, because this Driver already creates the appropriate subdivisions during communication.
Final Considerations
If users only want to use this Driver's default operations, and if a device complies with the standard protocol defined by
Modbus Organization, the steps presented in this Quick Configuration Guide should be sufficient to configure this Driver.
More details on I/O Tag configuration are provided on topic Configuring an I/O Tag.
This protocol is based on command and response messages, positioned at layer 7 of the OSI model, the application
layer, which provides client and server communication among devices connected to different types of networks. It offers
services with functions defined by an eight-bit code. The existing categories of function codes are the following:
· Public function codes: Protocol's well-defined functions, guaranteed to be unique, validated by the Modbus
community, and publicly documented in MB IETF RFC. They can assume values ranging from 1 to 64, from 73 to 99,
and from 111 to 127
· User-defined function codes: Non-standard functions, which do not need Modbus.org approval, without any
guarantee of being unique, and freely implementable. They can assume values ranging from 65 to 72 and from 100
to 110
· Reserved function codes: Codes with values inside the range of public functions, currently used by some
manufacturers for legacy products, and not publicly available anymore. Examples are 9, 10, 13, 14, 41, 42, 90, 91, 125,
126, and 127 codes. For more information, please check Annex A of protocol's specification, version 1.1b, which is
available at protocol's official website
This Driver currently implements 11 of all 19 public functions defined on the current version of protocol's specification,
1.1b, as well as some specific manufacturer's functions or related to this Driver's specific features, known as Special
Functions. All public functions implemented are described on topic Supported Functions. The following protocol's public
functions are not yet supported:
If users want to implement one of these functions, please contact Elipse Software's sales department.
Recommended Websites
Modicon Modbus Driver is available for download, at no cost, at Elipse Software's Drivers download area.
More information about the Modbus protocol can be found at www.modbus.org, protocol's official website.
Elipse Modbus Simulator is available for download, at no cost, at Elipse Software's E3 download area.
Modsim Modbus Slave Simulator, probably the best known in its category, can be purchased at www.win-
tech.com/html/modsim32.htm. This software emulates a device, allowing communication with this Driver.
Other alternatives for simulators and software tools related to this protocol can be found at protocol's official website.
Supported Functions
Modbus protocol functions supported by this Driver are described next.
Reading functions
Writing functions
Detailed information about each one of these functions can be found on Modbus protocol's specification, available for
download at Modbus Organization's website.
In addition to protocol's standard functions, as already stated, this Driver also implements special functions, not defined
by the protocol, usually related to mass memory readings. A list of all supported special functions can be checked on
topic Special Functions. A complete configuration of this Driver is described on topic Configuration.
If users want to add support to a new function in this Driver, please contact Elipse Software's sales department.
Special Functions
Special reading and writing functions are this Driver's functions not defined by the standard Modbus protocol. They were
developed to meet specific features of certain devices, or else to provide, in a standardized way by this Driver, features
not available in the standard protocol. This Driver, in its current version, includes the special functions described next.
Reading Functions
· 65 03: Mass Memory Reading (ABB MGE 144), described in details on topic Reading Mass Memory Registers from
ABB MGE 144 Meters
· GE SOE: Event Reading (GE PAC RX7 Systems), described in details on topic Reading an Event Buffer from GE PAC
RX7 Controllers
· GenSOE: SOE reading with a generic algorithm, implemented by a resident software in the slave device (PLC),
described in details on topic Elipse Software's Generic SOE Reading Algorithm
Writing Functions
· 65 01: Restarts, that is, performs a reset operation, a power meter (ABB MGE 144). This command is sent as a Tag's
simple writing command (Write). Tag's Value field is ignored by this Driver and can be kept in 0 (zero). For more
information, please check that device's manual
· 65 02: Zeroes the maximum and minimum memory (ABB MGE 144). This command is sent as a Tag's simple writing
command (Write). Tag's Value field is ignored by this Driver and can be kept in 0 (zero). For more information,
please check that device's manual
Notice that this Driver's special functions, except for the writing function 65 01, are directly or indirectly related to mass
memory reading of registers of their respective devices. For more information, please check topic Mass Memory
Reading. For a description on how to configure operations and Tags using these functions, please check topic
Configuration.
Configuration
This section describes how to configure this Driver. The topics Properties , Configuring Tags, and Mass Memory
Reading are discussed.
Properties
This Driver's properties can be configured at design time or at run time. A runtime configuration is also called an Offline
Mode Configuration, and it is described on a specific topic.
At design time, this Driver can be configured using its configuration window, displayed on the next figure.
To open this Driver's configuration window in E3 or Elipse Power, double-click the Driver object on Organizer and click
Driver settings , as shown on the next figure.
In Elipse SCADA, on the other hand, this Driver's configuration window can be opened by clicking Extra, on application's
Organizer.
This configuration window is divided into several tabs, some of them for IOKit library configuration, and others are
Driver-specific. For this Driver, the Modbus, Operations, and Gen SOE tabs are specific. All other tabs are for IOKit
library configuration, and they are not described on this Manual. For more information about IOKit library configuration,
please check topic Documentation of I/O Interfaces.
The topics Modbus Tab, Operations Tab, Gen SOE Tab, and Offline Mode Configuration describe this Driver's specific
tabs and also its runtime configuration, in Offline Mode, using scripts.
The next sections describe all configuration options available on this tab.
Protocol Options
This group of options gathers options referring to variations on protocol's standards, according to the next table.
OPTION DESCRIPTION
Modbus Mode On this option, users can select a protocol mode to use.
Protocol modes are variations defined by the standard for a
better adaptation to different physical layers, such as Serial,
Ethernet TCP/IP, or RAS, among others. The available
options are the following:
· RTU mode: Default mode for use in serial
communications. Includes a 16-bit CRC
· ASCII mode: Also used in serial communications, it is
used in simpler devices, which do not support RTU mode
requirements. It uses ASCII characters for transmission,
where each byte contains two ASCII characters, one per
nibble, thus it is less efficient than RTU mode, and rarely
This configuration option, described on the previous table, is a source of frequent doubts when addressing I/O Tags,
because there are many variations in how it is implemented by manufacturers. Next there is more information about this
addressing.
In protocol's standard data model, four data blocks are defined, or address spaces: Discrete Inputs, Coils, Input Registers,
and Holding Registers. In each one of these blocks, data elements are addressed starting at 1 (one). On the other hand, the
communication frame's specification defines a PDU with addresses that range from 0 (zero) to 65535. The relationship
between the address provided by the PDU and the address of data elements, therefore, has an offset of 1 (one), that is, if
in a request's PDU there is an address 0 (zero), the data element to access is the address 1 (one).
With this option on the Modbus tab, users can select whether this Driver sets that value automatically, thus allowing the
use of data element's address on Tags, the default option, or the value sent in the PDU is the same provided on Tag
configuration, the N4/B4 parameter in numerical configuration. There are devices that comply with Modbus standard in
their address maps, starting at one, and other devices that map their values without a default offset, directly using the
value of the address on communication's frame, starting at 0 (zero).
In addition to this single offset, there are still devices that use the old offset standard used by Modicon, the company that
created the protocol, which is known as Modbus Convention, detailed on topic Addressing Tips (Modbus Convention).
Please check device's manual for information on the register map used. When in doubt, please check manufacturer's
technical support.
NOTE
The Data Address Model Offset option used to be named Use Older Address on versions earlier than version 2.03,
where the Data is addressed from 1 option is equivalent to the old Use Older Address option enabled, and the Data is
addressed from 0 option is equivalent to the Use Older Address option disabled.
Other Options
The next table describes all other options on this tab, referring to this Driver's behavior.
OPTION DESCRIPTION
Default Slave Address This feature allows configuring a default address for
slaves, so that it is not necessary to configure them in each
Tag. To use this feature, configure the Slave Id, the N1/B1
parameter on numerical configuration or the Device field
on String configuration, as 1000, that is, all Tags with
their Slave Id equal to 1000 have this value replaced by the
value configured in the Default Slave Address option.
Users can also force using a default address in all Tags,
Wait Silence on error If this option is enabled, after every communication error
this Driver remains in loop, receiving data until a time-out
occurs. This clears the reception channel and prevents
problems in future communications due to the reception of
delayed bytes still in transit at the time of the error, and
which may be confused with a response to a new
command
Reconnect after Timeout (Ethernet only) With this option enabled, after any time-out error in
device's frame reception, this Driver performs a
disconnection and a reconnection to the physical layer,
clearing the connection from possible delayed frames still
in transit, which may affect future requests. This option
must be always enabled if using Modbus RTU in an
Ethernet TCP/IP layer is inevitable in legacy systems, as
the RTU mode does not have a transaction control,
therefore it is not always possible to distinguish a correct
response frame from a delayed one resulting from a
previous reading, possibly from another address, which
failed by a time-out. For new projects, it is strongly
recommended NOT using Modbus RTU or Modbus ASC
modes in an Ethernet TCP/IP layer. Notice that users must
keep the Retry failed connection every option enabled on
IOKit's Setup tab, so that this Driver reconnects after a
time-out. Otherwise, this time-out only generates a
disconnection and the application is responsible for
managing this new connection
NOTE
The old Swap Address Delay option was removed from the configuration window in version 2.08. This Driver still
supports it in pre-existing applications and allows enabling it by script. For more information, please check topic Offline
Mode Configuration. For new applications, it is recommended to use the Inter-frame Delay option on IOKit's Serial
tab, which replaces this old option with benefits.
Operations Tab
This topic describes how to configure the Operations tab on this Driver's configuration window, where all operations
used on I/O Tags are defined, as shown on the next figure.
Configuring operations is no longer used when configuring Tags by Strings, it is only used in the old numerical
configuration, the N/B parameters, on Elipse SCADA.
Operations
For a proper usage of this Driver, users must define which reading and writing Modbus functions are used for each I/O
Tag. To do so, if Tag configuration is performed using the old N/B numerical parameters in Elipse SCADA, select the
Operations tab on the configuration window.
For this Driver, Operations are configurations defining how each I/O Tag performs data writings and readings to and
from a device.
An operation is simply a definition of a pair of protocol functions, one for writing and another one for reading,
and a specification for additional conversions on the format of data that can be linked to application Tags. In other
words, in this Driver the N or B numerical parameters of I/O Tags do not directly reference protocol functions, but rather
pre-configured operations, which by their turn not only inform functions, protocol's native or even special ones, to use
when communicating, as well as the way native protocol data must be interpreted.
Configuration of I/O Tag parameters is described later on topic Configuring an I/O Tag. Next, there is a description of
the configuration of operations, which must be later linked to each I/O Tag.
NOTE
Operations work only as a template to configure I/O Tags, and user can, and usually want to, set a single operation to
several Tags, which have in common the same value for their N2/B2 parameters.
Functions
Modbus protocol's default functions provide data only in basic 16-bit Bit and Word formats. There are no additional data
formats in protocol's specification.
A list of all Modbus functions supported by this Driver, which can be set to the configured operations, can be checked on
topic Supported Functions.
In addition to protocol functions, this Driver also contains some Special Functions that are not part of protocol's
standard, with a proprietary format and commonly used for reading events (SOE).
Data Formatting
In addition to allow linking functions, from the protocol or special ones, to specific Tags, operations also allow defining an
additional formatting to apply to data, providing support to additional data types, not specified by the protocol, such as
32-bit (Float) and 64-bit (Double) floating point values. Supported data types are described on topic Supported Data
Types.
It is important to notice that, when 32- and 64-bit data types are defined in operations, users must define protocol
functions that work with 16-bit registers. This way, reading data with more than 16 bits results in reading several 16-bit
Modbus registers from a device, that is, to read a Tag linked to an operation defining a 32-bit Float data type, this Driver
must read two consecutive 16-bit registers from a device, concatenate them, and then perform a conversion to a Float
format.
Users can also define eight-bit data types, Byte, Int8, or Char, in operations. Notice that, as protocol functions do not
allow reading and writing isolated bytes, for each two Block Elements of eight-bit data types, this Driver is forced to
access a distinct 16-bit register on a device. For that reason, this Driver does not allow writing eight-bit data types to
Tags, to isolated Block Elements, or to Blocks with odd or unitary sizes. Writing eight-bit data types must be always
performed with even-size Blocks.
In addition to pre-defined data types, native or built-in data types, described on topic Supported Data Types, this Driver
also allows user-defined data types. These data types must be declared on a specific window, by clicking User Defined
Types on the Operations tab. Such data types are structures created from pre-defined data types. For more information
about user-defined data types, please check topic User-Defined Data Types.
Byte Order
In addition to protocol's reading and writing functions and the data type used, each operation also allows setting
additional manipulations to bytes, related to a byte order, that is, the order of bytes inside every value. These are called
swap options, Swap Bytes, Swap Words, and Swap DWords. Such options only need to be enabled for devices that do not
respect protocol's default byte order.
The Modbus protocol defines that its 16-bit values always use a byte order known as big endian, also known as Motorola,
because it is used by that manufacturer. The big endian standard always defines a byte order so that the most significant
byte of each value comes first. Thus, as an example, when reading the hexadecimal value 1234h, the device first sends the
most significant byte 12h and then the least significant one, 34h.
For devices that do not implement protocol's default byte order, and use another one known as little endian or Intel, data
is sent with the least significant bytes first. Users must then enable those swap options to reverse that byte order.
There are also devices that use different byte orders for 32- and 16-bit types. For devices that, for example, use Modbus'
default byte order (big endian) for 16-bit types, but provide 32-bit data with the least significant Word first (little endian),
· For devices that provide data using Modbus' default byte order, Motorola or big endian, with the most significant
bytes first, users must left all swap options disabled. This is the most common situation
· For devices using another byte order standard, with the least significant bytes first, little endian, users must enable all
swap options referring to the data type used, that is, for 16-bit types, enable the Swap Bytes option. For 32-bit data
types, enable the Swap Bytes and Swap Words options. For 64-bit types, all these swap options must be enabled
· In the least common case, devices that use different byte orders for different data sizes, providing, for example, the
most significant byte of each Word first, but the least significant Word of each DWord first, then users must evaluate
in which case each swap option must be enabled, so that it converts a value returned by a device to protocol's
default big endian format
NOTE
All mentioned swap options have no effect for Bit data types or for data types with an eight-bit size, Byte, Char, and
Int8. Swapping occurs inside every data type, that is, the Swap Words option has no effect for 16-bit data types, as well
as the Swap DWords option has no effect for 32-bit data types. BCD data types also do not allow swapping.
To check if a device uses some unusual byte order format, check its manufacturer's documentation. In case this
information is not found on that documentation, please contact manufacturer's technical support.
The topic Frequently Asked Questions contains tips on byte order configurations for some devices that are known to
use swap options.
Bit Mask
The Use Bit Mask option is an advanced feature, used in specific and unusual cases where users want to read only a bit
from the value returned by a device, but they cannot use application's bit mapping.
For most users, application's bit mapping fields are the best alternative to access bit masks, and there is no need to use
this Driver's feature.
This feature was initially created to allow reading bits from Holding Registers by specialized E3 libraries, in situations that
prevented the usage of application's bit mapping.
In this case, this Driver reads a value from a device normally and then masks it, to return to Tag's Value field only the
specified bit, 0 (zero) or 1 (one). The definition of a bit number to return is performed on I/O Tag's N3/B3 parameter.
The Use Bit Mask option can only be used with integer data types with 16 bits or more (Int16, Int32, Word, or DWord).
In addition, operations that enable this option can only be used for reading. The Modbus function for writing operations
(Write) that use this mask option can be defined as None.
By default, when a new Driver is added to an application, that Driver is already created with default operations, described
on the next table.
Default operations
These operations are the most commonly used, and operation 1 (one) is the most common one. For most devices,
select all operations needed among the ones provided by default, there is no need to create new operations or change
the configuration of these default operations.
To configure this new operation, select a number for it, used on I/O Tag's N2/B2 parameter, which function to use for
reading, and which function to use for writing, as well as informing a data type to be read or written by this Driver. Notice
that, when clicking Add, this Driver already suggests a value that is not in use for this new operation.
For more information about supported data types, please check topic Supported Data Types. All other fields can be
configured as needed. The next table contains a description of these fields.
OPTION DESCRIPTION
Size A size in bytes of each element of the selected data type
must be informed. This field is automatically filled in for
fixed-size data types, such as Byte, Word, and Int16, and it
must be filled in for String and BCD data types. For
Strings, this size defines exactly the number of bytes sent
or received for each String value, that is, for each Tag or
Block Element. If the String read or written has a shorter
size, the remaining bytes are filled in with zeroes to
complete its configured size. The String data type in this
Driver has no defined maximum limit size, this limit is the
maximum allowed by the protocol for frame's data area
of a certain function
Swap Bytes Indicates that this Driver must reverse the byte order, one
by one, to retrieve a value
Swap Words Indicates that this Driver must reverse the byte order, two
by two, in Words, to retrieve a value
Use Bit Mask Enables a bit masking of registers, using the N3/B3
parameter. This option only affects readings and can only
be used with integer data types, signed or unsigned, with
at least 16 bits of size, Int16, Int32, Word, or DWord.
Operations with this option enabled cannot be used for
writing. For most users, it is recommended to use
application's bit mapping, and leave this option
deselected. For more information, please check the
specific section
Protocol functions that can be configured in operations' Read and Write fields are described on topic Supported
Functions. The next table describes each one of the available options.
OPTION DESCRIPTION
Import Configuration This option allows importing configurations for operations
from versions prior to Modbus Master/Slave Driver
version 2.0, which stored these configurations on a
modbus.ini file. This Driver does not use INI files anymore
to store such configurations, which are now stored on the
application file. For more information, please check topic
Import and Export Operations
Export Configuration This option executes the opposite operation of the
previous option, generating an INI file containing all
operation configurations, in the current format or in the
same format of this Driver's previous versions. This way,
users can store operation configurations of a certain
device on a file, and these configurations can be used by
other applications. For more details, please check topic
Importing and Exporting Operations
Show Operations in Tag Browser If this option is not selected (default), templates of Tags
configured by Strings (Device and Item fields) are
displayed on Tag Browser. If it is selected, templates of
Tags numerically configured (N/B parameters) are
displayed on Tag Browser. When creating new instances of
this Driver, this option is deselected by default. In legacy
applications, when this Driver's version is updated from a
version previous to 3.1, this option is already selected,
keeping the behavior of previous versions
Add Adds a new operation to the list
Edit Updates the selected operation on the list, which is
equivalent of double-clicking an item
Remove Removes the selected operation from the list
As explained on topics String Configuration and Operations Tab, the Modbus protocol itself only supports Bit and
Word data types (16 bits) for the most commonly used functions implemented by this Driver (the only exception is
currently function 7). All other data types of this Driver are converted to Word at protocol's level, for reading from or
writing to a device or slave device.
Also notice that this Driver supports User-Defined Data Types, defined as structures with elements composed by the
native data types listed on the next table.
On the next table, data types use the same denominations of mnemonics for the data type field, when Tags are
configured by Strings. For the old numerical configuration, the same denominations are also used on Data column of
this Driver's configuration window, on the Operations tab. In some cases, frequent alternative denominations are
displayed between parentheses.
Double (or Real) -1.7E308 to 1.7E308 64-bit floating point (IEEE 754)
String Does not apply Text in ANSI format, with a determined
number of eight bit ASCII characters
(Chars)
BCD Check description BCD (Binary-Coded Decimal) numerical
value. When using this data type, an
application must provide a positive
and integer decimal value, sent in BCD
format, respecting the specified size.
The Size field, for BCD types, refers to
the number of bytes sent to represent
a value. As in BCD encoding each
figure is converted to a nibble, then
the allowed values must have a
maximum number of figures equal to
double the size of the value specified
in the Size field, that is, if a value of 2
(two) is selected for the Size field, the
maximum value that can be sent is
9999. Likewise, if Size is equal to 4
(four), the maximum value is then
99999999. Allowed values for the Size
field for BCD types are two (two,
Word) and four (four, Double Word).
For more information about the BCD
encoding, please check topic BCD
Encoding
GE_events Check description Data type used when reading an event
buffer (SOE) from a GE PAC RX7 PLC.
Its definition is only allowed for
operations that use the special reading
function GE SOE. These events are
returned as blocks with two Elements,
with timestamps defined by the
controller. For more information,
please check topic Reading an Event
Buffer from GE PAC RX7 Controllers
Bit 0 (zero) or 1 (one) This data type is automatically selected
when a bit-access function is selected.
Bit-access functions are 01, 02, 05, and
15. The Size field is not used for Bit
types. When using this data type, each
Tag or Block Tag Element represents a
bit
SP_events Check description Data type used when reading events
(SOE) in Schneider Electric relays from
SEPAM 20, 40, and 80 series. Its
definition is only allowed for
operations that use the special reading
function SP SOE. These events are
UTC32 1/1/1970 00:00 to 31/12/2035 Date and time data type represented
23:59:59.999 (please check the next as an unsigned 32-bit integer, DWord
note) or UInt, with seconds since 1/1/1970
00:00. This format does not represent
milliseconds, which are always
considered as 0 (zero)
Int16_sm -32767 to 32767 Signed 16-bit integer, with magnitude
signal
Int32_sm -2147483647 to 2147483647 Signed 32-bit integer, with magnitude
signal
Int52 and UInt52 -9007199254740992 to 52-bit integers converted to Double
9007199254740992 (floating point)
Str_I64 "-9223372036854775808" to 64-bit signed integers converted to
"9223372036854775807" String (text) format
Str_U64 "0" to "18446744073709551615" 64-bit, unsigned integers converted to
String (text) format
GenTime is a date and time data type originally defined and added to this Driver for use with Elipse Software's Generic
SOE Reading Algorithm. It is, however, a generic data type that can be easily used with almost any PLC.
In an application, that is, in values of Tags and Block Tag Elements, as well as in Tag's Timestamp field, this data type, as
well as all other date and time data types of this Driver, is represented by an application's native date and time data type.
For more information about other date and time data types supported by this Driver, please check topic Supported Data
Types. For more information about application's date and time data types, please check their respective user's manual,
because there are some differences between VBScript used in Elipse SCADA and VBScript used in E3 and Elipse Power.
In the PLC or slave device, this data type is represented by a structure composed by four 16-bit registers, or eight bytes,
as displayed on the next table.
Structure of registers
The base address, offset 0 (zero), for attribution on Tag's N4/B4 parameter accessing data, contains the year. The next
register, offset 1 (one), contains the day as the most significant byte and the month as the least significant byte. The offset
2 (two) contains the hour represented in the most significant byte and the minutes in the least significant byte. The fourth
register contains the four most significant bits of the Word representing seconds, and the remaining bits, the two least
significant of the most significant and the integer's least significant byte, representing milliseconds.
Notice that each Tag referencing this data type forces this Driver to read a block of four Modbus registers in a device to
represent the value of each Tag or Block Element to return a valid value.
Advantages of this data type are its simplicity, because it is easily generated in a PLC ladder, its milliseconds precision,
and its relative compression, as it does not need native support by the PLC or slave device.
User-defined data types, or structures, after configured on the User Defined Types configuration window, can be used by
this Driver's operations the same way as pre-defined data types.
These data types are in fact structures whose elements may have different native data types, that is, a user-defined data
type is merely a structure defined based on this Driver's pre-defined data types, native or built-in data types, allowing
users to configure Block Tags where each Element may have a different native data type.
Users can use almost all data types pre-defined by this Driver in their structures. The only data types not allowed are Bit
data types, eight-bit data types, variable-size data types, such as String and BCD, and event data types linked to specific
SOE functions.
Once a data type is defined, users can link it to any Tag, as long as it uses Modbus functions supporting Words, that is, it
is not allowed to link a user-defined data type to an operation that defines as its reading function (Read) the 01 function,
for example, because that function only reads bits.
In addition to the definition of structure elements, whose values are returned in Block Elements, users can also define the
type of a Tag's timestamp, as well as the default address for that structure, address that is used for the B4 parameter of
Tags available using E3's or Elipse Power's Tag Browser.
Applications
User-defined data types were originally implemented for use with Elipse Software's Generic SOE Reading Algorithm
(Gen SOE), as this algorithm performs a reading on data structure tables.
In addition to using with SOE's generic algorithm, this feature can also be used to group different data types on a single
Block Tag, optimizing communication in applications without Superblocks, such as Elipse SCADA, or if the device in use
for some reason does not allow using Superblocks. For more information, please check topic Superblock Reading
(Grouping).
Configuration of user-defined data types is performed on a specific window, by clicking User Defined Types on the
Operations tab of this Driver's configuration window, as shown on the next figure.
This window to configure user-defined data types allows editing files with structure configurations. When opening this
window for the first time, it displays the default configuration file, with comments, which defines three example types that
appear commented with multiple-line comments "/*" and "*/", as explained later.
The next figure displays the configuration window for user-defined data types, with a small file defining these three
example data types.
Notice that line comments always start with "//", identifying what is on the right, on the same line, as a comment, following
the pattern for line comments of the C++ programming language, which is also used for other languages such as Java
and C#.
Comments with multiple lines are also supported, still following the same C++ language syntax, starting by "/*" and
finishing by "*/". Notice that the example file that accompanies this Driver already applies that comment format to its
example types, leaving them commented by default. Remove the lines indicated by "/* Sample types entirely commented
by default" and "*/", without quotation marks, so that all three example data types are ready to use.
As the text of the configuration file changes, the status bar displays the result of this file's syntactical analysis, in real-time.
This status bar displays a "Status: OK!" message if no errors are detected in this file.
The line and column of cursor position in the edit box are always displayed on the right side of the status bar. Errors
displayed on the status bar always reference the line and column number where it was detected.
This check can be also fully performed by clicking Verify and, in case of any error, cursor is then automatically placed on
the error line.
The definition of each type has the following syntax, in which the elements inside brackets are optional:
struct <Type Name>
{
[timestamp = <date and time type>;]
[DefaultAddress = <address>;]
<type> [name of element 1];
<type> [name of element 2];
<type> [name of element 3];
[...]
<type> [name of element n];
}
Where:
· struct: Keyword, lower case, starting the definition of a user-defined data type.
· timestamp: Optional field indicating that this structure contains a device-defined timestamp, which must be returned
in Tag's Timestamp property. Each structure can have only one timestamp. The order in which it appears on this
structure affects the position in which this field is read in the frame returned by a device. Notice that in Tags this value
is returned only in the Timestamp property. Any date and time data types supported by this Driver can be defined. In
the current version, this Driver supports date and time data types GenTime, Sp_time, UTC64d, and UTC32. For more
information about data types, please check topic Supported Data Types
· DefaultAddress: Optional field specifying a default address value, used to fill the B4 parameter of Tags in Tag
Browser referencing operations containing this structure. Address values can be provided in decimal or hexadecimal
format. To use the later format, users must precede the number with the "0x" prefix, such as using "0x10" to encode
the decimal value 16 to hexadecimal
· <date and time type>: Pre-defined date and time data types for this Driver, which can be used as a timestamp by a
slave device. In the current version of this Driver, native data types GenTime, Sp_time, UTC32, and UTC64d are
accepted
· <type>: Element's data type. It must be defined as one of the pre-defined data types of this Driver, and written as it
appears on the Data option, on the configuration window for operation parameters, respecting lower and upper
case. Bit data types, eight-bit data types, and variable-size data types, such as BCD and String, are not allowed
· [name of element]: Optional parameter defining a name for each Block Element. If defined, determines a name for
Block Elements in Tags displayed in E3's or Elipse Power's Tag Browser. If not defined in structure's declaration, this
Driver then sets default names to Elements in Tag Browser, with the keyword "Element" followed by the index of that
Element in the Block, such as "Element1", "Element2", and so on
The Import File and Export File options allow importing and exporting a configuration file with user-defined data types
to text files on disk. These options can be used to create backup copies of a file, or to share it among several Drivers.
This file is always saved and read in Windows default ANSI format, using the Windows-1252 character set. Future versions
of this Driver may include support for other formats.
In addition to copying a file to disk, users can also use shortcut keys CTRL + A (Select All), CTRL + C (Copy), and CTRL +
V (Paste) to copy and paste this file's content to another Text Editor.
The Load Default Configuration option loads the default configuration file again in the editor, the same file loaded when
the configuration window is opened for the first time.
NOTE
When clicking Cancel, all changes performed on the file are discarded by this Driver. By clicking OK, this file is then
stored in the application. This operation performs a full check on this file and if any error is identified, this error is then
displayed and this window is not closed. If users want to save these changes with pending errors, export this file or copy
and paste it to another Text Editor.
Names for user-defined data types can be used as mnemonics for the Type field in the Item field, such as with Driver's
native data types, as long as this name has been previously declared, as defined earlier in this topic.
For more information on Tag configuration using Strings, please check topic String Configuration. Example:
1. Read or write Holding Registers (functions 03 and 06) of address 100 from a device with Id 5, interpreted as a user-
defined data type named "mytype", with Slave Id in the Item field:
b. Item: "5:shr100.mytype"
NOTE
Swap options, or byte order, for user-defined data types are only effective on the elements of the defined structure, not
on the entire structure, that is, if the Swap Words option is enabled, all elements with more than 16 bits have their
Words swapped. 16-bit elements, however, are not changed.
After defining new data types in the configuration file on the User-Defined Types window, these data types are available
for use in this Driver operations. Remember that only operations that use Modbus functions for access to 16-bit registers,
such as functions 03, 04, 06, and 16, allow user-defined data types.
The next figure displays the configuration of a new operation that uses a user-defined data type, or structure, named
TYPE3, showed on the previous example, after clicking Add.
NOTE
Swap options for user-defined types are only effective on the elements of the defined structure and not on the entire
structure, that is, if the Swap Words option is enabled, all elements with more than 16 bits have their Words swapped.
16-bit elements, however, are not changed.
After defining a new operation, by using the new type TYPE3, define a Block Tag with that same data type and size equal
to the number of elements of that structure, as shown on the next figure.
As this figure suggests, click on this Driver's Design tab to open Tag Browser and drag the desired data type from
the list Tags available from driver to the list Tags from current project.
Event-Reported Reading
User-defined data types or structures are generally used to define events in a PLC's memory, and can be used with Elipse
Software's Generic SOE Reading Algorithm. However, if users want to read events organized in a PLC's memory, such as
a sequence of structures, in an operation that only uses protocol's public reading function, that is, without using special
functions with the SOE algorithm, such procedure can be performed in these ways:
· Block Reading: Create a Block with a number of Elements that is a multiple of the number of elements of user's data
structure. For example, a user-defined data type or structure with two elements that represent events collected on an
arrangement in a PLC's memory. If users want to read a block with five events, they must define a Block Tag with 10
Elements. Thus, a single reading from this Tag retrieves all events at once
· Event-Reported Reading: Uses a sequence of Tag's OnRead events to read a data block. With it, considering the
example on the previous item, instead of creating a Tag with 10 Elements, users only need to create a single Block
Tag with two Elements, configuring its B3 parameter as "5". This way, when performing a Tag reading, E3 calls Tag's
OnRead event five times, and at each call the Elements and properties of this Block Tag contain data related to a
specific event. The most common usage for Tags reported by events is storing events read directly from a historical
database. This is easily performed using Historic's WriteRecord method previously linked to this Tag, on the OnRead
event of the event-reported Tag. For more information, please check topic about Event-Reported Tags on E3 User's
Manual
In other words, every I/O Tag using structures and using a protocol's public reading function, because this resource
does not work for special SOE functions, becomes an Event-Reported Tag if its B3 parameter is configured with a non-
null value.
For more information about I/O Tag configurations, please check topic Configuring an I/O Tag.
IMPORTANT
When reading mass memory events in event-reported Tags in E3 or Elipse Power, disable Tag's dead band, that is, the
EnableDeadBand property configured as False, and also the linked Historic object, that is, the DeadBand property
equal to 0 (zero), to avoid loosing events with close values. It is also important to disable the historic by scan, that is,
configure the ScanTime property as 0 (zero) in E3 or Elipse Power. This ensures that new events are only stored using
the WriteRecord method, executed in Tag's OnRead event, thus avoiding duplicated events.
Importing and exporting operations can be performed on this Driver's Operations tab, by clicking Import Configuration
or Export Configuration, as shown on the next figure.
These options allow importing and exporting operation configurations displayed on the Modbus Operations frame to INI
files.
On versions previous to 2.00 of this Driver, the configuration of operations were performed on a modbus.ini file, which
was loaded during the initialization of a Driver object. modbus.ini files of these old versions still can be loaded on this
Driver's current version, by using the import option.
Importing
Importing configuration files is very simple. Click Import Configuration and select an INI file. This Driver must load
operation configurations, which immediately appear on the Modbus Operations frame. This Driver allows importing files
generated by previous versions.
Exporting
Exporting files with operation configurations can be performed to share the same operation configurations among
different Driver objects, as well as performing backup copies of operation configurations of a certain device.
Another possible use is exporting configurations to a modbus.ini file compatible with previous versions of this Driver,
allowing to load these configurations on previous versions. This is not advisable but, if inevitable in case of legacy
applications, users must notice the next considerations.
When clicking Export Configuration, a window with the options shown on the next figure is opened.
Export options
On this window, users must select between exporting based on the new format, the New format with type mnemonics
option, with displayed data types defined as Strings (mnemonics), or based on the old format, the Old format with
types' numeric codes option, in which data types were identified by a numerical value, corresponding to the position
where they appeared on the Data option of the Operations tab.
This new format is more legible, making it easy to debug, and is used on the most recent versions of this Driver, and it is
the most recommended option.
The old format, on the other hand, must be selected only if it is indispensable to export for versions previous to version
2.08 of this Driver.
Notice that, to export modbus.ini files successfully to load them to versions previous to 2.00, operations cannot define any
new data type not implemented on the destination version, nor define operations that use the Use bit mask parameter,
or the import operation may fail.
Generally, it is recommended to avoid exporting configurations to previous versions, preferring updated versions of this
Driver.
· Enable control and data registers grouping (default True): Enables grouping control and data registers, to
perform the minimum possible number of readings. If this option is enabled, this Driver starts reading tables already
trying to read the maximum number of protocol-allowed registers, be them control or data registers, and possibly
reading the entire table in a single reading. Such procedure usually optimizes Tag scanning the same way as
Superblocks, because the time spent for reading large blocks is usually less than the time needed to perform several
readings of the same amount of data, although this may depend on the PLC. ATOS PLCs do not allow grouped
reading of control registers and data structures, thus requiring this option to be disabled
Available parameters
PARAMETER TYPE
ModiconModbus.ModbusMode Integer. Possible values are 0: Modbus RTU, 1: Modbus
ASCII, or 2: Modbus TCP
ModiconModbus.Olderaddr Boolean. Possible values are 0: Data is addressed from 0
(zero) or 1: Data is addressed from 1 (one)
ModiconModbus.UseDefaultSlaveAddress Boolean. Possible values are 0 (zero) or 1 (one)
ModiconModbus.DefaultSlaveAddress Unsigned integer
ModiconModbus.UseSwapAddressDelay Boolean. Possible values are 0 (zero) or 1 (one)
For more information about Offline configurations at run time, please check topic Documentation of I/O Interfaces.
Configuring Tags
This topic describes configurations for several types of Tags supported by this Driver. Tags are divided into categories
Configuring an I/O Tag and Configuring Special Tags.
I/O Tags allow reading and writing Modbus registers from and to slave devices, by using Modbus protocol functions, or
even special functions. This Driver does not differentiate between Block and simple Tags, in case of I/O Tags, that is, I/O
Tags work the same way as a Block Tag with a single Element.
Data is read from a device using protocol-supported formats, that is, registers with integer values of 16 bits, bytes, or
sets of bits, depending on the protocol's function used. For more information about protocol functions, please check
specifications at protocol's official website.
· String Configuration: This is the newest method that can be used with Elipse E3, Elipse Power, and Elipse OPC
Server, and recommended for new projects. It is not supported by Elipse SCADA
String Configuration
The String configuration of I/O Tags is performed using the Device and Item fields of each Tag.
That new configuration method does not work with Elipse SCADA, which still uses the old numerical configuration, with
N and B parameters.
N and B parameters are not used when configuring by Strings and they must be kept in 0 (zero).
Configuration by Strings makes Tag configuration more readable, making it easy to configure and maintain applications.
Block Reading
Tags configured by Strings can be simple Tags or Block Tags, with their Device and Item fields with the same syntax.
Device Field
In the Device field, the Slave Id, or device's identification address, must be provided as a number between 0 (zero) and
255 followed by a colon, such as "1:", "101:", or "225:".
Please remember that, in Modbus RTU Serial protocol, the Slave Id "0" (zero) is reserved for broadcasting, which only
makes sense if used by writing operations, because there is no return from devices, or else there would be conflicts.
Optionally, the Slave Id may appear at the beginning of the Item field, explained later, and in this case the Device field
must be kept empty. This option is detailed next.
Item Field
The Item field must provide all addressing and operation information to be performed by a Tag, using the following
syntax, in which parameters between brackets are optional.
<address space><address>[.<type>[<type size>]][.<byte order>][/bit]
As mentioned earlier, users can alternatively provide a Slave Id at the beginning of the Item field, such as the next
example.
<slave id>:<address space><address>[.<type>[<type size>]][.<byte order>][/bit]
In this case, as already explained, users must keep the Device field empty.
The next examples show the most common usage cases. Notice that quotation marks must not be added to the
application.
1. Reading or writing a Holding Register, functions 03 and 16, on address 100 of a device with Id 1 (one), and Slave Id
provided in the Device field:
a. Device: "1:"
b. Item: "hr100"
b. Item: "3:hr120"
3. Reading or writing a Coil, functions 01 and 15, on address 65535 (FFFFh) of a device with Slave Id 4 (four), here
provided in the Item field:
String-configured Tags
Mandatory fields for all Tags are described next and individually detailed later in this topic:
1. Address space: A mnemonic defining a set of protocol's reading and writing functions to use. Please check the table
with all supported mnemonics later on this topic.
2. Address: A numerical value identifying the item's address, register or bit, to read or write within the defined address
space. These values can be provided in decimal, hexadecimal, or octal. For decimal values, no prefix is needed, or
optionally a "&d" prefix can be used. For hexadecimal values, use the "&h" prefix, such as "&hFFFF". For octal values,
use the "&ho" prefix, such as "&o843". This address can have an offset relative to the address sent in the
communication frame, which depends on the convention used by the manufacturer. When in doubt about addressing
conventions, please check topic Addressing Tips (Modbus Convention). Particularly, check whether the device
implements the default offset of protocol's Data Model. Please check the Data Address Model Offset option on the
Modbus tab.
The next fields are optional, used for extensions to the default protocol or for compatibility with devices not fully
compliant with the protocol, and they are also individually detailed later in this topic:
1. Type: Defines how bytes from the data area of the communication frame must be interpreted. If omitted, the default
types of the protocol for the respective functions are used, that is, Word for functions to access registers and Bit for
functions to access digital data, Coils and Discrete Inputs. Please check the mnemonics table for all supported types
later in this topic.
2. Type size: Users must specify this field only for variable-size types, such as BCD and String. Its numerical value
indicates the size of the type in bytes.
4. Bit: Allows returning a specific bit of an integer value, which obviously only makes sense in Modbus functions returning
integer values or Words. Usually, users are advised to not use this feature, preferring application's bit mapping. Bit 1
(one) is the least significant and, the greater the value, the most significant is the bit. The maximum allowed value
obviously depends on the type size, which is currently 64 for Double types. This field corresponds to the old Use bit
mask option on numerical configuration. Please check more information on this option on topic Operations Tab.
Exceptions
Modbus protocol's functions 20 and 21, which access files, use a slightly different syntax from the one described
previously:
fr<file>.<register>[.<type>[<type size>]][.<byte order>][/bit]
Example:
Specifically for the SP SOE special function (Sepam SOE), to read all events:
spsoe<event type>.<initial addr.>[.<type>][.<byte order>][/bit]
Specifically for the SP SOE special function (Sepam SOE), to read events from specific points:
ptspsoe<event type>.<event addr.>
Specifically for the GE SOE special function (GE PAC RX7 SOE):
gesoe<tag type + point index>.<queue base addr.>
Please check specific topics about the special functions mentioned previously for more information about configuring the
respective Tags using Strings.
Addressing Space
Instead of explicitly defining Modbus functions or special reading and writing functions to use, as performed on the old
numerical configuration and its concept of operations, when configuring using Strings, users define an addressing
space through mnemonics listed on the next table, already linked to protocol's pre-defined functions and their respective
native data types.
Data Types
The table on the previous section lists all protocol's native data types, according to the Modbus functions used, as well as
some specific data types used in protocol's non-standard special functions. For Tags returning these native data types,
the Data Type parameter can be omitted from the Item field's String.
If users must interpret native data in a different way, which is common among devices using Modbus, they must specify a
data type to use, as explained in this section.
A list with all native data types supported by this Driver, as well as their description, can be checked on topic Supported
Data Types.
The next table lists all mnemonics used in the <type> parameter of the Item field for each supported data type, Driver-
native, and also an alias or an alternative name.
Int8 int8 i8
Int16 int16 i16
Int32 int32 i32
Word or UInt word u16
DWord or ULong dword u32
Float float f
Float_GE float_GE fge
Double or Real double d
Int52 int52 i52
UInt52 uint52 u52
String string s
Str_I64 str_i64 s_i64
Str_U64 str_u64 s_u64
BCD BCD bcd
GenTime GenTime gtm
UTC32 UTC32 -
In addition to the data types listed on the previous table, users can also provide mnemonics for user-defined data types
or structures. For more information, please check topic User-Defined Data Types.
To use user-defined data types in the Item field, however, the names of these data types must not be case-insensitive, as
the Item field does not differentiate upper and lower case. If that happens, this Driver does not allow using these data
types in the Item field. For more information, please check topic User-Defined Data Types.
Examples
1. Reading or writing Holding Registers, functions 03 and 16, to or from address 100 of a device with Id 1 (one),
interpreted as a DWord, with Slave Id in the Device field:
a. Device: "1:"
2. Reading or writing Holding Registers, functions 03 and 16, to or from address 150 of a device with Id 3 (three),
interpreted as a Float, with Slave Id in the Item field:
3. Reading or writing Holding Registers, functions 03 and 16, to or from address 1500 of a device with Id 5 (five),
interpreted as a Double, with Slave Id in the Item field:
4. Reading or writing Holding Registers, functions 03 and 06, to or from address 100 of a device with Id 5 (five),
interpreted as a Word, with Slave Id in the Item field:
b. Item: "5:shr100" or "5:shr100.u16", or "5:shr100.word". Notice that, because it is a Word, Modbus protocol's native
data type for Holding Registers, the data type can be omitted
5. Reading or writing Holding Registers, functions 03 and 06, to or from address 100 of a device with Id 5 (five),
interpreted as a user-defined data type named "mytype", with Slave Id in the Item field:
b. Item: "5:shr100.mytype"
BCD and String data types, as they have a variable size, demand the specification of a type size, in bytes, right after their
data type.
Notice that only data types 2 (two) and 4 (four) are valid, that is, 2 (two) and 4 (four) bytes or 4 (four) and 8 (eight)
digits for BCD data types. Examples:
1. Reading or writing Holding Registers, functions 03 and 16, to or from address 100 of a device with Id 1 (one),
interpreted as a 10-byte-String, five "hr" registers, with Slave Id in the Device field:
a. Device: "1:"
b. Item: "hr100.s10"
2. Reading or writing Holding Registers, functions 03 and 16, to or from address 100 of a device with Id 1 (one),
interpreted as an eight-digit-BCD, four bytes or two "hr" registers, with Slave Id in the Item field:
b. Item: "1:hr100.bcd4"
Byte Order
As explained on the syntax of the previous section, users can add an optional byte order parameter in Tag's Item field to
specify a byte ordering for devices that do not comply with protocol's standard. If a device complies with Modbus
protocol's default ordering, this field can be omitted.
If distorted values are read, which can be observed on early tests with a device, and if these values, converted to
hexadecimal, are correct after inverting the position of some bytes, please read this section carefully.
The Modbus protocol uses the big endian format by default, where values are formatted with their most significant bytes
coming first in communication frames. This is the default format used by this Driver. There is, however, a large amount of
devices in the market that use values with other combinations for byte ordering.
As an example, if this Driver reads a value equal to "1234h", or "4660" in decimal, by default this Driver waits that data to
be sent with a byte sequence equal to 12h and 34h. If a device uses an inverted default, which is called little indian, then
the byte 34h is sent first and then the byte 12h, and this Driver may interpret it as 3412h, or 13330 in decimal, unless these
two bytes were inverted before interpreting.
For 32-bit values, there are cases when Word values are swapped, but with bytes inside Word values keeping their default
ordering. For example, the value 12345678h can be received as 56781234h. There are also other situations, with several
different combinations for ordering.
To allow communication with these devices that do not follow protocol's standard byte order, this Driver allows users to
configure Tags by specifying the standard to use.
The byte order parameter corresponds to the swap options from the old numerical configuration, and it may have
values "b0", "b1", "b2", "b3", "b4", "b5", "b6", "b7", "alias", or else "alias2". For more information, please check the next
table.
The next table indicates that swap operations, Swap Bytes, Swap Words, and Swap DWords, are performed for each
ordering mnemonic, from "b0" to "b7".
Swapping operations
That is, "b0" does not perform any swap operation on data bytes, keeping the original ordering of bytes received from a
device, which is equivalent to deselecting the swap options on the Operations tab from the old numerical
configuration.
"b1", on the other hand, performs a byte swapping, two by two, that is, when receiving a Word, an unsigned 16-bit
integer, with the hexadecimal value 0102h, the value returned to the Tag is 0201h, with its bytes swapped. It is equivalent
to the old Swap Bytes option.
"b2" performs a Word swapping, that is, bytes two by two, which obviously affects only 32-bit data or larger. This is the
same as selecting the Swap Words option from the old numerical configuration. As an example, if the value 01020304h is
received from a device, the value used for application Tags is 03040102h.
"b3" performs byte and Word swapping, which is equivalent to the old Swap Bytes and Swap Words options enabled
simultaneously. In this case, the value 01020304h becomes 04030201h.
Likewise, "b4" performs a DWord swapping for 64-bit values, which corresponds to the Swap DWords option from the
old numerical configuration, that is, the value 1122334455667788h is interpreted as 5566778811223344h, and so on for
all other codes.
In most cases, a device's documentation specifies the byte order used, or how to configure it, because there are devices
that allow that configuration.
In cases where device's documentation does not contain a configuration, users must contact manufacturer's technical
support.
If there is no reliable information, users must perform empirical tests, analyzing the returned values, in hexadecimal,
comparing them to the expected values, and then observing if there are byte order inversions that may explain the
differences.
1. For devices providing data using Modbus protocol's default byte order, big endian or Motorola, with the most
significant bytes coming first, users must omit this parameter or define it as "b0". This is the most common situation.
2. For devices using another standard for byte order, with the least significant bytes coming first, little endian, users must
enable all swap options referring to the data type used, which corresponds to the "b7" mnemonic.
3. In the least common case, there are devices that use different byte orders for different data sizes, providing for
instance the most significant byte of each Word first, but the least significant Word of each DWord first. Therefore,
users must evaluate in which case each swap option must be enabled, thus converting the value returned by the device
to protocol's default big endian format.
NOTE
All mentioned swap options have no effect for Bit data types or eight-bit-size types, such as Byte, Char, and Int8.
Swapping occurs inside each data type, that is, the Swap Words option has no effect for 16-bit data types, as well as the
Swap DWords option has no effect for 32-bit data types. BCD data types do not allow swapping operations either.
The topic Frequently Asked Questions lists a few known cases, already observed on technical supports. Examples:
1. Reading or writing Holding Registers, functions 03 and 16, to or from address 1500 of a device with Id 5 (five),
interpreted as a Double without byte inversion, with Slave Id in the Item field:
2. Reading or writing Holding Registers, functions 03 and 16, to or from address 1500 of a device with Id 5 (five),
interpreted as a Double with the least significant byte of each Word coming first, and with Slave Id in the Item field:
3. Reading or writing Holding Registers, functions 03 and 16, to or from address 1500 of a device with Id 5 (five),
interpreted as a Double with the least significant byte coming first, or little endian, and with Slave Id in the Item field:
In addition to all Tags described previously, users can configure this Driver's Special Tags using Strings, which are
described in details on their specific topics. Please click an item for more information.
Special Tags
Numerical Configuration
Numerical configuration is performed using N and B parameters of I/O Tags, not using the Device and Item fields
available in Elipse E3 or Power, which must be kept empty.
This configuration method must be used in Elipse SCADA and in legacy applications. In applications using newer
products, such as Elipse E3, Elipse Power, or Elipse OPC Server, it is recommended to use String configuration.
I/O Tags configured numerically reference operations previously configured on configuration window.
Operations
As already explained on topic Operations Tab, this Driver supports other data types in addition to protocol's native data
types. For this reason, the concept of Operation was created on this Driver.
On operations using Modbus functions that read and write bits, such as protocol functions 1, 5, and 15, this Driver always
map binary values of each bit to Block Elements, where each Element represents the value of a specific bit.
Operations with eight-bit data types, such as the Byte data type, always imply, obviously, on reading at least two bytes, a
16-bit Modbus register. To prevent surprises, this Driver requires that eight-bit data writings be performed in pairs, that
is, writing Blocks with an even number of Elements. These operations must be referenced using I/O Tag's N2/B2
parameters, as described later.
The following configuration applies to I/O Tag's N parameters, as well as to I/O Block Tag's B parameters.
· N1/B1: Address of a slave device (PLC) on the network (Slave Id). This address can vary from 1 (one) to 247 for Serial
networks via Modbus RTU or vary from 0 (zero) to 255 for direct communication with Ethernet devices via Modbus
TCP. For Serial mode, the ID with a value of 0 (zero) is reserved for Broadcast mode, sending a message to all slave
devices (PLC) on the network. In Ethernet, in Modbus TCP mode, the address generally used is the IP address, but
the Slave Id can still be used when the IP address references a gateway connected to a device network, usually an
RS485 network, with Modbus RTU, using a gateway capable of performing a conversion from Modbus TCP to
Modbus RTU
NOTE
In Serial Modbus RTU, the Broadcast mode with N1 equal to 0 (zero) cannot perform readings, only writings. In this
mode all devices on the network are addressed, receiving the written value and not returning any response, to avoid
network conflicts.
· N2/B2: Operation code. References an operation added on this Driver's configuration window. For more information,
please check topic Operations Tab
· Modbus functions 20 and 21: For operations that use these functions for file access, the functions 20 and 21, the
N3/B3 parameters specify a file to access.
· Use Bit Mask: For Tags referencing operations with the Use Bit Mask option enabled, the N3/B3 parameter
specifies the number of the bit to access. For more information, please check topic Operations Tab.
· User-Defined Data Types: For operations that use structures, if the B3 parameter is greater than 0 (zero), it
defines the return of an event-reported block array, by using a sequence of Tag's OnRead events. For more
information, please check topic User-Defined Data Types.
· Gen SOE Special Function: For operations that use the Gen SOE special reading function, the N3/B3 parameter
indicates the size of the linked table in the PLC or slave device memory, as the maximum number of supported
events. For more information, please check topic Elipse Software's Generic SOE Reading Algorithm.
· N4/B4: Register, variable, or bit address on the slave device (PLC) to read or write, according to device's register
map. For more information, please check device's documentation. It is important to correctly configure the Data
Address Model Offset option. For more information, please check topic Modbus Tab and check if manufacturer's
documentation does not use offsets used by old Modbus devices, known as Modbus Convention.
· Size/Index (Block Tags only): Each Block Element represents a data value of a type defined in the operation used, in
the N2/B2 parameter. Notice that this protocol only supports Bit or Word types. Thus, if this operation selects the
DWord type, 32-bit, for each Block Element, this Driver must read two consecutive registers from a device.
Special Tags
In addition to I/O Tags, that is, Tags referring to operations, there are also special Tags to execute specific functions of
this Driver. These Tags are described on topic Configuring Special Tags.
The address provided in the Tag is sent together with protocol's request frame, with or without the default offset of 1
(one), required by the Modbus Data Model specified by the protocol, according to the configuration in the Data Model
Offset option, on the Modbus tab of this Driver's configuration window.
In addition to this default offset of 1 (one), defined on the current Modbus standard, version 1.1b, some manufacturers
still use the old Modicon standard, known as Modbus Convention, with an offset that can be added to the address, and
whose value depends on the Modbus function used, or more specifically, depends on which addressing space this
function accessed originally. Such additional offset must be ignored when defining Tag addresses on this Driver. Later on
this Manual there are more examples. The next table lists all offsets used by the Modbus Convention standard.
If a device's register map uses this convention, users must follow this procedure to determine the addresses to attribute
to Tags, in the Item field when configuring by Strings or in N4 or B4 parameters for numerical configuration:
2. Subtract from the address displayed on device's manual the offset shown on the previous table for the Modbus
function used. TIP: Remove the fifth digit from right to the left.
Notice that, in devices that use this old convention, users can determine which Modbus functions can be used to access
each register or bit using the offset used in its address.
Examples
ADDRESS WITH OFFSET (DEVICE) ADDRESS ON I/O TAG (ITEM OR MODBUS FUNCTION
N4/B4)
01234 1234 01: Read Coils, 05: Write Single Coil,
and 15: Write Multiple Coils
11234 1234 02: Read Discrete Inputs
31234 1234 04: Read Input Registers
41234 1234 03: Read Holding Registers, 06: Write
Single Register, and 16: Write Multiple
Registers
45789 5789 03: Read Holding Registers, 06: Write
Single Register, and 16: Write Multiple
Registers
65789 5789 20: Read General Reference and 21:
Write General Reference
Modbus functions 20 and 21 are intended to manipulate reading or writing of multiple subgroups of data, allocated in the
equipment's extended memory, or 6XXXXX references, according to the next table.
To use a PLC Tag to read the second register of Memory File Number 2 of Slave ID 1 (one), use the following parameters:
To use a Block Tag with 3 (three) Elements to read the last three registers of Memory File Number 3 of Slave ID 2 (two),
use the following parameters:
To use a PLC Tag for writing in the fourth register of Memory File Number 1 of Slave ID 3 (three), use the following
parameters:
NOTE
The Modbus protocol allows users to read or write multiple subgroups (file number) of data through a single request
via functions 20 or 21 respectively. However, this Driver only allows users to manipulate one subgroup of data at a time
in each PLC or Block Tag.
Starting with version 2.01, this Driver also supports Superblock Readings. With this feature enabled, users do not need to
group variables into Block Tags aiming to improve performance, it is possible to use only Tags without degrading
performance. And as the Superblock algorithm already considers the maximum block size allowed by the protocol, when
this feature is used this Driver also does not need to use the Automatic Partition feature.
In cases when, due to device's specificity, as described on topic Superblock Reading (Grouping), it is not possible to
enable the EnableReadGrouping property in E3 or Elipse Power, that is, the property that enables Superblocks, or if
users are using the old Elipse SCADA, which does not support grouping (Superblocks, then they must use Automatic
Block Partition to ignore protocol limits.
The article KB-23112 on Elipse Knowledgebase presents a summary of questions related to Tag grouping and Block
resizing in this Driver, discussed here and in other topics. For more information, please check topics Superblock Reading
(Grouping) and Optimization Tips.
With this feature, it is possible, and usually recommended, to create applications with only simple Tags, or PLC Tags in
Elipse SCADA, without performance issues, because group optimization on readings is automatically performed during
communication. The next figure displays the configuration of the EnableReadGrouping property on E3 or Elipse Power.
EnableReadGrouping property
Elipse SCADA does not support Superblocks. The behavior when reading Tags on Elipse SCADA is identical to E3 and
Elipse Power when the EnableReadGrouping property is configured as False. In both cases, this Driver relies on
Automatic Block Partition, and it can divide blocks with sizes larger than protocol limits into smaller blocks during
NOTES
Automatic grouping is performed based on application Tags in advise. Whenever new Tags enter or leave advise, the
Superblock algorithm redefines this grouping, that is, Superblocks to be read automatically, at run time, including only
Tags in advise.
IMPORTANT
Superblock grouping in E3, as well as Driver's Automatic Block Partition, require that a device supports the limits
established by standard Modbus. For more information, please check topic Maximum Limit for the Size of Blocks
Supported by the Modbus Protocol. There are devices, however, that support lower limits. For automatic block
partition and Superblock grouping to work on these cases, starting with version 2.03, this Driver allows customizing the
maximum limit supported for PDU (Protocol Data Unit). To do so, on this Driver's configuration window, Modbus tab,
enable the Customize Max. PDU Size option and configure the maximum size of bytes supported for PDU on this
device. If this device supports different limits for each type of function, users must perform a manual grouping, as
described further on this topic, observing all limits described on manufacturer's documentation.
The Superblock algorithm considers all limits and addressing spaces defined by standard Modbus protocol. For devices
that implement Modbus protocol with small variations, some additional advanced configurations may be necessary to use
this Superblock feature, if its usage appears viable. In these cases, it is necessary to disable automatic grouping, that is,
the EnableReadGrouping property configured as False, and then perform a manual grouping. The following conditions
may prevent using Superblocks, or may require additional advanced configurations :
· Devices that define maximum limits for block sizes lower than protocol's standard limit, that is, a limit of 253 bytes
for PDU. Solution: Configure the Customize Max. PDU Size option on the Modbus tab
NOTE
There are devices whose PDU limits vary according to the Modbus function used. In these cases, if it is necessary to use
functions with different limits, it is also necessary to disable Superblocks, that is, the EnableReadGrouping property
configured as False, by manually grouping Tags, as described later on this topic.
· Devices with discontinuities, or undefined address intervals inserted between valid intervals, on the register map.
Solution: Once it is impossible to inform to the Superblock algorithm which intervals cannot be inserted in blocks,
usually it is not possible to use Superblocks. Disable Superblocks, that is, configure the EnableReadGrouping
property as False, and manually group all Tags
· Devices that do not support block readings. Solution: Disable Superblocks, that is, configure the
EnableReadGrouping property as False, and define simple Tags
· Devices that only allow defining blocks in pre-determined addresses and with fixed sizes. Solution: Disable
Superblocks, that is, configure the EnableReadGrouping property as False, and define simple Tags, or PLC Tags in
Elipse SCADA, or Blocks according to a device's specification
Manual Grouping
Usually, the larger the grouping of variables in blocks, the less reading requests are needed to complete a scan cycle of
application Tags, thus increasing Tag's update speed. For this reason, if it is not possible to use automatic grouping, or
Notice that, due to the Automatic Block Partition feature, there is no need to prevent exceeding protocol's maximum
limits, as long as a device supports protocol's default maximum limits. If this device does not support these limits, but
defines fixed limits, valid for all supported Modbus functions, users must configure the Customize Max. PDU Size option
on the Modbus tab.
If a device supports different limits for each supported function, automatic partitioning can be also unfeasible. In these
cases, an application developer must also consider device's limits, and define blocks respecting these limits.
For a manual grouping, using user-defined data types can increase possibilities of grouping, by allowing to gather on a
single Block Tag variables from the same addressing space, that is, a single Modbus function, but with different data
types. In this case, the defined structure may have elements with different data types.
For more tips, please check topic Optimization Tips. The article KB-23112 in Elipse Knowledgebase presents a summary
of questions related to Tag grouping and block resizing in this Driver, discussed here and on other topics.
This service can be configured on the Modbus tab, to occur whenever detecting a communication error. With this Tag,
however, users can execute this service at any time by the application.
This Special Tag is executed using a Tag's writing command. Its value, written to the Tag, is ignored.
String Configuration
· Item: "ForceWaitSilence"
Numerical Configuration
· N2: 9001
Exception Codes
Exception codes are used by a slave device (PLC) to report a failure when executing a certain function. Slave devices do
not return exceptions in case of communication failures, a situation where these devices simply do not respond. Exception
codes are returned by slaves in situations where a master request, such as the case of this Driver, was successfully
received, but could not be executed for any reason, such as trying to read or write to a non-existent register. In this case,
the returned exception code indicates the type of error occurred, that is, the reason that this Driver's request, although
correctly received, could not be completed.
The specification of Modbus protocol defines nine exception codes. The list of protocol's default exceptions can be
checked on topic List of Default Exceptions of the Modbus Protocol. In addition to these codes, some manufacturers
define additional codes, specific to their devices. Such codes must be documented on a device's manual. If they are not,
please check with manufacturer's technical support.
String Configuration
· Device: Numerical value of device's Id (Slave Id) followed by a colon, such as "1:", "2:", "3:", and so on
· Item: "LastExceptionCode"
Numerical Configuration
· B2: 9999
· Element 1 (index 0): Exception code returned by a device. For more information, please check topic List of Default
Exceptions of the Modbus Protocol
· Element 2 (index 1): N2/B2 parameter of the I/O Tag generating this exception
· Element 3 (index 2): N3/B3 parameter of the I/O Tag generating this exception
· Element 4 (index 3): N4/B4 parameter of the I/O Tag generating this exception
· Element 5 (index 4): Size parameter of the I/O Tag generating this exception
· Element 6 (index 5): Device parameter of the I/O Tag generating this exception
· Element 7 (index 6): Item parameter of the I/O Tag generating this exception
The most common usage for this Tag during a normal scan of function Tags is via an exception Tag's OnRead event. In
this case, a script must first reject null values, because these values indicate that exceptions were not received. Next, users
If TagExc == 0
Return
EndIf
If TagExc == 1
... // Handles exception 1
ElseIf TagExc == 2
... // Handles exception 2
Else
... // Handles all other exceptions
EndIf
Sub TagExc_OnRead()
If Value = 0 Then
Exit Sub
End If
If Value = 1 Then
... ' Handles exception 1
ElseIf Value = 2 Then
... ' Handles exception 2
Else
... ' Handles all other exceptions
End If
In writing operations by script, on the other hand, where users must test for returned exceptions right after sending a
command, users must first zero the exception register. That avoids an eventual exception provoked by a writing command
to be confused with another pre-existing one. Execute the writing operation and test a Special Tag's value, which must
return 0 (zero) if no exception was received. In case it returns a value different from 0 (zero), then users can properly
handle that received exception. The next example is written in Elipse Basic (Elipse SCADA).
// Note: For this example, consider TagExc
// with automatic reading and writing enabled
// and TagVal with automatic writing disabled
If TagExc <> 0
... // Handles this exception
EndIf
NOTE
This Special Tag returns, in addition to an exception code returned on Element 0 (zero), also Tag parameters whose
communication provoked that exception. If this information is not needed, users can read the same register using a
simple Tag, or a PLC Tag in Elipse SCADA, without using a Block Tag. In this case, all recommended procedures remain
the same.
Callback Readings
Starting with version 2.08, this Driver implements callback readings, a feature available in E3, starting with version 3.0, and
in Elipse Power, which optimizes performance of mass memory readings. With this feature, an application delegates to
this Driver a Tag scan for reading mass memory events. In other words, an application does not need to keep asking this
Driver at each scan period. Instead, this Driver performs a verification of new events on a device and collects events as
soon as they become available, and sends them to the application.
On the current version of this Driver, the following functions for reading sequences of events (SOE) are supported:
· GE SOE: Performs event collecting from GE PAC RX7 PLCs. For more information, please check topic Reading an
Event Buffer from GE PAC RX7 Controllers
· SP SOE: Collects events from Schneider Electric SEPAM series 20, 40, and 80 relays. For more information, please
check topic Reading Events from Schneider Electric Relays from SEPAM 20, 40, and 80 Series
· GenSOE: This function uses a generic Algorithm created by Elipse Software, Elipse Modbus SOE, which can be used
by most Programmable Controllers. It requires the creation of an analogous programming procedure on PLC's
programming (ladder). For more information, please check topic Elipse Software's Generic SOE Reading Algorithm
· 65 03: Special function for reading mass memory events from ABB MGE 144 meters. For more information, please
check topic Reading Mass Memory Registers from ABB MGE 144 Meters
Event-reported Tags
String Configuration
Numerical Configuration
To read an event buffer from GE PAC RX7 using numerical configuration, users must define, on this Driver's configuration
window, an operation that uses as its reading function the special function GE SOE. Its data type must be defined as
GE_events.
· B1: Slave ID
· B3: 0 (zero)
At each scan on this Tag, this Driver checks if there are events on controller's buffer. If there are events, this Driver starts
an event-reading thread, which is executed in background, not blocking the scan of all other Tags. After finishing the
reading of this Driver's buffer, this event-reported Tag returns the set of events read on that scan.
Returned events generate a sequence of OnRead events on this Tag. For each read event, E3 or Elipse Power updates
Tag fields, the Element values and timestamps, with values from a certain event, and calls the OnRead event once. This
event's script must be defined by users, and it is generally used to insert Tag's data in a Historic.
Every event is represented by a Block with two Elements, with its Timestamp field read from a device. Fields from the
respective reading Block Tag are displayed on the next table.
For more information about event-reported Tags, please check the specific topic on E3 User's Manual.
IMPORTANT
When reading mass memory events in event-reported Tags in E3 or Elipse Power, disable Tag's dead band, that is, the
EnableDeadBand property configured as False, and also the linked Historic object, that is, the DeadBand property
equal to zero, to avoid loosing events with near values. It is also important to disable historic by scan, that is, in E3 or
Elipse Power configure the ScanTime property as 0 (zero). This ensures that new events are only stored using the
WriteRecord method, executed on Tag's OnRead event, avoiding duplication of events.
This Tags works as the previous one, except that it returns only events from a specific point.
Different from the previous event, the returned value only contains a single Element with a status value of a point, so that
only one Tag can be used. This Tag must be configured as follows:
String Configuration
Numerical Configuration
· N1: Slave ID
· N3: 200 + Point's index, such as configuring the N3 parameter as 202 for point 2 (two)
For more information about event-reported Tags, please check the specific topic on E3 User's Manual.
Real-time Tags
These Tags return the most recent event already read for a specific point. These events are stored on this Driver's internal
memory for each PLC's event reading, with their respective timestamps read from the device. This Tag uses the following
parameters:
String Configuration
Numerical Configuration
· N1: Slave ID
· Tag for collecting all table events (mandatory): Performs a collect of all table events from a certain memory zone
on a device. This Tag, in addition to returning all events read to an event-reported application, still stores events read
in this Driver's internal buffer, to remove them using readings on Tags for reading a single event, described next
· Tag for reading a single event (optional): Returns events received from a specified relay, with a certain address,
type, and zone. This Tag does not perform a direct reading from a device, but returns events from this Driver's
internal buffer, stored during the reading of a Tag for collecting all table events, described previously, that is, to be
able to read events with this type of Tag, a Collecting all events-type Tag must be already active, with its scan
enabled. This Tag is useful when users need to get events from a specific type and source, such as relay, zone,
address, and type. An example of usage is an association to Screen objects, displaying the status of a certain event
address. Although this Tag returns the same information returned by the previous Tag, its usage prevents users from
creating filters, Select Case clauses in VBScript, or any other method to separate several types of events returned by
a Tag for collecting all events by script in an application
An application must implement a Tag for collecting all events for each table or event zone to collect on each relay,
because it is during the reading of this Tag that actual events are collected from a device. Configuration for these two
Tags is presented next.
This is an event-reported Tag. Its typical usage is inserting events in a linked Historic, by using Historic's WriteRecord
method, called on Tag's OnRead event. At each reading, that is, at each Tag's scan period, this Driver can collect up to 4
(four) new events from a device. This is the maximum number of events that each relay's event zone contains at each
reading request.
As it is during the reading of this Tag that events are effectively collected from a device, even if its data is not used
directly, that is, even if there is no need to store all events in a Historic, its implementation is mandatory for single-
event Tags to return data. A Tag for collecting all events must be configured as a Block Tag with 3 (three) Elements, and
with the following parameters:
String Configuration
Example: To read Zone 1 (one) of Slave 1 (one), Device is equal to "1:" and Item is equal to "spsoe1". Alternatively,
Device can be equal to "" and Item equal to "1:spsoe1". For more information, please check the topic String
Configuration.
Numerical Configuration
To use numerical configuration, users must define, on the Operations tab, an operation that uses as its reading function
the special function SP SOE. Its data type is automatically defined as SP_events, as soon as the SP SOE reading function
is selected.
· B1: 1000 + Slave address (relay) on the network, between 1 (one) and 247
· B3: 0 (zero)
The next table describes the meaning of the Block Elements, which have their values returned as reported by events.
For more information about event-reported Tags, please check topic Tags Reported by Events on E3 User's Manual.
IMPORTANT
When reading mass memory events in event-reported Tags in E3 or Elipse Power, disable Tag's dead band, that is, the
EnableDeadBand property configured as False, and also the associated Historic object, that is, the DeadBand property
equal to 0 (zero), to avoid loosing events with close values. It is also important to disable historic by scan, that is, in E3
or Elipse Power configure the ScanTime property as 0 (zero). This ensures that new events are only stored using the
WriteRecord method, executed on Tag's OnRead event, avoiding duplication of events.
This is also an event-reported Tag, and users can use its OnRead event for storage in a Historic. Notice that this does not
prevent it to be treated as a normal Tag, or a real-time Tag, in case only its most recent value is relevant. As this Driver
only reads an internal buffer, it is advisable to define a very low scan time, even lower than the one from the other type of
Tag. CPU consumption at each scan can be considered as not significant. It is suggested to configure it as half the scan
period for a Tag for collecting all events.
As already mentioned, this Tag is used to get a status for a certain event address, without parsing or performing filters on
events that arrive by the previous Tag, by script, or by any other means. A typical application would be linking it to Screen
objects.
A Tag for reading a single event, as already mentioned, does not perform a reading of events from a device, but from
this Driver's internal buffer, previously filled during the reading of a Tag for collecting all events. This Tag returns a single
Element, an event-reported one, and it can be configured as a simple Tag, which does not need to be a Block Tag. This
Driver accepts up to eight events accumulated by event point, that is, for each combination of relay, zone, type, and event
address in its internal buffer. If there is an overflow, that is, if more than eight events from a single point are returned
without any single-event Tag collecting them, this Driver starts to discard older events. The correct configuration of a scan
time may prevent data loss.
String Configuration
· Item: "ptspsoe<Event type (800H by default)>.<Event bit address) + Event zone offset* (please check the next table)
>"
Example: To read 800H-type events at address 1 (one) of zone 2 (two), Device must be equal to "1:" and Item must be
equal to "ptspsoe&h800.&h8001". Alternatively, Device can be equal to "" and Item equal to "1:ptspsoe&h800.&h8001".
For more information, please check topic String Configuration.
Numerical Configuration
· N1: Slave address (relay) on the network, between 1 (one) and 247
· N2: Code of the operation configured with special reading function SP SOE
· N4: Event address (Event bit address) + Event zone offset, as described on the next table
Examples:
NOTE
To represent values in hexadecimal in Elipse E3 and in Elipse Power, users must use the prefix "&H", such as &H10 =
16. In Elipse SCADA, use the suffix "h", such as 10h = 16. On this Manual, however, the uppercase suffix "H" is used to
indicate values in hexadecimal format.
VALUE MEANING
00 Ramp down
01 Ramp up
· Timestamp: The Timestamp property represents the date and time an event was actually read from a relay, during
the reading of a Tag for collecting all events previously described
For more information about relay events, their meanings and addressing, please check manufacturer's documentation. For
more information about event-reported Tags, please check topic Tags Reported by Events on E3 User's Manual.
The generic algorithm for Sequencing of Events (SOE) of this Driver (Elipse Modbus SOE) was developed by Elipse
Software to provide a default alternative for reading events from programmable controllers that do not have a native
version of this feature, provided that these controllers meet some basic requirements of memory space and
programming features, and also allow the creation of tables and control registers described later.
This algorithm allows storing and reading events from almost all programmable controllers, in an optimized way, by using
features already implemented and validated in this Driver.
Event reading on this Driver follows a standard procedure, defined by Elipse Software, reading events from tables
created in PLC's memory or in slave devices by its resident application (ladder).
To use this algorithm, users must define Tags using this Driver's special function Gen SOE, which can be performed both
using the old numerical configuration, the N and B parameters, or the new String configuration, the Device and Item
fields. Tag configuration is described later on topic Acquisition Procedure in an Application.
During the process of reading events, the special function GenSOE always uses the Modbus function 03 (Read Holding
Register) to read registers from a device. For writing during the update of control registers, the default function used is
Modbus function 16 (Write Multiple Registers). By using the numerical configuration, users can select the writing function 06
(Write Single Registers), in the rare case of devices that do not support function 16, because the opposite is more common,
by using operation's Write field on the Operations tab.
PLC's resident software, ladder or equivalent, must keep updated all control registers that provide information to this
Driver, such as the number of events available for reading and the address of the last register to read.
A device can keep more than one event table, in different memory addresses, containing different data types. Each table
must be preceded by their respective control registers, in adjacent addresses. This table is formed by a circular buffer
in contiguous addresses, accumulating events or data for collecting by this Driver at each collect procedure or download
of events.
Users can define distinct data formats, or events, for each defined table, which are usually defined as a data structure,
and may contain event's timestamp field. Events can also be defined using a native data type of this Driver. In this case,
users cannot define a Timestamp field in the PLC, because the timestamp is sent with the date of reading, and the event
contains a single field, which can be represented by a simple Tag or a PLC Tag in Elipse SCADA.
The topics Event Table, Acquisition Procedure in a PLC, and Acquisition Procedure in an Application describe in
details this algorithm, its implementation in a PLC software (ladder), and how to perform its reading by using this Driver's
Tags, respectively.
Event Table
As already mentioned on topic Elipse Software's Generic SOE Reading Algorithm, each event table keeps events in a
circular buffer. The circular buffer of each table is defined by its initial address, or base address, contiguous to control
registers, and by its maximum number of registers, which defines its final limit. The following table shows a layout of
events inside a table's circular buffer.
Each row on the previous table represents a stored event, usually represented by a structure, or by User-Defined Data
Types.
Notice that, in the example of the previous table, the first element of that event structure is a timestamp. This field, whose
presence is not mandatory and that does not need to appear in the first position, defines Tag's Timestamp property and
it is not returned in its Elements. For more information, please check topic User-Defined Data Types.
Users can also define events with native data types of this Driver, and in this case there is only one data Element in each
event, without timestamp.
Events must be inserted in this circular buffer in ascending order, returning to the base address after reaching the upper
limit of this circular buffer. The following control registers must be defined for each table:
· Table status: Must be kept by the PLC, indicating the number of events available for reading in the circular buffer. It
must be updated by the device whenever new events are added to the circular buffer, or after finishing the collecting
of events by an application, which can be detected via Acquisition status
· Recording pointer: This value indicates an index, starting at 0 (zero), of the position where a device must insert the
next event. It must be incremented by the device after each new event insertion in the circular buffer, moving back to
the base address after reaching buffer's upper limit. Notice that this value must not be provided in units of Modbus
registers, but in event positions, and it must be incremented by one unit at every new event inserted, regardless of
the number of Modbus registers occupied for each event in the circular buffer. With this, the maximum allowed value
for this pointer is given by the formula MaxWritePtr = (Size of the circular buffer / Size of event structure) - 1
· Reserved: This register is currently not used. It may be used on future versions of this Driver, and it can be kept in 0
(zero) in its current version
As already mentioned, the base address of this circular buffer, that is, the address in which an event table starts, must be
contiguous to control registers.
Control registers, on the other hand, must be also set on contiguous addresses, on the same order presented previously,
allowing their reading on a single operation, that is, assuming that the base address of control registers for a certain
table is 100, the next table contains the addresses for the other registers.
Register addresses
REGISTER ADDRESS
Table Status 100
Recording Pointer 101
Acquisition Status 102
Reserved 103
Circular Buffer's Base Address 104
The topic Acquisition Procedure in a PLC describes a step-by-step acquisition procedure or algorithm based on a slave
device (PLC). On the next topic, Acquisition Procedure in an Application, there is a discussion on how to configure an
application for acquiring table events.
This topic presents a discussion about an algorithm for collecting events from the point of view of a PLC or slave device.
Its goal is to clarify to developers what must be implemented in PLC's resident application, or ladder.
A device must start inserting events in ascending order, starting at table's base address, that is, starting at the circular
buffer. For each new event inserted, the Recording Pointer must be incremented, pointing to the next available position in
that buffer.
This Driver performs a reading starting from the oldest to the newest event. The starting address of this reading is
calculated by this Driver using the value of Recording Pointer and Table Status.
If the number of available events is greater than protocol's maximum allowed into a single communication frame, this
Driver performs multiple block readings, updating the value of Acquisition Status after finishing this process with the total
amount of events read.
NOTE
If a device does not respect the default limit of 253 bytes for PDU, then users must configure the Customize Max. PDU
Size option, on the Modbus tab, according to supported limits, which must be described on manufacturer's
documentation.
A PLC can insert new events to a table during PLC's acquisition process, as long as there is no overflow on circular buffer,
that is, as long as its writing pointer does not exceed its reading pointer, by incrementing Table Status.
An event collecting or downloading procedure is finished when Table Status is zeroed. All collected events are then
provided to an application via event-reported Tags, as described on the next topic.
The next figure shows a flow chart, as a UML Activity Diagram, with a suggestion of implementation for a PLC logic. Notice
that some variations are possible, for example discarding the oldest event in case of overflow, which can be evaluated by
developers, depending on the context.
Timestamp
As already mentioned, every event is composed by a structure containing one or more data elements, usually, but not
necessarily, represented by User-Defined Data Types.
If structures or user-defined data types are used, then users can associate a timestamp to each PLC-provided event. In
this case, the value of the Timestamp field must be provided in a structure field, in PLC memory, in the order it was
As explained on topic User-Defined Data Types, any date and time type supported by this Driver can be used. The
GenTime data type, however, was specially created for use with Elipse Modbus SOE, due to an easy definition in PLC's
resident application, or ladder.
If a millisecond precision is needed, another option is consider this Driver's UTC32 data type, represented as an integer
with only 32 bits, or 4 (four) bytes, with seconds starting at 1/1/1970, without a milliseconds representation, considered as
0 (zero).
The next topic, Acquisition Procedure in an Application, describes how to configure an application for collecting events
accumulated in a PLC or programmable slave device.
This topic contains a detailed explanation on the configuration of an application to acquire events accumulated in a PLC or
programmable slave device.
Reading events in an application is performed using Tags that reference the special reading function Gen SOE. Tag's data
type defines the structure of events stored in the device's event table. If a native data type of this Driver is defined, or
built-in type, each event contains only one element of this data type, without a PLC-provided timestamp, because the
timestamp represents the instant events were collected. On the other hand, if user-defined data types are used, then
users can define structures for events, including timestamps, as explained later on this topic.
Next, there is a description of the configuration of Tags using the new methodology of configuring by Strings, the Device
and Item fields, as well as the old numerical configuration used by Elipse SCADA, the N and B parameters.
String Configuration
Where:
· N: "<Slave Id>:"
· start add.: Address of the first control register, using the value defined on the example table of topic Event Table
· type: Native or user-defined data type used for each event. For more information, please check topic String
Configuration
· type size: Used only for variable-size data types. For more information, please check topic String Configuration
· byte order: Byte ordering. It can be omitted for devices fully compliant with protocol's standard. For more
information, please check the Byte Order item on topic String Configuration. When structures are used, it only
affects their individual elements. For more information, please check topic User-Defined Data Types
· bit: Bit masking. Usually can be omitted, it would hardly be used here. For more information, please check the Bit
field on topic String Configuration
Example:
· Device: "1:"
· Item: "elsoe150.&h101.TYPE3"
This is a Structure data type containing 6 (six) data fields and a timestamp. Therefore, this Tag must be a Block with 6 (six)
Elements to represent that structure.
Notice that, as already explained, the value of a timestamp, although it occupies registers in the PLC, does not need Block
Tag Elements, because its value is returned in the Tag's Timestamp property.
NOTE
The N parameter informs the size of a table as the maximum number of events, not as Modbus records. Together with
the Start Address parameter, it indirectly informs the final address or upper limit of that table. The size of a table's data
area, therefore, in number of Modbus registers, is the product of N by the size of each event in number of Modbus
registers, that is, in 16-bit Words.
To configure Tags for reading Elipse SOE using a numerical configuration, users must configure an operation on the
Operations tab using the special function GenSOE.
The next figure shows an example of a new operation added using special function GenSOE with a Word data type.
Notice that function 16 (Write Multiple Registers) was selected as its writing function, which is the most commonly used
function. However, users are encouraged to use function 06 (Write Single Register) whenever supported by a device.
The next figure shows the same operation with a user-defined data type TYPE3 , which is a data type defined in the
example configuration file, available with this Driver and used as an example on this topic. For more information, please
check topic User-Defined Data Types.
This is, therefore, a Structure data type with 6 (six) data fields and a timestamp, and the default address, the Tag's B4
parameter, equal to "101H", or 257 in decimal. To read it, users must define a Block Tag with 6 (six) Elements and the
following configuration:
· B3: N (size of a device's table, as the maximum number of events that table can contain)
· B4: 100 (address of the first control register, using a value defined on the example table of topic Event Table)
· Size: 6 (six)
Notice that, if E3's or Elipse Power's Tag Browser is used to insert a Tag in an application, as explained on topic User-
Defined Data Types, Tag Elements are already named according to the name given to structure elements when they were
declared. Tag Browser can be opened by clicking on this Driver's Design tab.
Usage
Once defined an appropriate Tag, or Tags, enable its scan and let this Driver collect events from their respective table,
whenever new events are detected.
Tags linked to the GenSOE function, or elsoe when configuring by Strings, are always event-reported. This means, as
already explained on topic User-Defined Data Types, that this Driver can return several events on a single reading
operation, that is, on a single interval of a Tag's scan.
This means that this Driver returns a set of events, or for the previous example sets of blocks with 6 (six) data fields and a
timestamp, at once, which produces a sequence of OnRead events on a Tag, one for each event, or a block with 6 (six)
data fields and a timestamp, returned by this Driver.
For detailed instructions on the right way to handle event-reported Tags, please check topic Tags Reported by Events on
E3 User's Manual. Elipse SCADA User's Manual also contains an analogous topic.
In short, the usual way of handling event-reported Tags is by adding a call to the WriteRecord method of a previously
linked Historic object on Tag's OnRead event, ensuring that all events reaching this Historic are registered. In this case,
this Historic must be configured without a dead band, that is, the DeadBand property set to 0 (zero), and disabling
historic by scan, that is, in E3 or Elipse Power the ScanTime property set to 0 (zero). Tag's EnableDeadBand property
must also be configured to False.
IMPORTANT
When reading mass memory events in E3's or Elipse Power's event-reported Tags, disable Tag's dead band, that is, the
EnableDeadBand property configured as False, and also in the linked Historic object, that is, the DeadBand property
configured as 0 (zero), to avoid losing events with close values. It is also important to disable historic by scan, that is, in
E3 or Elipse Power the ScanTime property configured as 0 (zero). This ensures that new events are only stored using
the WriteRecord method, executed on Tag's OnRead event, avoiding duplicated events.
Some devices, such as PLCs by ATOS, do not support block readings using data types with different structures. In practice,
this prevents this Driver to read data from control and event registers as a single block. To collect PLC events with these
restrictions, users must disable the Enable Control and Data Registers Grouping option on the Gen SOE tab.
The special function 65 03 is ABB's proprietary and it is practically identical to protocol's standard function 03 (Read
Holding Registers), differing only on returned data, referring to ABB meter's mass memory.
Meter's register map, specifying data to read as well as its correct configuration, must be checked on meter's
manufacturer-provided documentation.
This Driver also contains special writing functions specific for this meter, functions 65 01 and 65 02. For more information
about those special writing functions, please check topic Special Functions and also device's documentation.
String Configuration
Where:
· Type: Data type. If omitted, assumes a default Word. For more information, please check topic String Configuration
· Type size: Used only for variable-sized data types. For more information, please check topic String Configuration
· Byte order: Byte ordering. If omitted, assumes protocol's default. For more information, please check topic String
Configuration
· Bit: Bit masking. Usually omitted, so prefer application's bit masks. For more information, please check topic String
Configuration
· N1/B1: Slave Id
· N2/B2: Code of the operation configured with function 65 03. Please check more information next
To configure Tags numerically, users must first add an operation with function 65 03 on the Operations tab of this
Driver's configuration window, as shown on the next figure.
Appendix
This section contains additional information about the Modbus protocol.
Optimization Tips
This topic enumerates some optimization tips to communicate with slave devices.
· Use Superblocks whenever possible, preferring to create simple Tags, or PLC Tags in Elipse SCADA, instead of Block
Tags. For more information, please check topic Superblock Reading (Grouping).
· If Superblocks are not an option, prefer to create Block Tags, grouping the largest possible number of variables in
the smallest number of blocks. For more information, please check the text about manual grouping on topic
Superblock Reading (Grouping).
· Consider all recommendations of article Performance tips for E3, on Elipse Knowledgebase.
· In case of high-latency networks, reduced bandwidth, or packet loss, please also read article E3's Network Settings for
networks with high latency, low bandwidth and/or packet loss.
· In high-latency networks, configure higher time-outs, considering the expected latency. Remember that a time-out is
only effective on delays, it does not interfere with performance on normal usage situations.
· Consider all recommendations of article Developing applications with optimum performances, also available on Elipse
Knowledgebase.
· In high-latency networks, configure higher time-outs, considering the expected latency. Remember that a time-out is
only effective on delays, it does not interfere with performance on normal usage situations.
· If possible, group all variables defined by a resident application, or ladder, that have the smallest scan time, in
contiguous addresses in PLC's memory. The total scan time of Tags highly depends on the capacity of grouping
variables in communication blocks.
· The application is trying to read a Float-type value, but it is failing. The value displayed by this PLC is completely
different from the one displayed by the application for the same address.
· Answer: This device does not use protocol's default byte order, or big endian. Users must configure a byte order
by executing a swap of Words, which corresponds to the b2 option on the configuration by Strings., or select the
Swap Words option on the configuration of operations on numerical configuration. For more information, please
check topic Operations Tab.
· The application is trying to read inputs and outputs of this PLC, but it is failing.
· Answer: This device does not allow reading or writing input and output variables, and users must use PLC's internal
variables to perform this reading, that is, create a mirror of inputs and outputs in an area where this Driver has
access. Users must also be careful to create a PLC routine to check when an application changes an output value,
so that it is effectively activated or deactivated in this PLC.
· The application is trying to read a DWord-type value, but the correct value is not displayed. The application displays
values different from the ones in this PLC.
· Answer: Please check the article Using Modbus Master (ASC/RTU/TCP) drivers with ATOS's controllers on Elipse
Knowledgebase. If using the new String configuration, the Device and Item fields, also check section Byte Order
on topic String Configuration. If using the old numerical configuration, the N/B parameters, also check topic
Operations Tab, specially the Byte Order section.
How to join two Int16-type values in this PLC into an Int32-type value in the application?
· There is a 32-bit number stored in two 16-bit registers in this PLC. How to display this number on an application's
screen as a single 32-bit register?
· Answer: Users must create Tags using 32-bit data types, such as Float, DWord, or Int32 data types. When
configuring an I/O Tag, users must inform the first address of each PLC variable. For more information, please
check topic Configuring an I/O Tag. This Driver then joins two 16-bit registers from the device into a single 32-bit
value, which is returned on Tag's Value field or on Block Tag's Element. If using a configuration by Strings, the
Device and Item fields, inform a data type right after register's address. For more information, please check topic
String Configuration. If using the old numerical configuration, the N/B parameters, users must define operations
· The application is already developed, but how to join values from two Words into a single Tag?
· Answer: Users can execute that join operation using scripts, by creating an unsigned 32-bit integer. To do so, users
must multiply the Word that contains the highest part of that Word by 65536 and then sum the Word that contains
the lowest part of that Word. For example, UInt32 = (HighWord × 65536) + LowWord.
· The application wants to read Float-type values. A reading function 03 and a writing function 16 with a Float data
type were configured. However, the application displays a value that is different from the one on this device.
· Answer: The official Modbus protocol uses a big endian byte order, with the most significant bytes of every value
coming first. If this Driver is reading nonsense values, even with its address correctly configured, probably the
device uses a non-standard byte order. In this case, users must configure its swap options. If users are using a
configuration by Strings, the Device and Item fields, please check the Byte Order section on topic String
Configuration. If users are using the old numerical configuration, the N/B parameters, please check the Byte
Order section on topic Operations Tab for more information on using these swap options.
How to communicate with more than one device on a Serial communication network?
· There is more than one device on a serial network, each one with a unique address. How to communicate with every
one of them?
· Answer: Users must be careful with the Slave Id of each I/O Tag, because this field indicates the device to
communicate. On an RS485 serial network, all devices listen simultaneously to all driver requests, that is, there is a
single bus, although only the one with the corresponding Slave Id responds to the request, because multiple
devices with the same Id are not allowed. When configuring by Strings, this value can be provided in the Device
field, or at the beginning of the Item field. For more information, please check topic String Configuration. If users
are using the numerical configuration, this value is provided in the N1/B1 parameter of each Tag. Users can use
the same operations for Tags from several devices. A good reference for information and tips regarding the
installation and maintenance of serial networks is the book Serial Port Complete, by Jan Axelson.
· There is more than one serial port on the computer. How to configure this Driver to communicate with devices
connected to each one of these ports?
· Answer: In this case, as there is more than one different physical layer, such as Serial 1, Serial 2, and so on, it is
necessary as many I/O Drivers as the existing ports. Configurations for this Driver's Tags can be the same for all
Driver objects or instances. The only difference is that one Driver must be configured to communicate via Serial 1
port, another Driver configured to communicate via Serial 2 port, and so on. Port configuration is performed on
the Serial tab of this Driver's configuration window. For more information, please check topic Properties.
How to communicate with more than one device on a serial network with an RS485 converter?
· There is an RS485 network with several devices communicating via an RS232-RS485 converter using a Serial port.
Whenever an address switches (Slave ID), that is, when this Driver requests data from another device, a time-out
occurs. After retrying the same message, this device answers normally. Is there a way of preventing this time-out
during an address or Slave ID switching?
· Answer: Some RS232-RS485 converters require a time interval to switch, that is, commuting from transmission
mode to reception mode, or vice versa. To circumvent this limitation, users can use the Inter-frame delay option
on the Serial tab of IOKit library, available on the configuration window. This option defines a time interval
between messages. The exact value of this interval depends on the converter in use but, if it is unknown, users are
recommended to try values between 50 ms and 300 ms.
· There is more than one device connected to an Ethernet network, each one with a unique IP address. How to
communicate with each one of them?
· Answer: Currently, for each IP address, users need as many I/O Drivers as the number of IP addresses to
communicate. The configuration referring to this Driver Tags can be the same for all Drivers. The only difference is
that one Driver must be configured to communicate with IP address 1 (one), another Driver must be configured to
communicate with IP address 2 (two), and so on. The Slave Id parameter can be still used in Modbus TCP mode to
differentiate devices connected to a Modbus Ethernet / RS485 gateway on the same IP address. Notice that this
gateway not only must allow an interconnection among Ethernet and serial networks, but also convert ModbusTCP
frames for the serial modes supported by devices, ModbusRTU or ModbusASC. The IP address must be
configured on the Ethernet tab of IOKit library, on this Driver's configuration window.
TIP
Avoid using protocol's RTU or ASC mode encapsulated in TCP/IP layer. If users want to encapsulate serial
communication of devices using Modbus RTU in TCP/IP, there are gateways available in the market that not only
encapsulate serial communication in Ethernet TCP/IP, the physical, network, and transport layers, but also convert
Modbus RTU into Modbus TCP, the application layer. As a last option, if it is inevitable to use Modbus RTU in Ethernet
TCP/IP layer, enable the Reconnect after Timeout option, described on topic Modbus Tab.
· Is there any software that simulates Modbus protocol and can be used for testing with this Driver?
· Answer: Yes, there are several alternatives. Elipse Software provides a free version (demo) of Elipse Modbus
Simulator on its website, which allows simulating the most basic protocol features. There is also the possibility of
using Elipse Software's Modbus Slave Driver as an emulator. Another possibility is Modsim, one of the oldest and
well known alternatives to emulate a slave Modbus device. This simulator can be purchased at http://www.win-
tech.com/html/modsim32.htm. In addition to it, there is also a free and open alternative named Free Modbus PLC
Simulator, available at http://www.plcsimulator.org. There are still many other options and a list with other software
can be found at Modbus.org website.
· Answer: This address varies from device to device. To know which is the exact address to use, please check
device's documentation or contact its manufacturer's technical support. The topic Addressing Tips (Modbus
Convention) provides tips on common additional offset conventions used by many manufacturers.
When to use RTS and DTR controls that appear on the Serial tab of this Driver's configuration
window?
· The device is communicating directly on computer's RS232 serial port. How to configure RTS and DTR controls?
· Answer: Please check device's documentation or manufacturer's technical support for the correct configuration.
· Answer: When communicating with devices using RS232-RS485 converters, such configurations depend on the
converter. The device, or Slave, does not influence it, as these signals only exist on the RS232 serial side, with no
equivalent on the RS485 serial layer. The RTS control is commonly used by older converters to switch between
transmission and reception modes, because RS485 is half-duplex, and in these cases it must be configured in
Toggle mode. There are some rare devices that require other configurations. On most recent converters, however,
switching between transmission and reception is automatic, and these signals in general are not used, and they
may be ignored. For more information, please check converter's documentation or manufacturer's technical
support.
When to use Swap Bytes, Swap Words, and Swap DWords options?
These options must be used for 16-, 32-, or 64-bit data types, whose byte order of this device-provided value does not
correspond to Modbus default byte order, where the most significant bytes always come first, or big endian standard,
also known as Motorola. If this Driver is reading nonsense values, or values different from the ones stored on the PLC, it
may use a byte order different from protocol's default. For more information, please check section Byte Order on topic
String Configuration or, if using the old numerical configuration, the N/B parameters, please check section Byte Order
on topic Operations Tab. Users are also advised to check device's documentation.
· The application is trying to read a Word value, but this value appears different from the one configured in the PLC. If
in the PLC it is configured as "1" (one), the application displays it as "256".
· Answer: Value 1 (one) in hexadecimal is 0001H and value 256 in hexadecimal corresponds to 0100H. This device
has a non-standard byte order. Users must enable the Swap Bytes option, the "b1" option on the String
Configuration, to read the correct value.
· The application contains a Tag configured to read a DWord value, but the value read by the application is different
from the value stored in the PLC. When setting the value "258", for example, to a PLC register, the application displays
a nonsense value of "16908288".
· Answer: The value 258 in hexadecimal is 00000102H and the value 16908288 in hexadecimal corresponds to
01020000H. This device has a byte order different from protocol's default, where the least significant Word comes
first. In this case, users must enable the Swap Words option, the "b2" option on the String Configuration, to read
the correct value.
How to correctly read Float data types from WEG TPW-03 PLCs?
· Answer: When configuring I/O Tags, users must enable the Swap Words option, which corresponds to the "b2"
option on String configuration. If users are using the old numerical configuration, the N/B parameters, please check
section Byte Order on topic Operations Tab.
Known peculiarities of devices from the ABB Advant Controller 31 series 90 family, such as ABB
07KT97
· An E3 or Elipse Power application is trying to read registers or bits from a PLC, but there are always errors.
· Answer: Devices from this series do not allow using E3 or Elipse Power Superblocks for the following reasons:
· There are interruptions on the address map of device's registers, with undefined address intervals.
· The maximum PDU size is different from the one established by protocol's default, and it is defined as a size that
supports 96 Words or Bits. As this protocol groups eight bits at each data byte, that results in different
maximum PDU sizes for reading functions for Bits and Words, which prevents customizing the maximum PDU
size allowed by this Driver, which does not allow configuring different limits for each protocol function.
· Prefer defining Block Tags, by grouping the largest possible number of variables in the smallest number of blocks,
respecting device's limit of 96 Words or 96 Bits for each Block. For more information, please check section about
Manual Grouping on topic Superblock Reading (Grouping).
NOTE
Users can also use automatic grouping, or Superblocks, if there is no need to read Words and Bits on the same Driver
object, obviously depending on the interval of addresses to read, more specifically, whether this interval contains
interruptions or not. In this case, anyway, users must configure the Customize Max. PDU Size option on the Modbus
tab, according to the limit of 96 Words, 96 × 2 = 192 bytes, or 96 Bits, 96 ÷ 8 = 12 bytes. Such possibility can be
carefully evaluated, in a case-by-case basis, by the application's developer.
The application is trying to read values with Float data types, and the following message appears on
this Driver's log: "Warning: denormalized float number! Returning zero". What to do?
· Answer: This message does not mean a communication or configuration error. Users are advised to check PLC's
programming why it is returning non-normalized values.
· Additional Information: Such message indicates that the device sent a floating point value, a Float, to this Driver in
IEEE 754 format, but non-normalized. Such values may be a result of arithmetical operations with results that
Non-normalized values are described in IEEE 754 standard, and they are not supposed to raise problems for this
Driver or for an application. However, due to previous error detections related to specific hardware, this Driver now
returns 0 (zero) to an application when receiving non-normalized values from a device, registering this message on
log.
For a more complete list of devices already validated for this protocol, please check Modbus Device Directory, maintained
by the Modbus Organization.
MANUFACTURER DEVICE
ABB ETE30, MGE 144, KT97, and KT98
Altus Almost all Altus devices have Modbus, except a few
models from Piccolo series
Areva MiCOM P127 and P632 relay
Atos ATOS PLCs support Modbus RTU protocol with small
variations regarding the maximum size of frames and byte
order. For more information about these variations, please
check the article Using Modbus Master (ASC/RTU/TCP)
drivers with ATOS's controllers, in Elipse Knowledgebase
BCM BCM1088, BCM1086, BCM-GP3000, and BCM2085
Ciber Brasil Multivariable Meter for Electrical Quantities UDP200 and
Multivariable Meter for Electrical Quantities UDP600
Exceptions are registered on this Driver's log, whenever detected, and they can be read by an application by reading the
last exception code.
Notice that, in addition to the exceptions listed here, a device may define other proprietary exceptions. In this case, they
are supposed to be described on manufacturer's documentation of that device.
Notice that, due to Superblock Reading and Automatic Block Partition features, present in this Driver's current version,
users hardly need to consider these limits in their applications, as this Driver already performs all optimizations
automatically during communication.
However, as there are devices that do not support default limits established by this protocol, users may need to know
these limits, and most of all they must know how to evaluate device's limits, in case they are forced to perform a manual
grouping. For more information, please check topic Superblock Reading (Grouping). In these cases, information on this
topic can be very helpful.
The Modbus protocol defines a simple data unit called PDU, or Protocol Data Unit, which is kept unchanged through
several protocol modes and through several communication layers.
A full communication frame, including a PDU and other additional header fields, is called ADU, or Application Data Unit.
According to this protocol's specification, a full Modbus frame, or ADU, can have a PDU with a maximum size of 253
bytes.
Thus, depending on the data type or Modbus function used in communication, this protocol imposes the limits for block
Elements at each communication described on the next table.
The article KB-23112: I/O Block's ideal size with Modbus driver in Elipse Knowledgebase presents a summary of questions
relative to Tag grouping and block resizing in this Driver, discussed here and on other topics.
BCD Encoding
BCD Encoding, or Binary-Coded Decimal, was originally created to circumvent limitations regarding the maximum number
of digits that can be represented in traditional formats for storing values. Formats such as the representation of real
numbers in floating point are usually acceptable for math and scientific calculations. However, rounding errors caused by
numbers that cannot be represented due to overflow or underflow problems may not be acceptable in certain
applications, such as financial procedures. To overcome that limitation, a BCD encoding was developed to allow
representing numbers up to the last digit.
In this representation, each decimal digit is represented only in a binary format, without limitations regarding its number
of digits.
The next table shows decimal digits and their corresponding values in BCD.
3 0011b 8 1000b
4 0100b 9 1001b
To improve efficiency of this encoding, it is common to represent two digits per byte. Notice that, on the previous table,
each decimal digit requires only 4 (four) bits, or a half byte, for its representation.
Such representation with 2 (two) digits in each byte is called Packed BCD, and this the representation used by this Driver,
that is, packets sent by this Driver with BCD values use a data byte for every 2 (two) digits of the represented decimal
value. That is why the Size field, for BCD data types, must be defined as half the maximum number of digits represented
in read or written values.
Example
As an example, suppose that users want to send the value 84 in decimal, 0x54 in hexadecimal format, using a packed BCD
encoding in one byte, the format used by this Driver.
The first step is separate the 2 (two) decimal digits that compose this value in its decimal representation:
· Digit 1: 8 (eight)
· Digit 2: 4 (four)
If users want to send this value to a device without a BCD encoding, then the value sent to the protocol is 84, which is
represented in hexadecimal format by 0x54, or else 01010100b in binary format.
Notice that, if this value 0x84 is mistakenly interpreted in BCD format as a value in hexadecimal format without this
encoding, and this value is then converted to decimal, users get the value 132, which is meaningless.
The next table presents a few more examples of decimal values between 0 (zero) and 99 and their respective
representations in Packed BCD format in 1 (one) byte, presented in hexadecimal and binary formats.
Note that the integer 11223344 contains 8 (eight) digits, so in the properties dialog of this Driver, users must create a new
Operation, defining the Data field as type BCD and the Size field with size 4 (four), in other words, the 8 (eight) digits of
the BCD value must be sized to bytes, grouping the digits always in pairs, 11 22 33 44, to know how many bytes are
required to represent it.
Driver Configuration
I/O Interface configuration is performed on a Driver's configuration dialog box. To access the configuration of this dialog
box in E3 (version 1.0), follow these steps:
Currently, an I/O Interface allows opening only one connection for each Driver. This means that, if users want to access
two serial ports, they must add two Drivers to an application and then configure each Driver for each serial port.
Setup Tab
The Setup tab contains Driver's general configurations. This tab is divided into the following groups:
· General configurations: Configurations of Driver's physical layer, time-out, and initialization mode
· Connection management: Configurations on how the I/O Interface keeps a connection and which recovery policy is
used on failure
Setup tab
OPTION DESCRIPTION
Physical Layer Select the physical layer on a list. Available options are
Serial, Ethernet, Modem, and RAS. The selected interface
must be configured on its specific tab
Timeout Configure a time-out, in milliseconds, for the physical layer.
This is the amount of time an I/O interface waits to receive
any byte from reception's buffer
Start driver OFFLINE Select this option so that the Driver starts in Offline mode
or stopped. This means that the I/O interface is not created
until this Driver is configured to Online mode by using a
Tag in an application. This mode enables a dynamic
configuration of an I/O interface at run time
OPTION DESCRIPTION
Mode Selects a management mode of a connection. Selecting the
Automatic option allows a Driver to manage the
connection automatically, as specified in the next options.
Selecting the Manual option allows an application to fully
manage a connection. Please check topic Driver Statuses
for more details
Retry failed connection every ... seconds Select this option to enable a Driver's connection retry in a
certain interval, in seconds. If the Give up after failed
retries option is not selected, the Driver keeps retrying
until a connection is performed, or until the application is
stopped
Give up after ... failed retries Enable this option to define a maximum number of
connection retries. When the specified number of
consecutive connection retries is reached, the Driver goes
to the Offline mode, assuming that a hardware problem
was detected. If a Driver establishes a successful
connection, the number of unsuccessful retries is cleared. If
this new connection is lost, then the retry counter starts at
zero
Disconnect if non-responsive for ... seconds Enable this option to force a Driver to disconnect if no byte
was received by the I/O interface during the specified time-
out, in seconds. This time-out must be greater than the
time-out configured in the Timeout option
OPTION DESCRIPTION
Log to File Enable this option and configure the name of a file to write
a log. Log files can be large, so use this option for short
periods of time, only for testing and debugging purposes.
If the %PROCESS% macro is used in the log file name, it is
replaced by the ID of the current process. This option is
particularly useful when using several instances of the same
Driver in E3, thus allowing each instance to generate a
separate log file. For example, when configuring this
option as c:\e3logs\drivers\sim_%PROCESS%.log, a file
named c:\e3logs\drivers\sim_00000FDA.log is generated
for process 0FDAh.
Users can also use the %DATE% macro in the file name. In
this case a log file is generated every day (in the format
aaaa_mm_dd). For example, when configuring this option
as c:\e3logs\drivers\sim_%DATE%.log, a file named c:
\e3logs\drivers\sim_2005_12_31.log is generated in
12/31/2005 and a file named c:
\e3logs\drivers\sim_2006_01_01.log is generated in
01/01/2006
Serial Tab
Use this tab to configure parameters for a Serial Interface.
Serial tab
OPTION DESCRIPTION
Port Select a serial port on the list, from COM1 to COM4, or
type the name of a serial port in the format COMn, such as
"COM15". When typing a port's name manually, the dialog
box only accepts port names starting with the expression
"COM"
Baud rate Select a baud rate on the list (1200, 2400, 4800, 9600,
19200, 38400, 57600, or 115200) or type a baud rate, such
as 600
Data bits Select 7 (seven) or 8 (eight) data bits on the list
Parity Select a parity on the list. The available options are None,
Even, Odd, Mark, or List
Stop bits Select the number of stop bits on the list. The available
options are 1, 1.5, or 2 stop bits
Enable 'ECHO' supression Enable this option to remove the echo received after the
I/O Interface sends data via serial port. If this echo is not
equal to the bytes just sent, then the I/O Interface aborts
communication.
Inter-byte delay (microseconds) Defines a delay between each byte transmitted by the I/O
Interface, in millionths of a second, that is, 1000000 is equal
to a second. This option must be used with small delays of
less than a millisecond
Inter-frame delay (milliseconds) Defines a delay between packets sent or received by the
I/O Interface, in thousandths of a second, that is, 1000 is
equal to a second. This delay is applied if the I/O Interface
sends two consecutive packets, or between a received
packet and the next sending
The Handshaking group configures the usage of RTS, CTS, and DTR signals in the handshaking process (controlling
when data can be sent or received via serial line). Most of the time, configuring the DTR control option to ON and the
RTS control option to Toggle works with RS232 serial lines as well as with RS485 serial lines.
OPTION DESCRIPTION
DTR control Select ON to keep the DTR signal always on while the
serial port is open. Select OFF to turn the DTR signal off
while the serial port is open. Some devices require the
DTR signal always on to allow communication.
RTS control Select ON to keep the RTS signal always on while the serial
port is open. Select OFF to turn the RTS signal off while the
serial port is open. Select Toggle to turn the RTS signal on
while sending bytes via serial port and turn it off when not
sending bytes, therefore enabling the reception.
Wait for CTS before send Available only when the RTS control option is configured
to Toggle. Use this option to force a Driver to check the
CTS signal before sending bytes via serial port, after
Ethernet Tab
Use this tab to configure parameters of an Ethernet Interface. These parameters, except port configurations, must also
be configured for use in the RAS.
Ethernet tab
OPTION DESCRIPTION
Transport Select TCP/IP for a TCP socket (stream). Select UDP/IP to
use a UDP socket (connectionless datagram)
Listen for connections on port Use this option to wait for new connections in a specific IP
port, common in Slave Drivers. If this option remains
unselected, the Driver connects to the address and port
specified in the Connect to option
Share listen port with other processes Select this option to share the listen port with other Drivers
and processes
Interface Select the local network interface, identified by its IP
address, that is used by the Driver to establish and receive
connections, or select the (All Interfaces) item to use any
local network interface
Use IPv6 Check this option to force the Driver to use IPv6 addresses
on all Ethernet connections. If this option is unchecked the
Driver will work with IPv4 addresses
Enable 'ECHO' suppression Enable this option to remove the echo from received data.
An echo is a copy of sent data, which can be returned
before a reply message
IP Filter List of restricted or allowed IP addresses from where a
Driver accepts connections (Firewall). Please check the
IO.Ethernet.IPFilter property for more details
PING before connecting Enable this option to execute a ping command, that is,
check whether a device can be reached on a network, for a
device before trying a socket connection. This is a quick way
of determining a successful connection before trying to
open a socket with a device. The time-out of a connection
with a socket can be very high. The available options are:
· Timeout: Specify the number of milliseconds to wait for a
reply from the ping command. Users must use the ping
command to check the normal reply time, configuring this
option for a value above that average. Usually this value
can be configured between 1000 and 4000 milliseconds,
that is, between one and four seconds
· Retries: Number of retries of a ping command, not
counting the first attempt. If all attempts fail, then the
socket connection is aborted
OPTION DESCRIPTION
Main IP Type the IP address of the remote device. Users can use an
IP address separated by dots, as well as a URL. In case of
a URL, the Driver uses the available DNS service to map
that URL to an IP address, such as "192.168.0.13" or
"Server1"
Port Type the IP port of the remote device, between 0 (zero)
and 65535
Backup IP 1, 2, and 3 Indicate here the IP address, the IP port, and the fixed local
IP port of up to 3 (three) backup addresses of a remote
device
Modem Tab
Use this tab to configure parameters of a Modem Interface. Some options on the Serial tab affect the modem
configuration, therefore users must also configure the Serial Interface.
Modem tab
The Modem Interface uses the TAPI modems installed on the computer.
OPTION DESCRIPTION
Select the modem to use Select a modem on the list of available modems on the
computer. If the Default modem option is selected, then
the first available modem is used. Selecting this option is
recommended specially when an application is used on
another computer
Modem settings Click to open the configuration window of the selected
modem
Dial Number Type a default number for dialing. This value can be
changed at run time. Users can use the w character to
represent a pause or a waiting time for a dial tone. For
example, "0w33313456" dials the number zero, waits, and
then dials the number "33313456"
RAS Tab
Use this tab configure parameters of a RAS Interface. Users must also configure the Ethernet tab.
A RAS Interface opens a socket connection with a RAS device. A RAS device is a server of modems available through
TCP/IP, waiting for socket connections on an IP port. For each connection accepted on this port, users have access to one
modem.
When connecting to a RAS device, first the I/O InterfaceIOKit connects to the socket on the IP address and port
configured on the Ethernet tab. After opening the socket, the following initialization or connection steps are performed:
1. Clear the socket, that is, remove any TELNET greeting message received from a RAS device.
5. If the CONNECT reply is received within the time-out, the socket is available for communication with the device, that is,
the connection was established.
If step 5 is successful, then the socket behaves as a normal socket, with the RAS device working as a router between the
Driver and the device. Bytes sent by the Driver are received by the RAS device and sent to the destination device using a
modem. Bytes received by the modem's RAS device are sent back to the Driver using the same socket.
After establishing the connection, the RAS interface monitors data received from a Driver. If a "NO CARRIER" String is
found, the socket is closed. If the RAS device does not send a NO CARRIER signal, the RAS Interface cannot detect when
the modem connection between the RAS device and the final I/O device fails. To recover from this failure, users are
strongly advised to enable the Disconnect if non-responsive option on the Setup tab.
OPTION DESCRIPTION
AT command A String with the full AT command used to dial to a
destination device. For example, "ATDT33313456" dials by
tone to number "33313456"
Connection timeout Number of seconds to wait for a modem's CONNECT
reply, after sending an AT command
General Configurations
This section contains information about the configuration of general I/O Tags and Properties of I/O Interfaces.
I/O Tags
General I/O Interfaces Tags (N2/B2 = 0)
The Tags described next are provided for all supported I/O Interfaces.
This Block returns Driver events generated by several sources in I/O Interfaces. The TimeStamp property of this Block
represents the moment this event occurred. The Block Elements are the following:
· Element 1: Source of event. Possible values are 0: Driver (specific of a Driver), -1: IOKit (generic events of I/O
Interfaces), -2: Serial Interface, -3: Modem Interface, -4: Ethernet Interface, or -5: RAS Interface
NOTE
A Driver keeps a maximum number of 100 events internally. If additional events are reported, older events are
discarded.
IO.PhysicalLayerStatus
This Tag indicates the status of a physical layer. Its possible values are the following:
· 0: Physical layer stopped, that is, the Driver is in Offline mode, the physical layer failed when initializing, or exceeded
the maximum number of reconnection attempts
· 1: Physical layer started but not connected, that is, the Driver is in Online mode but the physical layer is not
connected. If the Connection management option is configured as Automatic, the physical layer can be connecting,
· 2: Physical layer connected, that is, the physical layer is ready for use. This DOES NOT mean the device is connected,
only the access layer is working
IO.SetConfigurationParameters
B2 Parameter 0 (zero)
B3 Parameter 0 (zero)
B4 Parameter 3 (three)
Size Property 2 (two)
ParamItem Property IO.SetConfigurationParameters
Use this Tag to change any property of a Driver's configuration dialog box at run time.
This Tag works only while a Driver is in Offline mode. To start a Driver in Offline mode, select the Start driver OFFLINE
option on the Driver's configuration dialog box. Users can write to a PLC Tag or to a Block Tag containing the parameters
to change. Writing individual Block Elements is not supported, the whole Block must be written at once.
In Elipse SCADA, users must use a Block Tag. Every parameter to configure uses two Block Elements. For example, if users
want to configure three parameters, then the size of the Block must be 6 (3 × 2). The first Element is the property's name,
as a String, and the second Element is the property's value, according to the next example.
// 'Block' must be a Block Tag with automatic reading,
// scan reading, and automatic writing disabled.
// Configure all parameters
Block.element001 = "IO.Type" // Parameter 1
Block.element002 = "Serial"
Block.element003 = "IO.Serial.Port" // Parameter 2
Block.element004 = 1
Block.element005 = "IO.Serial.BaudRate" // Parameter 3
Block.element006 = 19200
// Writes the whole Block
Block.Write()
When using E3, the ability to create arrays at run time allows using an I/O Tag as well as a Block Tag. Users can use
Driver's Write method to send all parameters to the Driver, without creating a Tag, according to the next example.
Dim arr(6)
' Configure all array elements
arr(1) = "IO.Type"
arr(2) = "Serial"
arr(3) = "IO.Serial.Port"
arr(4) = 1
arr(5) = "IO.Serial.BaudRate"
arr(6) = 19200
' There are two methods to send parameters
' Method 1: Using an I/O Tag
tag.WriteEx arr
' Method 2: Without using a Tag
Driver.Write -1, 0, 0, 3, arr
A Driver does not validate parameter names or passed values, therefore be careful when writing parameters and values.
The Write method fails if the configuration array is incorrectly created. Users can check Driver's log or use the writeStatus
parameter of the WriteEx method to find out the exact cause of the error.
Dim arr(10), strError
arr(1) = Array("IO.Type", "Serial")
arr(2) = Array("IO.Serial.Port", 1)
arr(3) = Array("IO.Serial.BaudRate", 19200)
If Not Driver.WriteEx -1, 0, 0, 3, arr, , , strError Then
MsgBox "Failed configuring Driver parameters: " + strError
End If
IO.WorkOnline
This Tag informs the current status of a Driver and allows starting or stopping the physical layer. Possible values are the
following:
· 0 - Driver Offline: Physical layer is closed or stopped. This mode allows a dynamic configuration of a Driver's
parameters using the IO.SetConfigurationParameters Tag
· 1 - Driver Online: Physical layer is open or executing. While in Online mode, the physical layer can be connected or
disconnected and its current status can be checked on the IO.PhysicalLayerStatus Tag
In the next example, using E3, a Driver is configured to Offline mode, its COM port is changed, and then configured to
Online mode again.
'Configure to Offline mode
Driver.Write -1, 0, 0, 4, 0
'Change port to COM2
Driver.Write -1, 0, 0, 3, Array("IO.Serial.Port", 2)
'Configure to Online mode
Driver.Write -1, 0, 0, 4, 1
The Write method can fail when configuring a Driver to Online mode, that is, writing the value 1 (one). In this case, the
Driver remains in Offline mode. The cause of failure can be:
· Type of physical layer incorrectly configured, probably an invalid value was configured in the IO.Type property
· Physical layer probably did not create its working thread. Search the log file for a message "Failed to create physical
layer thread!"
· Physical layer could not start. The cause of failure depends on the type of physical layer. It can be an invalid serial
port number, a failure when starting Windows Sockets, or a failure when starting TAPI (modem), among others. This
cause is recorded on the log file
IMPORTANT
Even if the configuration of a Driver to Online mode is successful, this does not necessarily mean the physical layer is
ready to use, that is, ready to execute input and output operations with an external device. The IO.PhysicalLayerStatus
Tag must be checked to ensure the physical layer is connected and ready for communication.
Properties
These are general properties of all supported I/O Interfaces.
IO.ConnectionMode
Controls the management mode of a Connection. Possible values are 0: Automatic mode, where a Driver manages the
connection or 1: Manual mode, where an application manages the connection.
IO.GiveUpEnable
When configured to True, defines a maximum number of reconnection attempts. If all reconnection attempts fail, the
Driver enters the Offline mode. When configured to False, the Driver tries until a reconnection is successful.
IO.GiveUpTries
Number of reconnection attempts before this one is aborted. For example, if the value of this property is equal to 1
(one), a Driver tries only one reconnection when the reconnection is lost. If this one fails, a Driver enters the Offline mode.
IO.InactivityEnable
Configure to True to enable and to False to disable inactivity detection. The physical layer is disconnected if inactive for
a certain period of time. The physical layer is considered inactive only if it is capable of sending data but not capable of
receiving it back.
IO.InactivityPeriodSec
Number of seconds to check for inactivity. If the physical layer is inactive for this period of time, it is disconnected.
IO.RecoverEnable
Configure to True to enable a Driver to recover lost connections and to False to leave a Driver in Offline mode when a
connection is lost.
IO.RecoverPeriodSec
Delay time between two connection attempts, in seconds.
IO.StartOffline
Configure to True to start a Driver in Offline mode and to False to start a Driver in Online mode.
NOTE
It is pointless to change this property at run time, as it can only be changed when a Driver is already in Offline mode. To
configure a Driver in Online mode at run time, write the value 1 (one) to the IO.WorkOnline Tag.
IO.TimeoutMs
Defines a time-out for the physical layer, in milliseconds. One second is equal to 1000 milliseconds.
IO.Type
Defines the type of physical interface used by a Driver. Possible values are the following:
· N or None: Does not use a physical interface, that is, a Driver must provide a customized interface
· M or Modem: Uses a local modem, internal or external, accessed via TAPI (Telephony Application Programming
Interface)
· R or RAS: Uses a RAS (Remote Access Server) Interface. A Driver connects to a RAS device using the Ethernet Interface
and then sends an AT (dial) command
Statistical Configuration
This section contains information about the configuration of I/O Tags and Properties of I/O Interfaces statistics.
I/O Tags
Tags of I/O Interface statistics (N2/B2 = 0)
The Tags described next display statistics for all I/O Interfaces.
IO.Stats.Partial.BytesRecv
IO.Stats.Partial.BytesSent
N2 Parameter 0 (zero)
N3 Parameter 0 (zero)
N4 Parameter 1100
Configuration by String IO.Stats.Partial.BytesSent
This Tag returns the number of bytes sent through the current connection.
IO.Stats.Partial.TimeConnectedSeconds
This Tag returns the number of seconds a Driver is connected in the current connection or 0 (zero) if a Driver is
disconnected.
IO.Stats.Partial.TimeDisconnectedSeconds
This Tag returns the number of seconds a Driver is disconnected since the last connection ended or 0 (zero) if a Driver is
connected.
This Tag returns the number of bytes received since a Driver was loaded.
IO.Stats.Total.BytesSent
This Tag returns the number of bytes sent since a Driver was loaded.
IO.Stats.Total.ConnectionCount
This Tag returns the number of connections a Driver already established, successfully, since it was loaded.
This Tag returns the number of seconds a Driver remained connected since it was loaded.
IO.Stats.Total.TimeDisconnectedSeconds
This Tag returns the number of seconds a Driver remained disconnected since it was loaded.
Properties
Currently, there are no properties defined specifically to display I/O Interface statistics at run time.
I/O Tags
Tags of an Ethernet Interface (N2/B2 = 4)
The Tags described next allow controlling and identifying an Ethernet Interface at run time and they are also valid when
the RAS Interface is selected.
IMPORTANT
These Tags are available ONLY while a Driver is in Online mode.
Indicates the active IP address. Possible values are 0: The main IP address is selected, 1: The first alternative or backup IP
address is selected, 2: The second alternative or backup IP address is selected, or 3: The third alternative or backup IP
address is selected.
If the Ethernet or RAS Interface is connected, this Tag indicates which one of the four configured IP addresses is in use. If
the Interface is disconnected, this Tag indicates which IP address is used first on the next connection attempt.
During the connection process, if the active IP address is not available, the I/O Interface tries to connect using the next
alternative IP address. If the connection with the alternative IP address works, it is configured as the active IP address
(automatic switchover).
To force a manual switchover, write values from 0 (zero) to 3 (three) to this Tag. This forces a reconnection with the
specified IP address (0: Main IP address or 1, 2, 3: Alternative IP address) if the Driver is currently connected. If the Driver
is disconnected, this Tag configures the active IP address for the next connection attempt.
IO.Ethernet.IPSwitch
Any value written to this Tag forces a manual switchover. If the main IP address is active, then the Driver tries to connect to
each one of the alternative or backup IP addresses and back to the main IP address until a connection is established.
If the Driver is disconnected, this Tag configures the active IP address for the next connection attempt.
Properties
These properties control the configuration of an Ethernet Interface.
IO.Ethernet.AcceptConnection
Configure to False if the Driver must not accept external connections, that is the Driver behaves as a master, or
configure to True to enable the reception of connections, that is, the Driver behaves as a slave.
IO.Ethernet.BackupEnable[2,3]
Configure to True to enable an alternative or backup IP address. If the reconnection attempt with the main IP address
fails, the Driver tries to use an alternative IP address. Configure to False to disable its usage.
IO.Ethernet.BackupLocalPort[2,3]
Local port number to be used when connecting to an alternative IP address of a remote device. Used only if
IO.Ethernet.BackupLocalPortEnable is equal to True.
IO.Ethernet.BackupLocalPortEnable[2,3]
Configure to True to force the use of a specific local port when connecting to an alternative or backup IP address of a
remote device or configure to False to use any available local port.
IO.Ethernet.BackupIP[2,3]
Alternative or backup IP address of a remote device. Users can use a numerical address, as well as a device's host
name, such as "192.168.0.7" or "SERVER2".
IO.Ethernet.BackupPort[2,3]
Port number of an alternative or backup IP address of a remote device, used with the IO.Ethernet.BackupIP property.
IO.Ethernet.IPFilter
List with a comma-separated IPv4 or IPv6 addresses, which defines from which addresses a Driver accepts or blocks
connections. Users can use asterisks, such as "192.168.*.*", or intervals, such as "192.168.0.41-50", in any part of IP
addresses. To block an IP address or a range of IP addresses, use the tilde ("~") character at the beginning of the
address. Examples:
· 192.168.0.10, 192.168.0.15, 192.168.0.20: Accepts connections from IPv4 addresses 192.168.0.10, 192.168.0.15, and
192.168.0.20
· ~192.168.0.95, 192.168.0.*: Accepts connections from IPv4 addresses from 192.168.0.0 to 192.168.0.255, except the
IPv4 address 192.168.0.95
· If the last element on the list is an authorization, such as "192.168.0.24", then all IP addresses not found on the list are
blocked
· If the last element on the list is a block, such as "~192.168.0.24", then all IP addresses not found on the list are
authorized
If an IP address appears on more than one filter on the list, the leftmost filter has precedence. For example, in case of
"~192.168.0.95, 192.168.0.*", the IP address 192.168.0.95 fits both rules, but the rule that wins is the leftmost one,
"~192.168.0.95", and therefore this IP address is blocked.
When IOKit blocks a connection, it logs a message "Blocked incoming socket connection from {IP}!".
In case of UDP connections in broadcast listen mode, where a Driver can receive packets from different IP addresses,
blocks or permissions are performed at each packet received. If a packet is received from a blocked IP address, it logs a
message "Blocked incoming packet from {IP} (discarding {N} bytes)!".
IO.Ethernet.ListenIP
IP address of the local network interface that a Driver uses to establish and receive connections. Leave this property
empty to use any local network interface.
IO.Ethernet.ListenPort
Number of the IP port used by a Driver to listen to connections.
IO.Ethernet.MainIP
IP address of a remote device. Users can use a numerical address, as well as a device's host name, such as
"192.168.0.7" or "SERVER2".
IO.Ethernet.MainLocalPort
Local port number to use when connecting to the main IP address of a remote device. This value is only used if the
IO.Ethernet.MainLocalPortEnable property is equal to True.
IO.Ethernet.MainLocalPortEnable
Configure to True to force the use of a specific local port when connecting to the main IP address of a remote device or
configure to False to use any available local port.
IO.Ethernet.MainPort
Number of the IP port of a remote device, used with the IO.Ethernet.MainIP property.
IO.Ethernet.PingEnable
Configure to True to enable sending a ping command to the IP address of a remote device, before trying to connect to
the socket. This socket's connection time-out cannot be controlled, therefore sending a ping command before connecting
is a fast way to detect if the connection is going to fail. Configure to False to disable a ping command.
IO.Ethernet.PingTries
Maximum number of attempts of a ping command. Minimum value is 1 (one), including the first ping command.
IO.Ethernet.ShareListenPort
Configure to True to share a listening port with other Drivers and processes or False to open a listening port in
exclusive mode. To successfully share a listening port, all Drivers and processes that use that port must open it in shared
mode. When a listening port is shared, each incoming connection is distributed to one of the processes listening. This
way, if a Slave Driver only supports one connection at a time, users can use several instances of this Driver listening on the
same port, therefore simulating a Driver with support for multiple connections.
IO.Ethernet.SupressEcho
Configure to True to eliminate echoes in communication. An echo is the unwanted reception of an exact copy of all data
packets a Driver sends to a device.
IO.Ethernet.Transport
Defines a transport protocol. Possible values are T or TCP: Uses the TCP/IP protocol or U or UDP: Uses the UDP/IP
protocol.
IO.Ethernet.UseIPv6
Configure to True to use IPv6 addresses on all Ethernet connections or configure to False to use IPv4 addresses
(default).
I/O Tags
Tags of a Modem Interface (N2/B2 = 3)
The Tags described next allow controlling and diagnosing a Modem (TAPI) Interface at run time.
IMPORTANT
These Tags are available ONLY while the Driver is in Online mode.
Indicates a baud rate value for the current connection. If a modem is not connected, returns the value 0 (zero).
IO.TAPI.Dial
Write any value to this Tag to force a Modem Interface to start a call. This is an asynchronous command, only starting the
call process. Users can monitor the IO.TAPI.IsModemConnected Tag to detect when a call is established.
IO.TAPI.HangUp
Any value written to this Tag turns the current call off.
IO.TAPI.IsModemConnected
N2 Parameter 0 (zero)
N3 Parameter 3 (three)
N4 Parameter 3 (three)
String Configuration IO.TAPI.IsModemConnected
This Tag indicates the status of a modem connection. Possible values are 0: The modem is not connected, but it may be
performing or receiving an external call or 1: The modem is connected and the Driver completed or received an external
call successfully. While it is in this status, the physical layer can send or receive data.
IO.TAPI.IsModemConnecting
N3 Parameter 3 (three)
N4 Parameter 6 (six)
String Configuration IO.TAPI.IsModemConnecting
This Tag indicates the status of a modem connection, with more details than the IO.TAPI.IsModemConnected Tag.
Possible values are 0: Modem is not connected, 1: Modem is connecting, that is, performing or receiving an external call,
2: Modem is connected. While in this status, the physical layer can send or receive data, or 3: Modem is disconnecting the
current call.
Returns a String with the current status of a modem. Possible values are the following:
· "No status!": The Modem Interface was not open yet or was already closed
· "Modem error at initialization!": Driver could not initialize modem's line. Check Driver's log file for more details
· "Connecting...": Driver started a call successfully, and is currently processing that call
· "Ringing...": Indicates that the modem is receiving an external call, but it did not accepted it yet
· "Connected!": Driver connected successfully, that is, completed or accepted an external call
· "Error: no dial tone!": Driver aborted a call because the available line signal was not detected
· "Error: busy!": Driver aborted a call because the line was busy
· "Error: no answer!": Driver aborted a call because no answer was received from the other modem
IO.TAPI.PhoneNumber
Properties
These properties control the configuration of a Modem (TAPI) Interface.
IO.TAPI.AcceptIncoming
Configure to False if a modem cannot accept external calls, that is, the Driver behaves as a master, and configure to
True to enable receiving calls, that is, the Driver behaves as a slave.
IO.TAPI.ModemID
This is the identification number of a modem. This ID is created by Windows and used internally to identify a modem on
a list of devices installed on a computer. This ID may not remain valid if a modem is reinstalled or an application is
executed on another computer.
NOTE
It is advisable to configure this property as 0 (zero), indicating that a Driver must use the first available modem.
IO.TAPI.PhoneNumber
A telephone number used by Dial commands, such as "0w01234566", where the "w" character forces a modem to wait
for a call sign.
I/O Tags
Tags of a RAS Interface (N2/B2 = 5)
Currently, there are no Tags defined specifically to manage a RAS Interface at run time.
Properties
These properties control the configuration of a RAS Interface.
NOTE
A RAS Interface uses the Ethernet Interface, which for this reason must be also configured.
IO.RAS.ATCommand
An AT command to send through a socket to force a RAS device to perform a call using the current RAS channel, such
as "ATDT6265545".
I/O Tags
Tags of a Serial Interface (N2/B2 = 2)
Currently, there are no Tags defined specifically to manage a Serial Interface at run time.
Properties
These properties control the configuration of a Serial Interface.
IO.Serial.Baudrate
Specifies a baud rate of a serial port, such as 9600.
IO.Serial.CTSTimeoutMs
Time to wait for a CTS signal, in milliseconds. After turning the RTS signal on, a timer is started to wait for a CTS signal.
If this timer expires, the Driver aborts sending bytes through the serial port. Available only when the IO.Serial.RTS
property is configured as Toggle and the IO.Serial.WaitCTS property is configured to True.
IO.Serial.DataBits
Specifies the number of data bits to configure a serial port. Possible values are 5: Five data bits, 6: Six data bits, 7: Seven
data bits, or 8: Eight data bits.
IO.Serial.DelayAfterMs
Number of milliseconds to delay after the last byte is sent through a serial port, but before turning the RTS signal off.
Available only when the IO.Serial.RTS property is configured to Toggle and the IO.Serial.WaitCTS property is configured
to False.
IO.Serial.DelayBeforeMs
Number of milliseconds to delay after turning the RTS signal on, but before data is sent. Available only when the
IO.Serial.RTS property is configured to Toggle and the IO.Serial.WaitCTS property is configured to False.
IO.Serial.DTR
Indicates how a Driver deals with the DTR signal. Possible values are OFF: DTR signal is always turned off or ON: DTR
signal is always turned on.
IO.Serial.InterbyteDelayUs
Delay time, in milliseconds (1/1000000 of a second), for each two bytes sent through a Serial Interface.
IO.Serial.Parity
Specifies a parity for the configuration of a serial port. Possible values are E or Even: Even parity, N or None: No parity,
O or Odd: Odd parity, M or Mark: Mark parity, or S or Space: Space parity.
IO.Serial.Port
Number of the local serial port. Possible values are 1: Uses the COM1 port, 2: Uses the COM2 port, 3: Uses the COM3
port, or n: Uses the COMn port.
IO.Serial.RTS
Indicates how a Driver deals with the RTS signal. Possible values are OFF: RTS signal always off, ON: RTS signal always
on, or Toggle: Turns the RTS signal on when transmitting data and turns the RTS signal off when not transmitting data.
IO.Serial.StopBits
Specifies the number of stop bits for the configuration of a serial port. Possible values are 1: One stop bit, 2: One and a
half stop bit, or 3: Two stop bits.
IO.Serial.SupressEcho
Use a value different from 0 (zero) to enable suppressing the echo or 0 (zero) to disable it.
IO.Serial.WaitCTS
Configure to True to force a Driver to wait for the CTS signal before sending bytes when the RTS signal is turned on.
Available only when the IO.Serial.RTS property is configured to Toggle.
www.elipse.com.br
kb.elipse.com.br
forum.elipse.com.br
www.youtube.com/elipsesoftware
elipse@elipse.com.br