When communicating via Ethernet the form of the transferred data is the same as for M-BUS for serial link. The essential condition is that the M-BUS/Ethernet converter does no modifications to the transferred data.
The driver supports the usage of both PmaCommMsg and PmaCommGroup objects. For common data transfers, it is easier to use the PmaCommGroup object.
For easy integration of this driver into the application it is handy to use: Preconfigurations in group "M-BUS communication protocol"
| Unit: | Physical quantity: |
|---|---|
| GJ | Energy |
| W | Power |
| m3 | Volume |
| kg | Mass |
| m3/h | Volume Flow |
| kg/h | Mass Flow |
| C | Temperature (Forward, Return, Difference, External) |
| mbar | Pressure |
| V | Electric Voltage |
| A | Electric Current |
| second count | Averaging Duration, Actuality Duration .. |
| day count | On time, Operation time |
The binary date formats (TimePoint) are converted into a value of the Date type. Other values (counter, serial number ..) are not being converted.
In the PmaCommGroup object, the data items are configured by specifying the item type (Temperature, Volume ..). The driver then finds the desired data in the received message (if present) and saves it into the data item.
The "Common meter/Reading of generally configurated data" message in the PmaCommMsg object is used for common reading of the data. The designer can setup the data of the PmaCommMsg object exactly according to the meter type. If the designer does not know what the meter provides, then it is possible to set in this message to write received data into the INFO system. According to this listing, the designer can then set up the data of the object.
| Baud rate | 300 Bd. This rate should be supported by all meters. Then according to used meters the rate can be increased. Next recommended rates are: 2400 Bd, 9600 Bd, 38400 Bd. Many meters can be adjusted to some rates, even if they were set to another rate. Caution: converters often support only the rate of 9600 Bd. |
|---|---|
| Number of data bits | 8 (it is prescribed by M-BUS standard) |
| Parity | EVEN (it is prescribed by M-BUS standard) |
| Number of stop bits | 1 |
| Number of repeats after unsuccessful transmission | 0 (or greater). In order to conserve battery power, these meters go to sleep mode and so it is necessary to wake it up before the communication. The most simple solution is to set Number of repeats after unsuccessful transmission configurator to the value 1 (or more, probably the best value is 2) and Response receipt timeout to the value from 500 to 1000 ms. So the first sent message will wake up the meter and the following messages are then processed correctly. |
| Timeout between receiving 2 chars | 100 ms (or greater) |
| Delay between receive-send | 0 ms (or greater) |
| Filter ECHO chars | No. It depends on M-BUS/RS232 converter. |
| RTS flow control | log.0 |
| DTR flow control | log.0 |
| TCP/UDP port number | by converter M-BUS/Ethernet settings |
|---|---|
| Ethernet transfer type | by converter M-BUS/Ethernet settings |
| Response receipt timeout | 1000 ms (or greater). Only for serial link. The time (in milliseconds) the driver is waiting for the response on sending the message. If no response comes during this time, then the transfer of the message is terminated (the onEndOfTransfer event is triggered with error 24 or 66). |
|---|
To read the data from meters more often than 1 minute isn't worth. If the data are read more often than 4-30 seconds (it depends on the meter), then the meter doesn't send the data.
The variables in the PmaCommGroup object (or even better the variables in the PmaData object with ExtComm data extension) can be of arbitrary number, type and order. The driver uses optimalised internal communication messages for reading the data from the device.
All variables are read (if the "Data refresh enabled" configurator is checked). Writing variables into the device is not enabled for this driver.
In one PmaCommGroup object, the data items can be defined (variables on the "Data" page or ExtComm data extensions) for multiple meters simultaneously.
Sometimes it may be more advantageous to let one PmaCommGroup object represent a single meter - in such case the meter address can be defined in the "Default meter address" configurator and then the address needs not to be defined for each data itema (only the text "saD.." is defined - see further). This way it is easier to change the meter address just on one place.
ItemId is the text identifier of the item that is used for addressing the value in the device. The ItemID configurator tells the driver how to receive or send the item value. The text can be written manually, or it can be assembled in the window opened by the button to the right of the configurator. Macro expression can be used for input (it is evaluated after starting the application).
Examples of identifier syntax:
The text always begin with "sa" (Slave/Station Address) followed by a decimal address of the meter. The "D" (=default) character can be used instead of specific address, which means that the meter address is taken from the "Default meter address" configurator.
The identifier following after the comma specifies the area of desired data (defines the type of M-BUS message, causing the meter to send the data from desired area). The possible values are as follows:
The identifier following the comma specifies the desired value in selected area. The meter sends all the data from selected area simultaneously. The desired value can be identified by index (Index) or by value specification (additional options):
The identifiers following the comma define more specific values and are optional.
| Default meter address | The address defined here can be used for definitions in the "ItemID" configurator for the variables in this object (i.e. the variables on the "Data" page or in the ExtComm data extensions). The address can be entered in ItemID: - as for example sa1... - then the value will be read from the meter with address 1. - or saD... - the "D" character means default, and the address is taken from this configurator. This parameter can be modified and read in the script during runtime by methods: SetSpecParam("SlaveAddr") and GetSpecParam("SlaveAddr"). |
|---|
| Meter type | Meter type delection. It is recommended to select only "Common meter" here. Other options are considered obsolete and it is recommended to replace these by the PmaCommGroup object. Kamstrup MULTICAL - obsolete ABB SVM - obsolete Danfoss INFOCAL 5 - obsolete Landis ULTRAHEAT - obsolete Supercal SONTEX - obsolete CALMEX VKP - obsolete |
|---|---|
| Message type | Required message type for the corresponding meter. The following list contains messages only for Meter type = Common meter. |
Initialization of the meter (message type SND_NKE). It is used first of all for the initialization of control so-called FCB flag (see FCB flag handling) that serves to the meter as the information about the right sequence of the sent messages. It is recommended to call this message when the application starts and also when an communication error appears (see the pEvent.Error parameter in the PmaCommMsg.onEndOfTransfer event).
The address of the meter can be set exactly (value from 0 to 250) - then each meter confirms (responds) whether it took due note of the command. It is suitable also to use the universal address 255. Then all connected meters are initialized at once without any confirmations (see Address).
Sending of this message to the meter causes reset of application variables in the meter (message type SND_UD). What actually happens in the meter depends only on the meter. Majority of the following meters doesn't need this message. This message is used by: Communication with meters Sontex SUPERCAL.
This message will turn the slave station into so-called selected) state. After the station is turned into the selected state, then it communicates as if its address was 253 (see Address), until any other station is turned into the selected state. The station is selected by so-called secondary address, which is defined by following: IdentNr = identification number of the meter, Manufac = identification number of the manufacturer, Version = meter version, Medium = measured medium. These items are defined on the "Data-sent" page and can be received from the meters, for example, by the "Common meter/Reading of generally configurated data" message when starting up the meter.
Addressing stations by the secondary address is handy for for example:
(message type SND_UD). Using this message won't be probably needed in most cases because the rate can be set directly in the meter and it is not advisable to change it during run of the application. Many meters can also adjust themselves to more baude rates, even if they were set to another rate.
The message designed for reading data from meters (message type REQ_UD2). It is used only in special cases - for standard data reading it is better to use the PmaCommGroup object - see The communication description by the PmaCommGroup objects.
When reading standard data from a meter, the response does not contain only values, but also flags of the value type (flow, energy, power, etc.), flafs of the unit type (e.g. kWh,J,0.001kWh..), flags about the tarif type or memory number, etc. If you know the meaning of the values in the response from the meter, then you can configure and name items, into which the received values are stored, on the "Data-received" page by yourself. If you do not know what the meter sends, then you can use the "Common meter/Getting a complete list of gauges measured quantities" message type.
Except the standard data the meter can send the specific data that don't have the flag about the meaning and the unit any more. These data are always located after the standard data. If you know the meaning of these data (e.g. from the meter documentation), then even these data can be received in the message. It is sufficient to define next variables of corresponding types (Byte, Integer, Long) after already created variables on the "Data-received" page and then the value from the received message is stored in the corresponding variable without any conversion. To be more specific, it is possible to define if the specific data are stored in the message in binary form (i.e. no conversion is needed) or in BCD code. If the specific data are in BCD code, then you can already mentioned variable "DataAttr" set to 1, and the driver converts the value into the binary form (it would be also possible not to convert it and to use the Pm.TransformValue method but it would be much more complicated).
Some meters send data in more messages in the exact sequence. Even receiving the data can be done by this type of the message. You must configure more PmaCommMsg objects to individual messages, fill it the data respectively and then send the messages one after the other (by the PmaCommMsg.Run method). For these types of transfers the meter uses FCB flags (see FCB flag handling) and that's why the "FcbAttr" variable has to be set to 1. By this way some meters solve first of all reading the history. If you didn't set "FcbAttr" to 1, then you would have read only the 1st message (where there are current values only) all the time. If "FcbAttr" is set to 1, then the meter sends all messages it has - and sometimes it has really lots of them. For example the ABB SVM meter has stored historical data in 128 messages (fortunately of the same type, so that it is possible to read them by one object).
This message is meant for designers who know the M-BUS protocol. It is possible to configure the message (separatelly for receiving and separatelly for sending) from the "SingleCharacter", "ShortFrame", "ControlFrame" and "LongFrame" types, which are 4 possible message types of the protocol on the lowest level with setting the CField, AField and CIField values by the designer and with setting the user data. It is also possible to select the message type "Pure Bytes", which allows to send/receive the data withou any transformation of the protocol.
This type of the message will be used very rarely for special and test purposes.
This message creates a list of all items that can be read by the corresponding data message type (from message FCB with flag 0 or 1).