MODBUS DRIVER

Filename | MODBUS.DLL
Manufacturer | Modicon
Devices | Every Modbus v1 protocol compatible device
Protocol | Modbus v1
Version | 2.07 build 1
Last Update | 06/30/2010
Platform | Win32
Dependencies | IOKit v1.06 or higher

Introduction

This driver implements the Modbus Master/Slave protocol, which allows Elipse E3 to act as Master in a Modbus network, communicating with any slave device that implements Modbus protocol in ASCII, RTU or Modbus TCP modes.

The Modbus driver was developed alongside Elipse IOKit library.

This library, after configured by the user, is responsible for implementing access to the desired physical layer (Serial, Ethernet, Modem, RAS).

For further information on how to configure this driver, please refer to the IOKit User's Manual.

It is recommended that for proper driver usage the chapters Adding the driver to an Elipse application and Configuring Driver are read in this specific order.

If your are an experienced user on Elipse products, you can follow the Step by step.

Has this section of the documentation helped you configure the driver?
Yes No
Comments (150 characters):
There are 150 characters left.


The Modbus Protocol

 Top Previous Next

The Modbus protocol was first developed by Modicon (now Schneider Electric) in 1979, being today an open standard, implemented by hundreds of manufacturers in thousands of devices. Modbus is an application layer messaging protocol, positioned at level 7 of the OSI model, which provides client/server communication between devices connected on different types of buses or networks. It is a request/reply protocol and offers services with functions defined by a code of eight bits.

There are three categories of function codes:

· Public Function Codes: Functions well-defined by the protocol, guaranteed to be unique, publicly documented in MB IETF RFC, and validated by the modbus.org community.
· User Defined Function Codes: Non standard functions that do not need to be approved by modbus.org, therefore not guaranteed to be unique, can be freely implemented.
· Reserved Function Codes: Function Codes currently used by some manufacturers for legacy products and that are not available for public use.

All but the 22, 23, and 43 public function codes are implemented in this driver, as well as some manufacturer specific function codes.


Recommended Websites

The Modbus driver from Elipse is available for download (without cost) on Elipse website at Driver Download area.

More information about Modbus protocol can be obtained at www.modbus.org website.

A Modbus Slave Simulator can be found at www.win-tech.com/html/modsim32.htm. There is also the Free Modbus PLC Simulator software, available at www.plcsimulator.org.


Modbus Functions

The reading and writing operations that were implemented on Modbus driver, and that must be configured on N2/B2 property of communication tags, are described next:

Reading Functions:

· 01 - Bit Reading (Read Coil Status - 0x).
· 02 - Bit Reading (Read Input Status - 1x).
· 03 - Word Reading (Read Holding Registers - 4x).
· 04 - Word Reading (Read Input Registers - 3x).
· 07 - Status Reading (Read Exception Status).
· 20 - Extended Memory Reading (Read General Reference - 6x).

Writing Functions:

· 05 - Bit Writing (Force Single Coil - 0x).
· 06 - Simple Word Writing (Preset Single Register - 4x).
· 15 - Bit Writing (Force Multiple Coils - 0x).
· 16 - Word Writing (Preset Multiple Registers - 4x).
· 21 - Extended Memory Writing (Write General Reference - 6x).

The full driver configuration is describe on chapter Configuring the Driver.


Modbus Special Functions

The special writing and reading operations were developed to perform exclusive Special Functions to certain devices.

These functions must be configured on N2/B2 properties of communication tags and are described next.

Reading Functions:

· 6503: Mass Memory Reading (ABB MGE 144).
· SOE GE: Reading eventos (GE PAC RX7 Systems).

Writing Functions:

· 6501: Reset Device (ABB MGE 144).
· 6502: Reset Maximum and Minimum Memory (ABB MGE 144).

The full driver configuration is describe on chapter Configuring the Driver.


BCD Notation

The Binary Coded Decimal notation (BCD for short) was initially developed as a workaround for limitations in more traditional formats, regarding the maximum number of digits possible of being represented. The floating-point representation, for instance, can be acceptable for most mathematical and scientific calculations. However, such representation can result in rounding errors caused by the impossibility of representing every digit in some cases, when an underflow or overflow takes place, and that can be a problem in systems where such errors are not acceptable, as in financial systems.

The BCD notation overcomes such limitations because in this notation each digit is represented separately, with no limits regarding the maximum number of digits.

The next table shows the 10 decimal digits and its BCD representation:

Decimal | BCD | Decimal | BCD
0 | 0000b | 5 | 0101b
1 | 0001b | 6 | 0110b
2 | 0010b | 7 | 0111b
3 | 0011b | 8 | 1000b
4 | 0100b | 9 | 1001b

In order to improve efficiency of the BCD representation, it is very common to represent two digits per byte, since each decimal digit requires only four bits to be represented in that format. Such representation is known as Packed BCD, and is the one used by this driver. That is why the Size field in the Extra Configuration dialog box must be half the maximum number of digits to be represented in each value, since each byte will represent two digits of the original decimal value.


Data Types Supported by the Driver

OPTION | RANGE | DESCRIPTION
Char | -128 to 127 | 8-bit data, character.
Byte | 0 to 255 | Unsigned 8-bit word.
Int8 | -128 to 127 | Signed 8-bit word.
Int16 | -32768 to 32767 | Signed 16-bit word.
Int32 | -2.147.483.648 to 2.147.483.647 | Signed 32-bit word.
Word/Uint | 0 to 65535 | Unsigned 16-bit word.
Dword/ULong | 0 to 4294967295 | Unsigned 32-bit word.
Float | -3,4E38 to 3.4E38 | 32-bit floating-point value (IEEE 754) (4 bytes with the most significant first: EXP F2 F1 F0).
Float_GE | -1,427E+45 to 1,427E+45 | 3-bit floating-point value (not IEEE 754) (4 bytes in the order: EXP F2 F1 F0).
Double | -1,7E308 to 1,7E308 | Real 64-bit.
String | Not applicable | Word with 8-bit chars (text).
BCD | See description and the item BCD Notation | BCD (Binary Coded Decimal) numerical value. When using this type, the application must provide a positive and integer decimal value to be sent in BCD format, respecting the specified size. The Size field, in case of BCD type, refer to the number of bytes to be sent to represent the value. As in BCD notation each digit will be converted into a nibble, the allowed values must have the maximum number of digits equal to double the specified value on Size field. That is, if it is selected 2 for the Size field, the maximum value that can be sent is 9999. If Size is equal to 4, the maximum value is 99999999. The allowed values for the Size field in case of BCD types are 2 (WORD) and 4 (DOUBLE WORD). For more details on BCD codification, check the section BCD Notation on this manual.
GE Events | See description | Data type used on event buffer reading (SOE) of GE PAC RX7 PLC. These events are returned as two element blocks, with timestamps defined by the controller. For more information, see section Reading Buffer of events on GE PAC RX7 controllers.
Bit | 0 or 1 | This type is automatically selected when the user selects any function that accesses bit types. Functions that access bit types are the following: 01, 02, 05, and 15. Size field it not used for bit types. When using Bit type, each block element will represent a single bit.


List of Devices that Communicate with Modbus

The following table is a list of devices, separated by manufacturer, which Elipse is aware that they communicate via Modbus.

Manufacturer

Device

Schneider
· Twido
· A340
· Premium series
· Frequency Converters and soft starter
· MT and BT circuit breakers
· BT and MT protection relays

Weg
· TP 03

Novus
· N1100
· N2000
· N3000

Fatek
· FB - 14MCU

Unitronics
· V120

LG
· DMT40U

ABB
· ETE30
· MGE 144

BCM
· BCM1088
· BCM1086
· BCM-GP3000
· BCM2085

Altus

Almost all Altus devices have Modbus, except some models from Piccolo line.

Moeller
· XC100 - Serial Port 232
· XC200 - Serial Port 232/422/485 (communication module XIO-SER) and Ethernet Port
· XV200 - Serial Port 232 and Ethernet Port
· XVH300 - Serial Port 232 and Ethernet Port
· XV400 - Serial Port 232 and Ethernet Port

Deep Sea
· DSE5210
· DSE5310
· DSE5310M
· DSE5320
· DSE5510
· DSE5510M
· DSE5520
· DSE7310
· DSE7320

Areva
· MiCOM P127


Adding the Driver to an Elipse Application

This section describes how to add Modbus driver to Elipse SCADA and E3 applications.


On Elipse SCADA

Using the Organizer, select the Drivers item and then click the New button.

On the open window, select the desired driver (it must be decompressed on a directory on the computer in use) and then click Open.

The driver will then be added to the application.

In order for the driver to work correctly you still have to configure it.

Please read the chapter Configuring the Driver.


On Elipse E3

Using the Organizer, select the Server Objects item and then Drivers and OPC. Right-click the Insert Communication Driver option and then select the desired project.

On the open window, select the desired driver (it must be decompressed on a folder on the computer in use) and then click Open.

After clicking Open, the Configuration window will be open. On it you should configure the driver as needed.

On chapter Configuring the Driver there is a description on how to configure the driver.

By now, you can click OK on configuration window and the Close button of the next window (Tag Browser).


Configuring the Driver

This section describes how to configure Modbus driver.


Configuring Driver Properties

Configuring Read/Write Operations

For the correct working of this driver, it is necessary to define which reading or writing Modbus functions will be used. For this, you should access the Modbus tab on driver configuration dialog box. In this tab it is possible to define configurations, called operations, which will define reading and writing Modbus functions used by each tag, as well as the way read data must be interpreted (data types).

The list of Modbus functions supported by the driver, and which can be attributed to the configured operations, can be checked on the Modbus Functions item.

As a default, when a new driver is added to the application, it already adds seven standard operations, described on the following table.

OPERATION | READING FUNCTION | WRITING FUNCTION | Data Type | PURPOSE
1 | 3 - Read Holding Registers | 16 - Write Multiple Registers | WORD | For reading and writing 16 bit unsigned integers.
2 | 3 - Read Holding Registers | 16 - Write Multiple Registers | DWORD | For reading and writing 32 bit unsigned integers.
3 | 3 - Read Holding Registers | 16 - Write Multiple Registers | INT16 | For reading and writing 16 bit signed integers.
4 | 3 - Read Holding Registers | 16 - Write Multiple Registers | INT32 | For reading and writing 32 bit signed integers.
5 | 3 - Read Holding Registers | 16 - Write Multiple Registers | FLOAT | For reading 32 bit floating point values.
6 | 3 - Read Holding Registers | 15 - Write Multiple Coils | BIT | For reading and writing bits.
7 | 2 - Read Discrete Inputs | None | BIT | For reading bits from Discrete Inputs data block.

To add a new operation to the driver, it is enough to click the Add button.

According to the previous figure, after clicking Add, you should configure the new operation. You should always choose a number for this operation (this number will be used on N2/B2 parameter of communication tags), which Modbus function you want to use for reading and which Modbus function you want to use for writing, besides informing the data type will be read or written by the driver. For more information about supported data types, see the item Data types supported by the protocol. The other fields must be configured as needed. The description of the fields is:

Option | Description
Size | Must be informed the size in bytes of each element of the selected data type. This field is automatically filled in for fixed size data types, like BYTE, WORD and Int16 types, and it must be filled in for String and BCD data types. In case of strings, this size defines the exact number of bytes sent or received for each string value, that is, for each PLC tag or block element. If the string read or written has a smaller size, the rest of the bytes will be filled in with zeroes, in order to fill in the configure size. The String type on this driver does not have a defined maximum limit of size, being this limit the maximum limit allowed by the protocol for the data area of the frame of a certain function.
Rev Frame | Indicates that the direction of the bytes on the frame is inverted. If it is enabled, this option makes that all data area of the communication frame has its order inverted. This option has no effect when writing data.
Swap Byte | Indicates that the driver must invert the byte order one by one to get a value.
Swap Word | Indicates that the driver must invert the byte order two by two (in Words) to get a value.
Swap DWord | Indicates that the value must invert the byte order four by four (in DWords) to get a value.
Use Bit Mask | Enables masking register bits, using parameters N3/B3. This option affects only readings and can only be used with signed or unsigned integer data types. Operations that have this option enabled will not be able to be used for writing.

NOTE: The Swap options cited previously have no effect on BIT data types or types with 8 bits size (BYTE, CHAR, and INT8). The swapping occurs on every data type. That is, the Swap Word option will have no effect for 16 bits data types, as well as Swap Dword option will have no effect for 32 bits data types.

The Modbus functions that can be configured on Read and Write fields are described on chapter Modbus Functions.

The rest of the fields that appear on this tab are:

Option | Description
Import Configuration | This option allows to import configurations from versions prior to version 2.0 of Modbus Master/Slave driver, that stored those 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 itself.
Export Configuration | This options is the inverse operation of the previous one, generating an .ini file containing function configurations, with the same format of the previous versions of this driver. This way it is possible to keep function configurations on a file that can be used in other applications.
Add | Adds a new item to the list.
Edit | Updates a selected item on the list.
Remove | Removes the selected item from the list.

NOTE: The Rev Frame, Swap Byte, Swap Word, and Swap Dword options were added to allow compatibility with devices that do not follow the Modbus protocol standard on data coding. The standard Modbus protocol transfers data with most significant bytes first. If these options remain disabled, the driver behavior will correspond to protocol standard, being this the recommended option for most devices.

Configuring the Protocol Options

Option

Description

Modbus Mode

In this combo box the user must select the Modbus mode to be used. There are three available options:

· RTU Mode (default): Standard mode to use on serial communication. Includes 16 bits CRC.
· ASCII Mode: Also used on serial communication, it is used on simpler devices, which do not support RTU mode requisites. Uses ASCII characters for transmitting, where each byte has two ASCII characters (one for each nibble), so it is less efficient than RTU mode. Uses LRC (Longitudinal Redundancy Checking) for error checking.
· Modbus TCP: Used for TCP/IP communication. Includes a field for transaction checking and does not have an error checking system. The transaction field allows discarding delayed answers, avoiding that the driver assumes as a valid answer for the actual command answer frames from previous commands. This situation may occur if the previous modes were encapsulated on TCP/IP.

Customize Max. PDU Size

If enabled, this option allows to define a personalized maximum size for Protocol Data Unit (PDU). The Protocol Data Unit is the part of the protocol that does not vary among protocol modes (ModbusTCP, ASCII and RTU) and contains data area. The number of data bytes supported on every communication is given by this value minus the header bytes, which depend on Modbus function used. If it is disabled, the maximum considered size will be the standard value defined by Modbus protocol, that is, 256 bytes.

Enable CMS Addressing

This option can be used on devices that support TeleBUS protocol. If enabled, the driver starts to accept a 16 bits WORD as the slave address. That is, it is possible to define values above 255 and below 65536 as the slave address. In this case, the slave address is defined on the protocol by 3 bytes. If this options is enabled, the Default Slave Address option will no longer work.

Data Address Model Offset

This option enables or disables standard data offset of the protocol. On the standard data model of the protocol, four data blocks are defined, which are Discrete Inputs, Coils, Input Register and Holding Register. In each one of these blocks, the data elements are addressed starting at 1. The communication frame specification, on the other hand, defines a Protocol Data Unit (PDU) containing addresses that may vary from 0 to 65535. The relationship between the addressed provided on the PDU and the data element address, therefore, has an offset of 1. That is, if in the PDU of a request there is a 0 address, the data element accessed will be the address 1.With this option, the user can choose if he wants the driver to automatically adjust the value, in order to allow using data element address on tags, or if he wants the value sent on the PDU be the value provided on tag configurations. The options are:

· Data is addressed from 1: address provided on N4/B4 parameter will be decremented of 1 before sent to the device.
· Data is addressed from 0: address provided by the user will be used on protocol requests, without changes.

NOTE: The Data Address Model Offset option used to be named Use Older Address on versions prior to version 2.3 of this driver, where the Data is addressed from 1 option is the equivalent of the old Use Older Address option enabled, and the Data is addressed from 0 option is equivalent to the Use Older Address option disabled.

Option | Description
Default Slave Address | This feature allows you to configure a slave default address, so as not to be necessary to configure it in every tag. To use this resource, just configure the N1/B1 parameter as 1000. That is, all tags with B1/N1 = 1000 will have this value replaced by the value configured in the text box Default Slave Address. It is also possible to force the use of the default address in all tags, regardless of the value configured in N1/B1, by checking the Force Default Address option.
Use swap address delay | This option should be usually left disabled. It should be used only in some rare cases, when the controllers in the network require a delay after the communication with a specific slave, before being able to communicate with another slave. If your system requires such delay, you can enable the checkbox and enter the delay in milliseconds.
Wait Silence on error | If this option is enabled, after each communication error the driver will remain in loop receiving data until a timeout occurs. This clears the reception channel, preventing problems on future communications due to the reception of delayed bytes, which are still flowing at the moment of the error, and which may get confused by an answer to a new command.


Configuring in Offline Mode

The driver configurations can also be accessed at run time if the driver is started on OFFLINE mode, using the following strings:

PARAMETER

TYPE

ModiconModbus.ModbusMode

Integer:

· 0: Modbus RTU
· 1: Modbus ASCII
· 2: Modbus TCP

ModiconModbus.Olderaddr

Boolean (0 or 1)

· 1: data is addressed from 1
· 0: data is addressed from 0

ModiconModbus.UseDefaultSlaveAddress

Boolean (0 or 1)

ModiconModbus.DefaultSlaveAddress

Unsigned integer

ModiconModbus.UseSwapAddressDelay

Boolean (0 or 1)

ModiconModbus.SwapAddressDelay

Integer

ModiconModbus.WaitSilenceOnError

Boolean (0 or 1)

ModiconModbus.EnableCMSAddressing

Boolean (0 or 1)

ModiconModbus.EnCustomizeSuperblockSize

Boolean (0 or 1)

ModiconModbus.EnCustomizeMaxPDUSize

Boolean (0 or 1)

ModiconModbus.MaxPDUSize

Integer

ModiconModbus.ConfigFile

String containing configuration file with driver's read/write operations

For more information about OFFLINE configuration at run time, please refer to the IOKit User's Manual.


Configuring PLC/Communication Tags

The tags of this driver allow reading and writing on Modbus records on slave devices, using Modbus protocol functions. Data is read from the device in 16-bit WORD format, according to protocol specification, but they can be formatted according to one of the data types supported by the driver, before they are sent back to the application.

Driver operations can be defined on the driver's configuration window, formed by Modbus protocol reading and writing functions, and by a specific data format. These operations can be referenced usign N2/B2 parameters of the record access tags.

· N1: Address of the slave device (PLC) on the network. This address may vary from 1 to 255. You may still configure this parameter with a value of 0. Then this tag will work on broadcast mode, sending the message to all slave devices (PLC) that are on the network.

NOTE: on broadcast mode, with N1 = 0, it is not possible to perform readings, only writings. In this mode, all the network devices will be addressed, receiving the written value and not returning any answer, in order to avoid network conflicts.

· N2: Operation code. References a reading or writing operation added to the driver configuration window.
· N3: Additional parameter. For reading and writing file functions (functions 20 and 21), the N3 parameter specifies the file to be accessed. For the other reading and writing functions of the registers, N3 specifies the mask to be used on reading. This parameter will only be used if the Use Bit Mask option is enabled for the current operation, and the number of a specific bit to return is selected. A value of zero indicates the less significant bit. The value of the selected bit will always be returned on the value's less significant bit. That is, if Use Bit Mask option is enabled for operation on configuration window, the returned value of the tag will always be 0 or 1.
· N4: Address of the register or variable on the slave device (PLC) that needs to be read or written.

In addition to Modbus record access tags, there are also special tags to perform a specific function of the driver, as shown in the table below:

Special Tags

N2/B2 | Special Tag description
9001 | Forces execution of a "Wait Silence" (see section Configuring Special Tag to Force "Wait Silence")
9999 | Reads the last exception (see section Configuring Special Tag to Read Last Exception Codes)


Configuring Block Tags

These driver tags allow reading and writing Modbus registers on slave devices.

Using block tags you have the advantage of, on a single communication, read or write on several registers of the slave device.

For this, you must configure B parameters as described next:

· B1: Slave device address (PLC) on the network. This address may vary from 1 to 255. You may also configure this parameter with a value of 0. Then this tag will work on broadcast mode, sending the message to all slave devices (PLC) that are on the network.

NOTE: on broadcast mode, with N1 = 0, it is not possible to perform readings, only writings. In this mode, all the network devices will be addressed, receiving the written value and not returning any answer, in order to avoid network conflicts.

· B2: Number of reading or writing operation added on the driver configuration window.
· B3: Additional parameter. For reading and writing file functions (functions 20 and 21), B3 parameter specifies the file to be accessed. For the other reading and writing functions of the registers, B3 specifies the mask to be used on reading. This parameter will only be used if Use Bit Mask option is enabled for the current operation, and selects the number of a specific bit to return. A value of zero indicates the less significant bit. The value of the selected bit will always be returned on the value's less significant bit. That is, if Use Bit Mask option is enabled for operation on configuration window, the returned value of the tag will always be 0 or 1.
· B4: Address of the register or variable on slave device (PLC) that needs to be read or written.


Configuring Special Tag to Force "Wait Silence"

Special Tag used to discard all pending data communication until it finds a "timeout", indicating that there is no more data to be collected.

This Special Tag runs via a Tag PLC write command, with parameter B2 = 9001.


Configuring Special Tag to Read Last Exception Codes

As previously mentioned, the special tags for retrieving last exception codes are used to read the last exception code sent by a defined slave device. Such exception codes are automatically stored in driver internal registers, which can be accessed through this special tag. In addition, after each successful communication with a device that does not return any exception code, the driver automatically resets the associated internal register.

Exception codes are used by slaves to inform the master about errors occurred while executing a requested function. Slave devices do not return exceptions in case of communication errors; in such situations, slaves simply do not respond. Instead, slaves send the exceptions when the request frame was successfully received, but the requested function could not be performed by some reason, such as an attempt to read or write on a non-existent register. The exception code returned indicates the type of error that occurred. The Modbus specification defines nine exception codes, which are shown on the next table. In addition to these codes, some manufacturers also define additional exception codes, which are exclusive for their products.

The most usual way of using this tag during normal tag scan is through the exception tag OnRead event. In this case, the event script must first reject null values, since they indicate no exception was received. If a non-null value is read, the exception code reading can then be processed. It is advisable to reset the exception tag when leaving the script, to indicate this exception has already been hadled.

See the example below, written in Elipse Basic (Elipse SCADA):

// TagExc OnRead event

// Note: Consider the TagExc automatic read an write properties enabled

IF TagExc == 0

RETURN

ENDIF

IF TagExc == 1

... // PROCESS EXCEPTION CODE 1

ELSEIF TagExc == 2

... // PROCESS EXCEPTION CODE 2

ELSE

... // PROCESS OTHER EXCEPTION CODES

ENDIF

TagExc = 0 // RESETS INTERNAL EXCEPTION CODE REGISTER

See the example below, written in VBScript (Elipse E3):

'TagExc OnRead event

'Note: Consider the TagExc automatic read an write properties enabled

Sub TagExc_OnRead()

If Value = 0 Then

Exit Sub

End If

If Value = 1 Then

... 'PROCESS EXCEPTION CODE 1

ElseIf Value = 2 Then

... 'PROCESS EXCEPTION CODE 2

Else

... 'PROCESS OTHER EXCEPTION CODES

End If

Value = 0 'RESETS INTERNAL EXCEPTION CODE REGISTER

End Sub

On the other hand, in writing operations performed in scripts, in which one needs to read the exception code sent by the slave following the writing operation, the first thing to do is to reset the respective exception register, so the new exception read do not get confused with any preexisting exception. The script must then test the exception register after the writing operation. If the code read is not zero, the exception code can then be appropriately processed.

See the example below, written in Elipse Basic (Elipse SCADA):

// Note: Consider TagExc automatic read and write properties enabled

// and TagVal automatic write disabled

TagExc = 0 // RESETS EXCEPTION REGISTER

TagVal.WriteEx(10) // WRITES THE VALUE 10

IF TagExc <> 0

... // PROCESS EXCEPTION CODE

ENDIF

See the example below, written in VBScript (Elipse E3):

'Note: Consider TagExc automatic read and write properties enabled

' and TagVal automatic write disabled

Application.GetObject("Tags.TagExc").Value = 0 'RESETS EXCEPTION REGISTER

Application.GetObject("Tags.TagVal").WriteEx(10) 'WRITES THE VALUE 10

If Application.GetObject("Tags.TagExc").Value <> 0 Then

... 'PROCESS EXCEPTION CODE

End If

NOTE: The special B2 = 9999 tag returns, in addition to the exception code, the parameters of the tag whose communication would have generated the exception. In case such information is not needed, one can also use a PLC type tag with N2 = 9999 to read the same information. All previous recommendations remain valid in this case.

Standard exception codes, as defined by the Modbus protocol specification

Code | NaME | Meaning
1 | ILLEGAL FUNCTION | The function code received in the query is not an allowed action for the server (or slave). This may happen because the function code is only applicable to newer devices, and was not implemented in the selected unit. It could also indicate that the server (or slave) is in the wrong state to process a request of this type, for example, because it is not configured and is being asked to return register values.
2 | ILLEGAL DATA ADDRESS | The data address received in the query is not an allowed address for the server (or slave). More specifically, the combination of reference number and transfer length is invalid. For a controller with 100 registers, a request with offset 96 and length 4 would succeed, a request with offset 96 and length 5 will generate exception 02.
3 | ILLEGAL DATA VALUE | A value contained in the query data field is not an allowed value for server (or slave). This indicates a fault in the structure of the remainder of a complex request, such as that the implied length is incorrect. It specifically does NOT mean that a data item submitted for storage in a register has a value outside the application program expecting, since the Modbus protocol is unaware of the meaning of any particular value of any particular register.
4 | SLAVE DEVICE FAILURE | An unrecoverable error occurred while the server (or slave) was attempting to perform the requested action.
5 | ACKNOWLEDGE | Used together with programming commands. The server (or slave) has accepted the request and is processing it, but it will took a long time in this operation. This response is returned to prevent a timeout error from occurring on the client (or master). The client (or master) can next issue a Poll Program Complete message to determine if processing is completed.
6 | SLAVE DEVICE BUSY | Used together with programming commands. The server (or slave) is engaged in processing a long duration program command. The client (or master) should resend the message later when the server (or slave) is free.
8 | MEMORY PARITY ERROR | Used together with function codes 20 and 21 and reference type 6, to indicate that the extended file area failed to pass a consistency check. The server (or slave) attempted to read a record file, but detected a parity error on the memory. The client (or master) can retry the request, but maintenance may be required on the server (or slave) device.
0A | GATEWAY PATH UNAVAILABLE | Used together with gateways, indicates that the gateway was unable to allocate an internal communication path from the input port to the output port for processing the request. Usually this means that the gateway is misconfigured or overloaded.
0B | GATEWAY TARGET DEVICE FAILED TO RESPOND | Used together with gateways, indicates that no response was obtained from the target device. Usually means that the device is not present on the network.


Reading Event Buffer on GE PAC RX7 Controllers

To read event buffer (SOE) from GE PAC RX7 controllers, there must be defined on the driver configuration window a driver function using, as a reading function, the SOE GE option, and as a writing Modbus function the function 6 (Write Single Register). The data type must be defined as GE Events.

The event buffer can be read through three types of tags: tags reported by events, tags reported by events by points, and real time tags.

Tags Reported by Events

Tags reported by events return, at each reading operation, all events stacked on the driver's internal buffer.

The following parameters must be used:

· B1: Slave ID.
· B2: Operation Code defined on SOE GE function.
· B3: 0.
· B4: Base address of the event stack in the PLC.

On each scan of this tag, the driver will check if there are events on the controller. If there are, the driver will start an event reading thread, which will be executed in background, not blocking other tags scanning. After finishing buffer reading by the driver, this tag, reported by events, will return a set of reading events on the scan.

The events returned generate successive OnRead() events on this tag. For each reading event, E3 will update tag fields (element values and timestamp) with values from a certain event, and will call once the OnRead() event. The event called must be user-defined.

Each event will be represented by a two elements block, with a timestamp field indicating the value read from the device. The fields of the respective reading block tag are shown on the next table:

OFFSET | MEANING | DATA TYPE | RANGE
0 | Point identification | BYTE | 0 - 15
1 | Point status | BYTE | 0 - 1

Tags Reported By Events by Point

A new tag has been added to the version 2.5 of this driver, enabling the download of events for specific points.

This new tag works almost exactly as the preceding one, except for the events returned, which are associated to a single point. This point is specified in the N3/B3 parameter.

This tag does not return 2 elements, as the previous one. Instead, it returns a single element, containing the Point Status, so a PLC type tag can be used.

This tag must be configured as follows:

· N1: Slave ID.
· N2: Operation Code defined on SOE GE function
· N3: 200 + Point Index (ex: for point = 2, N3 = 202).
· N4: Base address of the event stack in the PLC.

Real Time Tags

These tags return the most recent event ever read for a specific point. These events are stored on the driver's internal memory at each event reading of the PLC, with their respective timestamps read from the device.

This tag uses the following parameters:

· B1: Slave ID.
· B2: Operation Code.
· B3: 100 + Point Index.
· B4: Base address of the event stack in the PLC.

Different from the previous one, this tag can be represented by a PLC tag or by a Block tag with only one element. The returned value represents the Point Status field of the event.


Step by Step

This section describes the necessary steps to configure Modbus driver.


Inserting the Driver

If you are using Elipse Scada, see the chapter Adding driver on Elipse Scada.

If you are using Elipse E3, see the chapter Adding driver on Elipse E3.


Configuring the Driver

Please, read the chapter Configuring the Driver.


Configuring Communication Tags

If you are going to use PLC/Communication Tag, read the chapter Configuring PLC/Communication Tags.

If you are going to use Block tags, read the chapter Configuring Block Tags.


Frequently Asked Questions

1) Known particularities of Twido devices from Schneider company.

· It is trying to read a float value but it is not getting it. On PLC, the address has a value of -234.5 and on Elipse it is displaying 0.

Answer: You should enable the Swap Word option on writing and reading function configuration of Modbus.

· It is trying to read PLC input and output but it is not getting it.

Answer: This device does not allow reading or writing on the input and output variables, and it is necessary to use PLC internal variables to make this bridge. That is, to create a mirror of inputs and outputs on an area where the Elipse driver have access to. You should also be careful while creating a routine on the PLC to check when an output value were changed by the supervisory so that it really be activated or deactivated by the PLC.

2) Known particularities of MPC 6006 from Atos - Schneider.

· It is trying to read a value of type DWord, however, is not getting the correct value. The application is presenting different values to those in the PLC.

Answer: You should enable the Swap Byte and Swap Word in the settings of reading and writing Modbus functions to agree with the "byte order" used by the PLC.

NOTE: Some of Atos PLCs allow the "byte order" is configured by the user.

3) How should I combine two Int16 type values (that are on the PLC) into a Int32 type (on Elipse)?

· I have a 32 bit value that is stored on 2 bytes of 16 bits each on the PLC. How should I do to display this number on the Elipse screen as a single record?

Answer: You should create, on Driver configuration window, a 03 reading function and a 05 writing function with Int32 data type. On communication tag configuration, you must use this function for reading and writing and inform the first address of the PLC variables.

NOTE: If the value to be read or written is unsigned it is still possible to configure, on Driver configuration window, a 03 reading function and 05 writing function with a DWord data type.
· I have my application already developed, but I want to know how to join two Word values on a single tag?

Answer: It is possible to join them using scripts. For this you must multiply the Word that contains the highest part of the Word by 32768 and then sum the Word that contains the lowest part of the Word. For example: (HighWord * 32768) + LowWord.

· I need to read Float type values, I configured the reading function as being 03 and the writing function as being 16 besides the data type to be Float, but on Elipse appears a value that does not match the value on the device.

Answer: The Modbus driver by default is big-endian. As it is a 32 bit data, it is necessary to invert all bytes. In this specific case it is necessary to check the Swap Byte and Swap Word options on reading and writing function configurations on the Driver configuration window.

4) How can I communicate with more than one device on my SERIAL communication network?

· I have more than one device on my serial network, each one with a unique address, how should I communicate with each one of them?

Answer: You should only be careful with N1 parameter of each tag because it is on this field that you must indicate with which device you want to communicate. The reading and writing functions may be the same for any device.

· I have more than one serial port on my computer, how should I configure the driver to communicate with devices that are connected on each one of the ports?

Answer: On this case, as there is more than one different physical layer (Serial 1, Serial 2, etc.), it is necessary to have as many communication drivers as the existent ports. The configuration referring to reading and writing functions is the same for all drivers. The only difference is that one driver must be configured to communicate via Serial 1, another driver must be configured to communicate via Serial 2, another one must be configured to communicate via Serial 3, and so on.

NOTE: It is important to be careful to not use the same DLL file for all drivers. Always indicate or make a copy of the file renaming it and placing it on another directory. Each added driver on Elipse must point to a different DLL file.

5) How can I communicate with more than one device on my SERIAL communication network with RS485 converter?

· I have an RS485 network with multiple devices communicating through a RS232<->RS485 converter by the serial port. Always that change of address (ID) between the slave devices, occurs a "time-out". After retry the same message, the unit responds normally. Is there any way to avoid this "time-out" during the change of address (ID)?

Answer: Some RS232<->RS485 converters requires a time interval to "switching" the RS485 network address, for this, use the "Inter-frame delay" option on tab "Serial" of Driver configuration, trying values from 50 up to 300 ms of time interval between messages.

6) How should I communicate with more than one device on my ETHERNET communication network?

· I have more than one device on my Ethernet network, each one with a unique IP address, how should I communicate with each one of them?

Answer: Now, for each IP address, it is necessary to have as many communication drivers as IP address you want to communicate. The communication referring to reading and writing functions is the same for all drivers. The only difference is that one driver must be configured to communicate with IP address 1, another driver must be configured to communicate with IP address 2, another driver must be configured to communicate with IP address 3, and so on.

NOTE: It is important to be careful to not use the same DLL file for all drivers. Always indicate or make a copy of the file renaming it and placing it on another directory. Each added driver on Elipse must point to a different DLL file.

7) Modbus Software Simulator.

· There is some software that simulates Modbus protocol which I can use to test with Elipse driver?

Answer: Yes. There is a Modsim software that simulates Modbus Slave protocol. It can be found at http://www.win-tech.com/html/modsim32.htm. There is also a Free Modbus PLC Simulator, available at www.plcsimulator.org.

8) How to configure N4/B4 parameter of communication tags.

· How should I know which address to use on N4/B4 parameter of my communication tag?

Answer: This address vary from device to device. To know which is the exact address to be used, please check the device manual or contact its technical support.

9) When to use RTS and DTR controls (which appear on Serial tab of Driver configuration window)

These signals are used only when communication between Elipse and the device is done using the Serial physical layer. You must check the device documentation or the vendor support to get the correct configuration. Next there is a description of some known configurations.

· I want to communicate with a N1100 device from Novus using a RS232/RS485 converter. Is it necessary any special configuration?

Answer: On this case it is necessary to configure the RTS control to Toggle.

· I want to communicate with Field Logger device from Novus using a USB/Serial converter and also using a RS232/RS485. Is it necessary any special configuration?

Answer: In this case it is necessary to configure the RTS control to Toggle and the DTR control to ON.

10) When to use Swap Byte and Swap Word functions.

· I am trying to read a Float type value but I am not getting it. On the PLC, this address has a value of -234.5 and on Elipse it is displayed as 0.

Answer: You should enable Swap Word option on Modbus reading and writing configuration functions.

· I am trying to read a floating point type value but the value that is displayed on Elipse is much more different from the one on the PLC.

Answer: A float value is composed of one exponent byte (EXP) and three more mantissa bytes (F0 F1 F2), summing four bytes (32 bits). The Modbus driver waits to receive a Float value on the following byte order: EXP F2 F1 F0. Sometimes, there may have a device that sends a Float value in another byte order, for example, F0 F1 F2 EXP. In this case, it will be necessary to reorder the received bytes from the device to the EXP F2 F1 F0 order, so that the driver could correctly interpret Float data. This way, to change from F0 F1 F2 EXP to EXP F2 F1 F0, it is necessary to enable Swap Byte and Swap Word options.


Driver Revision History

 Top Previous

VERSION

DATE

AUTHOR

COMMENTS

2.07

06/30/2010

A. Quites
· Adjustments in the reception of data to discard possible invalid bytes (case 11394).

C. Mello
· Update topic "Configuring Special Tag to Read Last Exception Codes" of the driver documentation (case 11233).
· Update topic "Frequently Asked Questions" of the driver documentation (case 11316).

2.06

11/26/2009

A. Quites
· Removed false error message in the LOG file for reading data from memory address zero (case 10654).
· Optimization of the reading of type bit via superblock (case 10971).

C. Mello
· Changed routine "Wait Silence" to be performed on any errors that occur in the driver. User can also run the "Wait Silence" manually by the new Special Tag N2 = 9001 (case 10850).
· Support for compatibility with the Windows CE platform (case 10914).

2.05

06/30/2009

A. Quites
· Fixed bug in the Swap Address Delay (case 10425).
· Default PDU maximum size updated in accordance with the modbus.org version 1.1b standard (case 10274).
· Fixed bug in the special tags for reading of the last exception, to avoid failure to report some exceptions (case 10337).
· Fixed bug in the year field of GE SOE events returned with the current day (GE PAC RX7) (case 10382).
· Fixed bug in function 20 - Read File Record (case 10312).

M. Ludwig
· Added new tag for reading of GE SOE events of specific points (case 10370).

2.04

02/17/2009

A. Quites
· Fixed an error reading on Bit types with superblocks (case 10100).
· Implemented most recent GE SOE event reading (case 10178).
· Created standard operations for the most common function types (case 9185).

2.03

09/02/2008

C. Mello
· Added new Float_GE data type (case 9427).

A. Quites
· Fixed an error on offline configuration of ModiconModbus.ModbusMode parameter (case 9831).
· Implemented a bit mask reading of registers (case 9682).
· Implemented an event buffer reading on GE PAC RX7 controllers (case 9523).
· Added the possibility to set the maximum PDU (case 9154).
· Fixed error in the bytes reordering features (Swap Byte, Swap Word, Swap DWord, Rev. Frame) when reading Word data type with Read Grouping (superblocks) enabled (case 9220).
· Implemented Enable CMS Addressing option (case 8665).
· Revision of less used Modbus functions (case 8730).
· Improved verification of data written using Modbus function 06 - Write Single Register (case 8663).

2.02

05/11/2007

A. Quites
· Fixed bug in the block reading of non-Word types, with superblocks (EnableReadGrouping) enabled (case 8243).

2.01

01/23/2007

A. Quites
· Added support for superblocks (case 6185).
· Improved consistency of N2/B2 parameters of register access tags (case 7714).
· Fixed bug in the reading of BCD data blocks types with size 4 (case 7728).
· Fixed bug in the reading of blocks of strings (case 7804).

2.00

11/10/2006

A. Quites
· Original IOKit version (case 3339).

1.00

R. Farina
· Every release published before revision control.


Configuring Special Tags to Read Last Exception Codes

 Top

As already mentioned, the special tags for retrieving last exception codes are used to read the last exception code sent by a defined slave device. Such exception codes are automatically stored in driver internal registers, which can be accessed through this special tag. Besides, after each successful communication with a device, which does not return any exception code, the driver automatically resets the associated internal register.

Exception codes are used by slaves to inform the master about errors occurred while executing a requested function. Slave devices do not return exceptions in case of communication errors, in such situations slaves simply do not respond. Slaves instead send the exceptions when the request frame was successfully received, but the requested function could not be performed by some reason, as for example the attempt to read or write on a non-existent register. The exception code returned indicates the type of error that occurred. The Modbus specification defines nine exception codes which are shown on the next table. Besides these codes, some manufacturers also define additional exception codes, exclusive of their products.

The most usual way of using this tag, during normal tag scan, is through the exception tag OnRead event. In this case, the event script must first reject null values, since they indicate no exception was received. If a not null value is read, the exception code reading can then be processed. It is a good practice to reset the exception tag when leaving the script, to indicate this exception has already been treated.

For an example, see the next Elipse Basic (Elipse SCADA) script:

// TAGEXC OnRead EVENT

// Note: Consider the TAGEXC automatic read an write properties enabled

IF TAGEXC == 0

RETURN

ENDIF

IF TAGEXC == 1

...// PROCESS EXCEPTION CODE 1

ELSEIF TAGEXC == 2

...// PROCESS EXCEPTION CODE 2

ELSE

...// PROCESS OTHER EXCEPTION CODES

ENDIF

TAGEXC = 0 // RESETS INTERNAL EXCEPTION CODE REGISTER

On the other hand, in writing operations performed in scripts, in which one needs to read the exception code sent by the slave following the writing operation, the first thing to do is to reset the respective exception register, so the new exception read do not get confused with any preexisting exception. The script must then test the exception register after the writing operation. If the code read is not zero, the exception code can then be appropriately processed. See the next example, also in Elipse Basic (Elipse SCADA):

// Obs.: for that example, consider TAGEXC automatic read and write

// properties enabled, and TAG automatic read disabled

TAGEXC = 0 // resets exception register

TAG = 10

TAG.WRITE()

IF TAGEXC <> 0

...// process exception code

ENDIF

NOTE: The special B2 = 9999 tag returns, besides the exception code, the parameters of the tag whose communication would have generated the exception. In case such information is not needed, one can also use a PLC type tag with N2 = 9999 to read the same information. All previous recommendations remain valid in this case.

Standard exception codes, as defined by the Modbus protocol specification

Code | NaME | Meaning
1 | ILLEGAL FUNCTION | The function code received in the query is not an allowed action for the server (or slave). This may happen because the function code is only applicable to newer devices, and was not implemented in the selected unit. It could also indicate that the server (or slave) is in the wrong state to process a request of this type, for example, because it is not configured and is being asked to return register values.
2 | ILLEGAL DATA ADDRESS | The data address received in the query is not an allowed address for the server (or slave). More specifically, the combination of reference number and transfer length is invalid. For a controller with 100 registers, a request with offset 96 and length 4 would succeed, a request with offset 96 and length 5 will generate exception 02.
3 | ILLEGAL DATA VALUE | A value contained in the query data field is not an allowed value for server (or slave). This indicates a fault in the structure of the remainder of a complex request, such as that the implied length is incorrect. It specifically does NOT mean that a data item submitted for storage in a register has a value outside the application program expecting, since the Modbus protocol is unaware of the meaning of any particular value of any particular register.
4 | SLAVE DEVICE FAILURE | An unrecoverable error occurred while the server (or slave) was attempting to perform the requested action.
5 | ACKNOWLEDGE | Used together with programming commands. The server (or slave) has accepted the request and is processing it, but it will took a long time in this operation. This response is returned to prevent a timeout error from occurring on the client (or master). The client (or master) can next issue a Poll Program Complete message to determine if processing is completed.
6 | SLAVE DEVICE BUSY | Used together with programming commands. The server (or slave) is engaged in processing a long duration program command. The client (or master) should resend the message later when the server (or slave) is free.
8 | MEMORY PARITY ERROR | Used together with function codes 20 and 21 and reference type 6, to indicate that the extended file area failed to pass a consistency check. The server (or slave) attempted to read a record file, but detected a parity error on the memory. The client (or master) can retry the request, but maintenance may be required on the server (or slave) device.
0A | GATEWAY PATH UNAVAILABLE | Used together with gateways, indicates that the gateway was unable to allocate an internal communication path from the input port to the output port for processing the request. Usually this means that the gateway is misconfigured or overloaded.
0B | GATEWAY TARGET DEVICE FAILED TO RESPOND | Used together with gateways, indicates that no response was obtained from the target device. Usually means that the device is not present on the network.