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.
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.
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.
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.
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:
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:
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.
Wrong COM port number in the program, damaged or miswired cable
M-Bus shortcircuited or populated by too many meters. Check the bus current, and use a more powerful meter if necessary.
Broken bus, wrong channel parameters in Merbon IDE (parity must be even), meters use different baudrate than that defined in the channel
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
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, email@example.com.
We will be happy to send you the most recent available prototypes per e-mail – please write to firstname.lastname@example.org.
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.