I'm reaching out to seek assistance with a technical issue I'm experiencing with ISTA WATER METER MBUS MODULE.

Recently, I've encountered some issue while integrating ISTA water meter Mbus module to PXC001.E.D using Relay PW60 level converter.

1. The reading shown on the water meter and the reading shown in the software are not the same. But still am getting some data nearby on mbsheet and its increasing linearly.

2. A few hours after software integration of the water meter loses its communication, the energy meters of another manufacturer connected in the same loop are working properly. There are 6 to 8 water meters and 3 to 4 energy meters are connected in one loop, similarly 3 loops will connect into one Mbus to RS 485 converter.

we've tried the following steps
1. Less number of water meters in one loop.
2. Water meters are connected as stand alone by removing the energy meters from loop
3. Connecting all devices in the loop by avoiding star connection.

Unfortunately, the issue persists. The software we use for scanning and integration are
1. MB Sheet.
2. Siemens Xworks Plus.

 

1. The reading shown on the water meter and the reading shown in the software are not the same.

1. Flow is dynamic, so an instantaneous flow rate on the meter might have changed by the time a Modbus poll picks up the value and shows it.

3. Modbus, like other any other digital protocol I'm aware of, throws away bad or corrupted messages. Only the contents of a complete message with a valid CRC field is passed along to the application. Which means that the data binary bits in the Modbus message received by the client, are the same data binary bits that were sent by server/slave.

Since the data's binary bits are same on each end, any discrepancy in the interpreted values could be

- faulty interpretation of the binary bits due to scaling
- faulty interpretation of the binary bits due to word/byte issues for long integers or floating point values
- "stale" data from a previous PLC cycle or loss of comm with a node in a wireless network
- mistakenly reading the wrong register and therefore getting the wrong data with expectations that it's something else.
- vendors have been known to have firmware issues. But a firmware problem that results in a mismatch of a displayed variable and that same value in a Modbus register seems to be a low probability, given the prominence of a displayed value (compared to an obscure value that is rarely ever checked). The vendor likely got that one right.

 

2. A few hours after software integration of the water meter loses its communication. There are 6 to 8 water meters

Does only one water meter exhibit the intermittent communications failure?

Does that failure affect any other devices on the same RS-485 bus?

 

@David_2, note that the meter the OP has uses the M-Bus (Meter Bus) protocol, not Modbus. M-Bus has its own unique 2-wire physical layer where the master modulates voltage to indicate Logic 0 and Logic 1, while the slave(s) modulate current. This is the reason for using the Relay PW60 media converter. Additional details can be found in the spec here:
https://m-bus.com/assets/downloads/MBDOC48.PDF

It's been a long while since I've worked with M-Bus, but it would be helpful if the OP can provide any M-Bus documentation for the meter (ISTA doesn't seem to have any on their website).

1. Regarding the different reading values, can you give a numeric example of what you're seeing on the meter, in the software, and in mbsheet?

What mode do your meter and software use/support for multibyte records? There is a CI field in M-Bus packets and in this field there is a Mode bit (bit 2) that indicates Mode 1 (Mode bit = 0) or Mode 2 (Mode bit = 1). Mode 1 indicates the least significant byte of a multibyte record is transmitted first, while Mode 2 indicates the most significant byte is transmitted first.

Are you able to provide the raw hexadecimal output from the meter?

2. Regarding the meter losing communication, have you confirmed and double-checked that no slave devices are configured for the same address? Does the meter remain responsive locally (via menu/screen, etc. on the meter itself) when the communication issue occurs? Are the meters powered and grounded properly according to the manufacturer's recommendations? Does the issue still occur if you wire your PW60 meter to only a single water meter?

 

Thanks for clarification. I thought Mbus was his shorthand for Modbus.

 

2. A few hours after software integration of the water meter loses its communication. There are 6 to 8 water meters

Does only one water meter exhibit the intermittent communications failure?

Does that failure affect any other devices on the same RS-485 bus?

No All the water meter stops talking, but same time the electric meter in the same loop replaying fine

 

@David_2, note that the meter the OP has uses the M-Bus (Meter Bus) protocol, not Modbus. M-Bus has its own unique 2-wire physical layer where the master modulates voltage to indicate Logic 0 and Logic 1, while the slave(s) modulate current. This is the reason for using the Relay PW60 media converter. Additional details can be found in the spec here:
https://m-bus.com/assets/downloads/MBDOC48.PDF

It's been a long while since I've worked with M-Bus, but it would be helpful if the OP can provide any M-Bus documentation for the meter (ISTA doesn't seem to have any on their website).

1. Regarding the different reading values, can you give a numeric example of what you're seeing on the meter, in the software, and in mbsheet?

What mode do your meter and software use/support for multibyte records? There is a CI field in M-Bus packets and in this field there is a Mode bit (bit 2) that indicates Mode 1 (Mode bit = 0) or Mode 2 (Mode bit = 1). Mode 1 indicates the least significant byte of a multibyte record is transmitted first, while Mode 2 indicates the most significant byte is transmitted first.

Are you able to provide the raw hexadecimal output from the meter?

2. Regarding the meter losing communication, have you confirmed and double-checked that no slave devices are configured for the same address? Does the meter remain responsive locally (via menu/screen, etc. on the meter itself) when the communication issue occurs? Are the meters powered and grounded properly according to the manufacturer's recommendations? Does the issue still occur if you wire your PW60 meter to only a single water meter?

1-let me check about hexadecimal value,
2- we confirm primary address, they are unique in each loop

 

1-let me check about hexadecimal value,
2- we confirm primary address, they are unique in each loop

Dear , Please find the details of two different water meter for your reference

 

Thank you for the additional data.

In your M-Bus Data table image, for address 20, item No. 3, volume shows a value of 1030, but is actually scaled incorrectly. It should be 1.03. Similarly, for address 21, the volume shown is 576 but should actually be 0.576.

There is an online M-Bus decoder here that you can use to verify (I find the "Raw" output option easier to match against your table instead of the "Postprocess" output option):
https://dev-lab.github.io/tmbus/tmbus.htm

Can you give a numeric example of what you're seeing on the meter, in the software, and in mbsheet that do not show the same value? Is it just that the volume readings differ by a factor of 1,000 as I described above?

 

Thank you for the additional data.

In your M-Bus Data table image, for address 20, item No. 3, volume shows a value of 1030, but is actually scaled incorrectly. It should be 1.03. Similarly, for address 21, the volume shown is 576 but should actually be 0.576.

There is an online M-Bus decoder here that you can use to verify (I find the "Raw" output option easier to match against your table instead of the "Postprocess" output option):
https://dev-lab.github.io/tmbus/tmbus.htm

Can you give a numeric example of what you're seeing on the meter, in the software, and in mbsheet that do not show the same value? Is it just that the volume readings differ by a factor of 1,000 as I described above?

Dear
As attached photo above the actual reading of first one is 1156 m3 , and second one is 699 m3

 

I suspect the readings shown via M-Bus are correct, it just may be that those readings were from the past. Take a look at the "time point" values immediately after the "volume" values. Perhaps those are supposed to indicate when the volume was sampled. I would guess that the first "time point" item (item No. 2) is the current date and time set on the meter and that the "time point" item immediately after the volume reading (item No. 4) may be the date the sample was taken. Now this may indicate some issue in the configuration or volume sampling of the meter, as the date shown for item No. 4 is December 31st 2024.

Do you have a user's manual for this meter? Some M-Bus devices are configurable for what data that they send in response to the the REQ_UD2 M-Bus request. Is there a way to trigger the meter to sample its current reading to output to M-Bus? Perhaps this is triggered via an M-Bus command or perhaps it's configured for a certain period.

 

I suspect the readings shown via M-Bus are correct, it just may be that those readings were from the past. Take a look at the "time point" values immediately after the "volume" values. Perhaps those are supposed to indicate when the volume was sampled. I would guess that the first "time point" item (item No. 2) is the current date and time set on the meter and that the "time point" item immediately after the volume reading (item No. 4) may be the date the sample was taken. Now this may indicate some issue in the configuration or volume sampling of the meter, as the date shown for item No. 4 is December 31st 2024.

Do you have a user's manual for this meter? Some M-Bus devices are configurable for what data that they send in response to the the REQ_UD2 M-Bus request. Is there a way to trigger the meter to sample its current reading to output to M-Bus? Perhaps this is triggered via an M-Bus command or perhaps it's configured for a certain period.

Dear,
I have only this document of the water mater