Integrating Modbus protocol for revenue meter

K

Thread Starter

Keith Mistry

We manufacture 3-phase revenue grade meters with embedded ethernet connectivity. Internal table structure is based on the ANSI C12.19 data tables, which is also an open protocol. We are planning to integrate the Modbus protocol.

Our first issue is that most of the information is read-only such as current billing values, last reset values, voltage, current and power factor by phase, load profile data etc. and the quantity of values far exceeds 125. Most are floating point.

So the question is how to do an optimal register mapping?

The second question is how to present the time series data such as load profile data. A single day's read is 96 interval readings with time stamp and status values for each interval. This is per channel. We are supporting 2 channels but can easily go to 5 or more.

Any direction and guidance would be appreciated.

Regards,

Keith Mistry
 
G

Greg Goodman

Keith,

Here are some suggestions. Please don't be insulted if some of them are pretty obvious.

1. group the readable data in logically related chunks. one factor to consider in grouping data is volatility.

configuration values are often grouped together, since they don't typically change at runtime, other than at a user's instigation.

other data may change at different intervals, or be interesting to groups that typically need the data at different intervals. alarm and fault indicators, for instance, are interesting to the SCADA system at high frequency; billing information, on the other hand, might only be collected once a day.

2. your time series data can be handled in several ways, each with its pros and cons.

a. the simple way is to assign a block of registers for each channel. each sample consists of several adjacent registers containing a reading and the associated timestamp and status. if we assume a floating point reading, and a register each for the timestamp and status, that's 4 registers per sample, times 96 samples, per channel.

pros: easy to implement, easy for the user to understand, and supported by even the simplest of Modbus masters.

cons: it's a lot of registers, and implies a large polling configuration for the master. it doesn't scale efficiently, and requires a large update to the register map documentation any time you come out with a model that supports more channels, or more frequent sampling.

b. a more sophisticated way is to use Modbus's write/read operation (func 23) to return any request for samples from a single span of registers. define a command register (say 40101) and a set of response registers (say 40001-40100). the master writes the channel and starting sample number requested into register 40001 (say, channel in the MSB and sample number in the LSB), and reads back up to 100 registers (25 samples) from the response registers. the number of read registers specified in the request determines the number of samples returned, starting with the one specified in the command register. (if you want, you can return a 'bad address' error if the number of requested registers is not a multiple of 4.)

pros: scalable, lends itself to efficient programmatic treatment (by, for instance, datalogging software that simply needs to fetch the values and stuff them into a database)

cons: more complicated to implement on the device side (i.e. you need a smarter Modbus comms handler to implement request-sensitive mapping of data to registers), not easily handled by HMIs with simplistic Modbus implementations

Hope this helps,

Greg Goodman
Chiron Consulting
 
S

Scott Henson

You are wise to consider a standard for your Modbus register mapping. Nothing is more annoying than to try to integrate products from a single company where every device or different versions of the same device use different structures. (Cutler-Hammer is the worst.)

You may want to look at the Modbus register mapping used by Square D PowerLogic http://www.powerlogic.com or Power Measurement http://www.pwrm.com since they have been producing 3-phase energy meters with Modbus for years.

I would highly recommend keeping the useful data as 4x Holding Registers. Modicon PLCs and some other Modbus masters have a difficult time reading coils (0x) or inputs (3x).

You may want to consider using 6x files for the time stamped values or waveforms that your software needs to read but the typical customer doesn't normally need to access. 6x files are a great way to get a bunch of 64KW blocks of registers.

Scott Henson
Niobrara R&D Corp.
 
Top