Also, please provide the manufacturer and model number of your energy meter. Perhaps the documentation you have is out of date and there is newer Modbus documentation more applicable to the firmware actually running on the meter.

 

Also, please provide the manufacturer and model number of your energy meter. Perhaps the documentation you have is out of date and there is newer Modbus documentation more applicable to the firmware actually running on the meter.

Its an HGR41EW energy meter from Hager/Rayleigh, but the spec sheet is for HGR43 because I can't find a copy for the 41 online. Ive already emailed and called the company, but Im waiting for them to get back to me :/
If you somehow manage to find it, good on you, because in googling "hgr41ew filetype: pdf" all I found besides this short overview was German academic journals.

 

No luck here either, but I did find documentation for a possibly related meter:
https://www.rayleigh.com/media/uploads/OP_RI-F400-G_OP585-V01.pdf

In that document, they do use 5-digit reference address with 0-based addressing (as I mentioned, something I've never seen before). The telling sign is they have a Hex Address column which is always 0-based.

Therefore, based on this, it's likely the HGR41EW uses the same convention, so Start Address 30000 (using their absurd 5-digit, 0-based reference notation) really means Input Register 1 (in 1-based notation) or 30001 in normal 5-digit reference notation.

So in ModScan, select Input Register as the type, subtract the 30000 offset from Hager's documented Start Address, and add 1. For example, for Current 3-Phase Average, the SYS Start Address is listed as 30022, therefore you would enter 23 in ModScan.

As a note, one pitfall when using 32-bit registers where you are unsure of whether the address is 0-based or 1-based is unwittingly reading across 32-bit registers. You may see seemingly correct values, but those values may be comprised of the upper half of one 32-bit value and the lower half of the next 32-bit value, and just happen to be correct because of the current values of the two 32-bit parameters.

 

No luck here either, but I did find documentation for a possibly related meter:
https://www.rayleigh.com/media/uploads/OP_RI-F400-G_OP585-V01.pdf

In that document, they do use 5-digit reference address with 0-based addressing (as I mentioned, something I've never seen before). The telling sign is they have a Hex Address column which is always 0-based.

Therefore, based on this, it's likely the HGR41EW uses the same convention, so Start Address 30000 (using their absurd 5-digit, 0-based reference notation) really means Input Register 1 (in 1-based notation) or 30001 in normal 5-digit reference notation.

So in ModScan, select Input Register as the type, subtract the 30000 offset from Hager's documented Start Address, and add 1. For example, for Current 3-Phase Average, the SYS Start Address is listed as 30022, therefore you would enter 23 in ModScan.

As a note, one pitfall when using 32-bit registers where you are unsure of whether the address is 0-based or 1-based is unwittingly reading across 32-bit registers. You may see seemingly correct values, but those values may be comprised of the upper half of one 32-bit value and the lower half of the next 32-bit value, and just happen to be correct because of the current values of the two 32-bit parameters.

I have good news! They got back to me, with a spec sheet. I tested some of the addresses, and Im getting data although it doesn't make a lot of sense. I don't have time to test everything today, so I'll update this post with more info when I start testing again tomorrow.

 

Thank you patrickduis, jschulze, and David_2! I've finally got real, correct values for power. It turns out the most recent hurdle was just not having the right addresses, and once I got the spec sheet, everything started lining up. You all were an immense help with figuring out the addressing, despite the energy metering company's best attempts to obstruct any understanding of their modbus standards. I'm a total beginner in this field, and I'm glad to have stumbled onto this forum, y'all are great.

There are some things left, like figuring out why I'm getting errors half the time (down from 90% using ModScan, so big improvement), and a few values aren't what they're supposed to be, but that might be down to certain CT/PT scaling factors being left out. But the most annoying part is (seemingly) over

 

@pineowple,

A former contributor was fond of saying, "The best thing about standards is: There are so many of them to choose from!"

And when it comes to MODBUS that is definitely the truth; sometimes it's just one little thing which causes most data to be 'jumbled', but then it can also be that "simple" memory address map and the shifts that can cause horrible problems until the 'author' of the MODBUS standard 'fesses up to how they modified the standard for some unknown and never-to-be-revealed reason. (Let a coder get hold of a standard from another company--even one which has been widely used for a long time; they will always "find" a way to improve the standard.) It's one of the reasons I sent all the MODBUS questions/issues I encountered to the 'author' at the factory and didn't waste any of my time on trying to resolve issues that I wasn't privy to how the standard was (re-)written. Made my life a lot simpler.

@patrickduis, @jschulze, and @David_2 are really great with most typically encountered MODBUS implementation issues and debugging them quickly.