I have started design of power and energy meter based on 8051 MCU. I plan to added MODBUS compliance to the device. Can anybody give somebody provide me some basic information about implementation? I hace RD2 MCU at 11 MHz. I need toi know what are minimum functions, disgnostic function one need to suport. Any sample aplication assembly code will help me a lot. Are there aby flow charts about MODBUS implemenation in these kind of devices?
Let's try to answer at least to one part of your questions.
Modbus commands implementation flow chart can be found in following document:"Modbus Application Protocol Specification" at www.modbus.org. They are universal whether they are to be implemented in VB or assembler.
Since you are going to develop some-meter you will need READ_INPUT_REGISTERS for measurement reading, READ_HOLD_REG and PRESET_MULTIPLE_REG (PRESET_SINGLE_REG is easier for start) for configuration parameters-reading and setting, e.g. from some PC application.
I suggest that all the function codes in the "Public" category be implemented in all Modbus devices. According to the draft IETF RFC these are:
Read Coil Status 01 (0x01)
Read Discrete Inputs 02 (0x02)
Read Holding Registers 03 (0x03)
Read Input Registers 04 (0x04)
Force Single Coil 05 (0x05)
Write Single Register 06 (0x06)
Force Multiple Coils 15 (0x0F)
Write Multiple Registers 16 (0x10)
Read File Record 20 / 6 (0x14 / 0x06)
Write File Record 21 / 6 (0x15 / 0x06)
Mask Write Register 22 (0x16)
Read/Write Holding Registers 23 (0x17)
Read Device Identification 43/14 (0x2B / 0E)
I would recommend implementing the minimum subset of function codes that you need to provide the required functionality.
Many (most?) slave devices implement only function codes 3 (Read Holding Registers) and 16 (Preset Multiple Registers). If your device is used purely for measurement (i.e. no requirement to write to the device) then you need only function 3.
If you need to set individual bits in the device, I would recommend function 22 (Mask Write Register) in preference to using coils (functions 1, 5 and 15) - but check that your master software supports it.
I wouldn't bother with discrete inputs (function 2) or input registers (function 4) - you can get the same functionality with holding registers. I wouldn't bother with function 6 (Write Single Register) unless your master software requires - function 16 does the job just as well. Functions 20 and 21 are only useful if your device needs a very large address space - I can't imagine that a power/energy meter would (unless you are storing lots of historical data).
Function 23 (Read/Write Holding Registers) can be handy if you want to "page" a set of registers - i.e. write to one register to select what information is available from another set of registers - but not necessary otherwise. Make sure that the write is done before the read if you do use it for paging!
The "basic" category of function 43 (Read Device Identification) would be useful for the future - it enables masters to check what slave they are talking to, and maybe do some auto-configuration, but not many masters support this function yet.
Fucntion code 8 (Diagnostics) is too device specific to be useful, and has never been widely implemented. If you want to provide device-specific diagnostic information, simply use holding registers for it. Diagnostics concerning communications & protocol are provided by the standard Modbus error responses.
Custom software development in Java and C/C++ for Linux
I agree that function/command 8 is uninteresting since it is proprietary.
In my view Modbus is a simple protocol in comparison with modern protocols like FOUNDATION Fieldbus and ControlNet. There is no reason to skimp further by not implementing all standard commands. The Modbus data link layer is extremely simple, there is no system management, there is no network management, the application layer is also very simple. So why not implement the "complete" application layer? Even a full Modbus implementation is sure to have a small footprint.
A complete implementation makes the product a lot easier to integrate into systems. If a product has quirky restrictions it just becomes frustrating to use. It is impossible to tell what different users are going to do with your energy meter. Perhaps the guy that first purchases the product is aware of any limitations and can work around them, but if someone else needs to work on the system in the future, all such special tweaks becomes difficult to deal with. If the meter is limited the user may not be doing much with it, but if it is capable, they can realize powerful new solutions for energy metering.
Most HMI software supports access to the 0xxxx, 1xxxx, 3xxxx and 4xxxx registers so implement all the related commands. Even devices that are analog/scalar by nature have digital points and vice-versa so you use them all. Perhaps give the option to access discrete points as both coil and register. Accessing discretes as coils/contacts may have some benefits in some hosts that likely were designed specifically to handle discretes this way.
Many devices today do not support all commands, nor do all hosts support all commands, but this is a chicken-and-egg problem. Once more devices start implementing a fuller command set, host applications will too. Once hosts implement a fuller command set, you can start making innovative things with it in your energy meter. Identification can be tremendously helpful during
commissioning and service, particularly for remote SCADA/telemetry applications. I hope that PLC and host softwares one day can implement clever features based on this command. Records can be useful in accessing large amounts such as data log recording hourly production or consumption for a power meter and then fetching it once a month.
I even hope more standard commands will be added, e.g. for hardware diagnostics (to replace the proprietary command 8) and maybe even hardware
configuration. Hopefully also standardization of the XMIT peer-to-peer
Jonas makes a very good point. Modbus/TCP was invented "overnight" as a quick fix to allow Ethernet access to PLCs for HMI and other such applications. It was never intended to be a full control interface like EtherNET/IP or Foundation Fieldbus HSE. Schneider Automation produced their final working code in about 4 months. The design philosophy was KISS (Keep It Simple Stupid), and it worked. With only four commands it solved 98% of the needs. Expansion of Modbus/TCP to the full Modbus protocol was never budgeted or approved.
Schneider recognized that Modbus/TCP was not enough, but has elected to follow a different path. Look at this web site: http://www.ida-group.org/ iDA Interfaces for Distributed Automation was formed initially for motion control networks, but has agreed to cooperate with ODVA (DeviceNet) and ProfiBus to come to a common bus interface. Schneider has two of the five Board members on iDA. This tells me that iDA is the future of Modbus/TCP. Version 1.1 of the iDA specification can be downloaded from: http://126.96.36.199/idagroup/service/download/IDA-Spec-V11.pdf
This is good work and a step in the right direction. There have been no announcements from Schneider on products to support iDA as yet.
Richard H. Caro, CEO
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728