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 ODVA ESE Wish List

Here is my wish list of things I's like to see clarified or added to ODVA Ethernet/IP. 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.

• CIP Legacy Table Object

CIP Legacy Table Object

Rockwell access legacy PLC by encapsulating PCCC (or DF1-like commands) within a vendor-specific CIP object. This is Ok, except that it suffers 2 problems. First, it is not a published standard. One can reverse engineer it, but that's not the way it should be. Second, the handling of PCCC commands is model specific - one needs to know WHICH processor one is contacting to select the correct command. This is also NOT the way it should be.

Do we really want such vendor-specific CIP objects for Modbus? for GE/SNP? for Omron/HostLink? for Siemens PPI? Do we want to create such objects ad-nauseam? Worse, such vendor-specific, protocol-specific objects offer a triple pain. First, the user needs to UNDERSTAND CIP and Ethernet/IP; Second, the user needs to UNDERSTAND the protocol in question; Third, the user needs to UNDERSTAND how the two are morphed together. This is the worst of all worlds.

So I'd like approach this problem another way. All of the protocols I mentioned above (plus perhaps 70% of all industrial protocols) have the concept of reading or writing a block of 16-bit registers. So my proposal is to create a vendor-neutral data table or array of data that can be read or written. Requests to read or write can be mapped to any common PLC protocol - details of the mapping is hidden within the device (or proxy) handing the CIP Legacy Table Object. So the user (caller) only needs to understand Ethernet/IP and the table object. 'Details' such as which PLC is attached can be hidden within the device/proxy.

My CIP Legacy Table Idea as PDF

return to top

CIP Direct Header

The Ethernet/IP 'protocol' was designed for more flexibility that we need - especially the variable sized fields in the CPF (common packet format). I suppose it doesn't really matter, but with the 16-bit range of the header command field we could have a single fixed packet format that covers both UCMM and CM packets. This eliminates the need to 'parse' the CPF. True, this cuts very little work out of Ethernet/IP, but it is work that serves no useful purpose for non-Rockwell legacy protocols.

return to top