Why not MODBUS...

R

Thread Starter

Ron Gage

Hi folks: I seem to be getting quite a bit of "why not use Modbus" questions out of this discussion. I hope to fully air my concerns about Modbus and why I think it to be totally inadequate for our primary purpose... First and foremost, the full Modbus spec is NOT open and has absolutely no signs that this will change. Yes, I know about the "open Modbus" protocol that is publically downloadable from Modicon. I beg you to take a full, careful look at this document. Please, tell me where in any of Modicon's publically available documentation I can find the full command and data layout for reading or writing rung data into a processor? Please, can you tell me how to fault reset a processor? How about clear memory or set/reset an access password? I would argue that Modbus is just as open as Allen Bradley's DF1 protocol. You can download the DF1 protocol from AB's website just as easily as you can download the Modbus protocol (AB's document number is 1770-6.5.16). It contains the exact same ommisions - it does not tell you how to do some of the more important stuff; those parts of the spec are NOT open. If we are going to use a spec, any spec, it needs to be FULLY documented. We can't afford to implement our own command for, say, password authentication, only to find that the same command on a "real" Modicon is the memory clear command. That would kinda blow compatibility right out of the water, I dare say. Another reason I would not chose Modbus is because of its specific lack of data typing. The Modbus protocol, as publically published, allows only 4 different data types - all integer based. Data type 0 for Outputs, Data type 1 for Inputs, data type 3 for read only values (direct reads from analog cards for example), and data type 4 for general 16 point integer registers (my primary experience has been with the 984's and micro's. If the Quantum is substantially different in that aspect, it is not documented in the OpenModbus spec). Floating point is supported only in the aspect of "you have to convert it yourself" from integer to IEEE using 2 integer addresses. BORING!!!! Finally, I would not use Modbus without SPECIFIC, EXPRESSED, WRITTEN permission from Modicon. Modbus is a trademarked name. Use of a trademarked name without specific permission (or the general fair-use exemptions) is generally actionable (i.e. lawsuit), at least here in the states. We are going to be marketing a product that is a direct competitor to Modicon - I think they would be "concerned" if we were to use their protocol without their permission. In closing, please keep in mind that I realize and understand that there will be some disagreement with what I have stated here. There will be some who think Modbus is the only logical choice. I understand and respect your opinion. This entire diatribe is just an enumeration of my feeling and position on the subject. This is NOT A FLAME BAIT attempt. I'm sorry if I ruffled any feathers with my words, but I feel the subject NEEDS to be debated! -- Ron Gage - Saginaw, MI ([email protected]) _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> I seem to be getting quite a bit of "why not use Modbus" questions out of > this discussion. I hope to fully air my concerns about Modbus and why I > think it to be totally inadequate for our primary purpose... You raise some very good points, Ron and I'm almost ready to concede. :) > First and foremost, the full Modbus spec is NOT open and has absolutely no > signs that this will change. Yes, I know about the "open Modbus" protocol > that is publically downloadable from Modicon. I beg you to take a full, This is what I was talking about... the straight packet format, not necessarily the rest of it since that would be different for most devices out there. When I said "why not ModBUS?" I specifically was referring to the packet structure. Personally I don't think anyone but Modicon uses the proprietary stuff and it's going the way of the dinosaur. > Another reason I would not chose Modbus is because of it's specific lack of > data typing. The Modbus protocol, as publically published, allows only 4 Data typing... pffft. If you ask for string data you get back (C) string data. If you ask for a float you get a float... it's all just bytes and their format should (in my opinion) be standard ANSI or IEEE, whichever seems appropriate. > Finally, I would not use Modbus without SPECIFIC, EXPRESSED, WRITTEN > permission from Modicon. Modbus is a trademarked name. Use of a trademarked > name without specific permission (or the general fair-use exemptions) is > generally actionable (i.e. lawsuit), at least here in the states. We are You can get around that in so many ways. "ModBUS<tm>-compatible" comes immediately to mind. National owns the trademark to "tri-state" so everyone just says "three-state" when they do up their datasheets. > In closing, please keep in mind that I realize and understand that there will > be some disagreement with what I have stated here. There will be some who > think Modbus is the only logical choice. I understand and respect your Not for me... I was just hoping that we could build on the basic data format of ModBUS so that all the devices out there which use the open part of the spec would be immediately able to either use or be used within LinuxPLC. Whatever specific extensions we decide to implement would be for LinuxPLC only and be freely available but that basic register get/register get I feel should be defined the same as the aged and battle-proven ModBUS. Next round! Regards, Andrew _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Ryan Van Slooten

From: "Ron Gage" <[email protected]> > <snip> > First and foremost, the full Modbus spec is NOT open and has absolutely no > signs that this will change. Yes, I know about the "open Modbus" protocol > that is publically downloadable from Modicon. I beg you to take a full, > careful look at this document. Please, tell me where in any of Modicon's > publically available documentation I can find the full command and data > layout for reading or writing rung data into a processor? Please, can you > tell me how to fault reset a processor? How about clear memory or set/reset > an access password? This is not a flame, just some comments. For all practical purposes, we do not care how they read or write a rung in Modbus unless we intend to implement it in the *exact* same fashion as they do. I would basically treat Modbus as a transport layer and use the general reference registers (data type 6) as memory location to put a file/program/whatever. Very inefficient, but it would work. > Another reason I would not chose Modbus is because of it's specific lack of > data typing. The Modbus protocol, as publically published, allows only 4 > different data types - all integer based. <snip... don't forget discretes...> > Floating point is supported only in the aspect of "you have > to convert it yourself" from integer to IEEE using 2 integer addresses. > BORING!!!! I totally agree. Actually the 2 integer to 1 float breaks down depending if you have hiword/loword or loword/hiword and what the HMI expects (some are configurable, some not, and some can't do IEEE FP at all). Major pain. But even more annoying is the Modbus scaling (or lack there of) for the integer types. We still run into DCS's that can only process 12-bit number so we end up scaling 0-4095 or 0-4000 or some crazy number or another common practice is to interpret the integer as 0-3276.7 so you have one decimal place of accuracy. I would love to dump all of that mess. Of course, for those devices, there will only be Modbus as they likely will never support anything else. If OIC is going to be a data access/collection protocol I would recommend putting more sophisticated features. Namely, support for building read and write lists rather than being able to read or write only consecutive addresses. It would be nice to also include data quality status, and possibly timestamp information. Possibly password/access control for variables. Possibly support for structures and enumerations. Anything else? Oh yes, don't forget the ability to browse the dataspace. It is my understanding (at least the last time I looked at CVS) that Modbus already existed. If it already exists, and we are talking about developing a new data access protocol, then I would recommend building one that has far more features than is currently available. I don't think the data access protocol should necessarily be the same as the programming protocol. It is fine if it is, but we should consider separating them as well. Oh well, that is all the comments I have at the moment. I'm not trying to flame anyone or be flame-bait myself, so please don't interpret this message as such. Ryan Van Slooten _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
R

R A Peterson

> First and foremost, the full Modbus spec is NOT open and has absolutely no signs that this will change. Yes, I know about the "open Modbus" protocol that is publically downloadable from Modicon. I beg you to take a full, careful look at this document. Please, tell me where in any of Modicon's publically available documentation I can find the full command and data layout for reading or writing rung data into a processor? Please, can you tell me how to fault reset a processor? How about clear memory or set/reset > an access password? Do we want a common communication protocal or a common PLC? I don't consider this particularly important. Modbus has other limitations that are far more onerous. > > I would argue that Modbus is just as open as Allen Bradley's DF1 protocol. You can download the DF1 protocol from AB's website just as easily as you can download the Modbus protocol (AB's document number is 1770-6.5.16). It contains the exact same ommisions - it does not tell you how to do some of the more important stuff; those parts of the spec are NOT open. If we are > going to use a spec, any spec, it needs to be FULLY documented. We can't afford to implement our own command for, say, password authentication, only to find that the same command on a "real" Modicon is the memory clear > command. That would kinda blow compatibility right out of the water, I dare say. > IIRC, DF1 is not an AB protocal. Its supposedly some standrad they got from somewhere else and is open. > Another reason I would not chose Modbus is because of its specific lack of data typing. The Modbus protocol, as publically published, allows only 4 different data types - all integer based. Data type 0 for Outputs, Data type 1 for Inputs, data type 3 for read only values (direct reads from analog cards for example), and data type 4 for general 16 point integer registers (my primary experience has been with the 984's and micro's. If the Quantum is substantially different in that aspect, it is not documented in the OpenModbus spec). Floating point is supported only in the aspect of "you have to convert it yourself" from integer to IEEE using 2 integer addresses. BORING!!!! > A good reason not to use it. > Finally, I would not use Modbus without SPECIFIC, EXPRESSED, WRITTEN permission from Modicon. Modbus is a trademarked name. Use of a trademarked name without specific permission (or the general fair-use exemptions) is generally actionable (i.e. lawsuit), at least here in the states. We are going to be marketing a product that is a direct competitor to Modicon - I > think they would be "concerned" if we were to use their protocol without their permission. > Do we care what its called? <remainder clip> Bob Peterson _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Ryan Van Slooten: > It is my understanding (at least the last time I looked at CVS) that > Modbus already existed. Yes - I'm not sure of the exact status, but if it doesn't work already it's well on the way. > If it already exists, and we are talking about developing a new data > access protocol, Yes. (Actually, I'm not sure what exactly is the point myself.) > then I would recommend building one that has far more features than is > currently available. That would be one reason to build a brand-new protocol. But beware of overengineering the thing. Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Ralph G. McDonald

&lt;Ryan VanSlooten wrote> This is not a flame, just some comments. For all practical purposes, we do not care how they read or write a rung in Modbus unless we intend to implement it in the *exact* same fashion as they do. I would basically treat Modbus as a transport layer and use the general reference registers (data type 6) as memory location to put a file/program/whatever. Very ineffiencient, but it would work. <<< I agree with Ryan and I believe that Modbus communication is essential for the LinuxPLC to function in the plant environment. In effect it is the lowest common denominator for communication between "Smart" devices in many of the industrial plants that I work in. As an example last year I did several projects involving Modbus for a local chemical company. We interfaced the custom control panels on 4 large air compressors to a local AB 5/04 via a ProSoft module. We needed to read a group of internal registers from the control panels, transfer the data to a set of tables in the AB, and scale to Floating Point for the Intellution FIX HMI at the head end. Then several months later did the same for Seimens power meter at a different location. All we really need is an easy way to read/write all of Modbus registers from the LinuxPLC. In both cases the Modbus was the only general purpose method of communications with the internal registers of the equipment. I am seeing more equipment ( valves, chemical feed pumps, VFDs, etc. ) available with ModBus communications every year. I have also been encouraging vendors and manufacturer's representatives to implement Modbus. At this level we don't need speed or elegance just a better way then multiple 4-20 loops and/or multiple discretes, and more noise resistance and greater distance then RS-232. Great discussion, many thoughtful ideas that are based on experience, thanks Ron for starting it. Ralph
 
H
snip>Please, tell me where in any of Modicon's publically available documentation I can find the full command and data layout for reading or writing rung data into a processor?<

You're right, that information is not published, NOR IS IT FIXED. The protocol is DIFFERENT for each Modicon processer. The programming panel sends a query to the PLC to determine its' type before any thing else happens.

snip> I would argue that Modbus is just as open as Allen Bradley's DF1 protocol.<

True! The details of programming PLC's are too processor specific to keep static; they NEED to be changable.

snip>If we are going to use a spec, any spec, it needs to be FULLY documented.<

Only if we plan to EXACTLY duplicate the operation of a specific PLC (BORING!!). Figure out how to interrogate a Modicon for its type, and use that to differentiate Us from Them. If you hook up a PC running Concept to it, Concept will ask "Who are you", we'll reply "Puffin", and Concept will reply "Sorry, don't know that one!"

snip>Another reason I would not chose Modbus is because of its specific lack of data typing. The Modbus protocol, as publically published, allows only 4 different data types - all integer based. Data type 0 for Outputs, Data type 1 for Inputs, data type 3 for read only values (direct reads from analog cards for example), and data type 4 for general 16 point integer registers..<

Same response as above: Implement what IS documented EXACTLY, and use machine specific extensions for whatever "fancy stuff" you feel you MUST have. That way you have the best of both worlds; compatibility with existing products AND all the proprietary latitude you could ever want.

Harvey Babb



 
Top