Welcome to PiiGAB M-Bus OPC Server v1

 Top Next

Welcome to a new dimension of M-Bus communication.

PiiGAB M-Bus OPC Server is a thin server that radically simplifies the communication with different M-Bus devices. You can mix meters from different manufacturers independently of single or multi-telegram, primary or secondary addressing, application reset etc.

PiiGAB reserves the right to revise, change or correct the contents within this document without any prior notice.

Copyright © 2005 to 2008 by PiiGAB, Processinformation i Göteborg AB. All trademarks or registered trademarks, used in this document, are the property of their respective owners.


Introduction

 Top Previous Next

The topics in this section provide some basic information about PiiGAB M-Bus OPC Server, what it's for and what you can do with it.

How to get started

► See Installation for details on how to install PiiGAB M-Bus OPC Server.
► Study the Introduction and User Interface sections for an introduction to the program.

Learning more

► See the Working Procedure section for detailed instructions on using PiiGAB M-Bus OPC Server.

How to buy

► See the How to buy section for detailed instructions on buying PiiGAB M-Bus OPC Server.


About PiiGAB M-Bus OPC Server

The PiiGAB M-Bus OPC Server v1 are supporting the OPC Server Data Access specifications 2.00, 2.05a and 3.00.

Key features for PiiGAB M-Bus OPC Server.

· Generic M-Bus OPC server
· Supports Variable Data Structure
· Mix different manufacturers on the same bus
· Supporting object tag type Value, Vib, Unit, Tariff, Storage, Function, Datatype, Record etc.
· Supports header tag type Idnumber, Manufacturer, Version, Medium, Access number, Status, Signature etc.
· All data types automatically converted to strings if needed.
· Vib reads standard and manufacturer specific text automatically from M-Bus tables
· Support for manufacturer specific data
· M-Bus strings is cached in the server for better performance
· Primary and secondary addressing
· Inheritance parameters
· Multi telegram support
· Serial, tcp and udp support

Running modes

The server and the interface can be used in several modes

Configuration

The configuration works totally independent from the server itself. You can make as many configuration files as you want during an unlimited time without a server license.

Monitor

The monitor function in the interface contents an OPC client. The server itself is a thin OPC server without an inbuilt interface.

Running

When you're using the client you can have the interface monitor connected during the same time.

See also:

Welcome to PiiGAB M-Bus OPC Server v1


Links and credits

M-Bus User group home page:

M-Bus Usergroup. International organization of users and producers of M-Bus devices.

weblink http://www.m-bus.com

Credits for the PiiGAB M-Bus OPC Server development:

Knowledge of OPC related subjects

We have used the server tool from OPC Labs. OPC Labs have also supported PiiGAB regarding all the OPC related subjects.

weblink http://www.opclabs.com

weblink http://www.quickopc.com

Knowledge of networking subjects

Trosoft AB, with the homepage below, has made the udp and tcp part in the server

weblink http://www.automatisera.nu

Knowledge of interface subjects

Basab Building Automation Software AB, has made the server interface.

See also:

How to contact PiiGAB


How to buy PiiGAB M-Bus OPC Server

You can buy PiiGAB M-Bus OPC Server direct from PiiGAB or from your system integrator. The PiiGAB M-Bus OPC Server is delivered in four different levels. Below you have a table with the different article numbers.

New licenses:

Article Number | Devices
PI-MBOPC20 | 1-20
PI-MBOPC250 | 1-250
PI-MBOPC1000 | 1-1000
PI-MBOPCN | 1-unlimited

Upgrades:

Article Number | Devices From è To
PI-MBOPC20-250 | 1-20 è 1-250
PI-MBOPC20-1000 | 1-20 è 1-1000
PI-MBOPC20-N | 1-20 è 1-unlimited
PI-MBOPC250-1000 | 1-250 è 1-1000
PI-MBOPC250-N | 1-250 è 1-unlimited
PI-MBOPC1000-N | 1-1000 è 1-unlimited

PiiGAB home page:

weblink http://www.piigab.com

weblink http://www.piigab.se

General questions:

weblink info@piigab.se

Email support:

weblink info@piigab.se

Contacts:

PiiGAB

Anders Carlssons gata 1

S-417 55 Göteborg

Sweden

Tel: +46 (0)31 55 99 77

Fax: +46 (0)31 22 70 71

See also:

Links and credits


Demo version

You can run PiiGAB M-Bus OPC Server in demo mode for 30 minutes. During demo you can connect and browse one channel and two devices. No other limitations are implemented.

When you buy a full license you don't need to reinstall anything only to plug in the dongle key or install the Registration Code and you are up and running.

License information dialog:

Example of a demo license

See also:

How to buy PiiGAB M-Bus OPC Server

License

License key


Installing

This chapter describes how to install and uninstall PiiGAB M-Bus OPC Server.


Installation step by step

To install PiiGAB M-Bus OPC Server, use the following procedure.

Full installation instructions

1. Perform the appropriate step to start the installation:
· If PiiGAB M-Bus OPC Server is on a CD-ROM, insert the CD-ROM into the computer’s CD-ROM drive.
· If you downloaded PiiGAB M-Bus OPC Server, double-click the downloaded file.

Either step displays the Welcome screen.

2. Click the Next button. The License Agreement dialog box appears.

· If you accept the license agreement click on the radio button "I accept the agreement".

3. Click the Next button. The User Information dialog box appears.

4. Click the Next button. The Select Destination Location dialog box appears.

· The path shows where the PiiGAB M-Bus OPC Server will be installed. We recommend the default location. To change this location, click the Browse button and select a different location.

5. Click the Next button. The Select Components dialog box appears.

· For a Full installation don't uncheck any checkbox.
· You can choose to make a custom installation with only some parts if you want.

6. Click the Next button. The Select Start Menu Folder dialog box appears.

· The path shows where the shortcuts will be installed. We recommend the default location. To change this location, click the Browse button and select a different location.

7. Click the Next button. The Select Additional Tasks dialog box appears.

· Check the box if you want the installation program shall create a desktop icon for you.

8. Click the Next button. The Ready to Install dialog box appears.

9. Click the Next button. The Installing dialog box appears.

· If the .NET framework is not detected on your computer you will see the following message. This is only for your information.

10. The Completing dialog box appears.

· Click Finish to complete the installation.

See also:

Uninstall


Requirements

Minimum system requirements

· Pentium II with Windows NT4 with service pack 6, Windows 2000 or Windows XP.
· 266 MHz processor
· 64MB ram
· 50 MB free space on the hard disk.
· Internet Explorer 4.0 or higher

See also:

Installation step by step


License key

The license key can be a hardware key or a software key. The hardware key is of type Sentinel SuperPro and it's delivered as an USB key or a mini parallel port key.

If you don't already have the sentinel driver installed on your computer you can find it at the CD or you can download the driver from our homepage http://www.piigab.se

If you need to update or make a control so you have the latest sentinel driver you can download it from http://www.safenet-inc.com/support/tech/sentinel.asp

See also:

License dialogbox


Uninstall

To Uninstall PiiGAB M-Bus OPC Server, use the following procedure.

1. Go to the Start Menu Folder where the PiiGAB M-Bus OPC Server is installed and click on the Uninstall icon. The below message should appear.

· Click Yes to continue the uninstall process.

2. The below message should appear when the uninstall is finished.

· Click Finish to complete the uninstall.

See also:

Installation step by step


Registering the server

The PiiGAB M-Bus OPC Server needs to be registered in order to show up in an OPC client's server browser. The server is registered automatically when you run the setup program. If you need to re-register the server use the command below in a Command Window.

To register the server:

[Drive:\][Path\]MBusOPC.exe /regserver

See also:

Unregistering the server


Unregistering the server

To unregister the PiiGAB M-Bus OPC Server use the command below in a Command Window.

To unregister the server:

[Drive:\][Path\]MBusOPC.exe /unregserver

See also:

Registering the server


User Interface

The PiiGAB M-Bus OPC Server user interface:


Overview

This topic provides a brief guide to the components of PiiGAB M-Bus OPC Server's user interface.


Menus

This section provides a reference to the individual menus and controls in the dialogs accessed with PiiGAB M-Bus OPC Server's menus.

Please note that although this reference is quite complete, only dialogs that really need explaining are documented in this section. For example, we assume that you can figure out what menu entries like Save and Save As do for yourself.


The File Menu

This menu contains the basic file options for creating, opening, saving and getting/setting PiiGAB M-Bus OPC Server projects.

File menu options:

New: | Create a new PiiGAB M-Bus OPC Server project file.
Open: | Open an existing project file.
Save: | Save the current project.
Save As: | Save the current project under a different name.
Get active project: | Get a saved project to be active.
Set to active project: | Set the existing project to active.
Exit: | Exits PiiGAB M-Bus OPC Server.

See also

Menus


The Edit Menu

The Edit menu contains basic editing commands like Cut, Copy and Paste. All these commands are also available via keyboard shortcuts (displayed in the menu), and most of them also have tools in the Toolbar.

Edit menu options:

Cut: | Cut the current selection to the Clipboard.
Copy: | Copy the current selection to the Clipboard.
Paste: | Paste the Clipboard contents to the current cursor position.

See also:

Menus


The View Menu

The View menu contains options for showing and hiding the various PiiGAB M-Bus OPC Server toolbars.

View menu options:

Toolbar: | Show or hide the toolbar displayed between the menu and the editing area.
Status Bar: | Show or hide the Status Bar displayed at the bottom of the page.

See also:

Menus


The Insert Menu

The Insert menu contains options for adding and inserting various M-Bus units.

Insert menu options:

Add Channel: | Adding a new channel to the configuration.
Add Device: | Adding a new device to the configuration.
Add Tag: | Adding a new tag to the configuration.

See also:

Menus


The Tools Menu

This menu provide direct access to a variety of tools included with PiiGAB M-Bus OPC Server.

Tools menu options:

License: | Show information about the installed license.
Log File: | Setting the debug level and path for the log file.

See also:

Menus


License

This dialog is used to show information about the installed license. It's also used for getting the computer System Id and to register the Software license key.

License information dialog:

Demo license

For test and demo you can connect one channel and two meters for running up to 30 minutes. The demo license is the same as a full license, therefore you don't need to make any reinstallation when going from demo to a full running license. You only have to install the hardware or software key and you are up and running.

Hardware key

The hardware key is a dongle of type Sentinel SuperPro and it's delivered as an USB key or a mini parallel port key.

If you don't already have the sentinel driver installed on your computer you can find it on the CD or you can download the driver from our homepage http://www.piigab.se

If you need to update or make sure you have the latest sentinel driver you can also download it from http://www.safenet-inc.com/support/tech/sentinel.asp

Serial Number: | The license serial number.
Demotime: | Configured demo time. Should be 0 for a full license.
Nr of channels: | Maximum number of channels in the installed license.
Nr of devices: | Maximum number of devices in the installed license.

Software key

The software key is based on a computer identification called System Id. With this System Id together with the ordered license size we will produce a registration code for you. Put in this registration code in the field "Registration Code:" and press "Store Registration Code". If everything works OK it will be shown, after some seconds, a message box with the text "Registration code was written to Registry".

Registration Code: | The license serial number.
System Id: | Computer system identification
Demotime: | Configured demo time. Should be 0 for a full license.
Nr of channels: | Maximum number of channels in the installed license.
Nr of devices: | Maximum number of devices in the installed license.

Get only System ID

If you want to find the system identification before you have installed PiiGAB M-Bus OPC Server you can use the separate software tool ShowSystemId.exe. This tool can be found on the CD or be downloaded from our homepage http://www.piigab.se

Be aware that you cannot run this tool directly from a memory sticker.

Combination of hardware and software key

It's possible to combine the hardware key with a software key. The number of channels and devices will be added together. The example below will correspond to a license of 510 channels and 1005 devices

See also:

Installation information


Log File

This dialog is used for setting debug level and path for the log file MbusOpc.log.

Log File properties dialog:

Debug Level: | Possibility to choose debugging of the M-Bus traffic.
Log file path: | The path for the log file.

See also:

Debug


Stop Server Process

The Stop Server Process provides access to stop the server process if it should be some more clients connected to the server.


The Help Menu

The Help menu provides access to this help file (Contents), which can also be accessed at any time by pressing the F1 key.

Help menu options:

Contents: | Showing this help file.
About: | Showing the copyright and version information.

See also:

Menus


Dialogs

This section provides a reference to the individual controls in the dialogs accessed with PiiGAB M-Bus OPC Server.


Channel Dialogs

The Channel Dialogs contains controls and options for inserting or changing the information around the channel communication and all the related parameters.


Channel Properties

This dialog box is used for adding new channels or for changing their properties.

Add Channel / Channel properties dialog:

This dialog box is displayed when you select one of the above options to add a new entry.

Channel Properties:

Channel Name: | Physical name of the channel, as it will appear in the namespace.
Description: | Channel description (not used in the namespace).

Set communication method

TCP Socket Client: | The channel works as a TCP socket client
TCP Socket Server: | This feature is not implemented in the current version.
UDP Socket Client: | The channel works as a UDP socket client
UDP Socket Server: | This feature is not implemented in the current version.
Serial: | The channel works as a serial client.
Dialup: | This feature is not implemented in the current version.

Set / Edit network properties

IP: | IP address e.g. 192.168.100.120
Port: | Port number
Reconnect time: | Time that have to elapse before the channel will try to reestablish a failed connection.

Set serial properties

ComPort: | The serial communication port number.
Baudrate: | The communication speed.
Databits: | Data bits is hard coded in the interface.
Stopbits: | Stop bits is hard coded in the interface.
Parity: | Parity is hard coded in the interface.

See also:

Dialogs


Device Dialogs

The Device Dialogs contains controls and options for inserting or changing the information around the addressing and communication with the meters.


Device Properties

This dialog box is used for adding new devices or for changing their properties.

Add Device / Device properties dialog:

This dialog box is displayed when you select one of the above options to add a new entry.

.

Device Properties:

Channel Name: | Physical name of the channel, as it will appear in the namespace.
Device Name: | Physical name of the device, as it will appear in the namespace.
Description: | Device description (not used in the namespace).

Address Properties:

The server are supporting both primary and secondary addressing

Primary addressing

Primary addressing is the most common method. If it's possible try to use this method regarding lesser communication traffic.

The allowed address range are 0 - 250 or 254.

Secondary addressing

The most common method with secondary addressing is to use only the meters Id number. In most cases this number is the same as the manufacturer label on the meter. Not used digits shall be filled up with the wildcard symbol 'F'. The interface it self will do this for you.

If two meters, from different manufacturers, should have the same number you need also to put in extra information about the Manufacturer, Version, Medium. If you don't know what to type in you can just make tags for Header, Idnumber, Manufacturer, Version and Medium to read out the information you need from the meter itself.

See also:

DeviceAddress

Selection and Secondary Addressing


Tag Dialogs

The Tag Dialogs contains controls and options for inserting or changing the information around the tags and data types you can use in PiiGAB M-Bus OPC Server.


Tag Properties

This dialog box is used for adding new tags or for changing their properties.

Add Tag / Tag properties dialog:

This dialog box is displayed when you select one of the above options to add a new entry

Tag Properties:

Channel Name: | Physical name of the channel, as it will appear in the namespace.
Device Name: | Physical name of the device, as it will appear in the namespace.
Tag Name: | Physical name of the tag, as it will appear in the namespace.
Description: | Tag description (not used in the namespace).
Data record: | M-Bus object number.
Tag type: | Tag type as value, tariff etc.
Data type: | OPC data type as VT_I2, VT_BSTR etc.
Bits: | The bit in status or int8.

Manufacturer specific data:

Offset: | The start byte in data record for manufacturer specific data.
Number of bytes: | Numbers of characters for manufacturers data when VT_BSTR is used
Bits: | Bit number (0 – 7) for Tag type Manufacturer Specific data.
BCD: | Check this box if the conversation of choosed manufacturer specific data shall be converted to BCD. Default is binary.

Options:

Decimals: | Number of decimals when data type VT_BSTR and scaling is used together.
Unsigned for string / real: | Check this box if you want to convert to unsigned when VT_BSTR or real is used.
Preceding zeros for BCD: | Set to 1 will show the leading zeros for M-Bus data type BCD.
Show Vib code: | Set to 1 will show the VIB code instead for text.

Access Rights:

Read: | Default in the server
Write: | Not implemented in PiiGAB M-Bus OPC Server v1.
Read and write: | Not implemented in PiiGAB M-Bus OPC Server v1.

See also:

Overview tag and data types


Tag Scale

This dialog box is used for scaling tags in one of two methods. The polynom conversion and the scale conversions can not be used at the same time. Leave the fields blank for the conversion method that not is to be used. If the fields in both methods are filled in, the OPC server will select the polynom conversion.
If all fields are blank, no conversion will take place and the value will pass through the server ‘as is’.

Scale dialog:

Polynom:

Offset (m): | The m offset ratio in the formula y = kx + m
Ratio (k): | The k polynom ratio in the formula y = kx + m

Scale:

Raw value: | The unscaled (raw) value of the variable that the OPC server reads from the meter.
Tag value: | The scaled value that the OPC server calculate from the raw value.
Min: | The raw "Min" value is scaled to tag "Min" value.
Max: | The raw "Max" value is scaled to tag "Max" value.

See also:

Tag parameters


Advanced Dialogs

The Advanced Dialogs contains controls and options for inserting or changing the information around the communication and all the objects that one can use in PiiGAB M-Bus OPC Server topics in addition to text.


Advanced Properties

This dialog box is used for changing the default M-Bus and communication inherited parameters for the channel and/or device tree.

Advanced dialog:

The parent level of the inherited parameter value can be found inside brackets below in the advanced properties dialog box. If you wants to break the tree thread you can write a new value. This new value will be inherited to the child.

M-Bus settings:

Live time: | Time for the server cache to live before reread.
Number of telegrams: | The number of telegrams the server will request from any device. If the device still have unread telegrams, they will be discarded.
Manual value: | Manual forced value of number of telegrams to request. Default is all telegrams in the meter.
Init read: | Determines the behaviour before any request is sent to the device.
Sub code: | Determines the behaviour if an optional application reset subcode is needed.

Communication settings:

Retries: | The number of times to retry a request which has timed out after no response.
Timeout: | If devices does not answer within this time, retries are made up to the number of desired retries.
Delay: | The period, in milliseconds, to wait between receiving a response and sending the next command. (Should be around 50mS)
Restart time: | The time that will elapse before an off-line device will be restarted (by an init message etc). Be careful to not use a to short interval, though it will affect performance.

See also:

Parameter inheritance


Working Procedure

This section describes the most common basic tasks you will use when working with PiiGAB M-Bus OPC Server.

The topics in this section are intentionally kept as brief as possible. The focus is on how to do what you need to do. More detailed background information on many subjects is provided in the Reference section and in other areas. Links to this information are provided in every topic in this section, and links back to the relevant subjects are also included in all the Reference sections.


Creating an empty new project

This part shows you the basics of creating a new project.

1. Select New in the File menu or click on new in the Toolbar to create a new project.
2. Select Add Channel.. in the Insert menu, or select Add Channel via to press the right hand mouse button pointed on the Server icon or click on channel in the Toolbar to Add a new channel to the project.
3. Select Add Device.. in the Insert menu, or select Add Device via to press the right hand mouse button pointed on the selected channel or click on device in the Toolbar to Add a new device to the channel.
4. Select Add Tag.. in the Insert menu, or select Add Tag via to press the right hand mouse button pointed on the selected device or click on tag in the Toolbar to Add a new tag to the device.
5. Save your project.
6. Select Set to active project in the File menu.
7. Click on play in the Toolbar for starting the monitor function.

See also:

Working Procedure


Creating a project from an old project

This part shows you the basics of creating a new project from an old project as a base.

1. Select Open in the File menu, click on open in the Toolbar or select Get active project in the File menu.
2. Add or change channels, devices and tags as you want.
3. Select Save As in the File menu for saving your project with a new name.
4. If you want to test the new project select Set to active project in the File menu.
5. Click on play in the Toolbar for starting the monitor function.

See also:

Working Procedure


Editing the project

This part shows you the basics of editing a project.

1. Select Open in the File menu, click on open in the Toolbar or select Get active project in the File menu.
2. Add or change channels, devices and tags as you want.
3. Select Save in the File menu for saving your project.
4. If you want to test the new project and it already is the active project you can go direct to 6.
5. If you want to test the new project and it's not the active project select Set to active project in the File menu.
6. Click on play in the Toolbar for starting the monitor function.

See also:

Working Procedure


Monitor

The PiiGAB M-Bus OPC Server contains an OPC client for testing and monitoring your tags. It will take a couple of seconds before the value will be shown depending of the OPC connection time.

1. Click on play in the Toolbar for starting the monitor function.
2. You can now look at the values.
3. Click on stop in the Toolbar for stopping the monitor function.

See also:

Quality flags

Working Procedure


Debug

The PiiGAB M-Bus OPC Server has a debugger there you can follow all M-Bus traffic. The debugging is starting via the Tools Menu and Log file. The dialog box below will appear.

The log file with name MBusOPC.LOG will be saved in the Log file path you have been chosen.

For each transmit and receive you will see at the first line date, time, direction -> or <-, channel name and device name. On the second line and below you will see the M-Bus message it self.

06:02:28 08:31:53 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:31:53 <- Lab.PadIn 4

                 <- e5

06:02:28 08:31:53 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:28 08:31:53 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 81

                 <- 00 00 00 01 fd 1b 0a d2 16

See also:

Log File


Connection

This section provides examples of log file sections from different meters when simulation of different disconnection has been made.


Normal connection

Example of normal working communication.

06:02:27 15:12:10 -- Start up server

06:02:27 15:12:10 -- Lab: Udp Connecting to 192.168.10.210, Port 10001

06:02:27 15:12:10 -- Lab: Connected

06:02:27 15:12:10 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:12:10 <- Lab.PadIn 4

                 <- e5

06:02:27 15:12:10 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 15:12:10 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 3c

                 <- 00 00 00 01 fd 1b 0a 8d 16

.

.

.

06:02:27 15:21:50 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:21:50 <- Lab.PadIn 4

                 <- e5

06:02:27 15:21:50 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 15:21:50 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 48

                 <- 00 00 00 01 fd 1b 0a 99 16

06:02:27 15:22:04 -- Shut down server


M-Bus disconnection

Example of udp communication when the M-Bus cable is disconnected and after a while reconnected.

Avbrott M-Bus

06:02:27 15:12:24 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:12:24 <- Lab.PadIn 4

                 <- e5

06:02:27 15:12:24 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:27 15:12:25 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 41

                 <- 00 00 00 01 fd 1b 0a 92 16

06:02:27 15:12:27 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:12:29 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:13:22 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:13:24 -> Lab.PadIn 4

                 -> 10 40 03 43 16

.

.

.

.

06:02:27 15:21:35 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:21:35 <- Lab.PadIn 4

                 <- e5

06:02:27 15:21:35 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 15:21:35 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 42

                 <- 00 00 00 01 fd 1b 0a 93 16


Udp disconnection

Example of udp communication when the Ethernet cable is disconnected and after a while reconnected.

06:02:27 15:36:01 -- Start up server

06:02:27 15:36:01 -- Lab: Udp Connecting to 192.168.10.210, Port 10001

06:02:27 15:36:01 -- Lab: Connected

06:02:27 15:36:01 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:36:02 <- Lab.PadIn 4

                 <- e5

06:02:27 15:36:02 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 15:36:02 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 49

                 <- 00 00 00 01 fd 1b 0a 9a 16

06:02:27 15:36:04 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:36:04 <- Lab.PadIn 4

                 <- e5

06:02:27 15:36:04 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:27 15:36:05 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 4a

                 <- 00 00 00 01 fd 1b 0a 9b 16

06:02:27 15:36:07 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:36:08 <- Lab.PadIn 4

                 <- e5

06:02:27 15:36:08 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 15:36:08 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 4b

                 <- 00 00 00 01 fd 1b 0a 9c 16

06:02:27 15:36:10 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:36:11 <- Lab.PadIn 4

                 <- e5

06:02:27 15:36:11 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:27 15:36:11 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 4c

                 <- 00 00 00 01 fd 1b 0a 9d 16

06:02:27 15:36:13 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:36:15 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:37:07 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:37:09 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:38:02 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:38:04 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:38:57 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:38:59 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:39:52 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:39:54 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:40:47 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:40:47 <- Lab.PadIn 4

                 <- e5

06:02:27 15:40:47 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 15:40:47 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 4d

                 <- 00 00 00 01 fd 1b 0a 9e 16

06:02:27 15:40:50 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:40:50 <- Lab.PadIn 4

                 <- e5

06:02:27 15:40:50 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:27 15:40:50 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 4e

                 <- 00 00 00 01 fd 1b 0a 9f 16

06:02:27 15:40:52 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:40:52 <- Lab.PadIn 4

                 <- e5

06:02:27 15:40:52 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 15:40:53 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 4f

                 <- 00 00 00 01 fd 1b 0a a0 16

06:02:27 15:41:06 -- Shut down server


Tcp disconnection

Example of tcp communication when the Ethernet cable is disconnected and after a while reconnected.

06:02:27 15:55:40 -- Start up server

06:02:27 15:55:40 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:55:40 -- Lab: Connected

06:02:27 15:55:40 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:55:40 <- Lab.PadIn 4

                 <- e5

06:02:27 15:55:40 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 15:55:41 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 50

                 <- 00 00 00 01 fd 1b 0a a1 16

06:02:27 15:55:43 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:55:43 <- Lab.PadIn 4

                 <- e5

06:02:27 15:55:43 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:27 15:55:44 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 51

                 <- 00 00 00 01 fd 1b 0a a2 16

06:02:27 15:55:46 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:55:46 <- Lab.PadIn 4

                 <- e5

06:02:27 15:55:46 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 15:55:47 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 52

                 <- 00 00 00 01 fd 1b 0a a3 16

06:02:27 15:55:49 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:55:51 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:56:44 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 15:56:44 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:57:05 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 15:57:05 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:57:26 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 15:57:26 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:57:47 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 15:57:48 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:58:09 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 15:58:09 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:58:30 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 15:58:30 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:58:51 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 15:58:51 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:59:12 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 15:59:12 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:59:33 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 15:59:34 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 15:59:55 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 15:59:55 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:16 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 16:00:16 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:37 -- Lab: WSAError (10060) WSAETIMEDOUT

06:02:27 16:00:37 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:38 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:38 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:39 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:40 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:41 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:41 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:42 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:42 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:43 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:43 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:44 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:44 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:45 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:46 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:47 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:47 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:48 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:48 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:49 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:49 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:50 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:50 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:51 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:52 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:53 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:53 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:54 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:54 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:55 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:55 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:56 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:56 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:57 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:58 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:00:59 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:00:59 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:01:00 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:01:00 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:01:01 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:27 16:01:01 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:27 16:01:02 -- Lab: Connected

06:02:27 16:01:02 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 16:01:02 <- Lab.PadIn 4

                 <- e5

06:02:27 16:01:02 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:27 16:01:02 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 53

                 <- 00 00 00 01 fd 1b 0a a4 16

06:02:27 16:01:04 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 16:01:04 <- Lab.PadIn 4

                 <- e5

06:02:27 16:01:04 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 16:01:04 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 54

                 <- 00 00 00 01 fd 1b 0a a5 16

06:02:27 16:01:06 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 16:01:06 <- Lab.PadIn 4

                 <- e5

06:02:27 16:01:06 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:27 16:01:07 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 55

                 <- 00 00 00 01 fd 1b 0a a6 16

06:02:27 16:01:09 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 16:01:09 <- Lab.PadIn 4

                 <- e5

06:02:27 16:01:09 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 16:01:09 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 56

                 <- 00 00 00 01 fd 1b 0a a7 16

06:02:27 16:01:11 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 16:01:11 <- Lab.PadIn 4

                 <- e5

06:02:27 16:01:11 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:27 16:01:11 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 57

                 <- 00 00 00 01 fd 1b 0a a8 16

06:02:27 16:01:13 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 16:01:13 <- Lab.PadIn 4

                 <- e5

06:02:27 16:01:13 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:27 16:01:13 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 58

                 <- 00 00 00 01 fd 1b 0a a9 16

06:02:27 16:01:15 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:27 16:01:15 <- Lab.PadIn 4

                 <- e5

06:02:27 16:01:15 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:27 16:01:16 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 59

                 <- 00 00 00 01 fd 1b 0a aa 16

06:02:27 16:01:28 -- Shut down server


Tcp collision A

Example of tcp communication when two units using the same IPAddress and portnumber.

06:02:28 08:30:04 -- Start up server

06:02:28 08:30:04 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:28 08:30:04 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10001

06:02:28 08:30:04 -- LabC1: Connected

06:02:28 08:30:08 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:28 08:30:08 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:28 08:30:09 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:28 08:30:09 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:28 08:30:10 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:28 08:30:10 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:28 08:30:11 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:28 08:30:12 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

.

.

06:02:28 08:31:10 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:28 08:31:11 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:28 08:31:12 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:28 08:31:12 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:28 08:31:13 -- Lab: WSAError (10061) WSAECONNREFUSED

06:02:28 08:31:13 -- Shut down server


Tcp collision B

Example of tcp communication when two units using the same IPAddress but different portnumbers.

06:02:28 08:31:52 -- Start up server

06:02:28 08:31:52 -- Lab: Tcp Connecting to 192.168.10.210, Port 10001

06:02:28 08:31:52 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:31:52 -- Lab: Connected

06:02:28 08:31:53 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:31:53 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:31:53 <- Lab.PadIn 4

                 <- e5

06:02:28 08:31:53 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:28 08:31:53 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 81

                 <- 00 00 00 01 fd 1b 0a d2 16

06:02:28 08:31:53 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:31:54 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:31:55 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:31:56 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:31:56 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:31:56 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:31:56 <- Lab.PadIn 4

                 <- e5

06:02:28 08:31:56 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:28 08:31:56 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 82

                 <- 00 00 00 01 fd 1b 0a d3 16

06:02:28 08:31:57 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:31:57 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:31:58 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:31:58 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:31:59 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:31:59 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:00 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:00 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:00 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:28 08:32:00 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:00 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 83

                 <- 00 00 00 01 fd 1b 0a d4 16

06:02:28 08:32:01 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:02 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:02 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:03 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:03 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:03 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:28 08:32:03 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 84

                 <- 00 00 00 01 fd 1b 0a d5 16

06:02:28 08:32:03 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:03 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:04 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:04 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:05 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:05 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:06 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:06 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:06 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:28 08:32:06 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 85

                 <- 00 00 00 01 fd 1b 0a d6 16

06:02:28 08:32:06 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:07 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:08 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:08 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:08 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:08 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:08 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:28 08:32:08 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 86

                 <- 00 00 00 01 fd 1b 0a d7 16

06:02:28 08:32:09 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:09 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:10 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:10 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:11 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:11 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:11 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:28 08:32:11 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 87

                 <- 00 00 00 01 fd 1b 0a d8 16

06:02:28 08:32:11 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:11 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:12 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:13 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:13 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:13 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:13 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:28 08:32:13 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 88

                 <- 00 00 00 01 fd 1b 0a d9 16

06:02:28 08:32:14 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:14 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:15 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:15 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:15 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:15 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:15 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:28 08:32:15 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 89

                 <- 00 00 00 01 fd 1b 0a da 16

06:02:28 08:32:16 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:16 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:17 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:17 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:17 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:17 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:28 08:32:18 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:18 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 8a

                 <- 00 00 00 01 fd 1b 0a db 16

06:02:28 08:32:18 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:19 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:20 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:20 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:20 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:20 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:28 08:32:20 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 8b

                 <- 00 00 00 01 fd 1b 0a dc 16

06:02:28 08:32:20 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:21 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:21 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:22 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:22 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:22 -> Lab.PadIn 4

                 -> 10 7b 03 7e 16

06:02:28 08:32:22 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:22 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 8c

                 <- 00 00 00 01 fd 1b 0a dd 16

06:02:28 08:32:22 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:23 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:23 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:24 -> Lab.PadIn 4

                 -> 10 40 03 43 16

06:02:28 08:32:24 <- Lab.PadIn 4

                 <- e5

06:02:28 08:32:24 -> Lab.PadIn 4

                 -> 10 5b 03 5e 16

06:02:28 08:32:24 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:24 <- Lab.PadIn 4

                 <- 68 13 13 68 08 03 72 92 02 02 07 ac 48 20 00 8d

                 <- 00 00 00 01 fd 1b 0a de 16

06:02:28 08:32:25 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:26 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:26 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:27 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:27 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:28 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:28 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:29 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:29 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:30 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:31 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:32 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:32 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:33 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:33 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:34 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:34 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:35 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:36 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:36 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:37 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:38 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:38 -- LabC1: Tcp Connecting to 192.168.10.210, Port 10002

06:02:28 08:32:39 -- LabC1: WSAError (10061) WSAECONNREFUSED

06:02:28 08:32:39 -- Shut down server


Meter examples

This section provides examples of log file sections from different meters.


ABB Delta Meter

Example of communication with ABB Delta Meter. It shows SND_NKE, primary addressing and multi telegram reading.

06:02:06 10:20:47 -- Start up server

06:02:06 10:20:47 -- Building 204: Udp Connecting to 192.168.100.198, Port 10001

06:02:06 10:20:47 -- Building 204: Connected

06:02:06 10:20:47 -> Building 204.ABB Delta

                 -> 10 40 03 43 16

06:02:06 10:20:47 <- Building 204.ABB Delta

                 <- e5

06:02:06 10:20:47 -> Building 204.ABB Delta

                 -> 10 5b 03 5e 16

06:02:06 10:20:47 <- Building 204.ABB Delta

                 <- 68 4b 4b 68 08 03 72 47 27 10 00 42 04 02 02 04

                 <- 20 00 00 0e 04 32 59 55 00 00 00 8e 10 04 32 59

                 <- 55 00 00 00 8e 20 04 00 00 00 00 00 00 01 ff 13

                 <- 01 0c ff 12 01 00 00 00 07 fd 17 40 00 00 28 00

                 <- 00 00 00 01 ff 18 f1 1f 00 00 00 00 00 00 00 6c

                 <- 16

06:02:06 10:20:47 -> Building 204.ABB Delta

                 -> 10 7b 03 7e 16

06:02:06 10:20:48 <- Building 204.ABB Delta

                 <- 68 68 68 68 08 03 72 47 27 10 00 42 04 02 02 05

                 <- 20 00 00 04 29 00 00 00 00 04 a9 ff 01 00 00 00

                 <- 00 04 a9 ff 02 00 00 00 00 04 a9 ff 03 00 00 00

                 <- 00 02 fd c8 ff 01 bd 08 02 fd c8 ff 02 b8 08 02

                 <- fd c8 ff 03 c2 08 0a fd da ff 01 00 00 0a fd da

                 <- ff 02 00 00 0a fd da ff 03 00 00 0a ff 59 00 50

                 <- 1f 00 00 00 00 00 00 00 00 00 00 00 bf 16

06:02:06 10:20:48 -> Building 204.ABB Delta

                 -> 10 5b 03 5e 16

06:02:06 10:20:48 <- Building 204.ABB Delta

                 <- 68 5e 5e 68 08 03 72 47 27 10 00 42 04 02 02 06

                 <- 20 00 00 02 ff 60 00 00 02 ff c2 ff 02 01 00 02

                 <- ff c2 ff 03 02 00 02 ff ca ff 01 00 00 02 ff ca

                 <- ff 02 00 00 02 ff ca ff 03 00 00 81 80 40 fd 1b

                 <- 00 c1 80 40 fd 1b 00 8e 80 40 fd 61 00 00 00 00

                 <- 00 00 81 40 fd 1a 00 0f 00 00 00 00 00 00 00 00

                 <- 00 00 41 16


SVM F4

Example of communication with SVM F4 Heatmeter. It shows secondary addressing and single telegram reading from a multi telegram meter. The meters Id number is 0432157 but only the last part 157 is used the rest is wild carded.

06:02:06 10:50:31 -- Start up server

06:02:06 10:50:31 -- Building 205: Udp Connecting to 192.168.100.199, Port 10001

06:02:06 10:50:31 -- Building 205: Connected

06:02:06 10:50:31 -> Building 205.SVM F4

                 -> 68 0b 0b 68 53 fd 52 57 f1 ff ff ff ff ff ff e4

                 -> 16

06:02:06 10:50:31 <- Building 205.SVM F4

                 <- e5

06:02:06 10:50:31 -> Building 205.SVM F4

                 -> 10 5b fd 58 16

06:02:06 10:50:32 <- Building 205.SVM F4

                 <- 68 90 90 68 08 c9 72 57 21 43 00 cd 4e 09 04 3d

                 <- 70 00 00 04 07 00 00 00 00 04 16 0f 00 00 00 84

                 <- 40 16 00 00 00 00 02 5b f3 00 02 5f f3 00 02 62

                 <- 00 00 04 22 28 20 00 00 04 26 9c 19 00 00 04 3d

                 <- 00 00 00 00 04 2e 00 00 00 00 04 6d 10 12 c6 02

                 <- 84 40 6e ae 00 00 00 84 80 40 6e 05 01 00 00 1f

                 <- fa 00 01 0b 0e ff 01 00 01 07 57 21 43 00 cd 4e

                 <- 09 04 07 af ef 03 57 21 43 00 05 1f 03 02 ff 0f

                 <- 05 3c 67 65 d0 65 54 06 78 06 05 00 46 29 1b 01

                 <- a0 05 62 41 46 16


Kamstrup

Example of communication with Kamstrup Multical Compact. It shows primary addressing. No SND_NKE shall be used for this meter.

06:02:06 17:21:55 -- Building 206: Udp Connecting to 192.168.100.198, Port 10001

06:02:06 17:21:55 -- Building 206: Connected

06:02:06 17:21:55 -> Building 206.Kamstrup

                 -> 10 5b 02 5d 16

06:02:06 17:21:55 <- Building 206.Kamstrup

                 <- 68 82 82 68 08 02 72 02 00 00 00 2d 2c 01 04 0c

                 <- 00 00 00 0c 06 00 00 00 00 0c 14 04 00 00 00 0c

                 <- 22 33 01 03 00 0c 59 26 23 00 00 0c 5d 76 24 00

                 <- 00 0c 61 00 00 00 00 0c 2d 00 00 00 00 0c 3b 00

                 <- 00 00 00 4c 06 00 00 00 00 4c 14 04 00 00 00 42

                 <- 6c c1 01 0f 02 00 00 00 00 00 00 00 00 00 28 00

                 <- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

                 <- 00 00 00 00 00 00 00 00 00 00 33 48 04 00 00 00

                 <- 10 01 06 02 06 00 1e 16


PadPuls M2

Example of communication with Relay PadPuls M2. It shows SND_NKE and primary addressing 10 (Hex 0a).

06:02:06 09:44:33 -- Start up server

06:02:06 09:44:33 -- Building 203: Udp Connecting to 192.168.100.198, Port 10001

06:02:06 09:44:33 -- Building 203: Connected

06:02:06 09:44:33 -> Building 203.PadPulsM2

                 -> 10 40 0a 4a 16

06:02:06 09:44:33 <- Building 203.PadPulsM2

                 <- e5

06:02:06 09:44:33 -> Building 203.PadPulsM2

                 -> 10 5b 0a 65 16

06:02:06 09:44:34 <- Building 203.PadPulsM2

                 <- 68 2f 2f 68 08 0a 72 01 25 49 01 ac 48 41 00 0d

                 <- 00 00 00 0c 13 02 01 00 00 04 6d 9a 14 c2 01 42

                 <- 6c bf 0c 4c 13 01 01 00 00 42 ec 7e df 0c 0f d0

                 <- 01 01 0c 98 16


Reference

This section covers the references for the configuration file, data types, tag types, parameters etc.


Overview tag and data types

This section is showing how different OPC data type are working together with MBus tag type respectively.

Record

Tag Type | I1 | UI1 | I2 | UI2 | I4 | UI4 | R4 | R8 | BSTR | BOOL | Description
Value | P | P | P | P | P | P | P | P | P | P |
Vib |  |  |  |  |  |  |  |  | P |  |
Unit |  |  | P |  |  |  |  |  | P |  |
Tariff |  |  |  |  | P |  |  |  | P |  |
Storage |  |  |  |  | P |  |  |  | P |  |
Function |  |  | P |  |  |  |  |  | P |  |
Datatype |  |  | P |  |  |  |  |  | P |  |
Record |  |  |  |  |  |  |  |  | P |  |
Man. Specific | P | P* | P | P* | P | P* |  |  | P* | P |

*Possible to convert binary values to Bcd.

Header

Tag Type | I1 | UI1 | I2 | UI2 | I4 | UI4 | R4 | R8 | BSTR | BOOL | Description
Header |  |  |  |  |  |  |  |  | P |  |
Idnumber |  |  |  |  | P |  |  |  | P |  |
Manufacturer |  |  | P |  |  |  |  |  | P |  |
Version |  |  | P |  |  |  |  |  | P |  |
Medium |  |  | P |  |  |  |  |  | P |  |
Acessnumber |  |  | P |  |  |  |  |  | P |  |
Status |  |  | P |  |  |  |  |  | P | P |
Signature |  |  | P |  |  |  |  |  | P |  |

See also:

Record

Header


Record

This section describes all tag types which can be found in the meter record or object.


Value

Examples of Value field

PiiGAB M-Bus OPC Server v1 can convert all M-Bus data types automatically to strings for you. This is especially good if you don’t know the data type the manufacturer wants you to use. Below is a coordinate system for helping you to find the correct OPC data type regarding the M-Bus data type. You can also readout the data type itself via the tag type Datatype.

The server is looking in the Mbus object for the data type and compare this with the chosen OPC data type regarding the table below. For example if you choose VT_I2 and the M-Bus data type in the object is Int48 you will have the quality flag Bad and also the quality subgroup configure error. In the PiiGAB M-Bus OPC Server interface it will show Bad (config error) when this error arises.

Value data types

Data type | Meaning | Code Hex | Code Dec | Length in byte | I1 | UI1 | I2 | UI2 | I4 | UI4 | R4 | R8 | BSTR | BOOL | Description
No data2 | No data | 0x0 | 0 | 0 |  |  |  |  |  |  |  |  | P |  | N/A (0x00)3
Int8 | 8 bit integer | 0x1 | 1 | 1 | P | P | P | P |  |  | P1 | P1 | P1 | P |
Int164 | 16 bit integer | 0x2 | 2 | 2 |  |  | P | P |  |  | P1 | P1 | P1 |  |
Int24 | 24 bit integer | 0x3 | 3 | 3 |  |  |  |  | P | P | P1,6 | P1 | P1 |  |
Int32 | 32 bit integer | 0x4 | 4 | 4 |  |  |  |  | P | P | P1,6 | P1 | P1 |  |
Real32 | 32 bit real | 0x5 | 5 | 4 |  |  |  |  |  |  | P | P | P |  |
Int485 | 48 bit integer | 0x6 | 6 | 6 |  |  |  |  |  |  |  | P1 | P1 |  |
Int64 | 64 bit integer | 0x7 | 7 | 8 |  |  |  |  |  |  |  |  | P1 |  |
Selection | Selection for readout | 0x8 | 8 | 0 |  |  |  |  |  |  |  |  | P |  | N/A (0x08)3
BCD2 | 2 digit BCD | 0x9 | 9 | 1 | P | P |  |  |  |  | P | P | P |  |
BCD4 | 4 digit BCD | 0xa | 10 | 2 |  |  | P | P |  |  | P | P | P |  |
BCD6 | 6 digit BCD | 0xb | 11 | 3 |  |  |  |  | P | P | P | P | P |  |
BCD8 | 8 digit BCD | 0xc | 12 | 4 |  |  |  |  | P | P | P6 | P | P |  |
Variable | Variable length | 0xd | 13 | n |  |  |  |  |  |  |  |  | P |  | ASCII7 N/A (0x0D)
BCD12 | 12 digit BCD | 0xe | 14 | 6 |  |  |  |  |  |  |  | P | P |  |
Special | Special functions | 0xf | 15 | n |  |  |  |  |  |  |  |  | P |  | N/A (0x1F)3 N/A (0x0F)3 N/A Special3

1 Possible to choose unsigned via the tag form. Signed is default.

2 If this data type is found the server will set the OPC data type to VT_EMPTY.

3 If these data types are found the OPC server will respond with this string respectively.

4 If the M-Bus data type is an int16 together with VIF6C (Timepoint [Date]) this datatype has to be VT_BSTR. VT_I2 will show the raw value not the date it self.

5 If the M-Bus data type is an int32 together with VIF6D (Timepoint [Date & Time]) this datatype has to be VT_BSTR. A VT_I4 will show the raw value not the date and time it self.

6 A four byte float has only 6-7 significant digits. Try to use double R8 if precision is the most important criterion.

7 The OPC Server is supporting variable length 8-bit text string according to ISO 8859-1. The OPC Server is responding with "N/A (0x0D)" for variable length positive/negative BCD number, binary number and floating point number according to IEEE 754 .

Data type limits

Data type | Variable | OPC Type | Size | Minimum value | Maximum value
Int8 | 8 bit integer | I1 | 1 byte | -128 | 127
Int8 | Unsigned 8 bit integer | UI1 | 1 byte | 0 | 255
Int16 | 16 bit integer | I2 | 2 bytes | -32768 | 32767
Int16 | Unsigned 16 bit integer | UI2 | 2 bytes | 0 | 65535
Int24 | 24 bit integer | - | 3 bytes | -8388608 | 8388607
Int24 | Unsigned 24 bit integer | - | 3 bytes | 0 | 16777215
Int32 | 32 bit integer | I4 | 4 bytes | -2147483648 | 2147483647
Int32 | Unsigned 32 bit integer | UI4 | 4 bytes | 0 | 4294967295
Int48 | 48 bit integer | - | 6 bytes | -140737488355328 | 140737488355327
Int48 | Unsigned 48 bit integer | - | 6 bytes | 0 | 281474976710655
Int64 | 64 bit integer | I81 | 8 bytes | -9223372036854775808 | 9223372036854775807
Int64 | Unsigned 64 bit integer | UI81 | 8 bytes | 0 | 18446744073709551615
BCD2 | 2 digit BCD | - | 1 byte | 0 | 99
BCD4 | 4 digit BCD | - | 2 bytes | 0 | 9999
BCD6 | 6 digit BCD | - | 3 bytes | 0 | 999999
BCD8 | 8 digit BCD | - | 4 bytes | 0 | 99999999
BCD12 | 12 digit BCD | - | 6 bytes | 0 | 999999999999
Real32 | Float | R4 | 4 bytes | 1.175494351 E - 38 | 3.402823466 E + 38
 | Double | R8 | 8 bytes | 2.2250738585072014 E - 308 | 1.7976931348623158 E + 308

1 Not supported in this version.

See also:

Overview data types

Data Type


Vib

Examples of Vib field

The server is looking through the file mbusOPC.ini, via the objects´ vifcode, for the M-Bus standard texts. The server also supports manufacturers specific texts via a specific .ini file.

If the server finds that the vibcode is manufacturer specific it will try to find the file mbusOPCXXX.ini, where XXX is the manufacturer ID. It will look through the file for a section name made up by a manufacturer ID, version and medium. As an example, the file mbusOPCABB.ini from ABB electricity meters are installed in the \Bin directory during the installation process.

To control if the text shown is correct you can check the "Show Vib code" in Tag properties. In this case you will see the M-Bus vifcode and from them you can follow the text via mbusOPC.ini and compare them via the M-Bus original documentation or the manufacture specific original documentation. The system with .ini files also makes it possible to change language for the text. If you do this be sure to take a backup copy of your own mbusOPC.ini before reinstallation of the server.

From version 1.2.1 the M-Bus OPC server is supporting Plain-text VIF.

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 9
Tag type: | Vib
Comment: | Value information block for record 9. Show Vib code = Unchecked.
Example: | Current (mA*10) L1

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 9
Tag type: | Vib
Comment: | Value information block for record 9. Show Vib code = Unchecked.
Example: | cust. ID

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 9
Tag type: | Vib
Comment: | Value information block for record 9. Show Vib code = Checked.
Example: | FD5a FF01

See also:

Value Information Block


Unit

Examples of Unit field

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 9
Tag type: | Unit
Comment: | Unit number for data record 9
Example: | 2

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | 9
Tag type: | Unit
Comment: | Unit number for data record 9
Example: | 2

Range:

Range:

0 – 1023

See also:

Data Information Block


Tariff

Examples of Tariff field

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 9
Tag type: | Tariff
Comment: | Tariff for data record 9
Example: | 2

VT_I4:

Data type: | VT_I4 (4-byte signed integer)
Record: | 9
Tag type: | Tariff
Comment: | Tariff for data record 9
Example: | 2

Range:

Range:

0 – 1048575

See also:

Data Information Block


Storage

Examples of Storage field

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 9
Tag type: | Storage
Comment: | Storage for data record 9
Example: | 2

VT_I4:

Data type: | VT_I4 (4-byte signed integer)
Record: | 9
Tag type: | Storage
Comment: | Storage for data record 9
Example: | 2

Range:

Range:

0 – 2199023255551

See also:

Data Information Block


Function

Examples of Function field

The function field gives the type of data as follows:

Code | Description | Function
0 | Instantaneous value | Inst
1 | Maximum value | Max
2 | Minimum value | Min
3 | Value during error state | Error

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 9
Tag type: | Function
Comment: | Function for data record 9
Example: | Inst

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | 9
Tag type: | Function
Comment: | Function for data record 9
Example: | 0

See also:

Data Information Block


Datatype

Examples of Data type field

The data field shows how the data from the master must be interpreted. The following table contains the possible coding of the data field:

Code | Description | Data type
0 | No data | No data
1 | 8 bit integer | Int8
2 | 16 bit integer | Int16
3 | 24 bit integer | Int24
4 | 32 bit integer | Int32
5 | 32 bit real | Real32
6 | 48 bit integer | Int48
7 | 64 bit integer | Int64
8 | Selection for readout | Selection
9 | 2 digit BCD | BCD2
10 | 4 digit BCD | BCD4
11 | 6 digit BCD | BCD6
12 | 8 digit BCD | BCD8
13 | Variable length | Variable
14 | 12 digit BCD | BCD12
15 | Special functions | Special

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 9
Tag type: | Datatype
Comment: | Datatype for data record 9
Example: | Int32

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | 9
Tag type: | Datatype
Comment: | Datatype for data record 9
Example: | 4

See also:

Data Information Block


Record

Examples of Record field

The record type adding all separate string types Unit, Tariff, Storage Datatype, Function, Value and Vib to one long string. With this type you have all information from the data record object you probably should need. Datarecord zero doesn’t exist therefore the server use this to write the header for the object information. It’s important to use a font type eg Courier New with the same width for each character.

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 0
Tag type: | Record
Comment: | Data record 0
Example: | Record Unit Tariff Storage Datatype Function Value Vib

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 1
Tag type: | Record
Comment: | Data record 1
Example: | DR1 0 0 0 BCD12 Inst 237268 Energy (Wh*10)

See also:

Data Information Block

Value Information Block


Manufacturer Specific

Examples of Manufacturer Specific field

The PiiGAB M-Bus OPC Server is supporting manufacturer specific data. Normally you need the documentation from the manufacturer to find out the correct position in the area. The manufacturer specific area itself is an own object or data record.

If you check the box BCD in the Tag properties the server will convert the data to BCD format. This is common when you are using heat meters which has extra pulse inputs for e.g. water meters.

VT_I1:

Data type: | VT_I1 (1-byte signed integer)
Record: | 9
Tag type: | Manufacturer specific
Offset: | 4
No of bytes: | -
Comment: | Manufacturer specific data in record 9
Example: | 1 byte data (byte 4)

VT_UI1:

Data type: | VT_UI1 (1-byte unsigned integer)
Record: | 9
Tag type: | Manufacturer specific
Offset: | 4
No of bytes: | -
Comment: | Manufacturer specific data in record 9
Example: | 1 byte data (byte 4)

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | 9
Tag type: | Manufacturer specific
Offset: | 4
No of bytes: | -
Comment: | Manufacturer specific data in record 9
Example: | 2 byte data (byte 4, 5)

VT_UI2:

Data type: | VT_UI2 (2-byte unsigned integer)
Record: | 9
Tag type: | Manufacturer specific
Offset: | 4
No of bytes: | -
Comment: | Manufacturer specific data in record 9
Example: | 2 byte data (byte 4, 5)

VT_I4:

Data type: | VT_I4 (4-byte signed integer)
Record: | 9
Tag type: | Manufacturer specific
Offset: | 4
No of bytes: | -
Comment: | Manufacturer specific data in record 9
Example: | 4 byte data (byte 4, 5, 6, 7)

VT_UI4:

Data type: | VT_UI4 (4-byte unsigned integer)
Record: | 9
Tag type: | Manufacturer specific
Offset: | 4
No of bytes: | -
Comment: | Manufacturer specific data in record 9
Example: | 4 byte data (byte 4, 5, 6, 7)

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | 9
Tag type: | Manufacturer specific
Offset: | 4
No of bytes: | 8
Comment: | Manufacturer specific data in record 9
Example: | 8 byte from position 4

VT_BOOL:

Data type: | VT_BOOL (Boolean)
Record: | 9
Tag type: | Manufacturer specific
Offset: | 4
No of bytes: | -
Bit number: | 2 (range 0-7)
Comment: | Manufacturer specific data in record 9
Example: | Third bit from right.

See also:

Overview data types

Manufacturer Specific Data Block


Header

This section describes all tag types which can be found in the header object.


Header

Examples of Header field

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | -
Tag type: | Header
Comment: | Total Header
Example: | 00102886 SVM 09 Heat (inlet) 74 40 0000

See also:

Fixed Data Header


Idnumber

Examples of Identification number field

Identification Number is a customer number, coded with 8 BCD packed digits (4 Byte), and which thus runs from 00000000 to 99999999

VT_I4:

Data type: | VT_I4 (4-byte signed integer)
Record: | -
Tag type: | Idnumber
Comment: | Identification number
Example: | 102886

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | -
Tag type: | Idnumber
Comment: | Identification number
Example: | 00102886

See also:

Fixed Data Header


Manufacturer

Examples of Manufacturer field

Manufacturer is coded unsigned binary with 2 bytes. This manufacturer ID is calculated from the ASCII code of EN 61107 manufacturer ID (three uppercase letters) with the following formula:

IEC 870 Man. ID =

[ASCII(1st letter) - 64] • 32 • 32

+ [ASCII(2nd letter) - 64] • 32

+ [ASCII(3rd letter) - 64]

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | -
Tag type: | Manufacturer
Comment: | Value for manufacturer
Example: | 1090 (0x0442)

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | -
Tag type: | Manufacturer
Comment: | Short name for manufacturer
Example: | ABB

See also:

Fixed Data Header


Version

Examples of Version field

Version specifies the generation or version of this counter and depends on the manufacturer.

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | -
Tag type: | Version
Comment: | Version
Example: | 2

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | -
Tag type: | Version
Comment: | Version
Example: | 2

See also:

Fixed Data Header


Medium

Examples of Medium field

Medium is coded with a whole byte. The text is readout from MbusOPC.ini

Medium | Code hex
Other | 00
Oil | 01
Electricity | 02
Gas | 03
Heat (Volume measured at return temperature: outlet) | 04
Steam | 05
Hot Water | 06
Water | 07
Heat Cost Allocator. | 08
Compressed Air | 09
Cooling load meter (Volume measured at return temperature: outlet) | 0A
Cooling load meter (Volume measured at flow temperature: inlet) | 0B
Heat (Volume measured at flow temperature: inlet) | 0C
Heat / Cooling load meter | OD
Bus / System | 0E
Unknown Medium | 0F
Reserved | 10 to 15
Cold Water | 16
Dual Water | 17
Pressure | 18
A/D Converter | 19
Reserved | 20 to FF

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | -
Tag type: | Medium
Comment: | Medium
Example: | 2

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | -
Tag type: | Medium
Comment: | Medium
Example: | Electricity

See also:

Fixed Data Header


Accessnumber

Examples of Access number field

Access Number has unsigned binary coding, and is increased by one after each RSP_UD from the slave.

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | -
Tag type: | Accessnr
Comment: | Access number
Example: | 2

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | -
Tag type: | Accessnr
Comment: | Access number
Example: | 2

See also:

Fixed Data Header


Status

Examples of Status field

Status field are used to indicate application errors.

Bit | Meaning
0 | Application busy
1 | Any application error
2 | Power low
3 | Permanent error
4 | Temporary error
5 | Specific to manufacturer
6 | Specific to manufacturer
7 | Specific to manufacturer

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | -
Tag type: | Status
Comment: | Status
Example: | 2

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | -
Tag type: | Status
Comment: | Status
Example: | 2

VT_BOOL:

Data type: | VT_BOOL (Boolean)
Record: | -
Tag type: | Status
Status bit | 0
Comment: | The first bit in status byte
Example: | true / false

See also:

Fixed Data Header


Signature

Examples of Signature field

Signature remains reserved for future encryption applications, and until then is allocated the value 00 00 h.

VT_I2:

Data type: | VT_I2 (2-byte signed integer)
Record: | -
Tag type: | Signature
Comment: | Signature
Example: | 2

VT_BSTR:

Data type: | VT_BSTR (String)
Record: | -
Tag type: | Signature
Comment: | Signature
Example: | 2

See also:

Fixed Data Header


Configuration File

This section describes how the configuration file is built up.


Overview

File type

The configuration file is a ISO-Latin1 text based CSV-file. The item delimiter character is a comma ‘,’.

File location

The server will have a look in the registry for the ConfigurationFileName string value in the location HKEY_LOCAL_MACHINE\SOFTWARE\PiiGAB\MBus OPC Server.

Object tags

The first item in each (valid) row is a tag that determines how the rest of the row is interpreted. The file is a three level hierarchy, with the following tags:

[CHANNEL]
[DEVICE]
[TAG]

[CHANNEL] objects form the top level, they may have several [DEVICE] objects, which in turn may have several [TAG] objects.

If the first item does not contain any of these tags, the row will simply not be interpreted.

Each child object contain its parents name. The parent object must appear before any of its child objects. The child objects does not need to follow any specific order, but for readability it is nicer if they appear follow their parent object.

Names must NOT contain periods ‘.’, though they form the complete hierarchically ItemId.

The first items always follow the same schema as:

[CHANNEL],LabC1,,,,<object specific parameters>
[DEVICE],LabC1,,Meter1,,<object specific parameters>
[TAG],LabC1,,Meter1,Dr1_Value,<object specific parameters>
[TAG],LabC1,,Meter1,Dr2_Value,<object specific parameters>
[DEVICE],LabC1,,Meter2,,<object specific parameters>
[TAG],LabC1,,Meter2,Dr1_Value,<object specific parameters>
[TAG],LabC1,,Meter2,Dr2_Value,<object specific parameters>
[CHANNEL],LabC2,,,,<object specific parameters>
[DEVICE],LabC2,,Meter1,,<object specific parameters>
[TAG],LabC2,,Meter1,Dr1_Value,<object specific parameters>
[TAG],LabC2,,Meter1,Dr2_Value,<object specific parameters>

ItemId

The OPC ItemId which is used to locate any specific tag in the namespace is formed by concatenating all three level names in the hierarchy .They are separated by a period ‘.’.

Example:

LabC2.Meter1.Dr2_Value

Remarks

Time values are all in msecs - generally stored in a 32-bit (signed) integer.

Default values for the channel and node tree will be inherited by child objects (nodes and tags) if they do not have any specific settings (i.e. their value is set to nothing in the child object). These values are notified in the Inherit column.


Channel

Parameter position in ObjectTag [CHANNEL]

Pos | Parameter Name | Inherit
0 | ObjectTag |
1 | ChannelName |
2 | (not used) |
3 | (not used) |
4 | (not used) |
5 | (reserved) |
6 | (reserved) |
7 | Description |
8 | Retries | P
9 | Timeout | P
10 | RestartTime | P
11 | Delay | P
12 | LiveTime | P
13 | NrOfTelegrams | P
14 | InitRead | P
15 | SubCode | P
16 | (reserved) |
17 | (reserved) |
18 | (reserved) |
19 | ComMode |
20 | IPAddress |
21 | PortNumber |
22 | ModemName |
23 | PhoneNumber |
24 | ComPort |
25 | Baudrate |
26 | DataBits |
27 | StopBits |
28 | Parity |
29 | FlowControl |
30 | ReconnectTime |
31 | (reserved) |
32 | (reserved) |
33 | (reserved) |
34 | (reserved) |
35 | (reserved) |


Device

Parameter position in ObjectTag [DEVICE]

Pos | Parameter Name | Inherit
0 | ObjectTag |
1 | ChannelName |
2 | (not used) |
3 | DeviceName |
4 | (not used) |
5 | (reserved) |
6 | (reserved) |
7 | Description |
8 | Retries | P
9 | Timeout | P
10 | RestartTime | P
11 | Delay | P
12 | LiveTime | P
13 | NrOfTelegrams | P
14 | InitRead | P
15 | SubCode | P
16 | (reserved) |
17 | (reserved) |
18 | (reserved) |
19 | DeviceAddress |
20 | (reserved) |
21 | (reserved) |
22 | (reserved) |
23 | (reserved) |
24 | (reserved) |
25 | (reserved) |


Tag

Parameter position in ObjectTag [TAG]

Pos | Parameter Name
0 | ObjectTag
1 | ChannelName
2 | (not used)
3 | DeviceName
4 | TagName
5 | (reserved)
6 | (reserved)
7 | Description
8 | (reserved)
9 | (reserved)
10 | (reserved)
11 | (reserved)
12 | (reserved)
13 | (reserved)
14 | (reserved)
15 | (reserved)
16 | (reserved)
17 | (reserved)
18 | (reserved)
19 | DataRecord
20 | TagType
21 | DataType
22 | AccessRights
23 | Option1
24 | Option2
25 | Option3
26 | Polynom offset (m)
27 | Polynom ratio (k)
28 | (reserved)
29 | (reserved)
30 | (reserved)
31 | Raw zero scale
32 | Raw full scale
33 | Eng. zero scale
34 | Eng. full scale
35 | Decimals if BSTR
36 | (reserved)
37 | (reserved)
38 | (reserved)
39 | (reserved)


Parameters

This section describes all parameters in the configuration file.


Common

This section describes the common parameters.


Object Tag

Description

Row descriptor.

Allowable Values:

[CHANNEL]

[DEVICE]

[TAG]

See also:

Parameters


Channel Name

Description

Physical name of the channel, as it will appear in the namespace.

See also:

Parameters


Device Name

Description

Physical name of the device, as it will appear in the namespace.

See also:

Parameters


Tag Name

Description

Physical name of the tag, as it will appear in the namespace.

See also:

Parameters


Description

Description

Tag description, not used in the namespace.

See also:

Parameters


Common (Inherit)

This section describes the common inherited parameters.


Retries

Description

The number of times to retry a request which has timed out after no response.

Allowable Values:

Default Value: 1

See also:

Parameters


Timeout

Description

Specifies how many milliseconds to wait for a response before regarding a request as having failed (and either doing a retry or returning an error). The time should be long enough to avoid false errors.

Allowable Values:

Default Value: 2000mS

See also:

Parameters


RestartTime

Description

The time that will elapse before an off-line device will be restarted (by an init message etc). Be careful to not use a to short interval, though it will affect performance.

Allowable Values:

Default Value: 120000

See also:

Parameters


Delay

Description

The period, in milliseconds, to wait between receiving a response and sending the next command.

Allowable Values:

Default Value: 50mS

See also:

Parameters


LiveTime

Description

Time for the cache to live before reread.

The slave response telegrams are saved inside the server during the LiveTime. If the client make a new request during this time, the response will come from the cache. If the time has elapsed a new request will be made.

Allowable Values:

Default Value: 30000mS

See also:

Parameters


NrOfTelegrams

Description

The number of telegrams the server will request from any device.

Normally the server is looking for MDH = 1Fh the slave signals to the master that it wants to be readout once again (multitelegram readouts). The master must readout the data until there is no MDH = 1Fh in the respond telegram.

You have possibilities to set NrOfTelegrams to manual and choose how many telegrams the server shall readout. If the device still has unread telegrams, they will be discarded. This is commonly used in heatmeters which has many telegrams and you only want to read out e.g. the first telegram.

Remember to reset the meter before next readout. If not it will continue to readout the following telegram during the next request.

Allowable Values: 1 to 100

Default Value: Auto/All

See also:

Parameters

InitRead


InitRead

Description

InitRead or meter reset determines the behaviour before any request is sent to a device.

Most common is to use the SND_NKE to switch to the first telegram, although this is not defined in the standard or in the documentation of the M-Bus Usergroup. Per definition the SND_NKE should just reset the link layer (FCB) but not the application layer. But it is now usually to reset to the first frame with SND_NKE. Some meters uses correctly the Application reset and not a SND_NKE. The usergroup defines that a selection (secondary address) shall act like a SND_NKE (reset link layer). The newer meters, need often an additional application reset to switch to the first frame. This has to be done after the secondary selection. Some manufacturer use the application reset subcode to select a special telegram, e.g. standard values or enhanced billing.

Allowable Values:

0 = No specific init packet

1 = SND_NKE (default)

2 = Application reset

3 = SND_NKE + Application Reset

No specific init packet

This selection is typical for Kamstrup meters.

SND_NKE (default)

If you have a multitelegram meter and have choosen to use only e.g. the first telegram via NrOfTelegrams you need to reset the telegramcounter, with the command SND_NKE or Application reset, in the meter before the next readout.

Application reset

With application reset command the server can release a reset of the application layer in the slaves. Each slave himself decides which parameters to change - e.g. which data output is default - after it has received such an application reset.

SND_NKE + Application Reset

This selection should work in most cases but will be quite slow depending of a lot of traffic.

Default Value: SND_NKE = 1

See also:

Parameters

SubCode

NrOfTelegrams


SubCode

Description

Determines the behavior if an optional application reset subcode is needed. This function is always working together with InitRead mode 2 or 3.

It is possible to use optional parameters after application reset. The use of the value zero for the number of the subtelegram means that all telegrams are requested.

Slaves with only one type of telegram may ignore application reset and the added parameters but have to confirm it.

Coding | Description | Examples
0 | All |
1 | User data | consumption
2 | Simple billing | actual and fixed date values+dates
3 | Enhanced billing | historic values
4 | Multi tariff billing |
5 | Instaneous values | for regulation
6 | Load management values for management |
7 | Reserved |
8 | Installation and startup | bus adress, fixed dates
9 | Testing | high resolution values
10 | Calibration |
11 | Manufacturing |
12 | Development |
13 | Selftest |
14 | Reserved |
15 | Reserved |

Allowable Values: No subcode, 0 - 15

Default Value: No subcode

See also:

Parameters

InitRead


Channel

This section describes the channel parameters.


Comm Mode

Description

This parameter manage the type of individual port connection.

Allowable Values:

0 = TCP, Socket Client

1 = TCP, Socket Server 1

2 = UDP, Socket Client

3 = UDP, Socket Server 1

4 = Serial

5 = Dial up 1

1 This feature is not implemented in the current version of PiiGAB M-Bus OPC Server.

See also:

Parameters


IPAddress

Description

IP address e.g. 192.168.100.120

See also:

Parameters


PortNumber

Description

TCP/UDP port e.g. 10001

See also:

Parameters


ModemName

This feature is not implemented in the current version of PiiGAB M-Bus OPC Server.

See also:

Parameters


PhoneNumber

This feature is not implemented in the current version of PiiGAB M-Bus OPC Server.

See also:

Parameters


ComPort

Description

Communication port number.

Allowable Values: 1 to 256.

Default Value: Communication port 1

See also:

Parameters


Baudrate

Description

Communication speed

Allowable Values:

Baud | 300 | 600 | 1200 | 2400 | 4800 | 9600 | 19200 | 38400 | 576001 | 1152001
Values in file | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Note | 1 | 2 | 2 | 1 | 2 | 1 | 2 | 2 | 2 | 2

NOTE 1 Recommended standard baud rates.

NOTE 2 These baud rates are reserved for special operator agreement only and should be avoided.

Default Value: 2400 Baud

1 This feature is not implemented in the interface of PiiGAB M-Bus OPC Server. Regarding to standard EN 13757-2 maximum baud rate is 38400 baud.

See also:

Parameters


DataBits

Description

Data bits.

Allowable Values: 7 or 8 data bits.

Default Value: 8 data bits is hard coded in the interface.

See also:

Parameters


StopBits

Description

Stop bits.

Allowable Values: 1, 1½ or 2 stop bits

Default Value: 1 stop bit is hard coded in the interface.

See also:

Parameters


Parity

Description

Parity.

Allowable Values: No parity, Odd parity, Even parity, Mark or Space

Default Value: Even parity is hard coded in the interface.

See also:

Parameters


FlowControl

Description

Flow control.

Allowable Values: No flow control or Hardware flow control

Default Value: No flow control hard coded in the interface.

See also:

Parameters


ReconnectTime

Description

Time that have to elapse before the channel will try to reestablish a failed connection.

· for TCP it is the connect retry interval (socket client) or the listen/accept interval (socket server)
· for TAPI it is the redial interval1
· for serial it is the port open attempt interval (if failed)

Allowable Values:

Default Value:

1 This feature is not implemented in the current version of PiiGAB M-Bus OPC Server.

See also:

Parameters


Device

This section describes the device parameters.


DeviceAddress

Description

During selection individual positions of the secondary addresses can be occupied with wildcards (Fh). Such a wildcard means that this position will not be taken account of during selection, and that the selection will be limited to specific positions, in order to address complete groups of slaves (Multicasting). In the identification number each individual digit can be wildcarded by a wildcard nibble Fh while the fields for manufacturer, version and medium can be wildcarded by a wildcard byte FFh.

Allowable Values:

Primary address as a single number:

0 - 250 or 254

or secondary address using the format:

FFFFFFFF.FFFF.FF.FF

Exempel secondary addresses

a) 00102747.0442.02.02

b) 00102747.FFFF.FF.FF

c) FFFFFF47.FFFF.FF.FF

See also:

Parameters


Tag

This section describes the tag parameters.


DataRecord

Description

The telegrams object or data record number.

Allowable Values:

Manufacturer dependent

See also:

Parameters


TagType

Description

The tag types supported by the server and the corresponding number which is used in the configuration file.

Allowable Values:

1 = Value

2 = Vib

3 = Unit

4 = Tariff

5 = Storage

6 = Function

7 = Datatype

8 = Record

9 = Manufacturer Specific

16 = Header

17 = Idnumber

18 = Manufacturer

19 = Version

20 = Medium

21 = Acessnumber

22 = Status

23 = Signature

See also:

Parameters


DataType

Description

The OPC data types supported by the server and the corresponding standard number which is used in the configuration file.

Allowable Values:

0 = VT_EMPTY

2 = VT_I2

3 = VT_I4

4 = VT_R4

5 = VT_R8

8 = VT_BSTR

11 = VT_BOOL

8 bits in Value (M-Bus data type int8).

8 bits in Status

8 bits in Manufacturer Specific

16 = VT_I1

17 = VT_UI1

18 = VT_UI2

19 = VT_UI4

See also:

Parameters


AccessRights

Description

Allowable Values:

1 = Read

2 = Write1

3 = Read & Write1

Default Value: 1

1This feature is not implemented in the current version of PiiGAB M-Bus OPC Server.

See also:

Parameters


Option1

Description

Offset for manufacturer specific data.

Allowable Values:

Default Value:

See also:

Parameters


Option2

Description

· Numbers of characters for manufacturers data when VT_BSTR is used
· Bit number (0 – 7) for TagType Status.
· Bit number (0 – 7) for TagType Manufacturer Specific data.
· Bit number (0 – 7) for TagType Value when VT_I1 is used.

Allowable Values:

Default Value:

See also:

Parameters


Option3

Description

Option 3 is used for many different things as have an on/off structure.

Unsigned for string

Bit 0 is set to1 (value 1) for Unsigned values when VT_BSTR or real.

Preceding zeros

Bit 1 is set to 1 (value 2) for M-Bus data types BCD2, BCD4, BCD6, BCD8 and BCD12 will show the leading zeros when VT_BSTR and TagType Value or Record are used.

Show Vib code

Bit 2 is set to 1 (value 4) for TagType Vib or Record will show the VIB code instead for table text

Manufacturer specific BCD

Bit 3 is set to 1 (value 8) for manufacturer specific data when conversion to BCD

Value bit inverted

Bit 4 is set to 1 (value 16) for value bit when it shall be inverted.

See also:

Parameters


Polynom offset (m)

Description

The m offset ratio in the formula y = kx + m

Allowable Values:

Default Value:

See also:

Parameters


Polynom ratio (k)

Description

The k polynom ratio in the formula y = kx + m.

Allowable Values:

Default Value:

See also:

Parameters


Raw zero scale

Description

The raw value scale starting point in a coordinate system (x1). If left blank, scale conversion will not take place.

Allowable Values:

Default Value:

See also:

Parameters


Raw full scale

Description

The raw value scale ending point in a coordinate system (x2). If left blank, scale conversion will not take place.

Allowable Values:

Default Value:

See also:

Parameters


Eng. zero scale

Description

The destination value scale starting point in a coordinate system (y1). If left blank, scale conversion will not take place.

Allowable Values:

Default Value:

See also:

Parameters


Eng. full scale

Description

The destination value scale ending point in a coordinate system (y2). If left blank, scale conversion will not take place.

Allowable Values:

Default Value:

See also:

Parameters


Decimals if BSTR

Description

Number of decimals when data type VT_BSTR is used. Decimals will only be shown when used together with Scaling.

Allowable Values:

Default Value:

See also:

Parameters


Parameter inheritance

Parameter inheritance is a feature that gives device parameters their great flexibility and power. If you understand parameter inheritance you will be able to use and organize your devices much more efficiently.

What is parameter inheritance?

Parameter inheritance means that parameters based on other parameters inherit the values of their parent parameters. If a parameter is changed in the parent the change is automatically inherited by all child parameters.

And this is the next important aspect of parameter inheritance: It only applies to parameters that have not been changed in the child. As soon as a parameter is changed in a device it is "fixed", and no longer affected by changes in the channel.

The inheritance tree

Let's have a look at a simple example of a parameter inheritance tree. The standard style on which all other styles are based is called Default and it's set by the server. The example below shows the parameter Live Time based on Default. Please note that this tree is simplified to make the explanations easier; in reality there are more attributes.

Advanced properties dialog

The parent level of the inherit parameter value can be found inside brackets in the advanced properties dialog box. If you want to break the tree thread you can write a new value. This new value will be inherited to the child.

Table of inherit parameters

The below parameters are a collection of all parameters which can be inherited.

Parameter | Default
Retries | 1
Timeout | 2000
RestartTime | 120000
Delay | 50
LiveTime | 30000
NrOfTelegrams | Automatic (100)
InitRead | SND_NKE (1)
SubCode | No Subcode (-1)

See also:

Advanced Properties

Common (Inherit)


Quality flags

The PiiGAB M-Bus OPC Server supports some of the sub status for OPC Quality flags. It doesn't support the limit bit field so the server always return 0 for limit bit field. How the message are shown in the client depends of how the vendor has implemented the information from the quality flags.

The quality flags are defined in the form of three bit fields; quality, substatus and limit status. The bits are arranged as: QQSSSSLL

Substatus for BAD Quality

Bit value | Code (Dec) | Quality Description in M-Bus server OPC Interface | Define (OPC-standard) | Description
000000LL | 0 | Bad | Non-specific | The value is bad but no specific reason is known
000001LL | 4 | Bad (config error) | Configuration Error | There is some server specific problem with the configuration.
000010LL | 8 | Bad (not connected) | Not Connected | The input is required to be logically connected to something but is not. This quality may reflect that no value is available at this time, for reasons like the value may have not been provided by the data source.
000011LL | 12 | Bad (device failure) | Device Failure | A device failure has been detected
000100LL | 16 | Bad (sensor failure) | Sensor Failure | A sensor failure had been detected
000101LL | 20 | Bad (last known value) | Last Known Value | Communications have failed. However, the last known value is available
000110LL | 24 | Bad (comm failure) | Comm Failure | Communications have failed. There is no last known value is available.
000111LL | 28 | Bad (out of service) | Out of Service | The block is off scan or otherwise locked This quality is also used when the active state of the item or the group containing the item is InActive.

Substatus for UNCERTAIN Quality

Bit value | Code (Dec) | Quality Description in M-Bus server OPC Interface | Define (OPC-standard) | Description
010000LL | 64 | Uncertain | Non-specific | There is no specific reason why the value is uncertain.
010001LL | 68 | Uncertain (last usable value) | Last Usable Value | Whatever was writing this value has stopped doing so.
010100LL | 80 | Uncertain (sensor not accurate) | Sensor Not Accurate | Either the value has ‘pegged’ at one of the sensor limits or the sensor is otherwise known to be out of calibration via some form of internal diagnostics.
010101LL | 84 | Uncertain (eng unit exceed) | Engineering Units Exceeded | The returned value is outside the limits defined for this parameter.
010110LL | 88 | Uncertain (sub normal) | Sub-Normal | The value is derived from multiple sources and has less than the required number of Good sources.

Substatus for GOOD Quality

Bit value | Code (Dec) | Quality Description in M-Bus server OPC Interface | Define (OPC-standard) | Description
110000LL | 192 | Good | Non-specific | The value is good. There are no special conditions.
110110LL | 216 | Good (last usable value) | Local Override | The value has been Overridden. Typically this is means the input has been disconnected and a manually entered value has been ‘forced’.


M-Bus Overview

This section is a part of the M-Bus User group official “The M-Bus: A Documentation” Version 4.8 and from "The M-Bus: An Overview"

The M-Bus ("Meter-Bus") is a new European standard for remote reading of heatmeters and it is also usable for all other types of consumption meters as well as for various sensors and actuators.

With its standardization as a galvanic interface for remote readout of heat meters this bus wins a great importance for the energy industry as relevant users.

The remote reading of heat meters can take place in different ways, beginning with the classical method - manual reading by the personnel of the providers - up to the remotely controlled collection of all the meter values for a complete housing unit. The latter is a logical continuation/extension of the technical development of consumption meters and is realizable with the help of the M-Bus.

Here some substantial characteristics of this interface are mentioned regarding their new possibilities:

· The data (e.g. heat consumption) are read out electronically
· At one single cable, which connects to a building controller all consumption meters of a housing unit can be attached
· All meters are individually addressable
· Apart from the availability of the data at the controller also a remote reading is possible

A set of advantages arise, both for the supply enterprises, and for their customers:

· The reading is fast and avoids reading errors
· The data being present in machine-readable form makes the further processing easier.
· A remote readout saves personnel expenditure, avoids unnecessary penetration into the private sphere of the inhabitants and permits to mount meters in places which are difficult to access.
· Short reading intervals are possible, which reduces the problems with tenant change or tariff amendments
· Due to the short reading intervals statistical data can be obtained, which can be used as a base for network optimization

The standardization of the m-bus results in further technical possibilities. In particular devices of different manufacturers can be operated on the same bus; the users are free therefore in the choice of the manufacturer. On the other hand, a stimulation of the market can be expected, also regarding other m-bus based counters, so that with the very variable configuration options even difficult problems can be solved.

In the development of the m-bus also economic and technical aspects of the interface have been considered, that are relevant for everyday use. These are essentially:

· Large number of connectable devices
· Possibility for network expansion
· Fail-safe characteristics / robustness
· Minimum cost
· Minimum power consumption in the meters
· Acceptable transmission speed

None of the many already existing bus systems was able to fulfill all these constraints. Now with the M-Bus as a new standardized interface for the reading of consumption meters, an optimal compromise between price and performance can be offered.


Principles of operation

Block diagram showing principle of the M-Bus System with 810 converter and the server

In order to realize an extensive bus network with low cost for the transmission medium, a two-wire cable was used together with serial data transfer. In order to allow remote powering of the slaves, the bits on the bus are represented as follows:

The transfer of bits from master to slave is accomplished by means of voltage level shifts. A logical "1" (Mark) corresponds to a nominal voltage of +36 V at the output of the bus driver (repeater/converter), when a logical "0" (Space) is sent, the repeater/converter reduces the bus voltage by 12 V to a nominal +24 V at its output.

Bits sent in the direction from slave to master are coded by modulating the current consumption of the slave. A logical "1" is represented by a constant (versus voltage, temperature and time) current of up to 1.5 mA, and a logical "0" (Space) by an increased current drain requirement by the slave of additional 11-20 mA. The mark state current can be used to power the interface and possibly the meter or sensor itself.

The quiescent state on the bus is a logical "1" (Mark), i.e. the bus voltage is 36 V at the repeater, and the slaves require a maximum constant quiescent current of 1.5 mA each.

When no slave is sending a space, a constant current will be drained from the repeater which is driving the bus. As a result of this, and also the resistance of the cable, the actual Mark voltage at the slaves will be less than +36 V, depending on the distance between the slave and the repeater and on the total quiescent current of the slaves. The slave must therefore not detect absolute voltage levels, but instead for a space detect a voltage reduction of 12 V. The repeater must adjust itself to the quiescent current level (Mark), and interpret an increase of the bus current of 11-20 mA as representing a space. This can be realized with acceptable complexity only when the mark state is defined as 36 V. This means that at any instant, transmission is possible in only one direction - either from master to slave, or slave to master (Half Duplex).

As a result of transmission in the master-slave direction with a voltage change of 12 V, and in the answering direction with at least 11 mA, besides remote powering of slaves a high degree of insensitivity to external interference has been achieved.

Segmentation

An M-Bus system can consist of several so-called zones, each having its own group address, and interconnected via zone controllers and higher level networks. Each zone consists of segments, which in turn are connected by remote repeaters. Normally however, an M-Bus system consists of only a single segment, which is connected via a local repeater to a Personal Computer (PC) acting as master. Such local repeaters convert the M-Bus signals into signals for the RS232 interface.

Cable

A two-wire standard telephone cable (JYStY N*2*0.8 mm) is used as the transmission medium for the M-Bus. The maximum distance between a slave and the repeater is 350 m; this length corresponds to a cable resistance of up to 29Ω. This distance applies for the standard configuration having Baud rates between 300 and 9600 Baud, and a maximum of 250 slaves. The maximum distance can be increased by limiting the Baud rate and using fewer slaves, but the bus voltage in the Space state must at no point in a segment fall below 12 V, because of the remote powering of the slaves. In the standard configuration the total cable length should not exceed 1000 m, in order to meet the requirement of a maximum cable capacitance of 180 nF.


Transmission Parameters

The M-Bus protocol uses asynchronous serial bit transmission, in which the synchronization is implemented with start and stop bits for each character. There must be no pauses within a telegram, not even after a stop bit. Since quiescence on the line corresponds to a 1 (Mark), the start bit must be a Space, and the stop bit a Mark. In between the eight data bits and the even parity bit are transmitted, ensuring that at least every eleventh bit is a Mark. The bits of data are transmitted in ascending order, i.e. the bit with the lowest value (LSB = least significant bit) is the first one to be found on the line. The transmission takes place in half duplex and with a data rate of at least 300 Baud. In the figure the transmission of a byte in calling and replying direction is represented.

Transmission of a Character in Calling and Replying Direction


Telegram Format

According to IEC 870-5, three different data integrity classes (I1, I2 and I3) are envisaged for the transmission of remote control data. For the M-Bus protocol of the data link layer the format class FT 1.2 is used, which is contained in the data integrity class I2, which specifies a Hamming Distance of four.

The format class FT 1.2 specifies three different telegram formats, which can be recognized by means of special start characters. Below the telegram formats used for the M-Bus will now be explained.

Single Character | Short Frame | Long Frame
E5h | Start 10h | Start 68h
 | C Field | L Field
 | A Field | L Field
 | Check Sum | Start 68h
 | Stop 16h | C Field
 |  | A Field
 |  | CI Field
 |  | User Data (0-252 Byte)
 |  | Check Sum
 |  | Stop 16h

Telegram Formats

· Single Character

This format consists of a single character E5h, and serves to acknowledge receipt of transmissions.

· Short Frame

This format with a fixed length of five characters begins with the start character 10h, and besides the C and A fields includes the check sum and the stop character 16h.

· Long Frame

With the long frame, after the start character 68h, the length field (L field) is first transmitted twice, followed by the start character once again. After this, there follow the function field (C field), the address field (A field) and the control information field (CI field). After the user data inputs, the check sum are transmitted, which is built up over the same area as the length field, and in conclusion the stop character 16h is transmitted.

Meaning of the Fields

In this section, the fields used for telegram formats will be explained. These all have a length of 1 Byte, corresponding to 8 bits.

L field (Length Field)

The L field gives the quantity of the user data inputs plus 3 (for C,A,CI). It is transmitted twice in Long Frame format

C Field (Control Field, Function Field)

Besides labeling the functions and the actions caused by them, the function field specifies the direction of data flow, and is responsible for various additional tasks in both the calling and replying directions.

Bit Number | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Calling Direction | 0 | 1 | FCB | FCV | F3 | F2 | F1 | F0
Reply Direction | 0 | 0 | ACD | DFC | F3 | F2 | F1 | F0

Coding of the Control Field

The highest value (most significant) bit is reserved for future functions, and at present is allocated the value 0; bit number 6 is used to specify the direction of data flow. The frame count bit FCB indicates successful transmission procedures (i.e. those that have been replied to or acknowledged), in order to avoid transmission loss or multiplication. If the expected reply is missing or reception is faulty, the master sends again the same telegram with an identical FCB, and the slave replies with the same telegram as previously. The master indicates with a 1 in the FCV bit (frame count bit valid), that the FCB is used. When the FCV contains a "0", the slave should ignore the FCB. (The server has always 1 in the FCV bit)

The bits 0 to 3 of the control field code the true function or action of the message. The table shows the function codes used in the calling and the replying directions.

Name | C-field (binary) | C-field (hex) | Telegram | Description
SND_NKE | 0100 0000 | 40 | Short Frame | Initialization of Slave
SND_UD | 01F1 0011 | 53/73 | Long Frame | Send User Data to Slave
REQ_UD2 | 01F1 1011 | 5B/7B | Short Frame | Request for Class 2 Data
REQ_UD1 | 01F1 1010 | 5A/7A | Short Frame | Request for Class 1 Data*
RSP_UD | 00AD 1000 | 08 | Long Frame | Data Transfer from Slave to Master after Request

Control Codes of the M-Bus Protocol (F = FCB-Bit, A = ACD-Bit, D = DFC-Bit)

*The server does not support Class 1 Data

A Field (Address Field)

The address field serves to address the recipient in the calling direction, and to identify the sender of information in the receiving direction. The size of this field is one Byte, and can therefore take values from 0 to 255. The addresses 1 to 250 can be allocated to the individual slaves, up to a maximum of 250. Unconfigured slaves are given the address 0 at manufacture, and as a rule are allocated one of these addresses when connected to the M-Bus. The addresses 254 (FEh) and 255 (FFh) are used to transmit information to all participants (Broadcast). With address 255 none of the slaves reply, and with address 254 all slaves reply with their own addresses. The latter case naturally results in collisions when two or more slaves are connected, and should only be used for test purposes. The address 253 (FDh) indicates that the secondary addressing has been performed in the Network Layer instead of Data Link Layer. The remaining addresses 251 and 252 have been kept for future applications.

CI Field (control information field)

The CI-field codes the type and sequence of application data to be transmitted in the frame. The EN1434-3 defines two possible data sequences in multibyte records. Bit two (counting begins with bit 0, value 4), which is called M bit or Mode bit, in the CI-field gives an information about the used byte sequence in multi-byte data structures. If the Mode bit is not set (Mode 1), the least significant byte of multi-byte record is transmitted first, otherwise (Mode 2) the most significant byte. The M-Bus user group recommends using only the Mode 1 in future applications. The server is supporting only Mode 1.

Check Sum

The Check Sum serves to recognize transmission and synchronization faults, and is configured from specific parts of the telegram. The Check Sum is calculated from the arithmetical sum of the data, without taking carry digits into account.


Communication Process

The Data Link Layer uses two kinds of transmission services:

Send/Confirm: SND/CON

Request/Respond: REQ/RSP

Send / Confirm Procedures

SND_NKE

This procedure serves to start up after the interruption or beginning of communication. The value of the frame count bit FCB is adjusted in master and slave, i.e. the first master telegram with FCV=1 after SND_NKE contains a FCB=1. The slave responds to a correctly received SND_NKE with an acknowledgment consisting of a single character (E5h).

SND_UD

With this procedure the master transfers user data to the slave. The slave can either confirm the correct receipt of data with a single character acknowledge (E5h), or by omitting a confirmation signal that it did not receive the telegram correctly.

Request / Respond Procedures

REQ_UD2 RSP_UD

The master requests data from the slave using the REQ_UD2 telegram. The slave can either transfer its data with RSP_UD, or give no response indicating that the REQ_UD2 telegram has not been received correctly or that the address contained in the telegram does not match.


Selection and Secondary Addressing

The server supports secondary addressing. The secondary addressing starts with a slave selection command:

68h

0Bh

0Bh

68h

53h

FDh

52h

ID1-4

Man 1-2

Gen

Med

CS

16h

Structure of a telegram for selecting a slave (mode 1)

The master sends a SND_UD with the control information 52h to the address 253 (FDh) and fills the specific meter secondary address (identification number, manufacturer, version and medium) with the values of the slave which is to be addressed. The address FDh and the control information 52h are the indication for the slaves to compare the following secondary addresses with their own and to change into the selected state should they agree. In this case the slave must answer the selection with an acknowledgement (E5h), otherwise the slave doesn’t send an answer. "Selected state" means that this slave will be addressed with the bus address 253 (FDh). In other words the network layer has associated this slave with the address 253 (FDh).

During selection individual positions of the secondary addresses can be occupied with wildcards (Fh). Such a wildcard means that this position will not be taken account of during selection, and that the selection will be limited to specific positions, in order to address complete groups of slaves (Multicasting). In the identification number each individual digit can be wildcarded by a wildcard nibble Fh while the fields for manufacturer, version and medium can be wildcarded by a wildcard byte FFh.

The state of the selection remains unchanged until the slave is deselected with a selection command with non-matching secondary addresses, or a SND_NKE to address 253. The slave, who uses mode 1 for multibyte records, will be selected by a telegram with the CI-Field 52h and the right secondary address, but it will be deselected by a telegram with the CI-Field 56h and any secondary address.


Manufacturer Specific Data Block

The MDH consists of the character 0Fh or 1Fh (DIF = 0Fh or 1Fh) and indicates that all following data are manufacturer specific. When the number of bytes given in the length field of the connection protocol has not yet been used up, then manufacturer specific data follow this character, whose coding is left to the manufacturer. The length of this data is calculated from the L-Field minus the length of the so-called standard data (C-Field, A-Field, CI-Field and the data up to and including the data block 0Fh).

In case of MDH = 1Fh the slave signals to the master that it wants to be readout once again (multitelegram readouts). The master must readout the data until there is no MDH = 1Fh in the respond telegram.


Data Information Block

The DIB contains at least of one byte (DIF), data information field), and can be extended by a maximum of ten DIFE's (data information field extensions). The following information is contained in a DIF:

Bit 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Extension Bit | LSB of storage number | Function Field |  | Data Field : Length and coding of data

Coding of the Data Information Field (DIF)

The function field gives the type of data as follows:

Code | Description | Function
00 | Instantaneous value | Inst
01 | Maximum value | Max
10 | Minimum value | Min
11 | Value during error state | Error

Coding of the function field

The data field shows how the data from the master must be interpreted in respect of length and coding. The following table contains the possible coding of the data field:

Length in Byte | Code | Meaning | Data type
0 | 0000 | No data | No data
1 | 0001 | 8 bit integer | Int8
2 | 0010 | 16 bit integer | Int16
3 | 0011 | 24 bit integer | Int24
4 | 0100 | 32 bit integer | Int32
4 | 0101 | 32 bit real | Real32
6 | 0110 | 48 bit integer | Int48
8 | 0111 | 64 bit integer | Int64
0 | 1000 | Selection for readout | Selection
1 | 1001 | 2 digit BCD | BCD2
2 | 1010 | 4 digit BCD | BCD4
3 | 1011 | 6 digit BCD | BCD6
4 | 1100 | 8 digit BCD | BCD8
n | 1101 | Variable length* | Variable
6 | 1110 | 12 digit BCD | BCD12
n | 1111 | Special functions | Special

Coding of the data field

Special Functions (data field = 1111b):

DIF | Function
0Fh | Start of manufacturer specific data structures to end of user data
1Fh | Same meaning as DIF = 0Fh + More records follow in next telegram
2Fh | Idle Filler (not to be interpreted), following byte = DIF
3Fh..6Fh | Reserved
7Fh | Global readout request (all storage#, units, tariffs, function fields)

If data follows after DIF=0Fh or 1Fh these are manufacturer specific data records. The number of bytes in these manufacturer specific data can be calculated with the L-Field. The DIF 1Fh signals a request from the slave to the master to readout the slave once again. The master must readout the slave until there is no DIF=1Fh inside the respond telegram (multi telegram readout).

The Bit 6 of the DIF serves to give the storage number of the data concerned, and the slave can in this way indicate and transmit various stored counter states or historical values, in the order in which they occur. This bit is the least significant bit of the storage number and allows therefore the storage numbers 0 and 1 to be given without further DIFE's. In this way the storage number 0 stands for the actual value. If higher storage numbers are needed, the slave allows a DIFE to follow the DIF, and indicates this by setting the extension bit.

Each DIFE (maximum ten) contains again an extension bit to show that a further DIFE is being sent. Besides giving the next most significant bit of the storage number, this DIFE allows the transmission of information about the tariff and the subunit of the device from which the data come. In this way, exactly as with the storage number, the next most significant bit or bits will be transmitted. The figure shows the structure of a DIFE:

Bit 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Extension Bit | (Device) Unit | Tariff |  | Storage Number

Coding of the Data Information Field Extension (DIFE)

With the maximum of ten DIFE´s that are provided, there are 41 bits for the storage number, 20 bits for the tariff, and 10 bits for the subunit of the meter. There is no application conceivable in which this immense number of bits could all be used.

No | DIB | Bit 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
0 | DIF | E | S | F | F | D | D | D | D
1 | DIFE | E | U | T | T | S | S | S | S
2 | DIFE | E | U | T | T | S | S | S | S
3 | DIFE | E | U | T | T | S | S | S | S
4 | DIFE | E | U | T | T | S | S | S | S
5 | DIFE | E | U | T | T | S | S | S | S
6 | DIFE | E | U | T | T | S | S | S | S
7 | DIFE | E | U | T | T | S | S | S | S
8 | DIFE | E | U | T | T | S | S | S | S
9 | DIFE | E | U | T | T | S | S | S | S
10 | DIFE | E | U | T | T | S | S | S | S

Detailed Coding of the Data Information Field Extension (DIFE)

Where: E = Extension Bit

S = Storage Number (0 – 2199023255551)

F = Function Field

D = Data Field: Length and coding of data

U = Unit (Device) (0 – 1023)

T = Tariff (0 – 1048575)


Value Information Block

After a DIF or DIFE without a set extension bit there follows the VIB (value information block). This consists at least of the VIF (value information field) and can be expanded with a maximum of 10 extensions (VIFE). The VIF and also the VIFE's show with a set MSB that a VIFE will follow. In the value information field VIF the other seven bits give the unit and the multiplier of the transmitted value.

Bit 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Extension Bit | Unit and multiplier (value)

Coding of the Value Information Field (VIF)

There are five types of coding depending on the VIF:

1) Primary VIF: 00h .. 7Ah

The unit and multiplier is taken from the table for primary VIF.

2) Plain-text VIF: 7Ch (Not supported in the server)

In case of VIF = 7Ch / FCh the true VIF is represented by the following ASCII string with the length given in the first byte. Please note that the byte order of the characters after the length byte depends on the used byte sequence. This plain text VIF allows the user to code units that are not included in the VIF tables.

3) Linear VIF-Extension: FDh or FBh

In case of VIF = FDh or VIF = FBh the true VIF is given by the next byte and the coding is taken from the table for secondary VIF. This extends the available VIF´s by another 256 codes.

4) Any VIF: 7Eh / Feh (Not supported in the server)

This VIF-Code can be used in direction master to slave for readout selection of all VIF´s. See chapter 6.4.3.

5) Manufacturer specific: 7Fh / FFh

In this case the remainder of this data record including VIFE´s has manufacturer specific coding.

The VIFE can be used for actions which shall be done with the data (master to slave), for reports of application errors (slave to master) and for an enhancement of the VIF (orthogonal VIF). The last feature allows setting VIF´s into relation to the base physical units (e.g. VIF=10 liter, VIFE= per hour) or coding indirect units, pulse increments and change speeds.

In case of VIFE = FFh the next VIFE's and the data of this block are manufacturer specific, but the VIF is coded as normal.

After a VIF or VIFE with an extension bit of "0", the value information block is closed, and therefore also the data record header, and the actual data follow in the previously given length and coding.


Variable Data Blocks

The data, together with information regarding coding, length and the type of data is transmitted in data records. As many blocks of data can be transferred as there is room for, within the maximum data length of 255 Bytes, and taking account of the C, A , and CI fields, the fixed data block. The upper limit for characters in the variable data blocks is thus 240 byte. The Usergroup recommends a maximum total telegram length of 255 bytes (234 bytes for variable data blocks) to avoid problems in modem communication. The manufacturer data header (MDH) is made up by the character 0Fh or 1Fh and indicates the beginning of the manufacturer specific part of the user data and should be omitted, if there is no manufacturer specific data.

Data Record Header (DRH) |  |  |  | Data
Data Information Block (DIB) |  | Value Information Block (VIB) |  |
DIF | DIFE | VIF | VIFE |
1 Byte | 0 - 10 Bytes | 1 Byte | 0 - 10 Bytes | 0 - n Bytes

Structure of a Data Record (transmitted from left to right)

Each data record consists of a data record header (DRH) and the actual data. The DRH in turn consists of the DIB (data information block) to describe the length, type and coding of the data, and the VIB (value information block) to give the value of the unit and the multiplier.


Fixed Data Header

In this topic:

Structure

Identification Number

Manufacturer

Version

Medium

Access Number

Status

Signature

Structure

The first twelve bytes of the user data consist of a block with a fixed length and structure

Identification No | Manufacturer | Version | Medium | Access No | Status | Signature
4 Byte | 2 Byte | 1 Byte | 1 Byte | 1 Byte | 1 Byte | 2 Byte

Identification Number

Identification Number is a customer number, coded with 8 BCD packed digits (4 Byte), and which thus runs from 00000000 to 99999999.

Manufacturer

Manufacturer is coded unsigned binary with 2 bytes. This manufacturer ID is calculated from the ASCII code of EN 61107 manufacturer ID (three uppercase letters) with the following formula:

IEC 870 Man. ID =

[ASCII(1st letter) - 64] • 32 • 32

+ [ASCII(2nd letter) - 64] • 32

+ [ASCII(3rd letter) - 64]

Version

Version specifies the generation or version of this counter and depends on the manufacturer.

Medium

Medium is coded with a whole byte. The text is readout from MbusOPC.ini

Medium | Code hex
Other | 00
Oil | 01
Electricity | 02
Gas | 03
Heat (Volume measured at return temperature: outlet) | 04
Steam | 05
Hot Water | 06
Water | 07
Heat Cost Allocator. | 08
Compressed Air | 09
Cooling load meter (Volume measured at return temperature: outlet) | 0A
Cooling load meter (Volume measured at flow temperature: inlet) | 0B
Heat (Volume measured at flow temperature: inlet) | 0C
Heat / Cooling load meter | OD
Bus / System | 0E
Unknown Medium | 0F
Reserved | 10 to 15
Cold Water | 16
Dual Water | 17
Pressure | 18
A/D Converter | 19
Reserved | 20 to FF

Access Number

Access Number has unsigned binary coding, and is increased by one after each RSP_UD from the slave.

Status

Status field are used to indicate application errors.

Bit | Meaning
0 | Application busy
1 | Any application error
2 | Power low
3 | Permanent error
4 | Temporary error
5 | Specific to manufacturer
6 | Specific to manufacturer
7 | Specific to manufacturer

Signature

Signature remains reserved for future encryption applications, and until then is allocated the value 00 00 h.


Variable Data Structure

The CI-Field codes 72h are used to indicate the variable data structure in long frames (RSP_UD).

Fixed Data Header | Variable Data Blocks (Records) | MDH | Manufacturer specific data
12 Byte | Variable number of bytes | 1 Byte | Variable number of bytes

Variable Data Structure in Reply Direction


Applications of the FCB-mechanism

 Top Previous

Multi-telegram answers (RSP_UD) from slave to master

If a total answer sequence from a slave will not fit into a single RSP_UD (respond user data) telegram from the slave to the master, the master signals by a toggled FCB-Bit together with a set FCV-Bit in the next REQ_UD (Request user data) telegram that its link layer has properly received the last RSP_UD-telegram from the slave. The slave answers to a REQ_UD-request with toggled FCB-Bit with a set FCV-bit from the master with a RSP_UD containing the next link layer telegram section of a multi-telegram answer, otherwise it will repeat the last telegram. Note that a slave with a single RSP_UD-telegram may simply ignore the FCB in the REQ_UD2-telegram and send always the same (single) telegram. Note also that a slave with exactly two (sequential) RSP_UD-answer telegrams may simply use the FCB of the REQ_UD2 to decide which of both telegrams should be transmitted. Thus a slave with one or two (sequential) RSP_UD answer-telegrams does not require an internal "Last-REQ_UD2-FCB"-image bit. A slave with three or more (sequential) RSP_UD answer telegrams requires such an internal memory bit. Note that such an internal memory bit for the RSP_UD-direction must be independent of an possible additional internal memory bit for the SND_UD direction.

Frozen answer telegrams from slave to master

In same instances a slave will freeze the data of its last RSP_UD answer telegram into an additional temporary storage and will repeat these previously frozen RSP_UD answer, if the FCB has not been toggled. After the reception of a toggled FCB-Bit with a set FCV-Bit or after the reception of a REQ_UD2 with the FCV-Bit cleared, the slave will generate a next answer telegram reflecting the current state of all its data instead of repeating the data values frozen at the first REQ_UD2 attempt with toggled FCB.