Welcome to PiiGAB M-Bus Explorer v2

Welcome to PiiGAB M-Bus Explorer v2

 This is the first topic Next topic No expanding text in this topic Print this topic

Welcome to PiiGAB M-Bus Explorer v2

 This is the first topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Welcome to a new dimension of M-Bus communication.

PiiGAB M-Bus Explorer is a tool for configuration of version 2 of PiiGAB M-Bus OPC Server. PiiGAB M-Bus Explorer is also used for configuring the mapping between the modbus slave and the M-Bus client as well as between M-Bus Ascii and the M-Bus client in PiiGAB M-Bus gateway series 900.

PiiGAB M-Bus OPC Server

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. Read more here.

Modbus

With PiiGAB M-Bus Explorer you can configure the mapping between a modbus register and an M-Bus OPC Item. In order to configure you first have to make standard OPC items and then connect them to modbus registers. After that you have to upload the OPC configuration file and the cross reference file to the 900 gateway via its web interface.

M-Bus Ascii

With M-Bus Ascii (this is a name made up by PiiGAB) you can send the OPC Item string directly from a client software and you will receive a string with the meter value from the 900 gateway. The M-Bus requests to the meter is handled by the 900 gateway. You have to upload the OPC configuration file to the 900 gateway via its web interface.

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

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


Introduction

Introduction

 Previous topic Next topic No expanding text in this topic Print this topic

Introduction

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The topics in this section provide some basic information about PiiGAB M-Bus Explorer, it's usage and its possibilities.

How to get started

ØSee Installation for details on how to install PiiGAB M-Bus Explorer.

Ø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 Explorer.

How to buy

ØSee the How to buy section for detailed instructions on buying PiiGAB M-Bus Explorer.


About PiiGAB M-Bus Explorer

About PiiGAB M-Bus Explorer

About PiiGAB M-Bus Explorer

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The PiiGAB M-Bus Explorer v2 is supporting the OPC Server Data Access specifications 2.00, 2.05a and 3.00.

Whats new in version 2.01.02.001

Implemented:

·int64 to VT_I8, VT_UI8

·int48 to VT_I8, VT_UI8

·BCD12 to VT_I8, VT_UI8

·VT_R8 can also be used but the fraction part will only support up to 49 bits then an exponent will be shown.

·Possible to scale VT_I8 and VT_UI8

·Better performance on TRACE when many parallel channels are working in the same time.

Whats new in version 2.01.01.001

Implemented:

·A combination of SlaveSelect + SND_NKE

·Extra parsing of 0x2f.

·Support for DNS name.

·Norwegian and German language is supported.

Whats new in version 2.01.00.002

Implemented:

·Parsing for 0x2f

Whats new in version 2.01.00.001

Implemented:

·ValueSplit

·Configuration files is also saved as a .bak file.

·Private data Siemens RVD

·Many small adjustments around input controls.

Whats new in version 2.00.00.001

First version 2 release

Key features for PiiGAB M-Bus Explorer including M-Bus OPC Server V2

·Import templates

·Save a meter as a template

·Backup/Restore tool

·Change language online

·Write to meters

·Groups of meters

·Manuel init string

·Supports Fixed Data Structure

·Project files

·Version handling

·Free searching in tag database

·Enhanced debug

·M-Bus objects in manufacturer specific area

Key features for PiiGAB M-Bus OPC Server V1

·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 and reals 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 a built-in interface.

Running

When you're using the client you can have the interface monitor connected simultaneously.

See also:

Welcome to PiiGAB M-Bus Explorer v2


Links and credits

Links and credits

Links and credits

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

M-Bus User group home page:

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

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

Credits for the PiiGAB M-Bus Explorer 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. QuickOPc V5 is implemented in the interface for the monitor function.

Web16 http://www.opclabs.com

Web16 http://www.quickopc.com

Knowledge of networking subjects

Trosoft AB (see website below) has made the UDP and TCP part in the server and parts of the license system.

Web16 http://www.automatisera.nu

See also:

How to contact PiiGAB


How to buy PiiGAB M-Bus Explorer

How to buy PiiGAB M-Bus Explorer

How to buy PiiGAB M-Bus Explorer

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

New licenses:

Article Number | Devices
PI-EXPL20 | 1-20
PI-EXPL250 | 1-250
PI-EXPL1000 | 1-1000
PI-EXPLN | 1-unlimited

Upgrades:

Article Number | Devices From è To
PI-EXPL20-250 | 1-20 è 1-250
PI-EXPL20-1000 | 1-20 è 1-1000
PI-EXPL20-N | 1-20 è 1-unlimited
PI-EXPL250-1000 | 1-250 è 1-1000
PI-EXPL250-N | 1-250 è 1-unlimited
PI-EXPL1000-N | 1-1000 è 1-unlimited

Upgrades from version 1 to version 2:

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

Licence keys:

Article Number | Devices
PI-SENTINY | Sentinel Super-Pro Tiny
PI-SENUSB | Sentinel Super-Pro USB
PI-SOFTKEY | Software Key
PI-FLASHUSB | USB Flash Key

For ordering:

Web16 order@piigab.se

PiiGAB home page:

Web16 http://www.piigab.com

General questions:

Web16 info@piigab.se

Email support:

Web16 support@piigab.se

Contacts:

PiiGAB

Anders Carlssons gata 7

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

Demo version

Demo version

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

You can run PiiGAB M-Bus Explorer in demo mode for 30 minutes. During demo mode you can connect and browse one channel and five devices, meaning you can work with your project without any limitations. The only limitation implemented is for Monitoring the values where the limitation for one channel and five devices is in place.

The demo license is the same as a full license, therefore you don't need to make any reinstallation when going from a demo license to a full running license. You only have to install the hardware or software key and you are up and running.

Below is an example of starting in demo mode.

In demo mode you will see the word "Demo" just to right of the key icon in the status bar.

See also:

How to buy PiiGAB M-Bus Explorer

License

License key


Installing

Installing

Installing

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

See also:

Installation step by step


Installation step by step

Installation step by step

Installation step by step

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Full installation instructions

1.Perform the appropriate steps to start the installation:

· If PiiGAB M-Bus Explorer is on a CD-ROM, insert the CD-ROM into the computer’s CD-ROM drive.

· If you downloaded PiiGAB M-Bus Explorer, 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 Explorer 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 desire.

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.

10. The Completing dialog box appears.

·Click Finish to complete the installation.

See also:

Uninstall


License key

License key

License key

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The license key can be a hardware key or a software key. The hardware key is alternatively a Sentinel SuperPro and it's delivered as an USB key or a mini parallel port key. From version 2 we can also deliver the hardware key as an USB Flash 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.com

If you need to update or make sure 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

Uninstall

Uninstall

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

1.Go to the Start Menu Folder where the PiiGAB M-Bus Explorer 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 OK to complete the uninstall.

See also:

Installation step by step


Registering the server

Registering the server

Registering the server

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The PiiGAB M-Bus Explorer 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 M-Bus OPC server:

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

See also:

Unregistering the server


Unregistering the server

Unregistering the server

Unregistering the server

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

To unregister the M-Bus OPC server:

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

See also:

Registering the server


User Interface

User Interface

User Interface

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The PiiGAB M-Bus Explorer user interface:


Menus

Menus

Menus

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

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


The File Menu

The File Menu

The File Menu

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

File menu options:

New: | Create a new M-Bus OPC Server project file.
 | Create a new M-Bus meters to Modbus (900) project file.
 | Create a new M-Bus Ascii (900) 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: | Make a saved project active.
Set As Active Project: | Make the existing project active.
Exit: | Exits PiiGAB M-Bus Explorer.

See also

Menus


The Edit Menu

The Edit Menu

The Edit Menu

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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:

Undo: | Undo the last editing action. Note that this must be selected repeatedly for some more complex actions.
Redo: | Reverse the last Undo operation.
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.
Search: | Search and find objects in the project.

See also:

Menus


Find Object

Find Object

Find Object

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This dialog is used to help you to find all types of objects as tags, devices, groups and channels from your configuration file. You can double click on the object and you will go directly to that specific object.

Find Object dialog:

See also:

The Edit Menu


The Project Menu

The Project Menu

The Project Menu

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Project menu options:

Add Channel: | Adding a new channel to the configuration.
Add Group: | Adding a new group to the configuration.
Add Device: | Adding a new device to the configuration.
Add Tag: | Adding a new tag to the configuration.
Import Configurationfile: | Import the configuration file from e.g. PiiGAB M-Bus OPC Server version 1
Export Configurationfile: | Export the configuration file for e.g. merging in a bigger project.
Root Settings: | Setting default values for parameters.
Properties: | Showing project properties.

See also:

Menus


Properties

Properties

Properties

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This dialog is used to show properties and file information.

Properties dialog

See also:

The Edit Menu


Import Configuration file

Import Configuration file

Import Configuration file

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This dialog is used to import the configuration file from e.g. PiiGAB M-Bus OPC Server version 1.

Import configuration dialog:

See also:

The Tools Menu


Export Configuration file

Export Configuration file

Export Configuration file

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This dialog is used to export the configuration file for e.g. merging in a bigger project.

Export Configuration dialog:

See also:

The Tools Menu


The Templates Menu

The Templates Menu

The Templates Menu

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The Template menu contains basic commands for import and save meters as templates.

Templates menu options:

Import Template: | Import meter templates.
Save Meter as Template: | Save meter as template.

See also:

Menus


Import template

Import template

Import template

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This dialog is used to import and show properties for a saved template.

Import template dialog:

See also:

The Tools Menu


Save Meter as template

Save Meter as template

Save Meter as template

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This dialog is used to save a meter as a template.

Save meter as template dialog:

See also:

The Tools Menu


The Tools Menu

The Tools Menu

The Tools Menu

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This menu provide direct access to a variety of tools included in the PiiGAB M-Bus Explorer.

Tools menu options:

License | Show information about the installed licenses.
Language: | Change language online.
Modbus Register List: | Showing how the Modbus registers is used.
Debug: | Setting the debug level and path for the log file.
Start Monitor: | Starting showing the meter values.
Stop Monitor: | Stop showing the meter values.
Stop Server Process: | The Stop Server Process provides access to stop the server process if there should be more clients connected to the server.
Backup/Restore: | Backup and Restore the project.
Options: | Eventually this will contain different extra options. Today the only option is fast writing.

See also:

Menus


License

License

License

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

For test and demo you can connect one channel and five 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 a demo license to a full running license. You only have to install the hardware or software key and you are up and running.

License information dialog:

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 you will see the licence information; version, Nr of channels and Nr of devices.

Registration Code: | The license serial number.
System ID: | Computer system identification
Version: | The license version. Should be 2.
Nr of channels: | Maximum number of channels in the installed license.
Nr of devices: | Maximum number of devices in the installed license.
Demotime: | Configured demo time in minutes. Is shown only if demotime is chosen.

Hardware USB Flash key

The USB Flash key is a standard USB memory sticker. The driver for the USB sticker you normally already have on your computer.

Serial Number: | The license serial number.
Version: | The license version. Should be 2.
Nr of channels: | Maximum number of channels in the installed license.
Nr of devices: | Maximum number of devices in the installed license.
Demotime: | Configured demo time in minutes. Is shown only if demotime is chosen.

Hardware Sentinel 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.com. 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

With the Serial Number we can produce an Upgrade Code code from version 1 to version 2 for you. Put in this Upgrade Code in the field "Upgrade Code:" and press "Upgrade". If everything works OK you will see the message box with the information "Upgrade succeeded".

Serial Number: | The license serial number.
Version: | The license version. Should be 2.
Nr of channels: | Maximum number of channels in the installed license.
Nr of devices: | Maximum number of devices in the installed license.
Demotime: | Configured demo time in minutes. Is shown only if demotime is chosen.
Upgrade Code: | Code for upgrading from version 1 to version 2.

Combination of hardware and software key

It's possible to combine the hardware keys with the software key. The number of channels and devices will be added together. The example below will correspond to a license of 765 channels and 750 devices. See also below for how it's presented in the status bar.

See also:

Installation information

The Tools Menu


Language

Language

Language

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This dialog is used for changing language on line without any restart of the software.

All the texts is implemented in special language files. If you are interested to translate PiiGAB M-Bus Explorer to other languages please send an email to us.

Language dialog:

See also:

The Tools Menu


Modbus Register List

Modbus Register List

Modbus Register List

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This dialog is used to show how the modbus registers is used.

You can see if some registers are overlapped or if you have unwanted spaces between registers. If the registers are overlapped they will be marked with a red square. Move the mouse over the red square and you will see which OPC items that is overlapped.

Modbus Register List dialog:

See also:

The Tools Menu


Debug

Debug

Debug

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Debug properties dialog:

Debug Level: | Possibility to choose debugging of the M-Bus traffic.
No Debug | Only basic debugging will be made such as server start/stop, connection etc.
Level 1 | Al request/response messages will be stored in the file.
Level 2 | A vertical line will be inserted between each object to give a better possibility to do a readout of the objects.
Path to logfile: | The path for the log file.

See also:

Debug

The Tools Menu


Backup/Restore

Backup/Restore

Backup/Restore

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This dialog is used to help you to make a backup or to restore your project.

Backup dialog:

Restore dialog:

See also:

The Tools Menu


The View Menu

The View Menu

The View Menu

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The View menu contains options for showing various PiiGAB M-Bus Explorer windows.

View menu options:

View statistics tags: |  | Show statistics meter tags on the same page as normal tags.
Windows: | Server Browser | Show Server Browser Window.
 | Explorer Window | Show Explorer Window.
 | Project Properties | Show Project Properties Window.
 | Reset View | Reset Window View.

See also:

Menus


The Help Menu

The Help Menu

The Help Menu

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Help menu options:

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

See also:

Menus


Dialogs

Dialogs

Dialogs

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


Root Properties

Root Properties

Root Properties

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The Root Dialog contain controls and options for inserting or changing the information around the root communication as well as the related parameters.

Root properties dialog:

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

For a closer explanation see Advanced Properties.

See also:

Dialogs


Channel Properties

Channel Properties

Channel Properties

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

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
UDP Socket Client: | The channel works as a UDP socket client
Serial: | The channel works as a serial client.

Set network properties

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

Set serial properties

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

See also:

Dialogs


Group Properties

Group Properties

Group Properties

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The Group Dialogs contain controls and options for inserting or changing the information around the group communication and all the related parameters.

Add Group / Group properties dialog:

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

For a closer explanation see Advanced Properties.

See also:

Dialogs


Device Properties

Device Properties

Device Properties

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

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

Special Properties:

From version 2.01.00.001 it supports decoding of objects in manufacturer specific area.

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 - 251 or 254. (Address 251 is reserved for M-Bus masters).

Secondary addressing

The most common method used 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. Blank space shall be filled up with the wildcard symbol 'F' and the interface itself will do this for you.

If two meters, from different manufacturers, should have the same number you need to put in extra information about the Manufacturer, Version and 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

Tag Dialogs

Tag Dialogs

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


Tag Properties

Tag Properties

Tag Properties

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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: | Read is default in the server
Write: | Only write possibilities
Read and write: | Read and Write possibilities.

See also:

Overview tag and data types


Tag Write Properties

Tag Write Properties

Tag Write Properties

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

This part describes how to configure the write properties in the Tag Properties Dialog. The write possibilities is a new function in version 2. If you have suggestions or if something doesn't work as you expecting please tell us so we can make the enhancements to your satisfaction.

Add Tag / Tag properties dialog:

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

In this first version TagType shall always be Value and DataType VT_BSTR.

Write Properties:

CI: | Control information field (CI field) is always 0x51
DIB + VIB | The DIF and VIF fields from CI field (not including CI field). Can be one or two delimited by ':'
Format | Value. Writing values from the OPC client
 | ManString. Writing a complete hex string from the OPC client.
Reset cache livetime after write: | With this checked the cache live time will be set to zero. This means a new meter read will be forced so the new written value can be read back without waiting for live time.

Example ABB DELTAplus electricity meter:

Byte No | Size (in bytes) | Value | Value (ManString) | Description
1 | 1 | 68 | 68 | Start character
2 | 1 | 07 | 07 | L-field
3 | 1 | 07 | 07 | L-field
4 | 1 | 68 | 68 | Start character
5 | 1 | 53/73 | 53/73 | C-field, SND_UD
6 | 1 | xx | xx | A-field, address
7 | 1 | 51 | 51 | CI-field, data send
8 | 1 | 01 | 01 | DIF size, 8 bit integer
9 | 1 | FF | FF | VIF next byte is manufacturer specific
10 | 1 | 13 | 13 | VIFE tariff
11 | 1 | xx | 04 | New tariff
12 | 1 | xx | xx | CS checksum
13 | 1 | 16 | 16 | Stop character

Example Value

With Format "Value" you can configure the hexstring containing the data information preceding the value itself. The server will build up the rest as Start characters, L-field, C, A and CI field. It will also calculate the checksum and put in the result together with the stop character. The above example is showing how to set a new tariff in the ABB Deltaplus electricity meter. The server is expecting the meter to give the answer 0xe5 when it has received and accepted the written information.

The OPC client now only has to send a value to the server. The server will make a control that the value is inside the allowed range. In the above example the server knows that the value shall have a range between 0 to 255 depending of that the DIF size is an 8 bit integer value.

Example Manual String

With Format "ManString" you have to send the whole string from the byte after CI-field including the value itself. The Server will convert the string from the OPC client and build up the rest as Start characters, L-field, C, A and CI field. It will also calculate the checksum and put in the result together with the stop character. In this case the server does not check the range, rather It's up to the client to make sure that the range is within allowed areas.

If the OPC client has a built in script language it can be used to build up different strings to a meter depending of the situation. You can send all these strings to the same meter tag.

Example Double input

The server also support double information for both Format "Value" and "ManString" The double information is delimited by a ':' sign. A typical case is if you need to send a password just before you are sending the value.

Please see below for an example.

Value
Dib/Vib: 01FF13:01FF13
User Input: 4:3

ManString
Dib/Vib:
User Input: 01FF1304:01FF1303

See also:

Overview tag and data types


Tag Scale

Tag Scale

Tag Scale

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 is not 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 (y = mx + b)
Ratio (k): | The k polynom ratio in the formula y = kx + m (y = mx + b)

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 Properties

Advanced Properties

Advanced Properties

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 Explorer topics in addition to text.

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.
Nr 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

Working Procedure

Working Procedure

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

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.


M-Bus OPC Server

M-Bus OPC Server

M-Bus OPC Server

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section will explain the working procedure around the configuration of the M-Bus OPC Server.


Creating an empty new project

Creating an empty new project

Creating an empty new project

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This part shows you the basics of creating a new M-Bus OPC Server project.

1.Select New in the File menu or click on New in the Toolbar to create a new project.

2.Select M-Bus OPC Server as new Project Type.

3.Select Add Channel... in the Project menu, or select Add Channel via the right hand mouse button pointed on the Server icon or click on Channel32 in the Toolbar to Add a new channel to the project.

4.If you want you can start with adding a Group or go direct to 5 add a device. Select Add Group... in the Project menu, or select Add Group via the right hand mouse button pointed on the selected channel or click on Group32 in the Toolbar to Add a new device to the channel.

5.Select Add Device... in the Project menu, or select Add Device viathe right hand mouse button pointed on the selected channel or click on Device32 in the Toolbar to Add a new device to the channel.

6.Select Add Tag... in the Project menu, or select Add Tag via the right hand mouse button pointed on the selected device or click on Tag32 in the Toolbar to Add a new read tag to the device.

7.Save your project. Two files will now be saved. The project file xxxx.xml and the configuration file xxxx.csv

8.Select Set to active project in the File menu.

9.Click on Run32 in the Toolbar for starting the monitor function.

See also:

Working Procedure


Creating a project from an old project

Creating a project from an old project

Creating a project from an old project

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 Folder32 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 Run32 in the Toolbar for starting the monitor function.

See also:

Working Procedure


Editing the project

Editing the project

Editing the project

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This part shows you the basics of editing a project.

1.Select Open in the File menu, click on Folder32 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 Run32 in the Toolbar for starting the monitor function.

See also:

Working Procedure


Monitor

Monitor

Monitor

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The PiiGAB M-Bus Explorer 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 Run32 in the Toolbar for starting the monitor function.

2.You can now look at the values.

3.Click on Stop32 in the Toolbar for stopping the monitor function.

See also:

Quality flags

Working Procedure


Upgrade from V1 to V2

Upgrade from V1 to V2

Upgrade from V1 to V2

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This part shows you the basics of upgrading a project from PiiGAB M-Bus OPC Server version 1 to version 2 handled in PiiGAB Explorer.

1.Select New in the File menu or click on New in the Toolbar to create a new project.

2.Select M-Bus OPC Server as new Project Type.

3.Select Import Configuration file in the Project menu and choose your old project .csv file

4.Now you can continue as a version 2 project.

See also:

Working Procedure


M-Bus meters to Modbus (900)

M-Bus meters to Modbus (900)

 Previous topic Next topic No expanding text in this topic Print this topic

M-Bus meters to Modbus (900)

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section will explain the working procedure around the configuration of the converting from M-Bus to Modbus for the 900 gateway.


Creating an empty new project

Creating an empty new project

Creating an empty new project

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This part shows you the basics of creating a new M-Bus meters to Modbus (900) project.

When you configure the converting of M-Bus meters to Modbus you will use the same configuration method as for the M-Bus OPC Server.

1.Select New in the File menu or click on New in the Toolbar to create a new project.

2.Select M-Bus meters to Modbus (900) as new Project Type.

3.Select Add Channel... in the Project menu, or select Add Channel via the right hand mouse button pointed on the Server icon or click on Channel32 in the Toolbar to Add a new channel to the project. The channel parameters is not used in 900 as they are only used for testing.

4.If you want you can start with adding a Group or go direct to 5 add a device. Select Add Group... in the Project menu, or select Add Group via the right hand mouse button pointed on the selected channel or click on Group32 in the Toolbar to Add a new device to the channel.

5.Select Add Device... in the Project menu, or select Add Device via the right hand mouse button pointed on the selected channel or click on Device32 in the Toolbar to Add a new device to the channel.

6.Select Add Tag... in the Project menu, or select Add Tag via the right hand mouse button pointed on the selected device or click on Tag32 in the Toolbar to Add a new read tag to the device.

7.Save your project. Three files will be saved. The project file xxxx.xml, the configuration file xxxx.csv and a cross reference file xxxx_Mbus2Modbus.csv. The cross reference file has the information about the relation between modbus registers and OPC Items.

8.Select Set to active project in the File menu.

9.Click on Run32 in the Toolbar to start the monitor function for testing the values before you upload the configuration files to 900.

10. Upload now the configuration file xxxx.csv and the cross reference file xxxx_Mbus2Modbus.csv to the 900 gateway through its web interface.

11. Further information about Modbus and 900 can be found in separate documents.

See also:

Working Procedure


M-Bus Ascii (900)

M-Bus Ascii (900)

 Previous topic Next topic No expanding text in this topic Print this topic

M-Bus Ascii (900)

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section will explain the working procedure around the configuration of the conversion from M-Bus to M-Bus ASCII for the Pi-900 gateway.

The M-Bus ASCII protocol is developed by PiiGAB with the purpose of helping users to an easy way of reading M-Bus meters without the need of an M-Bus driver installed on the computer.


Creating an empty new project

Creating an empty new project

Creating an empty new project

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This part shows you the basics of creating a new M-Bus Ascii (900) project.

When you configure the M-Bus meters to M-Bus Ascii you will use the same configuration method as for the M-Bus OPC Server.

1.Select New in the File menu or click on New in the Toolbar to create a new project.

2.Select M-Bus Ascii (900) as new Project Type.

3.Select Add Channel... in the Project menu, or select Add Channel via the right hand mouse button pointed on the Server icon or click on Channel32 in the Toolbar to Add a new channel to the project. The channel parameters is not used in 900 as they are only used for testing.

4.If you want you can start with adding a Group or go direct to 5 add a device. Select Add Group... in the Project menu, or select Add Group via the right hand mouse button pointed on the selected channel or click on Group32 in the Toolbar to Add a new device to the channel.

5.Select Add Device... in the Project menu, or select Add Device via the right hand mouse button pointed on the selected channel or click on Device32 in the Toolbar to Add a new device to the channel.

6.Select Add Tag... in the Project menu, or select Add Tag via the right hand mouse button pointed on the selected device or click on Tag32 in the Toolbar to Add a new read tag to the device.

7.Save your project. Two files will be saved. The project file xxxx.xml and the configuration file xxxx.csv.

8.Select Set to active project in the File menu.

9.Click on Run32 in the Toolbar for starting the monitor function for testing the values before you upload the configuration file to 900.

10. Upload now the configuration file xxxx.csv through its web interface.

11. Further information about M-Bus Ascii and 900 can be found in separate documents.

See also:

Working Procedure


Protocol description

Protocol description

Protocol description

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The core of the protocol is the OPC item which is built up from Channel, Device and Tag. If you have experience from OPC Servers this is probably well known. The reason for using this technique is that we have implemented the same dynamic M-Bus client in the PiiGAB 900 as we have in the PiiGAB M-Bus OPC Server. The positive consequence of this is that you can use the same configuration tool as for the OPC Server. You simply take the configuration file and upload it to the PI-900 instead of using it together with the OPC Server.

This also means that you can test your configuration file with the monitor function using the demo version of the OPC Server before you upload the file to the PI-900.

The only thing needed from the M-Bus ASCII client is the name of your tags which is the same as OPC Item. See example below..


Message structure

Message structure

Message structure

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The communication structure is a typical Request/Response message structure. You can choose if you want to have a Cyclic Redundancy Control (CRC) control for each message. CRC should normally be used if you are using RS232 or RS485. If you are using TCP or UDP a CRC is already a part of a higher communication layer and is therefore not needed although it is allowed.

For detailed protocol information please send an email to: support@piigab.se


Debug

Debug

Debug

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The PiiGAB M-Bus Explorer 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

Connection

Connection

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


Normal connection

Normal connection

Normal connection

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

M-Bus disconnection

M-Bus disconnection

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Udp disconnection

Udp disconnection

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Tcp disconnection

Tcp disconnection

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Tcp collision A

Tcp collision A

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Tcp collision B

Tcp collision B

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Meter examples

Meter examples

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


ABB Delta Meter

ABB Delta Meter

ABB Delta Meter

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

SVM F4

SVM F4

Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Kamstrup

Kamstrup

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

PadPuls M2

PadPuls M2

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Reference

Reference

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


Overview tag and data types

Overview tag and data types

Overview tag and data types

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Record

Record

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


Value

Value

Value

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Examples of Value field

PiiGAB M-Bus Explorer v2 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 Explorer 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 | I8 | UI8 | 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 | P | P |  |  | P1 | P1 | P1 | P |
Int164 | 16 bit integer | 0x2 | 2 | 2 |  |  | P | P | 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 |  |  |  |  |  |  | P | P |  | P1 | P1 |  |
Int64 | 64 bit integer | 0x7 | 7 | 8 |  |  |  |  |  |  | P | P |  | P1,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 | P |  |  | P | P | P |  |
BCD4 | 4 digit BCD | 0xa | 10 | 2 |  |  | P | P | 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 |  | 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.

8 VT_R8 can be used but the fraction part will only support up to 49 bits then an exponent will be shown.

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 | I8 | 8 bytes | -9223372036854775808 | 9223372036854775807
Int64 | Unsigned 64 bit integer | UI8 | 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

See also:

Overview data types

Data Type


Vib

Vib

Vib

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Unit

Unit

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Tariff

Tariff

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Storage

Storage

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Function

Function

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print 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

Datatype

Datatype

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Record

Record

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Manufacturer Specific

Manufacturer Specific

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Examples of Manufacturer Specific field

The PiiGAB M-Bus Explorer 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

Header

Header

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


Header

Header

Header

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Idnumber

Idnumber

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Manufacturer

Manufacturer

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Version

Version

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Medium

Medium

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Accessnumber

Accessnumber

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Status

Status

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Signature

Signature

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Configuration File

Configuration File

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section describes how the configuration file is built up.


Overview

Overview

Overview

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 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 first row is normally the object tag [ROOT].

The rest of the file is a four level hierarchy, with the following tags:

[CHANNEL]
[GROUP]
[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.

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>
[GROUP],LabC2,Part1,,,<object specific parameters>
[DEVICE],LabC2,Part1,Meter1,,<object specific parameters>
[TAG],LabC2,Part1,Meter1,Dr1_Value,<object specific parameters>
[TAG],LabC2,Part1,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:

LabC1.Meter1.Dr2_Value
LabC2.Part1_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.


Root

PiiGAB M-Bus Explorer Online Help

Channel

Channel

 Previous topic Next topic No expanding text in this topic Print this topic

Channel

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Parameter position in ObjectTag [ROOT]

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 | InitString | P
17 | (reserved) |
18 | (reserved) |


Channel

Channel

Channel

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 | InitString | P
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) |


Group

PiiGAB M-Bus Explorer Online Help

Channel

Channel

 Previous topic Next topic No expanding text in this topic Print this topic

Channel

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Parameter position in ObjectTag [GROUP]

Pos | Parameter Name | Inherit
0 | ObjectTag |
1 | ChannelName |
2 | GroupName |
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 | InitString | P
17 | (reserved) |
18 | (reserved) |


Device

Device

Device

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Parameter position in ObjectTag [DEVICE]

Pos | Parameter Name | Inherit
0 | ObjectTag |
1 | ChannelName |
2 | GroupName |
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 | InitString | P
17 | (reserved) |
18 | (reserved) |
19 | DeviceAddress |
20 | (reserved) |
21 | (reserved) |
22 | (reserved) |
23 | (reserved) |
24 | DeviceOption |
25 | Template description |


Tag

Tag

Tag

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Parameter position in ObjectTag [TAG]

Pos | Parameter Name
0 | ObjectTag
1 | ChannelName
2 | GroupName
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 | Format (writing)
37 | DIB + VIB (writing)
38 | (reserved)
39 | (reserved)


Parameters

Parameters

Parameters

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section describes all parameters in the configuration file.


Common

Common

Common

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section describes the common parameters.


Object Tag

Object Tag

Object Tag

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

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

Allowable Values:

[ROOT]

[CHANNEL]

[GROUP]

[DEVICE]

[TAG]

See also:

Parameters

Channel

Device


Root Name

PiiGAB M-Bus Explorer Online Help

Group Name

Group Name

 Previous topic Next topic No expanding text in this topic Print this topic

Group Name

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

Physical name of the root. The root has the only purpose to keep the basic default values for the inheritance of parameters.

See also:

Parameters


Channel Name

Channel Name

Channel Name

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

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

See also:

Parameters


Group Name

Group Name

Group Name

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

Physical name of the device group as it will appear together with Device Name in the namespace. The Group Name and Device Name is added together with a underscore between in the namespace e.g "group_device".

See also:

Parameters


Device Name

Device Name

Device Name

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

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

See also:

Parameters


Tag Name

Tag Name

Tag Name

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

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

See also:

Parameters


Description

Description

Description

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

Tag description, not used in the namespace.

See also:

Parameters


Common (Inherit)

Common (Inherit)

 Previous topic Next topic No expanding text in this topic Print this topic

Common (Inherit)

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section describes the common inherited parameters.


Retries

Retries

Retries

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Timeout

Timeout

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

RestartTime

RestartTime

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Delay

Delay

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

LiveTime

LiveTime

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

NrOfTelegrams

NrOfTelegrams

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

InitRead

InitRead

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 correctly use 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, sometimes need an additional application reset to switch to the first frame. This has to be done after the secondary selection. Some manufacturers 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

4 = Manual InitString

5 = SND_NKE + Manual InitString

6 = Slave Select + SND_NKE

No specific init packet

This selection is typical for Kamstrup meters.

SND_NKE (default)

If you have a multitelegram meter and have chosen 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.

Manual InitString

This string is a special string to send before any request is sent to the device. Typical use is if the meter is a multi telegram meter and it supports a command telling the meter to answer with one of the telegram as a single telegram meter.

SND_NKE + Manual InitString

Extra reset before the init string.

Slave Selection + SND_NKE

If you have problems to reset the telegram pointer in a meter when using secondary addressing this can be your choice.
1) Slave Select
2) SND_NKE to primary address 253
3) Normal Slave Select
4) REQ_UD2 to primary address 253

Default Value: SND_NKE (1)

See also:

Parameters

SubCode

NrOfTelegrams


SubCode

SubCode

SubCode

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


InitString

InitString

InitString

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

Special string to send before any request is sent to the device.

Allowable Values:

Default Value: The string is empty

See also:

Parameters


Channel

Channel

Channel

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section describes the channel parameters.


Comm Mode

Comm Mode

Comm Mode

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 Explorer.

See also:

Parameters


IPAddress

IPAddress

IPAddress

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

IP address e.g. 192.168.100.120

See also:

Parameters


PortNumber

PortNumber

PortNumber

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

TCP/UDP port e.g. 10001

See also:

Parameters


ModemName

ModemName

ModemName

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

See also:

Parameters


PhoneNumber

PhoneNumber

PhoneNumber

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

See also:

Parameters


ComPort

ComPort

ComPort

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

Communication port number.

Allowable Values: 1 to 256.

Default Value: Communication port 1

See also:

Parameters


Baudrate

Baudrate

Baudrate

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 Explorer. Regarding to standard EN 13757-2 maximum baud rate is 38400 baud.

See also:

Parameters


DataBits

DataBits

DataBits

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

StopBits

StopBits

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Parity

Parity

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

FlowControl

FlowControl

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

ReconnectTime

ReconnectTime

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 Explorer.

See also:

Parameters


Device

Device

Device

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section describes the device parameters.


DeviceAddress

PiiGAB M-Bus Explorer Online Help

Device Address

Device Address

 Previous topic Next topic No expanding text in this topic Print this topic

Device Address

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 - 251 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


DeviceOption

PiiGAB M-Bus Explorer Online Help

Device Option

Device Option

 Previous topic Next topic No expanding text in this topic Print this topic

Device Option

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

DeviceOption is used for anything that has an on/off structure.

Unsigned for string

Bit 0 is set to 1 in order to read out M-Bus objects in the manufacturer specific area.

See also:

Parameters


TemplateDescription

PiiGAB M-Bus Explorer Online Help

Template Description

Template Description

 Previous topic Next topic No expanding text in this topic Print this topic

Template Description

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

Template Description is used for special information about the specific template. This information has to be recorded when saving the template itself.

See also:

Parameters


Tag

Tag

Tag

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

This section describes the tag parameters.


DataRecord

DataRecord

DataRecord

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

The telegrams object or data record number.

Allowable Values:

Manufacturer dependent

See also:

Parameters


TagType

TagType

TagType

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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
48 = ValueSplit
49 = ValueSplitHigh
50 = ValueSplitLow

See also:

Parameters


DataType

DataType

DataType

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

20 = VT_I8

21 = VT_UI8

See also:

Parameters


AccessRights

AccessRights

AccessRights

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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 Explorer.

See also:

Parameters


Option1

Option1

Option1

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

Offset for manufacturer specific data.

Allowable Values:

Default Value:

See also:

Parameters


Option2

Option2

Option2

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Option3

Option3

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description
Option 3 is used for anything that has 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.

Reset cache livetime after write

Bit 5 is set to 1 (value 32) for for write options. Indicates that the meters cache livetime must be reset after a write.

See also:

Parameters


Polynom offset (m)

Polynom offset (m)

 Previous topic Next topic No expanding text in this topic Print this topic

Polynom offset (m)

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

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

Allowable Values:

Default Value:

See also:

Parameters


Polynom ratio (k)

Polynom ratio (k)

 Previous topic Next topic No expanding text in this topic Print this topic

Polynom ratio (k)

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

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

Allowable Values:

Default Value:

See also:

Parameters


Raw zero scale

Raw zero scale

Raw zero scale

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Raw full scale

Raw full scale

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Eng. zero scale

Eng. zero scale

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Eng. full scale

Eng. full scale

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Decimals if BSTR

Decimals if BSTR

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


Format writing

Format writing

Format writing

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

Number for the Write Properties Format.

0 = Value 0x00

1 = ASCII 0x01 (Not yet available)

2 = DateTime 0x02 (Not yet available)

3 = Date 0x03 (Not yet available)

4 = Manuel String 0x04

Allowable Values:

Default Value: Value

See also:

Parameters


DIB/VIB writing

DIB/VIB writing

DIB/VIB writing

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

Description

The string be saved here, which will be send before the value when Write Properties Format "Value" is used.

Allowable Values:

Default Value:

See also:

Parameters


Parameter inheritance

Parameter inheritance

Parameter inheritance

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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)
InitString | ""

See also:

Advanced Properties

Common (Inherit)


Quality flags

Quality flags

Quality flags

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The PiiGAB M-Bus Explorer 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

M-Bus Overview

M-Bus Overview

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Principles of operation

Principles of operation

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Transmission Parameters

Transmission Parameters

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Telegram Format

Telegram Format

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Communication Process

Communication Process

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Selection and Secondary Addressing

Selection and Secondary Addressing

Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Manufacturer Specific Data Block

Manufacturer Specific Data Block

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Data Information Block

Data Information Block

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Value Information Block

Value Information Block

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Variable Data Blocks

Variable Data Blocks

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Fixed Data Header

Fixed Data Header

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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

Variable Data Structure

Variable Data Structure

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

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


Fixed Data Structure

Fixed Data Structure

Fixed Data Structure

 Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function

The fixed data structure, besides a fixed length, is limited to the transmission of only two counter states of a predetermined length, which have binary or BCD coding. In contrast the variable data structure allows the transmission of more counter states in various codes and it also allows for further useful information about the data. The number of bytes of the transmitted counter states is also variable with this data structure. Contrary to the fixed structure, the variable structure can also be used in calling direction. For this reason the fixed data structure is not recommended for future developments.

To identify the fixed data structure, the number 73h for the control information field are used.

Identification No | Access No | Status | Medium/Unit | Counter 1 | Counter 2
4 Byte | 1 Byte | 1 Byte | 2 Byte | 4 Byte | 4 Byte

Fixed Data Structure in Reply Direction (transmit sequence from left to right)

The Identification Number is a serial number allocated during manufacture, coded with 8 BCD packed digits (4 Byte), and which thus runs from 00000000 to 99999999.

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

With the field Status various information about the status of counters, and faults which have occurred, can be communicated - see the table below.

Bit | Meaning with Bit set | Significance with Bit not set
0 | Counter 1 and 2 coded signed binary | Counter 1 and 2 coded BCD
1 | Counter 1 and 2 are stored at fixed date | Counter 1 and 2 are actual values
2 | Power low | Not power low
3 | Permanent error | No permanent error
4 | Temporary error | No temporary error
5 | Specific to manufacturer | Specific to manufacturer
6 | Specific to manufacturer | Specific to manufacturer
7 | Specific to manufacturer | Specific to manufacturer

Coding of the Status Field

The field Medium/Unit is always transmitted with least significant byte first and gives the medium measured for both counter states, and the units for each of the two counter states.

Medium | Code hex
Other | 00
Oil | 01
Electricity | 02
Gas | 03
Heat | 04
Steam | 05
Hot Water | 06
Water | 07
Heat Cost Allocator | 08
Reserved | 09
Gas Mode 2 | 0A
Heat Mode 2 | 0B
Hot Water Mode 2 | 0C
Water Mode 2 | OD
Heat Cost Allocator Mode 2 | 0E
Reserved | 0F


Applications of the FCB-mechanism

Applications of the FCB-mechanism

 Previous topic This is the last topic No expanding text in this topic Print this topic

Applications of the FCB-mechanism

 Previous topic This is the last topic JavaScript is required for expanding text JavaScript is required for the print function

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.