Today is...
Monday, October 21, 2019
Welcome to, the global online
community of automation professionals.
Featured Video...
Featured Video
Wiring and programming your servos and I/O just got a lot easier...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Energy Meters and Data Register Reading Issues
Difference in readings between energy meter and its data register

We have a data reg and meter for the energy calculations of power being transmitted to the client. I have noticed the difference in the readings of energy meter and its data reg. Data reg is reading more than the meters itself.

What could be the reason behind this?
Is data reg faulty? because meters are calibrated every two years.

If anyone know, then share your experience.

1 out of 1 members thought this post was helpful...

There are typically hundreds of values in these energy meters. The first thing I'd investigate is whether one is reading the correct register.

This thread from a couple years back alludes to a problem reading floating point values

There was another thread on the a similar topic where the read value was close, but not exact, but I can't find that thread.

As I recall the problem involved getting a close, but not exact value for a floating point number.

The first register was a 16 bit word from one FP value and the 2nd 16 bit word was a different FP value from the adjacent register. Most masters have a choice of two methods for interpreting Big Endian vs Little Endian data, and when interpreted with the 'wrong' alternative word swap method, the resulting value was very close but not exactly the same as expected value. I assume that the adjacent data values were relatively close in value for this to happen.

If this is the actual problem, reading/using one register lower as the 'start' word for the value and changing the method of interpreting FP to the alternative would provide the correct number.

I assume you mean that you are reading a register in the meter to import the data to scada or some other database? If this is the case, then the only two answers I have are a configuration error or a bad meter. What format is the data in? What protocol is reading the data?

Dear Freakboynv2000, thank you for your answer.

>I assume you mean that you are reading a register in the
>meter to import the data to scada or some other database?
>If this is the case, then the only two answers I have are a
>configuration error or a bad meter. What format is the data
>in? What protocol is reading the data?

We have quantum meters installed at our site. The meters read MWHrs and MVARhrs and we use data reg to save the readings and print them at 0000 hrs daily. They are connected via TCP/IP.

The main purpose of the data reg is to store the readings of the meters, multiply the current and voltage with some technical formulae and show the results on the printer daily and we take monthly readings also from the data reg by connecting the laptop. These readings are for how much we import the energy from the grid and how much we exported to the grid and some more.

Now the problem i am facing is that i took spot readings of the meter at 0000 hours and compare the data reg printed values with them and there was a difference which should not be there. Data reg is reading more than the spot values of the meter. As far as meters are concerned they are calibrated many times by 3rd party and found within tolerance range. But i compared the data of previous years and still found the same issue.

What you suggest can be the problem? Is there any issue with registers which are storing the data?

You probably have a configuration, scaling or addressing problem. The data can be stored in several formats that are acceptable to Modbus. If this information is incorrect then the values will not display properly. If the data is raw and doesn't require scaling then you can rule that out. It could be that the reg is reading the wrong addresses and therefor getting the wrong data. You will have to eliminate these issues one at a time until you find the culprit.