en
cz

M-Bus communication bus installation, part 3 - M-Bus in Merbon IDE

In the previous parts, we focused on design and installation of the hardware components. Now let’s look at the job of the application programmer. His or her task is to check if all meters are properly connected to the bus, and declare their variables in the application program.

There are two ways how to do that.

The first one is to insert meter prototypes from libraries into the project, enter their primary or secondary addresses provided by meter suppliers (heating, cooling, sanitary or electrical contractors), and check if all meters on the bus are communicating properly. However, this method usually fails because the meter suppliers are not able to provide the meter lists complete and in time, or the required meter prototypes are not available.

Therefore it is more efficient to go another way: to read the meters directly from the bus and import them to Merbon IDE. The development environment reads the M-Bus meter response and shows a list of all available variables for a particular meter. The variables required for further processing in the program are to be marked and imported. It is also good that the parsed telegram is always up-to-date (while a library prototype may be rather obsolete if the meter manufacturer had introduced changes in the firmware), and parsed meter data are always available (unlike a library prototype for a particular meter type).

Merbon IDE contains several useful functions for detection and integration of M-Bus meters. Next, we show how to detect, address, read and parse the meters, and how to create prototypes, or software models. They are then copied into the project, and addressed according to the real list of installed meters.

There are basically two hardware topologies possible:

A simple connection with no PLC is on the left. It may also be that the PLC is installed, but it shall run continuously to control the technology, and thus can not be used for meter detection because in the Commissioning mode its control algorithms would be stopped. There is Merbon Runtime (RT) running on the PC with Merbon IDE. Merbon RT is part of the installation, and emulates the PLC functionality for meter commissioning. Merbon RT uses the PC’s peripherals, so to connect the M-Bus, a USB to RS232 cable and RS232 – M-Bus converter are required (e.g. Domat R095). If a single meter or two are tested in the office, USB – M-Bus converters may be used, such as Relay Mikro-Master, just note that the number of meters to connect may be limited because of limited capabilities of the converter power supply.

In the right part of the topology drawing above, there is a PLC-based setup with connection over the Ethernet. A RS232 port of the PLC is used to communicate with the RS232 – M-Bus converter. This layout is more useful in the early stages of commissioning, when the PLC is not required to be in full control mode at all times. Remote connection is also possible, as the Ethernet network may be VPNed up to the engineer’s desk, so all newly added meters may be detected and added to the program at any time with no need for travelling and reconnecting of cables.

Create a new project in Merbon IDE, attach Merbon RT or a PLC, and insert a M-Bus communication channel. Remember to set the serial communication parameters properly: M-Bus requires Even parity with baudrate 2400 or 9600 bps, according to the default setting of the meters. Some meters use autobaud, which means that they detect the baudrate of the request, and respond with the same baudrate. Upload the project to the runtime or PLC, so that the program is able to use the communication channel.

In the M-Bus channel context menu there is a function Search M-Bus meters on network.

Launch it to switch the runtime to Commissioning mode and select if the meters shall be searched using primary or secondary addresses.

Searching primary addresses

This makes sense if the meters are configured so as to use unique primary addresses (ranged 1...250). Default meter address, as set by the manufacturer, is usually 1. This means that if the meters have not been configured before or at the installation, detection using primary addresses will not work: the responses would collide on the bus. Some meter types, such as Kamstrup Multical, have their primary address set as the last two digits of their serial number (secondary address). There is high probability in small networks that the primary addresses at one M-Bus line will be unique, and no collissions appear. Merbon IDE requests all addresses in the entered range, one after another, and if a meter responds, it is listed in the table of found meters.

According to the M-Bus standard, each meter – regardless of its primary address – should reply to a request sent to address of 254. This means that if there is only a single meter on the bus and its primary address is not known, the bus can be „searched“ only for address 254, which saves the scanning time: the software needs not to wait for tenths of timeouts.

Searching secondary addresses

The secondary address represents a different addressing concept. It should be unique for every meter, and unlike primary address, it can not be changed. It is a eight-digit decimal number, i.e. ranged 00000000 to 99999999. Scanning the entire range would apparently take an extremely long time. This is why Merbon IDE combines searching by groups of addresses with collission detection. The addresses are not just scanned one after another: they are queried using masks. The detection process may then look as follows:

Query: Is there a meter on the bus whose secondary address starts with 0...?
Response: (no response – timeout expires)
Query: Is there a meter on the bus whose secondary address starts with 1...?
Response: (illegible – more meters have responded at the same time and their telegrams collided)
Query: Is there then a meter on the bus whose secondary address starts with 10...?
Response: (no response – timeout expires)
Query: Is there a meter on the bus whose secondary address starts with 11...?
Response: (no response – timeout expires)
Query: Is there a meter on the bus whose secondary address starts with 12...?
Response: A single meter responds, reporting secondary address of 12345678.
However, there may be other meters on the bus with addresses 13..., 14..., etc., up to 19... The program then goes on:
Query: Is there a meter on the bus whose secondary address starts with 13...?
...
Etc. It is apparent that when a collission appears, the request goes „deeper“ and all the ten positions in the respective order are queried. There is always one of the three results:

  • no response – there is no meter in the queried range, the program continues with the next number in the order up to 9,
  • single response – there is only a single meter in the queried range, which replies with its full secondary address, and is recorded in the table of found meters,
  • collission of more responses – there are two or more meters in the queried range: the next lower order is searched one after another starting with 0, and the process follows recursively until the complete range is covered.

This algorithm is able to scan the complete bus within 10 to 15 minutes or less (depending on the address layout, timeout length, and number of retries, usually each request is sent three times). The progress is indicated through the green progress bar, and the communication can be checked also at the Rx / Tx LEDs at the M-Bus converter.

If Merbon RT is used, the search progress is displayed in its program window:

The number at right, such as 0x03ffffff, is the mask that specifies the queried address range. Here, it is „...whose secondary address starts with 03...“. Note that at the two latter meters which have their secondary addresses next to each other, the mask must go as far as into its maximum depth – to the last, lowest order. This is why numbers 05468560 to 05468569 must have been scanned.

After the scanning has finished, Merbon IDE shows the table with all found meters.

The first one has primary address of 2, the next two have 0 (most probably this is their default address). Note that the detection using primary addresses would not have been possible, as these two meters would collide. The Identification number is the secondary address, it is to be completed by zeroes from the left to achieve the 8-digits form.

Note that at some meters the secondary addresses do not match with serial numbers. These are mostly water meters with external M-Bus adapters which are snapped on the meters after the meters are installed. The serial number (secondary address) of the adapter has no relation to the meter serial number. If there is a floor plan or table with meter serial numbers, the numbers may not match the list of the scanned secondary addresses. Then it is necessary to see the meters again and jot down the serial numbers of their M-Bus adapters.

The primary addresses can be changed directly in the result table, with no special software necessary. The process is as follows:

  • focus the meter whose primary address is to be changed,
  • set its new address in the field below,
  • click the Set button,
  • to verify, click Back and scan the bus again.

Now for the most interesting part: insert the detected meter as a device into the communicaton channel.

If the found meter type already exists in the library as a prototype, check the box in the Import column. However, most probably the meter is not present in the library, so check the Create box for one or more meters. If there are more meters of the same type on the bus, it is more efficient to insert only one meter in the channel, select (and rename, if necessary) variables to import, and copy this device into more instances and only change each meter’s address. Of course, if a meter type is to be deployed at another project, it can be saved in the library as a library prototype.

The difference is that copied meters are mutually independent devices and when edited (e.g. if some variables are removed) the other meters in the project are not affected, while if a prototype is edited, all instances of the same type are affected by the changes. The instances are references to the library prototype.

For every meter that was checked as Create there will be displayed a table with all parsed variables. All these data are contained in the meter’s response to a general query, Merbon IDE parses the reply according to the M-Bus protocol standard, and displays variable names, their formats, units, etc.

At the meter on the above screenshot, energies for two tariffs and actual power were selected. After import there is a device added to the channel and respective global variables are created. The generic name (Meter_2) is to be renamed to the real meter name, such as Charger_box_312.

Edited project can be uploaded to the PLC and run. Start debug to see the current meter values in the PLC Value column.

Note that when a meter is generated, the Use secondary address option is selected by default. If primary addresses shall be used for communication, this property must be changed here (which may be also done for more variables together).

If the bus has been commissioned before, the meters do not need to be detected. The meter can be created from real device in the context menu of the channel. The selection of variables follows in the same way as above, just the primary or secondary address is entered directly.

There are following recommendations for naming of the meters and variables:

  • The meter name should identify the consumption point, and the name should be informative for users. Typically, it is an apartment number, rental unit, supplied circuit, etc.
  • The variable name should contain the measured energy type.
  • Remember to enter the physical unit in the global variable properties.
  • If a transform is required, it is to be configured in the data point properties in the device. For example, the energy in the meter above is read in Wh to achieve higher resolution, while it will be useful to read it in kWh to fit numerically with the meter LCD display value. Use linear transform with K = 0.001.
  • It may be useful to read also the meter serial number as a variable (if available) to check that the meter position is that entered in the floor plans.

Possible problems and their solution:

No meter detected, the M-Bus converter does not send data when scanning (LED Tx dark)

Wrong COM port number in the program, damaged or miswired cable

Red LED permanently on at the M-Bus converter

M-Bus shortcircuited or populated by too many meters. Check the bus current, and use a more powerful meter if necessary.

Converter sends data when scanning, no response from meters

Broken bus, wrong channel parameters in Merbon IDE (parity must be even), meters use different baudrate than that defined in the channel

Converter sends data when scanning, red alarm LED is on as a response

Bus overloaded (too many meters connected) – use a more powerful converter or scan only a part of the bus; address collission when detecting with primary addresses (the meters have their default primary addresses) – use secondary address detection

Some variables do not appear in the list of parsed variables

The meter may require special communication, there may be problems with telegram segmentation, etc. Please send the communication between Merbon IDE and meter (port monitor data) and the meter type to Domat Control System technical support, support@domat.cz.

I want to engineer my project before going to site, but I do not have the prototype library

We will be happy to send you the most recent available prototypes per e-mail – please write to support@domat.cz.

The value is loaded, but it is meaningless or -1, etc.

Data type probably doesn't match. The default, automatically assigned integer data type is DINT, the range of which may not be sufficient sometimes and is also signed (it can also take negative values, which does not make sense for cumulative quantities). Change the ST type in the Data Point Properties to UDINT or ULINT.