Modbus licensing (was NET: Which Network To Use?)

C

Thread Starter

Curt Wuollet

From a totally objective viewpoint, I would cautiously agree. The only remaining obstacles for Modbus are the the proprietary nature of Modbus+ and the fact that the licensing doesn't clearly allow what a lot of folks are already doing. Modicon retains the right to shut down Modbus.org and others who implement the protos without a formal agreement. I doubt that it would be in their interest to do so as the genie has been out of the bottle for a long time. Why not then, recognize the reality and either change or disclaim the licensing or better yet, put control of the protos in the hands of Modbus.org. Don't get me wrong, I applaud the singular enlightenment shown in allowing wide use of the Modbus protos. I even hold them up as an example of how relinquishing absolute control has had
only good consequences. It's just that barriers remain for those who could best forward the intent behind those policies.

As an example, the MAT/Plc project still runs the risk, however small, that we can be ordered to cease and desist using Modbus and especially giving away code that implements the protocol as we have absolutely no control over how that code could be used or by whom. I have made polite and
repeated requests to clarify the situation one way or the other and keep being referred to a click through license that is simply irrelevent to
our situation. We have no legal entity to enter into an agreement and would simply like permission or at least assurance that we won't be sued.

Yet I believe they want us to use Modbus or at worst, don't care if we do what everyone else and their uncle is doing with Modbus. And I'm sure
they realize that it is impractical and utterly unenforcable for us to make users click through their license. We still have a technical
problem.

As one of a nebulous collection of volunteers operating clearly in the public interest, simply doing what a lot of other people are doing, I
doubt that it could be demonstrated that harm is being done. But, as the founder of the project, I want to do the right thing and I would like to
recognize their contribution to the project as we will need a great deal of cooperation from corporations to serve the community as we would like. A wink and a nod, or being ignored, denies them the position of being recognized for their forward thinking and insightful policies and keeps
me awake nights.

I see it as very important as we progress into a more open, more cooperative era, that these initial steps be recognized as historic and
ground breaking. That they be seen as positive actions rather than simply a failure to prosecute or the like. Why should the inevitable be seen as
negative? There is certainly enough demonstrated support and demand for openness to praise and recognize leadership rather than lip service.

Regards

cww

List Manager wrote:
> ---------- Forwarded message ----------
> From: Lee J Ward <[email protected]>
> To: [email protected]
> Subject: Re: NET: Which Network To Use?
>
> As a proponent, the answer for me is easy. Modbus TCP is the way
> forward at this point in time. The modbus instruction set is truly
> open, not proprietry. Check out http://www.modbus.org Here you can
> check out the standards, realize the virtues and download some useful
> information. Let's face it, almost every automation vendor, many
> control instument providers and other equipment vendors have Modbus
> connectivity. Using TCP/IP as the transport is the next logical step.
> Move on or move over I say.
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.
 
L

Lynn August Linse

> From: Curt Wuollet <[email protected]>
> From a totally objective viewpoint, I would
> cautiously agree. The only remaining obstacles
> for Modbus are the the proprietary nature of
> Modbus+ and the fact that the licensing doesn't
> clearly allow what a lot of folks are already
> doing. Modicon retains the right to shut down
> Modbus.org and others who implement the protos
> without a formal agreement. I doubt that
> it would be in their interest to do so as the
> genie has been out of the bottle for a long
> time. Why not then, recognize the reality and
> either change or disclaim the licensing or
> better yet, put control of the protos in the
> hands of Modbus.org.
> (clip)

Actually, that's in the process of being done as we speak - but aiming more at IETF than Modbus.ORG. I'm not directly involved, so cannot say with authority much more. Send an email to [email protected] if you want a better status update or to offer support for this move.

regards
Lynn August Linse, Senior IA Application Engineer
15353 Barranca Parkway
Lantronix Inc, Irvine CA 92618
[email protected]
www.lantronix.com
Tel: (949)279-3969
Fax: (949)453-7152
 
C

Curt Wuollet

Hi Lynn

If this comes to pass, it would indeed be a first and a significant event.
Evwn an attempt is groundbreaking as the courage is manifested in the act.
While the IETF is somewhat occult, they have been a trustworthy caretaker of the most valuable standards in the world, no one owns the internet,
yet.
And because of it's primacy and wide, if grudging, support, what better candidate for the First and Only Open Standard in automation than
Modbus?
I will certainly add my support for the idea for what it's worth. Life could suddenly become much better if it spurs competition on who can make life easiest for their integrators and customers. What a concept!

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
Hi everyone:

> ---------- Forwarded message ----------
> From: Lee J Ward
>
> As a proponent, the answer for me is easy. Modbus TCP is the way
> forward at this point in time. The modbus instruction set is truly
> open, not proprietry. Check out http://www.modbus.org Here you can
> check out the standards, realize the virtues and download some useful
> information. Let's face it, almost every automation vendor, many
> control instument providers and other equipment vendors have Modbus
> connectivity. Using TCP/IP as the transport is the next logical step.
> Move on or move over I say.

I can't believe I actually read this. Modbus is open.. Yeah, right it is. Oh, sure, it is open, just like AB's DF1 protocol (see ab doc# 1770-6-5-16). It fully documents the frame layout, and even gives you some basic commands to play with.

Modbus is just as open as AB's DF1 - partially open, that is.

If Modbus was truely open, then the docs would clearly show you how to edit/add rungs/networks. If Modbus was truely open, then it would tell you how to put the processor in "Program Mode" or "Run Mode". If Modbus was truely open, then
it would tell us how to modify the enable/disable status of a coil (allow forcing of an output or input).

Modbus, like AB's DF1, is just open enough to whet your appetite and to make you think you are getting something really neat (and possibly useful).

Here is the test to see if your protocol is truely open...
If, using nothing other than the publically published specification, you can write a complete programming suite for the PLC (rung editor, config editor, memory editor, up/downloads, etc...), then and only then will your protocol be
considered open. As long as there remains ANY hidden commands, your protocol remains proprietary, regardless of how bright your spotlight is.

--
Ron Gage - Owner, Linux Network Services - Saginaw, Michigan - 989-274-8088
Your one-stop source for Reliable, Secure and Affordable Networking Solutions
CELL Webpage - http://www.lns-saginaw.net/cell.php
 
J
Programming function codes are machine specific and, open or closed, should not be part of the Modbus protocol specification.

For example, a Modicon Quantum with a 984 executive, a Modicon Compact with an IEC execute, and a Control Microsystems SCADAPak can all be programmed over Modbus protocol, but the Modbus messages used to modify the programs are unique to each controller. They have to be, the instruction sets in these three controllers are completely different.

When a controller manufacturer chooses not to publish his programming function codes he makes his controller less open, but that does not make the basic Modbus protocol any less open. Any manufacturer can make his PLC programmable through Modbus protocol.

Jay Kirsch
 
I believe you're asking an awful lot from a communications protocol specification. We don't blame the IETF because the HTTP spec doesn't
describe how to order a book from Amazon.

Using a Modbus "standard" to move a box from the Program state to the Run state wouldn't help much with my HVAC controller--I don't have one
enable/disable switch because while I'm working on the algorithms for one air handling unit, I want to let the box continue to control the other AHUs.

This illustrates the downside of standards. It casts the functionality in stone, for some period of time anyway, and slows the pace of innovation.
And by innovation, I don't mean just adding more and more functionality. Partitioning of the functionality to permit the optimal application of
control to the problem at hand provides the opportunity different vendors to cost effectively meet different customers' needs.

Best,
B.O. Apr. 25, 2002
--
Robert Old, System Architecture, [email protected]
Siemens Building Technologies, Inc., Building Automation
1000 Deerfield Pkwy., Buffalo Grove, IL 60089-4513 USA
Phone: +1(847)941-5623, Fax: +1(908)547-6544
 
Quoting Jay Kirsch <[email protected]>:

> Programming function codes are machine specific and, open or
> closed, should not be part of the Modbus protocol specification.

So, a balkanization of the standard is permissible depending on the need/whim of the manufacturer? Hmmm, kinda reminds me of Kerberos and a certain Washington state software company....

> When a controller manufacturer chooses not to publish
> his programming function codes he makes his controller
> less open, but that does not make the basic Modbus protocol
> any less open. Any manufacturer can make his PLC
> programmable through Modbus protocol.

I guess I am lost here. Partial publication == open? In my mind (warped as it is), partial publication == partially open.

Don't get me wrong. I think Modbus is fine for certain things. It is certainly a simple, simplistic communications protocol that does it's job quite well. I just object to it referring to itself as "open" when in fact it is not. It is
partially open - granted, the part that is open is most likely to be the most useful part. It's that little corner of the spec where the "do not enter" signs are that bothers me.

Think of it this way. Consider Ethernet. Now, let assume that TCP and UDP were fully open and disclosed (as they are today), but ICMP was considered "proprietary" and remained undocumented (publically). Would it be permissible to refer to Ethernet as an open networking standard under this condition?

--
Ron Gage - Owner, Linux Network Services - Saginaw, Michigan - 989-274-8088
Your one-stop source for Reliable, Secure and Affordable Networking Solutions
CELL Webpage - http://www.lns-saginaw.net/cell.php
 
M

Mark Blunier

From: "Blunier, Mark" <[email protected]>
To: <[email protected]>
Subject: RE: BUSN, OPENC: Modbus licensing (was NET: Which Network To Use?)

> > Programming function codes are machine specific and, open or
> > closed, should not be part of the Modbus protocol specification.

> > When a controller manufacturer chooses not to publish
> > his programming function codes he makes his controller
> > less open, but that does not make the basic Modbus protocol
> > any less open. Any manufacturer can make his PLC
> > programmable through Modbus protocol.
>
> I guess I am lost here. Partial publication open? In my
> mind (warped as it is), partial publication partially open.

Modbus is a communication protocol. If the function calls used
to program a PLC use function calls that are not in the protocol,
then I would agree that the programming software is using an
extended (non-open) version of the protocol. However, if it is
using a function call that is defined, but the data that is transferred
by the function call is undefined then they are not extending
the protocol.

> Don't get me wrong. I think Modbus is fine for certain
> things. It is certainly
> a simple, simplistic communications protocol that does it's
> job quite well. I
> just object to it referring to itself as "open" when in fact
> it is not. It is
> partially open - granted, the part that is open is most
> likely to be the most
> useful part. It's that little corner of the spec where the
> "do not enter" signs
> are that bothers me.
>
> Think of it this way. Consider Ethernet. Now, let assume
> that TCP and UDP were
> fully open and disclosed (as they are today), but ICMP was considered
> "proprietary" and remained undocumented (publically). Would
> it be permissible
> to refer to Ethernet as an open networking standard under
> this condition?

No. You seem to be defining of Ethernet being both the communication
network and protocol. But again, are the programming codes that are used
to program the PLCs functions that are not define by the standard like in
your analogy, ICMP, or are they information that is being carried by the
standard, but in an unknown form, as SMTP or FTP is carried through TCP,
but not defined under your Ethernet?

 
R

Ralph Mackiewicz

> Think of it this way. Consider Ethernet. Now, let assume that TCP
> and UDP were fully open and disclosed (as they are today), but ICMP
> was considered "proprietary" and remained undocumented (publically).
> Would it be permissible to refer to Ethernet as an open networking
> standard under this condition?

I know this is nitpicking but if you want to make a point I think the proper terms are needed.

Neither TCP, UDP, or ICMP are a part of Ethernet. Ethernet is an IEEE data link (acutally the Media Access Control (MAC) component of the data link) and physical link standard. You should replace "Ethernet" with "the Internet" (with a capital "I") in your paragraph above.

To answer the question would the Internet still be "open" if ICMP was closed: I suppose not. But, if you didn't need ICMP then it would be "open enough". IMHO that is what Modbus is: open enough for a register access protocol.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
Top