Supports Open Standard (was: Fw: LinuxPLC: attn Rob.)

H

Thread Starter

Harald Albrecht

Christopher linuxma[email protected] wrote:

> Look at www.opcfoundation.org we are a major player
> in that open standard.

Excuse me, but what is so "open" about OPC? As the "O" stands for OLE (Automation), it is based on a proprietary component system called "COM". How can I interface my Linux PLC with some office PC, loop tuning software, etc., each running on a
different o/s? How can I integrate my PLC with Distributed Control Systems, running Solaris and HP-UX (because they have to work, not to reboot)?

And the OPC foundation is open? Well, some guy from the OPC foundation's booth at Interkama fair last year asked me to join the foundation. "It would be only around $1000 per year" -- <irony>a
real bargain for a university chair</irony>. I asked him for the benefits. "Well," he responded, "we would then get the documentation." "Early than those which are available from the public section of their web site," I asked. "No," he responded. So I asked him what are the benefits of paying $1000 and getting the same specs everbody+dog is able to download. "Then I have to ask someone for what are the benefits," he told me. Good guy.

For me, "open" is about openness and frankness, without signing a big cheque first. Reminds me somehow of the "Open Software Foundation" -- was incompatible to "open" and now is history.
<bigot mode off>

Regards,
Harald Albrecht

--
Harald Albrecht
Chair of Process Control Engineering
Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238
email: [email protected]-aachen.de

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Harald and all

I'm not sure where this came from, and I agree with you, but, it's preaching to the choir, IMHO and a peripheral issue at best. OLE is not relevent to the Linux PLC, nor is a religious war about any Microsoft only "standards", I submit that, by definition, we may interface to such things but, they can not be an integral part of an
Open Source project because they are not open nor open source and contradict the goals of the project. A dependance on proprietary methods is simply not acceptable. If you can't GPL it, it isn't open enough for the project. If someone can devise a way to do it that solves a problem for
them and others and doesn't violate the GPL or copyrights/patents that would encumber the project, fine. We will have to address these issues as we want to interface with the maximum number of proprietary systems and peripherals
but it must be done without compromising the project. I invite constructive discussion on how to do this. Please forgive me Ron, but if we, for example, roll Ron's code directly into the core project and AB decides to sue, we could be injuncted for years from distributing code or even individually or collectively liable. Huge
amounts of Windows code depend on the felicity of MS in certain areas, with questionable licensing that says it can only be used with Windows for example. That's why I want to stick to tools
and methods that are clearly GPL so we can't be shut down. This I'm sure, is seen as bigotry in some quarters, but, the "establishment" is litigious and not very happy about what we're
doing ;^). For what it's worth, my Modbus code has the same problem. It will have to be distributed seperately. The other stuff I'm doing is GPL. How do we deal with this folks?

Regards,

Curt Wuollet


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

> Microsoft only "standards", I submit that, by definition, we may
> interface to such things but, they can not be an integral part of an
> Open Source project because they are not open nor open source
> and contradict the goals of the project.

I don't want to play the zealot and its not about Microsoft "standards" in general. After sorting out the "open" thing about OPC, the question I still have is: what solutions are "out there" to
connect, for instance, a LinuxPLC to other systems? Typically, PLCs seem to be part of a larger game, involving "higher operational levels", like process supervision, MES, etc. A stand-alone LinuxPLC, playing alone with itself, seems rather boring to me.

> A dependance on proprietary methods is simply not acceptable.
> If you can't GPL it, it isn't open enough.for the project.

What about the Artistic License then? ;-)

> [more license issues snipped]

Patent issues have to be sorted out first -- because that can be a dangerous trap to tap into, just look at the FF/Profitbus battle (which sometimes looks to me like "North America ./. Ol' Europe").

Regards,
Harald

--
Harald Albrecht
Chair of Process Control Engineering
Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238
email: [email protected]-aachen.de

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Christopher Di Biase

Curt,

This perked my curiosity so I sat down and skimmed the OPC licence agreement again. Basically what the licence on the OPC Spec says is that essentially open to all developers who wish to adhere to the standard set of COM interfaces. True the spec is controlled by those companies and developers willing to shell out the cash to join the foundation, but the specification is free for all who wish to develop around it.

Now true this probably has limited use for a Linux project, but should someone port the COM/DCOM architecture over to Linux or X11, then it would be perfectly reasonable and rather advantageous to support a standard that is gaining popularity in the Automation industry. I wouldn't worry about OPC support opening the door for lawsuits and that sort of thing. OPC is
meant to help get the industry away from proprietary interfaces and lock us all into the same standard. (though I can't say the same about COM :)

Christopher Di Biase
[email protected]

At08:26 PM 4/25/2000 -0500, Curt Wuollet wrote:
<<ever growing thread snipped for our digest readers :)>>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
&lt;RANDOM THOUGHT MODE&gt;

If you folks don't mind me jumping in here....

I have been giving this OPC stuff some thought (I have a possible need to implement it in ABEL in one form or another). OPC = OLE for Process Control, OLE = Object Linking and Embedding. Isn't this something akin to CORBA?

What I have been think of is simply: what is OPC in it's simpliest form: it is a standard way to exchange data from propriatary servers (PLC's, HMI's) to "standard applications" by using a standard set of library calls. The library can be thought of as a wrapper around a comm system. In other words, the end application won't care about what the wrapper is talking to. The application will just say "I need the first stored integer value in memory". The wrapper
takes care of calling the proper comm routine to retrieve that value, the comm routine takes care of talking to the PLC and getting the real value.

My thoughs: wouldn't it be sort of easy to come up with our own "standard" for an OPC work-alike product under Linux/Unix? By utilizing either CORBA or NetPipes, it shouldn't be too difficult. Just a little time consuming
(especially coming up with a standard - documented completely). From there, it would be a small effort to deliver sample working code to demonstrate exchanging data between a PLC and, say, Gnumeric.

Besides, by coming up with our own, we stand a much better chance of not "stepping on any toes" per-se. OPC has become a "standard" because there isn't anything else out there that does what it does. How about throwing in some
competition?

&lt;/RANDOM THOUGHT MODE&gt;

Ron Gage - Saginaw, MI
([email protected])

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Ron and all

I've struggled very hard with the hypocrisy of creating "yet another standard" verses the chance to build the only really open standard in the industry. I've thought it through at great length for both the fieldbus and the object comms.
I've even taken a hardware design through the feasibility stage on the fieldbus side, an ethernet I/O engine where we could run our own protocol. In fact, that's what lit the fire for this project. I wanted to do that project very badly simply so I could use a Linux box for automation and control without all the BS. I may still do that project and release both the hardware design and the proto as public domain and GPL respectively. That, in my opinion, is the only way we will _ever _have an open fieldbus. I'm damn near mad enough to take on another project since I hit the GEFanuc site today and was bombarded with the word "OPEN" on nearly every proprietary product line they have. The CORBA/COM thing is for me, a non-issue except for legality. I know it's heresy, but I still don't see the benefit of merging my control system
with my office suite. Even if MS is doing it. I still would like to avoid OO to maximise our pool of developers. I would support a socket based standard protocol specifically created for our purposes and kept lean so we could distribute processes in a standard way but, I can't get excited on flash and glitz when the basics aren't happening. Connecting with the Microsoft world
is really low on my list of priorities until we have something to connect to it. I'm wide open to be convinced it's a "gotta have" I'm more excited about a browser interface as it's cross-platform and fairly easy with Linux but, that's gonna hafta wait also. If anyone has time and money to do the hardware thing, talk to me.

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D

Darryl Palmer

I hope I don't have to continually state this but COM is "OPEN" Microsoft released the specs to The Open Group, the same people that support DCE, and
they have their own version called COMSOURCE see
http://www.opengroup.org/comsource/. The only thing that was not released by Microsoft is how they serialize objects hierarchically to streams. As far as OPC charging $1000 and giving nothing is bogus. Our school joined the ControlNet Association, like that is really open, and for $500 bucks we got membership and some of the ControlNet transceivers, which sell by itself for $500.

Now what is really funny is that I think the Open Software Foundation was the predecessor to The Open Group.

Darryl Palmer
Cleveland State University



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Darryl

No, you don't have to keep stating it.
As an interface, but, not a dependency.
Let me restate that. I agree we have to interface with the MS world. The likelihood of this Open Source Linux project that seeks to define open for the automation industry being dependent on COM is about nil. If you want NT, write for
NT. I'm trying to hard to be agnostic, but it _is_ intended as an alternative to all that, not a workalike.

see: www.opensource.org

And I find Microsoft's Open Group membership hilarious. You don't need a group to be open, just GPL it. If the Open Group were open I'd be looking at Motif and browsing the source for OSF1/Tru-64.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
Ron,

I've been looking at that issue for a while. CORBA would be the go. It would be, IMHO, easier to implement CORBA interfaces than OPC. There is work going on to create a GPL CORBA/COM bridge. There are already commercial options out there.
If we implement CPC (sorry, I couldn't resist... acronyms are an industry wide virus...) now, it could interface fairly easily later on with OPC clients and servers if necessary. I'd think, though, that such a move under GPL would create an alternative defacto standard that would be quickly and widely adopted within the Linux & probably *nix world.

For Linux particularly, a clean set of CORBA interfaces would be of great benefit. It'd fit in with GNOME rather nicely. This is in keeping with the general *nix idea of small useful components that you can use as building blocks for your solutions. Plus there would be the opportunity for innovation. A LGPL object library providing "Points" in "Maps" for "Devices" in "Networks" which could be configured to manage data from various servers through CORBA bindings would be a great thing.


Regards,
Sheldon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Jose Fernandez

Hi all

I have noted in this mail, Curt mentions "the project", I am new in this list and I'm interesting to know more about the project, Is there any FAQ or Introductory document to this lists?, the goals or objectives of "the project", how could one help or participate?, someone would send it directly to my e-mail box?.

Best regards and thank you all

Jose Manuel
http://www.internet.ve/asic/index.html

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Jose;

No we don't have a format charter or FAQ, mostly because there's so little agreement on how to implement. One we get as many as three people to agree on any one approach, I'll be happy to document it or leave it to our de facto documentation team. As far as my vision is concerned, the first couple messages in the archive cover that, and other folks vision is expressed along the way. I am proceeding along
the original plan, hoping that a first pass bare bones implementation will provide the stone for the stone soup. I have coded a simple map
viewer, most of an Opto22 Modbus/TCP driver and have some more ethernet I/O coming as the Opto22 Modbus seems to be brain dead. There is some work in the cvs archive from various people but none
of it seems related to my work or others. I'm afraid the mail archive is the only way to get up to speed. We may end up with 5 different
machines or none. It remains to be seen if we can get together on one.

Regards

Curt Wuollet.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> I have coded a simple map viewer,

Do you have that viewer handy?

Before I hand over the SMM as `finished', I'm going to want to see it working, and I'm going to need a map viewer for that.

Might as well use yours...


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top