| Lynn's Industrial Automation Protocol Tips |
| Home > Modbus > Modbus RFC Wish List > | |||||||||||||
|
The information on this web page is either Lynn's opinion or something Lynn agrees with. He has complete control over its contents. Nothing contained within this pages is approved by or represents the opinion of Digi International, The Modbus Organization, the Modbus-IDA Group, ODVA, or any other organization Lynn is associated with. Lynn's Modbus RFC Wish ListHere is my wish list of things I's like to see clarified by Request-For-Comment or Modbus RFC. I need help to create the draft RFC to submit to www.modbus-ida.org. Anyone else with similar interests is invited to help me. If I have a draft started, it will be linked in below as an OpenOffice v1.1document. I'll also try to link in a Word 97 export of this, but the OpenOffice is the formal draft format.
Some Modbus details are very core to the technology. These are recommended practise and must be supported to pass conformance tests. Obviously, Modbus is widely implemented as-is and such changes must be considered slowly and carefully. Most likely, core RFC are clarifications to solve existing market confusion. Such an RFC should make most vendors and users happy - but may force a small minority of vendors to modify their products. What is a 'Vendor Extension' RFC? In the market today there is a wide variety of creative thinking being labeled as Modbus. Some of these create no market/user confusion, but most DO create problems. Much to the dismay of buyers/users, often 2 or more vendors create similar but incompatible creativity. So 'Vendor Extension' RFC are designed to be easier to pass. They will NOT be included in conformance tests - however be warned that most Vendor Extension RFC will include the clause that the vendor extension is an option and must NOT be enabled by default. In other words, Modbus products with vendor extensions MUST BY DEFAULT BE 100% compatible with Modbus products that do not implement the vendor extensions. This will likely require many vendors to modify their products in order to claim full Modbus compliance. Packing of IEC data types in Holding Registers (Core RFC) By now everyone should know that the recommended way to move 32-bit long integers and floating points is to pack them into two consecutive registers. However, whether the registers are high word first or low word first is left to implementors imagination. For a short time the www.modbus.org specification included an appendix covering this, but the most recent specification has eliminated this. I want to create an RFC to unambiguously define how common data types should be packed into 16-bit holding registers. How to Filter Modbus functions for security (Core RFC) Won't it be nice if a Modbus slave could be configured to allow some master/clients to have full access and others read-only access? This would be ideal for applications when some remote clients come through a firewall. We should go through the standard Modbus functions and define how to classify them for read-only etc. Define an XML format to document a Modbus slave's registers (Core RFC) Currently, users of small Modbus devices need to manually enter register data from a user manual into OPC and other tools. It would be better to define a simple XML format to document those registers. Then small devices (like Loop Controllers or I/O blocks) can be browsed and auto-imported into OPC and other tools. For serial devices, perhaps the only value is a file the user collects from the vendor. But with Ethernet-enabled devices, we could even define a standard URL and use HTTP and/or FTP for tools to auto-import the info. Modbus/TCP format in UDP - Modbus/UDP (Vendor Extension) A growing number of vendors offer Modbus/UDP as an option to Modbus/TCP in their products.
Worse, a low-end products are ONLY supporting Modbus/UDP or calling Modbus/RTU encapsulated into UDP
as Modbus/UDP.
Both of these practises are confusing buyers and users.
So I want to document what vendors desiring to offer this should and should NOT do,
plus what they should call and NOT call it.
Encapsulation of serial Modbus in TCP and/or UDP (Vendor Extension) Many vendors just encapsulate serial Modbus directly in TCP or UDP packets. Most UNIX systems can just as happily send serial Modbus in BSD sockets as they can true serial ports. A growing number of OPC servers allow most of their serial protocols to be packed in TCP. Unfortunately, many vendors refer to this as "Modbus in Ethernet", which also is confusing buyers and users. So I want to document what vendors desiring to offer this should and should NOT do, plus what they should call and NOT call it. Handling timing for 'Report-by-exception' or XMIT (Vendor Extension) In theory, if the Master sends a poll, the slave responds, then the Master delays a short while (say 20 msec?) this gives the Slave the opportunity to initiate a Master-like write request to 'report' an important change. If the Master/Client is a Modbus bridge to TCP/IP, this is a hugely useful feature as Modbus/TCP would allow both incoming and outgoing connections. It would be very feasible to allow the 'slave' to force a data write into a remote master PLC or OPC/HMI package. Handling time-stamped data (Vendor Extension) In theory, a remote proxy or gateway could be polling a slave at a high rate of speed, and a central site contacts it periodically to gather the data. This means the central site would not poll the current data, but a series of reads of "what was" in the past. We should be able to come up with a simple RFC to define such historical records by Modbus. They could also be the basis of event logging - the remote could create a time-stamped record of when a valve opened or closed and the central site could import this event into a log after the fact. |
||||||||||||
| Feedback - Contact | Lynn's Industrial Automation Protocol Tips | Copyright 2004 | |||||||||||