Today is...
Wednesday, July 26, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
connectivity (OPC)
Is there any OPC effort in GPL for Linux, because in my opinion this is a great way of taking this project to the factory floor. I am not saying that it is the only way, just that it is a good way. ...
By Juan Carlos Orozco on 8 March, 2001 - 2:15 pm

I am a great fan of this list, because I believe that it has a promising future. For the moment time and lack of experience programming in Linux has been the main restrictions for contributing in the code of this project, I hope in the future to be able with some tuition from the group to collaborate. For now I will try to help commenting on some issues that I think may be relevant. Is there any OPC effort in GPL for Linux, because in my opinion this is a great way of taking this project to the factory floor. I am not saying that it is the only way, just that it is a good way. This is a good link between a PLC of x brand and all the well known HMI, we could later develop an alternate GPL equivalent instead of OLE if OLE is a problem of conflict in license (I am talking here without knowing how this private-GPL licenses can be used or combined). It is not likely that a customer with an installed base for his automation is going to throw everything and reinstall all in GPL software even if it is free. If we develop an HMI as has been said on other messages, we may also need to support OPC to integrate with proprietary hardware. But for now I think is more important for the LPLC to be able to connect to HMI's via OPC. It is also not likely in the near future to substitute OPC with a GPL standard. By the way isn't OPC supposed to be open? In that case we do not need to replace it and just embrace it for our project. Juan Carlos Orozco ACElab Industrial Automation jorozco@ace-lab.com www.ace-lab.com -----Mensaje original----- De: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]En nombre de Perry Sink Jeff, >> I am eager to see what can be done with this. I do >> integration work in the PLC realm and have been >> waiting to finally find something like this. >> Is this ready for plantfloor testing, or when will it >> be? I see that there is discussion as to using lp >> connections. >> Is there going to be connectivity to existing plc >> networks? There are several vendors who have Linux drivers written for their cards -- SST, Synergetic/Hilscher, Phoenix, and maybe some others as well. Most of the popular buses are covered. >> How about OPC? Has some rendering of COM been ported >> to Linux? Intrinsyc software (http://www.intrinsyc.com/) has Linux OPC servers they have written (not GPL, I'm almost certain) which allow an OPC server and an OPC client to be separated by a network or even by the internet, around the world. One or both of them can be non-windows as well -- I just talked to one of their senior product developers yesterday at the NMW trade show. I doubt this is much use to this list per se, but at least it can be done. Perry Sink Synergetic _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Mario de Sousa on 9 March, 2001 - 3:04 pm

Juan Carlos Orozco wrote: > > Is there any OPC effort in GPL for Linux, because in my opinion this is a > great way of taking this project to the factory floor. I am not saying that > it is the only way, just that it is a good way. > If anybody knows about such a beast, please let me know! > (...) > By > the way isn't OPC supposed to be open? In that case we do not need to > replace it and just embrace it for our project. Yes, the OPC is an open standard. It standardises a collection of DCOM interfaces for communication with Industrial hardware. This means that the API is standardised, but we need a DCOM implementation on Linux to use it. DCOM uses DCE (Dictributed Computing Environment, anybody remember this?) RPCs, and not the standard SUN RPCs already available for Linux, and used for NFS. This is another hurdle for implementing DCOM over Linux. With the microsoft standards continually changing, we might just as well forget this approach. Another method is to write a proxy OPC server, i.e. an OPC server that runs on Windows, and uses a Puffin proprietry protocol (or any other protocol we choose) to communicate with the PuffinPLC. This is the most common solution currently being used for OPC servers for PLCs. Actually, if the PuffinPLC supports a standardised communication protocol, then any OPC server that supports that protocol may be used! I think this is already the case. PuffinPLc supports modbus, and you might want to check out www.kepware.com that sell an OPC server that supports this protocol! They even let you download a fully functional evaluation copy that only runs for an hour, before needing to be restarted. Mind you, this is how there evaluation copy worked last year. Don't know if it still the same... Off course, it would be nicer to have our own GPL'd OPC server, but that can come later... Cheers, Mario. ---------------------------------------------------------------------------- Mario J. R. de Sousa msousa@fe.up.pt ---------------------------------------------------------------------------- The box said it requires Windows 95 or better, so I installed Linux _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Wallinius Mattias on 9 March, 2001 - 3:08 pm

For the record COM/DCOM exists on Linux but not GPL'd and DCOM protocol doesn't change to much. There is even a "free" full spec of it. To change the DCOM protocol fundamentally would really make "things" happen ;-). The DCE RPC also exists GPL'd. It has been a community project and I wouldn't call SUN RPC "standard", which one of all RPC protocols is the standard. They are all basically serialized callstacks, with different twists. Should the free GPL'd OPC server be built on MS platform or on Linux? For the Puffin PLC the name of "proprietary" doesn't sound right. /Mattias The opinion above is my own and etc,etc. _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Ryan Van Slooten on 9 March, 2001 - 3:31 pm

Hi all, I've been lurking a while and just had a couple of comments. Instead of focusing on OPC with DCOM and RPC, I would look at OPC/XML. While the standard isn't finished yet, it represents the future of OPC and eliminates the need for COM/DCOM and Microsoft dependence. Why spend time writing a custom protocol, when you can leverage the many tools available for XML and develop an open protocol? OPC offers so many benefits over Modbus including the transfer of many built-in datatypes, as well as structures and data quality status. I would recommend making OPC/XML the preferred method of communications and if someone still needed OPC 1.x-2.x you could build an OPC proxy server running on a Windows machine. Obviously, I'm a big XML and I remember a discussion about XML a while ago but don't remember how it turned out. Maybe OPC/XML isn't the correct protocol to standardize on, but I agree with Matthias that a "proprietary" protocol just doesn't suit the project. Ryan _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Ken Irving on 9 March, 2001 - 3:37 pm

On Fri, Mar 09, 2001 at 08:54:48AM -0800, Ryan Van Slooten wrote: > > I would recommend making OPC/XML the preferred method of > communications and if someone still needed OPC 1.x-2.x you > could build an OPC proxy server running on a Windows > machine. > > Obviously, I'm a big XML and I remember a discussion about > XML a while ago but don't remember how it turned out. > Maybe OPC/XML isn't the correct protocol to standardize on, > but I agree with Matthias that a "proprietary" protocol > just doesn't suit the project. I'm not sure that the various XML discussions really "turned out" one way or the other, but if there's an OPC/XML protocol either defined or in development it might be put to good use making this (LinuxPLC) effort usable by some proprietary MMI systems. I've been messing with XML and XML protcols for a while, but I'm not in a position to push any particular flavor. That depends on the willingness of information producers and users to agree on the specific language elements and structure, and the choices are really quite arbitrary. What seems to make sense to me is to try to make the protocol as clearly descriptive as possible; IOW, describe the problem (i.e., the information being transported), and try to use the description as the protocol. I've tried to do this for "generic" PLC queries, ladder logic programs, and other applications, perhaps to good effect. Until I have some way to demo/use/work these things, however, I'm not going to try to foist them off on folks for general use. OPC, DDE, etc., however are already defined and in place, and some way to tap in to those realms would be a good thing. I don't think that this would dictate the direction of this project, but would just be one way it could be used. Ken -- Ken Irving <jkirving@mosquitonet.com> _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Juan Carlos Orozco on 13 March, 2001 - 2:50 pm

Ryan Van Slooten proposed using OPC/XML instead of OPC/DCOM and I agree with him that this could be and interesting combination. I know that the drawback is that the specification is not ready, but maybe it will be in the time that we implement this part of the project (just guessing). I found the next link regarding this subject that may be of interest. http://www.froudeconsine.co.uk/town/estate/on50/xml.shtml Juan Carlos Orozco ACElab Industrial Automation jorozco@ace-lab.com www.ace-lab.com _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Wallinius Mattias on 13 March, 2001 - 4:02 pm

Has anyone even tried SOAP? The performance s..ks. We even wrote a small version doing the same, minimizing headers and all that stuff, still the same result. Parsing takes time and trying to invoke some code after parsing also takes time. In our experiment we use Java and COM. Phillipe Kahn said something like "A thing on a thing is never as fast as a thing." I consider the OPC/XML spec to be interesting but not for tasks like data collection from control systems. This is a spec for connecting high level systems to OPC and personally I don't think that the OPC type of data has anything to do in thoose systems. At least not with out some "treatment". For connectivity I think it would be nice to have OPC and adapt the interfaces for Java RMI/CORBA. I'll check what could be used to make an OPC server directly on Linux. I know that Software AG already has an DCOM implementation for Linux but I recon we can't use it without paying. I will look into the DCE RPC code and see whats needed and if anyone has started an ORPC project. Implementing the OPC parts are not that difficult. We could also consider using TAO or similar CORBA stuff to implement an abstraction layer very similar to OPC. Any other suggestions? XML should be last on the list due to performance. /Mattias _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Harald Albrecht on 13 March, 2001 - 5:29 pm

> Has anyone even tried SOAP? The performance > s..ks. We even wrote a small version doing the > same, minimizing headers and all that stuff, > still the same result. Parsing takes time and > trying to invoke some code after parsing > also takes time. Working with XML always involves quite some heavy cpu cycles for parsing. You can reduce them to some extend by a hand-written and hand- optimized parser, but then with needs a lot of coding effort and maintainance also tends to be heavy. Especially as the XML tool market is still a moving target, even with the fine Apache Xerces and Xalan packages, or with expat and Sablotron, it is no silver bullet. The idea of SOAP is to define a very flexible envelope and content representation identification system, much in the spirit of the way email is handled by RFC 821 and the MIME RFCs. To make that clear: SOAP just supplies one of the many possible serialization / representation schemes and it does not impose anything on the data model carried in a SOAP entity. Also, SOAP does not impose anything on the interaction schemes between SOAP communication partners. While probably seeming uncomforable abstract to many people, I consider SOAP to be a very good thing. From reading the spec it is well appearant that people like Don Box know how to object oriented technologies for information representation. The main reason behind the OPC Foundation's hype for XML is that they can not connect to many ERP, MIS systems. These systems are not Microsoft and almost in any case you will not find COM, neither DCOM. CORBA might be but at this time I'm not aware of a product offering CORBA interfaces in the area of factory and process automation. So OPC is not allowed to enter the important "upper levels". When I was at ISA Expo last autumn in New Orleans, all the MS spinmeisters talked up XML all the time and freely admitted that DCOM is dead as it can not be used to connect to ERP, etc. It is always astonishing how fast MS drops one technology and turns itself around 180 degrees. And then, they even admitted that OPC's hyped change-driven interfaces will most probably not survive in today's form, maybe not at all. They are not suitable for the interaction schemes necessary for communication with upper levels, but only for HMI. And HMI is only a *small* part of factory and process automation. Even connecting a online process simulator requires cyclic phase-locked communication, not the change-driven model almost any OPC servers implement. And being dependend on the way a particular OPC server implements interaction is the recipe for desaster. > In our experiment we use Java and COM. And SOAP as the "transport protocol", or did you use some home-grown transport layer? > Implementing the OPC parts are not that > difficult. That's why several commercial vendors are making a good living of selling OPC server frameworks (with ifak Magdeburg, SoftIng coming to my mind, but there are also others I don't remember at the moment). While in principle the OPC spec seems to be straightforward it can impose severe headaches: just think of the messed-up "browsing" interface and handling the process image and invoking callbacks. I wish you good luck for your undertaking -- ever met Augias and his stable, per chance? BTW -- are there any OPC client frameworks available? The divergence between the COM objects specified and the informal tag tree is a pain in the a*. And with Alarms&Events the thing is slowly going belly up. And then there's still the funny part of configuring DCOM on Linux. You have to edit the registry keys, so local applications know which remote COM objects are available on which other hosts. Oh, and did you think about firewalls and that there is no IIS available for Linux, so you can not tunnel DCOM via HTTP? Especially for OPC you need to be able to do this as the spec is heavily centered on either cyclically or change- driven callback notification. So you need HTTP- to-COM gateways/routers on both ends where COM objects sit: in both the OPC server and client. Just my .02 Euro. Harald -- Harald Albrecht Chair of Process Control Engineering RWTH Aachen University of Technology Turmstrasse 46, D-52064 Aachen, Germany Tel.: +49 241 80-7703, Fax: +49 241 8888-238 _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Wallinius Mattias on 14 March, 2001 - 9:39 am

-----Original Message----- From: Harald Albrecht [mailto:HARALD@plt.rwth-aachen.de] Wallinius Mattias <Mattias.Wallinius@tetrapak.com> wrote: > Has anyone even tried SOAP? The performance > s..ks. We even wrote a small version doing the > same, minimizing headers and all that stuff, > still the same result. Parsing takes time and > trying to invoke some code after parsing > also takes time. Working with XML always involves quite some heavy cpu cycles for parsing. You can reduce them to some extend by a hand-written and hand- optimized parser, but then with needs a lot of coding effort and maintainance also tends to be heavy. Especially as the XML tool market is still a moving target, even with the fine Apache Xerces and Xalan packages, or with expat and Sablotron, it is no silver bullet. The idea of SOAP is to define a very flexible envelope and content representation identification system, much in the spirit of the way email is handled by RFC 821 and the MIME RFCs. To make that clear: SOAP just supplies one of the many possible serialization / representation schemes and it does not impose anything on the data model carried in a SOAP entity. Also, SOAP does not impose anything on the interaction schemes between SOAP communication partners. [Mattias] I am not saying that SOAP isn't good. It's an excellent spec and no offence on Don or any other by the way. But for the purpose we use OPC forget SOAP and XML. And also all the SOAP toolkits available are in more or less beta stadium. While probably seeming uncomforable abstract to many people, I consider SOAP to be a very good thing. From reading the spec it is well appearant that people like Don Box know how to object oriented technologies for information representation. The main reason behind the OPC Foundation's hype for XML is that they can not connect to many ERP, MIS systems. These systems are not Microsoft and almost in any case you will not find COM, neither DCOM. CORBA might be but at this time I'm not aware of a product offering CORBA interfaces in the area of factory and process automation. So OPC is not allowed to enter the important "upper levels". [Mattias] I also find that ERP and MES system will change dramatically the coming years. I still don't see why and how you should use data from control systems in the ERP systems. It doesn't belong there with out being refined. The ERP systems have major flaws today and are target not for organisations rather for managment. When I was at ISA Expo last autumn in New Orleans, all the MS spinmeisters talked up XML all the time and freely admitted that DCOM is dead as it can not be used to connect to ERP, etc. It is always astonishing how fast MS drops one technology and turns itself around 180 degrees. And then, they even admitted that OPC's hyped change-driven interfaces will most probably not survive in today's form, maybe not at all. They are not suitable for the interaction schemes necessary for communication with upper levels, but only for HMI. And HMI is only a *small* part of factory and process automation. [Mattias] I don't see the HMI as the only part where you can use this. Data colletion for certain purposes are good sample. Even connecting a online process simulator requires cyclic phase-locked communication, not the change-driven model almost any OPC servers implement. And being dependend on the way a particular OPC server implements interaction is the recipe for desaster. [Mattias] We are not talking control here. For control, yes, cyclic phase-locked communication is required. For data collection no. I disagree with you. I can prove you wrong. ;-) > In our experiment we use Java and COM. And SOAP as the "transport protocol", or did you use some home-grown transport layer? [Mattias] We took SOAP and cut the specs and made something similar. Yes, we handcoded a lot to get up performance. The transport is so to say home grown but SOAP influenced. We would have prefered using SOAP but the libraries we tried to use were too much beta. We got better performance but I would say that an evolved SOAP will match that. > Implementing the OPC parts are not that > difficult. That's why several commercial vendors are making a good living of selling OPC server frameworks (with ifak Magdeburg, SoftIng coming to my mind, but there are also others I don't remember at the moment). [Mattias] COM isn't easy if you don't understand the model fully. Understanding COM and COM programming was and is a problem area. While in principle the OPC spec seems to be straightforward it can impose severe headaches: just think of the messed-up "browsing" interface and handling the process image and invoking callbacks. I wish you good luck for your undertaking -- ever met Augias and his stable, per chance? [Mattias] This has been done before ;-). The browsing interface isn't that bad. Yes, the OPC specs have flaws but there are worse than the browsing interface. BTW -- are there any OPC client frameworks available? The divergence between the COM objects specified and the informal tag tree is a pain in the a*. And with Alarms&Events the thing is slowly going belly up. [Mattias] There are no COM objects specified! Only interfaces. But the interfaces can easily lead to a certain design of objects. The divergence has a function. The "tag" tree, which by all means can be flat, is just the name of "item" objects that can be addressed. Then I agree that this interface could and should have been a bit differently designed. I can imagine why it looks like it looks considering some history. And then there's still the funny part of configuring DCOM on Linux. You have to edit the registry keys, so local applications know which remote COM objects are available on which other hosts. [Mattias] Why? I don't think it's wise to use it internally on Linux. There are other better ways for interprocess communication there. It should be used for connecting from Windows to Linux. There will exist Windows machines for a long time and so will Linux. Oh, and did you think about firewalls and that there is no IIS available for Linux, so you can not tunnel DCOM via HTTP? Especially for OPC you need to be able to do this as the spec is heavily centered on either cyclically or change- driven callback notification. So you need HTTP- to-COM gateways/routers on both ends where COM objects sit: in both the OPC server and client. [Mattias] Please get real. Do you use firewalls internaly in a production facility for example? Perhaps I didn't express my idea good enough. OPC is used and works fine. It's a way of getting connectivity to HMI,SCADA and MES systems. Yes, MES systems. Most MES systems today can use OPC. I have had a very good look around. There are problems with OPC, yes, but if you fairly easy can get the connectivity , why not. If you are to talk between PLC it is another story. By the way I really appreciate your patronizing tone ;-). _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Harald Albrecht on 14 March, 2001 - 10:09 am

> [Mattias] I also find that ERP and MES system > will change dramatically the coming years. I > still don't see why and how you should use > data from control systems in the ERP systems. > It doesn't belong there with out being refined. > The ERP systems have major flaws today and are > target not for organisations rather for > managment. Spoken straight to my heart ... both kinds of systems are typically sold this way: only sell them directly to the highest ranks and promise them everything. Once sold, make your living patching inappropiate brigdes and models. > [Mattias] I don't see the HMI as the only part > where you can use this. Data colletion for > certain purposes are good sample. While it is typicall done this way I think it's the wrong way up(tm). More than once customers end with huge, monolithic data bases -- nicknamed "data graves" here in Germany, because you burry your data for once and all. So comes "data mining" has become some kind of mass sports... Add archived data for other aspects, like hour counters, auto-calibration data, tear information, etc. You can either burry it in SAP or you can make the sensor the genuine source of information it knows better. And for archiving you simply do not need change-driven communication. Instead you want either phase- locked (urg) or batched transfer. I know of one large manufacturer of process automation systems who wants to get rid of spontaneous, change- driven reports from their field controllers and instead switch over to polling them. Memory isn't an issue any more with modern controllers. The whole system gets much more robust when faced with network failures and outages. > [Mattias] We are not talking control here. For > control, yes, cyclic phase-locked > communication is required. For data collection > no. I disagree with you. I can prove you > wrong. ;-) Of course you are right. But I have met so many engineers wanting only phase-locked communication for HMI. Especially I remember those coal mine where the control personnel wanted to get feedback within 20ms. Their own reaction time was at least two orders of magnitude slower, but then it is nice to know after 20ms that your fibre cable hanging 1300 meters down the shaft has just been ripped down. > [Mattias] There are no COM objects specified! > Only interfaces. Oh yes, of course! Caught with bad terminology ... shame on me! > But the interfaces can easily lead to a > certain design of objects. The divergence > has a function. The "tag" tree, which by all > means can be flat, is just the name of "item" > objects that can be addressed. Then I agree > that this interface could and should have been > a bit differently designed. I can imagine why > it looks like it looks considering some > history. I don't agree with you that the "tag" tree is meant to be flat. As far as I know nothing in the spec mentions or imposes that. However, implementors are free to represent all their tags in a flat "hierarchy". The problem I'm talking about is the following: a tag can either have a value or not if it is located a branch in the hierarchy. If the tag is a leaf it should have a value (unfortunately, the spec is very unclear about this). The problem behind this is that appearantly no-one thought about clearly separating the concept of data (leafs) and branches only acting as hierarchical order means. Probably this has been caused by putting the spec together much too fast without thinking about the information model elements at all. "No ma', no need'nk no stink'n data model" > [Mattias] Why? I don't think it's wise to use > it internally on Linux. There are other better > ways for interprocess communication there. It > should be used for connecting from Windows to > Linux. There will exist Windows machines for a > long time and so will Linux. I was not talking about interprocess communication -- I don't think that COM (or CORBA) is that bad for a specific kind of interprocess communication. I was talking about DCOM communication between a Linux and a Windows box. You *have* to configure the DCOM communication. No way around that. Roll-outs I've seen were slightly less than 1000 machines, unfortunately mainly diverse, so no simple set of images could be made and simply copied, but instead most machines had to be configured by hand. Just imagine Microsoft had invented the Web (they surely have, just ask Bill) and it had been implemented using DCOM. You would either have to configure communication with each web site individually (hacking the registry) or you would simply configure your box to contact only Microsoft's Web-DCOM portal for once and all, so they can control who is requesting what and what content gets delivered. Just imagine... > [Mattias] Please get real. Do you use > firewalls internaly in a production facility > for example? Yes (I'm not allowed to talk about names though). Hybrid systems, basically routers with traffic shaping and control lists. Those companies are running large production facilities and each part has to be separated from all others. One of the many reasons to keep broadcast traffic to an absolute minimum, other reasons is to make sure that only specific information can travel accross the facilities. > Most MES systems today can use OPC. Maybe I'm not that well informed. What kind of industry you are working in: factory or process automation? I'm not aware of large process industry plants here in Germany which run OPC with their MES, ERP systems. But probably I don't have the full picture. Harald -- Harald Albrecht Chair of Process Control Engineering RWTH Aachen University of Technology Turmstrasse 46, D-52064 Aachen, Germany Tel.: +49 241 80-7703, Fax: +49 241 8888-238 _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 14 March, 2001 - 10:14 am

Thank you Harald. It is my opinion that we can find something more appropriate without much effort. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Harald Albrecht on 14 March, 2001 - 10:18 am

Curt, > It is my opinion that we can find something > more appropriate without much effort. My previous mail should not be OPC, (D)COM or MS bashing. I just wanted to point out properties of these technologies, which are in my very own opinion currently weak points. From lurking around the list I get the impression that while the goal of the PuffinPLC is to create a Linux-based PLC (sic!), there is no common agreement about what functionality a PLC constitutes (you might also call it "modules", but that sounds rather like an implementation aspect). This problem is not new and manifests itself within many houses (industrial manufacturers and users) and is partly caused by different cultures in factory and process automation. Probably everybody agrees that communication with other systems is needed (wanted) and disagrees about the technology to use. But it is still not evident to me what functionality should be provided by a Puffin PLC -- probably part of this are the sections four and five in the FAQ. Part of this problem showed up in the discussion Mattias Wallinius and I had about OPC: his communication needs differ in some areas greatly from what I need in our projects -- things like online engineering of field controllers and many other things come to mind. In other places we do probably very much agree about the way to tackle a particular problem/task and what technologies are currently not well suited to do this. Just my Euro .02 (gaining some small ground on cents...) Harald -- Harald Albrecht Chair of Process Control Engineering RWTH Aachen University of Technology Turmstrasse 46, D-52064 Aachen, Germany Tel.: +49 241 80-7703, Fax: +49 241 8888-238 _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 14 March, 2001 - 10:29 am

Hi Harald Addressing the group: At the moment, I am not ms or opc or dcom bashing either. My question is specifically why do we want/need them. I've been automating things for a while and have never had the requirement to connect to a spreadsheet or wordprocessor. What is behind this push to use MS IP? ( Yes, I know it's "open" ) And I'm asking folks as a serious question. I have only a vague idea of what this stuff is used for, it's a Windows only game, and I'm trying to get over a knee jerk reaction that it will make us dependent on having at least one Windows server around someplace for it to be of any use. Nobody has mentioned just why they want it, only that they do. I've already said that if they want to write it and it doesn't encumber us legally and it can be GPL'd we'll have it. I'm still in the dark as to why. I'd rather solve these problems the Linux way as the MS methods _always_ have a hidden agenda and typically suck. (Fact not bash) They also are often restricted to X86 and of course, Windows platforms. I have a fairly clear idea of what we intend to do with LPLC. First we want to do PC based control in the manner of PLC's. We would like to be compatible with as many existing systems as possible so that we can use whatever IO hardware the customer wants and we can bridge protos when desired. We want and need an all Linux suite of tools and languages so we can be self hosted and self supporting. These can all be distributed among machines as that is inherent in the Linux way of doing things. All free and open of course. Second we want to be able to do SCADA and HMI so you can have a complete automation system running our free, open, alternative without regard for the number of seats and other restrictions. Between GNU and Linux we have all the tools to do this without any restrictions. Third we want to do whatever you want to do with automation tools but couldn't because you didn't have choice. We provide a free platform for education, a vendor neutral environment and the means to go between disparate systems. If there's something you want to do that we don't provide, we provide 98% of what you need so you only have to write the 2% and then we all have it. The OSS tools we build can then be used for other OSS projects that we can gain from and to open up automation in general. Fourth we want to change an industry by showing it how much better and simpler things can be when people share and cooperate. We want to be able to do this on any of the platforms Linux runs on from ucsimm to Beowolf, from Dragonball to Alpha to S390. (Getting carried away) Basically we want for people to be able to do automation systems without getting raped or locked in or starved for the information to make their project a success. And we want to do it on the best platform going for automation, Linux. FOR the people who need it. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Todd Lyons on 14 March, 2001 - 12:33 pm

Curt Wuollet wrote: > us dependent on having at least one Windows server > around someplace for it to be of any use. Nobody Are you discounting Samba? With a Linux box serving an NT domain (or even workgroup), no M$ server is necessary. Or am I missing the point of your message? -- Blue skies... Todd | Get a bigger hammer! | Never mind me. I'm speaking out of | | http://www.mrball.net | my /dev/ass anyway. | | http://faq.mrball.net | --Gash Teshome | _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 14 March, 2001 - 12:58 pm

Hi Todd That could very well be true, I don't know just what people have in mind exactly. I suspect they _want_ to achieve automation systems that are 90% Windows. I am certainly not a Windows expert. Again addressing the group: I don't care if we interface with Windows, but if we need a Windows license to have a complete system, we have failed in my estimation. I am also not too keen on being blown out of the water by something Redmond changes or does, possibly just for that purpose, as they have a long history of such conduct. I don't mind interoperability, in fact that's to be encouraged. I have a real problem with any kind of dependence on anything not OSS, whether controlled by MS, a consortium of MS lackeys or even automation consortia who could have reason to want us suppressed. We just can't depend on potential malefactors. I wish them no ill will, but it's not wise to count on them for our survival as a project. IMHO To present a credible alternative we need a Linux way of doing everything. SAMBA is the Linux way of doing MS file shares, for example. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Ken Irving on 14 March, 2001 - 2:31 pm

On Wed, Mar 14, 2001 at 07:29:05PM -0600, Curt Wuollet wrote: > > I don't care if we interface with Windows, but if we need > a Windows license to have a complete system, we have failed in my > estimation. I am also not too keen on being blown out of the water by > something Redmond changes or does, possibly just for that purpose, > as they have a long history of such conduct. I don't mind interoperability, > in fact that's to be encouraged. I have a real problem with any kind of My impression at the beginning of this thread was that the goal was to be able to interface the LinuxPLC with existing MMIs, and I think that's in line with the interoperability you mention. Also, the question was for a GPLd way to do this, in line with the open nature of the project. I don't see anything like a move to adopt MS "standards" into the LinuxPLC project itself, but just a way to make it possible to use the LinuxPLC with other systems. > ... > for our survival as a project. IMHO To present a credible alternative > we need a Linux way of doing everything. SAMBA is the Linux way > of doing MS file shares, for example. I agree, and MMIs, historians, alarm managers, etc., will all be developed and made available in due course. I don't think that having interfaces to other systems weakens this project. Ken -- Ken Irving <jkirving@mosquitonet.com> _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 14 March, 2001 - 4:29 pm

Ken Irving wrote: > On Wed, Mar 14, 2001 at 07:29:05PM -0600, Curt Wuollet wrote: > > > > I don't care if we interface with Windows, but if we need > > a Windows license to have a complete system, we have failed in my > > estimation. I am also not too keen on being blown out of the water by > > something Redmond changes or does, possibly just for that purpose, > > as they have a long history of such conduct. I don't mind interoperability, > > in fact that's to be encouraged. I have a real problem with any kind of > > My impression at the beginning of this thread was that the goal > was to be able to interface the LinuxPLC with existing MMIs, and > I think that's in line with the interoperability you mention. Also, > the question was for a GPLd way to do this, in line with the open > nature of the project. I don't see anything like a move to adopt > MS "standards" into the LinuxPLC project itself, but just a way to > make it possible to use the LinuxPLC with other systems. And I thank you Ken, that's the first real reason I have heard for having it. Of course, it would be cheaper to do Linux MMI and more reliable, but at least that is a plausible reason. I am also most interested in anything we could do with OPC that we can't do within Linux. > > ... > > for our survival as a project. IMHO To present a credible alternative > > we need a Linux way of doing everything. SAMBA is the Linux way > > of doing MS file shares, for example. > > I agree, and MMIs, historians, alarm managers, etc., will all > be developed and made available in due course. I don't think > that having interfaces to other systems weakens this project. I'm pretty sure that all of that is available for Linux now, but not free or open. Also from my perspective, given the long service life of most automation solutions, if they get what they want with Windows today we won't have another opportunity for many years. I am unabashedly in favor or all Linux systems wherever possible. It's how we deliver the most benefit. and the only way to establish a reputation for reliability and lower support costs. If we hook in to an existing disaster, it's still a disaster. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Ken Irving on 14 March, 2001 - 4:56 pm

On Wed, Mar 14, 2001 at 10:49:56PM -0600, Curt Wuollet wrote: > Ken Irving wrote: > > > > My impression at the beginning of this thread was that the goal > > was to be able to interface the LinuxPLC with existing MMIs, and > > I think that's in line with the interoperability you mention. Also, > > the question was for a GPLd way to do this, in line with the open > > nature of the project. I don't see anything like a move to adopt > > MS "standards" into the LinuxPLC project itself, but just a way to > > make it possible to use the LinuxPLC with other systems. > > And I thank you Ken, that's the first real reason I have heard for having it. > Of course, it would be cheaper to do Linux MMI and more reliable, but at > least that is a plausible reason. I am also most interested in anything we > could do with OPC that we can't do within Linux. My hope is that those Linux MMIs will stand up to the competition on an equal (or more so ;) basis, when they're available and demonstrable. But I have potential customers/clients who have standardized on Wonderware, for instance, and any control system that is proposed to part of their systems has to work with that system. AFAIK, that means OPC or DDE. One way I've (only) thought about implementing such a thing would be to use a commercial product on the MS side (e.g., Software Wedge) to communicate via TCP/IP to a protocol running on Linux or other platform. The systems I'm thinking of don't need extreme performance, either, just something that works reliably. > Also from my perspective, given the long service life of most > automation solutions, if they get what they want with Windows today > we won't have another opportunity for many years. I am unabashedly > in favor or all Linux systems wherever possible. It's how we deliver > the most benefit. and the only way to establish a reputation for reliability > and lower support costs. If we hook in to an existing disaster, it's still > a disaster. One scenario I'd hope to be involved with would be to deploy a Linux server to a control system, whether LinuxPLC or a gateway to another system, so that it works with the customer's chosen and existing front end. Then, be able to demo a Linux-based MMI or services on the same server, without involving the BigName front end at all, e.g. perhaps via a web interface. IOW, the same scheme that has gotten Linux into a lot of systems without the PHBs even being aware of what's going on. Ken -- Ken Irving <jkirving@mosquitonet.com> _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 15 March, 2001 - 3:57 pm

Thanks Ken That's all I'm asking for is real life examples. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By David Nimmons on 15 March, 2001 - 3:59 pm

Wonderware and other MMI's do not use OPC to communicate with the hardware, but instead use Modbus, DH+, ControlNet, etc. OPC is used to allow external applications such as spreadsheets access to the process data, with Wonderware acting as the OPC server. For Wonderware to communicate with the LinuxPLC, all that is required is a driver for Wonderware that speaks the LinuxPLC protocol. Wonderware will then provide the OPC access. When we develop a Linux based MMI, then we have to decide whether or not to provide OPC functionality. Since so many 3rd party applications depend on OPC for access it would probably be desirable. At the plant where I work we use Aspen for our historical trending and Pavilion for advanced process control. These communicate with our Foxboro and ABB DCS's using OPC. These are both Unix based systems and if I am not mistaken the OPC server runs on the Unix machines, so it should be possible to implement OPC without requiring Windows. I, personally would prefer to come up with our own protocol and convince all the third party vendors to support it also since I hate using anything associated with Microsoft, but, reality being what it is....... Ken Irving wrote: >My hope is that those Linux MMIs will stand up to the competition on an equal (or more so ;) basis, when they're available and demonstrable. But I have potential customers/clients who have standardized on Wonderware, for instance, and any control system that is proposed to part of their systems has to work with that system. AFAIK, that means OPC or DDE. < _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Juan Carlos Orozco on 14 March, 2001 - 4:31 pm

I want to back up Ken Irving's impression, the main motivation for doing OPC in LPLC is to be able to communicate with all the MMI that are already out there in the factory floor. Intellution, Wonderware, WinCC, Rockwell, etc. all have the possibility of communicating with OPC servers, the other solution is to have a driver for LPLC for each one of those systems which is very unpractical (see next paragraph for more possible solutions to this). The motivation for OPC is certainly not just for fun and also not to restrict this project to an external authority it is just a way of interoperating with OPC compliant systems. The OPC dilema may not be our highest priority for the moment but it is a good idea to forsee the direction of the project in advance. There have been several proposals to achieve this goal so far: 1 Implementing DCOM and OPC in Linux, Advantages: Total integration in Linux of the LPLC and transparent interoperability with OPC clients. Disadvantages: Very complex project to code. 2 Use modbus with existing OPC-modbus drivers running on windows to interoperate with LPLC. Advantages: This solution is ready to be used. Disadvantages: This should be taken as a less common denominator for this type of connectivity and not as the solution to the problem. We can not have named tags, alarms, history elements. One of the important improvements in integrated automation systems is to be able to manage the IO points by name in just one place. This way the project keeps its names synchronized when we do a change of name or when we move the signal from one input to another. 3 Write an OPC-LPLC bridge that runs on windows. Advantages: We can use the other features in OPC that we had to compromise in the previous solution. This is a solution where we see OPC as a temporary solution and not an integral part of our project. Disadvantages: Not so easy to write, although not so complex as the first case. We will not be able to integrate this as our PLC MMI communication solution because it can not run on Linux. 4 Use OPC using XML with the new specs that are currently being developed by OPC. By the way the other 3 solutions where OPC-DCOM. Advantages: We don't rely on DCOM which is proprietary. We could use this solution as an integral part of our PLC MMI communication solution. We will be compatible with third party solutions that adopt this protocol in the future. It can run on Linux natively. Disadvantages: The spec is not ready yet. There is a speed penalty (for this we could use alternative communication protocols for XML and SOAP maybe corba). Also not easy to code more or less like the previous case. We wont be able to integrate to OPC/DCOM systems. The important difference between some of this solutions are how deep into our design should OPC be integrated? We need to answer some questions to have a solution for this. Is OPC the way of the future for PLC-MMI communication? Do we want to create a solution that competes with OPC? How open is OPC really? its roots in DCOM even in their name are a major psychological barrier for a project like LPLC. OPC is not perfect but it is also a work in progress and it has more time in the field and with a very respectable penetration. IMHO if we don't want to depend on OPC at least we should create something so similar that when we make a bridge to OPC we can communicate BOTH WAYS in a transparent form. We could take different approaches taking one or a combination of some of the solutions as our strategy to communicate with OPC depending on our view of the future of OPC. The alternative to not taking OPC into account is that we create an alternative protocol to OPC and our own MMI or a third party MMI that use our protocol. I don't see this happening any time soon. Remember that this new MMI has to compete with Wonderware, Intellution, etc. I am not saying this is not possible, I find an open source alternative for this MMIs very compelling. It is just that this is a non trivial task and it will take some time to develop and some more time to penetrate in the market. And maybe as usual we are going to see both solutions coexist so we better set some ground to communicate with them as clear as we can. SAMBA is a good example of the benefits that we can have by communicating with the rest of the automation applications. Juan Carlos Orozco ACElab Industrial Automation jorozco@ace-lab.com www.ace-lab.com _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 15 March, 2001 - 4:01 pm

Hi Juan There is another possibility that I like, replace all that expensive stuff with Linux stuff. I have to think that way, being a peripheral on a massive NT network doesn't do it for me. And I need to think that's possible and a major improvement. Otherwise what are we trying to do here? I am pragmatic enough to see your point and I'm not criticizing you, but we gotta have goals and it's my job to focus on them. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Juan Carlos Orozco on 15 March, 2001 - 4:41 pm

Hi Curt, First of all, I want to say that I am not trying to persuade to use OPC and specially not trying to persuade to use DCOM into this project. It may seem this way because what I am in favor is to achieve maximum interoperability for the LPLC project, I think this is the best way of achieving exactly what you intend, this is to replace the expensive stuff with Linux stuff. OPC is to LPLC what SAMBA is to Linux. And modbus is to LPLC what ftp is to Linux (in the file sharing sense). The second analogy needs some explanation, modbus and ftp are both very good things and desirable to have them, the problem is that for certain applications (windows file sharing in the case of ftp) it does not integrate so well to the environment. Specifically it would be a good thing to have an exposed catalog of the available IO points of the LPLC with human readable names to interconnect with an MMI. As a real life example, a customer with Wonderware for a plant supervision and about 10 machines with a mixture of Siemens S5, S7 and SLCs integrates a network using two separated local networks (RS485) each to communicate with Siemens and AB. The networks end on a windows machine and Wonderware communicates with all of their machines for plant supervision. As an exercise how could we migrate to Linux in this company. The first step would be probably to put in new machine automations an LPLC with modbus and integrate to the Wonderware machine via a separate modbus RS485 or modbus/tcp. The next step besides putting more machines with LPLC would be to try to change Wonderware (when LPLC has a competing software available). One option for this step is that our MMI can be used as OPC client and use the information available from the other non LPLC networks maybe as an intermediate step. Other probably better solution could be to use network cards and Linux drivers to integrate LPLC MMI to the Siemens and AB PLC networks. One possible scenario is that a customer such as this will be reluctant to switch to another MMI because a) The one they have work and they are afraid of trying something new, b) Even if the new MMI is free it is very expensive to program all their specific configurations for their plant. In a company that this last scenario is the case is where a complete integration via OPC of the machines that use LPLC become first class citizens and a compelling option against other brand PLCs. Conclusions: OPC is not the only solution to integrate LPLC to current PLC networks (Profibus, Devicenet, etc...) but it is one possible solution. For some private networks like siemens MPI it could be the only solution other than doing a special driver. A very desirable feature for a LPLC is to expose a catalog of available services, alarms, IO, History using human readable names. This could be achieved using OPC or inventing our own protocol. For LPLC to become a first class citizen on windows based supervisory systems such as Wonderware, Intellution, etc... it would be good to have an OPC bridge that takes into account the previous features. This is where the first analogies in this writing applies. It is a good idea to think of replacing the expensive stuff with Linux stuff but it is not realistic at least for some years to come. Juan Carlos Orozco ACElab Industrial Automation jorozco@ace-lab.com www.ace-lab.com _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 16 March, 2001 - 3:08 pm

Hi Juan Juan Carlos Orozco wrote: > > Hi Curt, > First of all, I want to say that I am not trying to persuade to use OPC and > specially not trying to persuade to use DCOM into this project. It may seem > this way because what I am in favor is to achieve maximum interoperability > for the LPLC project, I think this is the best way of achieving exactly what > you intend, this is to replace the expensive stuff with Linux stuff. > > OPC is to LPLC what SAMBA is to Linux. And modbus is to LPLC what ftp is to > Linux (in the file sharing sense). The second analogy needs some > explanation, modbus and ftp are both very good things and desirable to have > them, the problem is that for certain applications (windows file sharing in > the case of ftp) it does not integrate so well to the environment. > Specifically it would be a good thing to have an exposed catalog of the > available IO points of the LPLC with human readable names to interconnect > with an MMI. Yes, it would. We don't need Windows to do that. > > As a real life example, a customer with Wonderware for a plant supervision > and about 10 machines with a mixture of Siemens S5, S7 and SLCs integrates a > network using two separated local networks (RS485) each to communicate with > Siemens and AB. The networks end on a windows machine and Wonderware > communicates with all of their machines for plant supervision. As an > exercise how could we migrate to Linux in this company. The first step would > be probably to put in new machine automations an LPLC with modbus and > integrate to the Wonderware machine via a separate modbus RS485 or > modbus/tcp. The next step besides putting more machines with LPLC would be > to try to change Wonderware (when LPLC has a competing software available). > One option for this step is that our MMI can be used as OPC client and use > the information available from the other non LPLC networks maybe as an > intermediate step. Other probably better solution could be to use network > cards and Linux drivers to integrate LPLC MMI to the Siemens and AB PLC > networks. One possible scenario is that a customer such as this will be > reluctant to switch to another MMI because a) The one they have work and > they are afraid of trying something new, b) Even if the new MMI is free it > is very expensive to program all their specific configurations for their > plant. In a company that this last scenario is the case is where a complete > integration via OPC of the machines that use LPLC become first class > citizens and a compelling option against other brand PLCs. > > Conclusions: > > OPC is not the only solution to integrate LPLC to current PLC networks > (Profibus, Devicenet, etc...) but it is one possible solution. For some > private networks like siemens MPI it could be the only solution other than > doing a special driver. This one interests me. > A very desirable feature for a LPLC is to expose a catalog of available > services, alarms, IO, History using human readable names. This could be > achieved using OPC or inventing our own protocol. Or even with some existing cross platform products. > For LPLC to become a first class citizen on windows based supervisory > systems such as Wonderware, Intellution, etc... it would be good to have an > OPC bridge that takes into account the previous features. This is where the > first analogies in this writing applies. This one seems to interest other people a lot. But this is where we could do the most good with replacement. > It is a good idea to think of replacing the expensive stuff with Linux > stuff but it is not realistic at least for some years to come. I find that attitude very fatalistic. There is a great deal of application code that could be shared with the project if we can provide the basis and make it attractive. You are assuming that we will have to write all this with our tiny group of coders. That's like assuming that Linus wrote all of what we call Linux himself. At least 95% of Linux is contributed from outside the core kernel development group. This, not the genius of a few is what makes OSS work. Once we have a platform for add-ons we can expand the number of contributors exponentially. Consider this, everyone who has written their own software for automation, HMI, SCADA, etc. has done so for much the same reasons that we are doing LPLC. This maverick software is very difficult to market on it's own. If you can combine it as a whole package, it becomes much more viable. If you can shift your model to services and contribute the software to the cause you stand to gain immensely compared to letting it molder. It will happen, all we have to do is frame the movement and get it moving. It's much better to be a part of a strong OSS movement than to craft even the most elegant software that is used only once and no one else sees. Think about it, all the ingredients are there, we need to provide the catalyst. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Harald Albrecht on 14 March, 2001 - 12:37 pm

Curt, > My question is specifically why do we > want/need them. I've been automating things > for a while and have never had the requirement > to connect to a spreadsheet or wordprocessor. > What is behind this push to use MS IP? So I have successfully managed to cover my Unix and Linux background completely ;) My collegues are still killing themselves laughing when they think about me being considered pushing MS IP. To clear the situation I would like to cite Marshall T. Rose (of SNMP fame) about ISO, with a slight change: "Pushing MS IP means pushing it over the cliff". > I've been automating things for a while and > have never had the requirement to connect to a > spreadsheet or wordprocessor. Perfectly comprehensible. While I am also not a fan of SIA (Spreadsheets In Automation), we have over here control personnel which uses Excel for report generation. It's easy to learn for them and no need to buy a separate and expensive report generator. Of course, MS Office isn't inexpensive to say the least, but administration is often like the wheather ... clouded. > And I'm asking folks as a serious question. That was also my intend when I brought up my questions and discoveries. But maybe you could not see the wood for the many trees I put up. As for the OPC/COM question I would suggest to do a Windows local bridge, which is COM to MS applications and which runs some LPLC protocol. No need to create a compatible DCOM environment on Linux. But as this is still a large amount of work to manage, probably no-one wants to do it, at least right now when the things Curt mentioned have still to be done (perfectly comprehensible). > We want to be able to do this on any of the > platforms Linux runs on from ucsimm to > Beowolf, from Dragonball to Alpha to S390. While not running Linux, Alphas are deployed for quite some time in process plants over here in Germany. One customer has quite a bunch of Alphas with 2GB RAM running large object databases which are used for plant supervision. And for the other side of the range, "intelligent" remote i/o running Linux would be a nice vision... With best regards, Harald -- Harald Albrecht Chair of Process Control Engineering RWTH Aachen University of Technology Turmstrasse 46, D-52064 Aachen, Germany Tel.: +49 241 80-7703, Fax: +49 241 8888-238 _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 14 March, 2001 - 2:32 pm

Harald Albrecht wrote: > Curt, > > > My question is specifically why do we > > want/need them. I've been automating things > > for a while and have never had the requirement > > to connect to a spreadsheet or wordprocessor. > > What is behind this push to use MS IP? > So I have successfully managed to cover my Unix > and Linux background completely ;) My collegues > are still killing themselves laughing when they > think about me being considered pushing MS IP. > To clear the situation I would like to cite > Marshall T. Rose (of SNMP fame) about ISO, with > a slight change: "Pushing MS IP means pushing it > over the cliff". No Harald, I know who you are. Your contributions are legion and I am much in your debt. I wasn't implying that you were pushing MS IP although I am happy I could give your colleagues a good laugh. I quite often mix group comment with individual reply. Rude of me, I know, but I did mention at the top I was addressing the group. We have some folks who are constantly suggesting MS "innovations" for our use which I have a hard time seeing as appropriate without some explanation. > > I've been automating things for a while and > > have never had the requirement to connect to a > > spreadsheet or wordprocessor. > > Perfectly comprehensible. While I am also not a > fan of SIA (Spreadsheets In Automation), we have > over here control personnel which uses Excel for > report generation. It's easy to learn for them > and no need to buy a separate and expensive > report generator. Of course, MS Office isn't > inexpensive to say the least, but administration > is often like the wheather ... clouded. > > > And I'm asking folks as a serious question. > > That was also my intend when I brought up my > questions and discoveries. But maybe you could > not see the wood for the many trees I put up. > > As for the OPC/COM question I would suggest to > do a Windows local bridge, which is COM to MS > applications and which runs some LPLC protocol. > No need to create a compatible DCOM environment > on Linux. But as this is still a large amount of > work to manage, probably no-one wants to do it, > at least right now when the things Curt > mentioned have still to be done (perfectly > comprehensible). ********** group questions *********** I understood that much, that we would be able to pump data to a Windows system. How much of that do people do and for what purposes? Is it essential? Strategic? merely neat? Or will it sell more Windows? **************************************** > > We want to be able to do this on any of the > > platforms Linux runs on from ucsimm to > > Beowolf, from Dragonball to Alpha to S390. > > While not running Linux, Alphas are deployed for > quite some time in process plants over here in > Germany. One customer has quite a bunch of > Alphas with 2GB RAM running large object > databases which are used for plant supervision. > And for the other side of the range, > "intelligent" remote i/o running Linux would be > a nice vision... The intelligent IO running Linux _will_ happen. Even if I have to fund it entirely out of pocket. It will take a while in that event but it will happen. > With best regards, > Harald And warmest regards from this end cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Frank Gross on 14 March, 2001 - 4:27 pm

Sorry to say I have been doing nothing but lurking. However many of our customers are requesting database and spreadsheet interfacing some even request retrofit on old equipment. We may be a special case since we are a specialty marking device manufacturer. For what it is worth. _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 15 March, 2001 - 12:39 pm

Hi Frank, You ought to come up more often. I would imagine that you have specialty software to support. Another plausible reason. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Ryan Van Slooten on 14 March, 2001 - 12:36 pm

I think the issue Harald brought up needs to be addressed before any new protocol is developed. Namely, what is the purpose of the protocol and what needs does the protocol address? At first glance of the mentioned OIC proposal, I fail to see any compelling reason to use OIC instead of Modbus. Does OIC have (substantial) benefits over Modbus? Most of the discussions of protocols involve the desire to provide more information than simple protocols, such as Modbus, provide. OPC, despite its faults, has a number of advantages over simple protocols. Unfortunately, I would never want to put the COM/DCOM mess on a PLC. That is why the XML option seemed attractive. Unfortunately, that is also paired with SOAP which adds more overhead (I wouldn't mind forgetting the SOAP altogether but performance still wouldn't be enough for some). Therefore, it seems that an interesting alternative would be OPC/WAP. WAP is a form of binary XML, which ideally would reduce much of the parsing overhead. Please see http://www.w3.org/TR/wbxml/ for the latest proposal or http://www.wapforum.org/ for other information. I haven't looked into the possibility of OPC/WAP, but it seems feasible. However, ACPLT/KS looked quite promising. I don't know if there are major performance issues with that, but it would probably be easier to port that than any of the other projects mentioned. Just my $0.02 (not earning much at the moment...) Ryan --- Harald Albrecht <HARALD@plt.rwth-aachen.de> wrote: > <snip...> > Part of this problem showed up in the discussion > Mattias Wallinius and I had about OPC: his > communication needs differ in some areas greatly > from what I need in our projects -- things like > online engineering of field controllers and many > other things come to mind. In other places we do > probably very much agree about the way to tackle > a particular problem/task and what technologies > are currently not well suited to do this. > <snip...> > > Just my Euro .02 (gaining some small ground on > cents...) > Harald _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 14 March, 2001 - 10:13 am

Hi I agree more or less completely, I'm also searching for the compelling reason to use these technologies for automation. Seriously, what does this buy us that is so relevant to automation? Can someone please explain? Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Jake Brodsky on 13 March, 2001 - 2:52 pm

On Fri, 9 Mar 2001 08:54:48 -0800 (PST), Ryan Van Slooten wrote: >Hi all, I've been lurking a while and just had a couple of >comments. Instead of focusing on OPC with DCOM and RPC, I >would look at OPC/XML. While the standard isn't finished >yet, it represents the future of OPC and eliminates the >need for COM/DCOM and Microsoft dependence. Why spend time >writing a custom protocol, when you can leverage the many >tools available for XML and develop an open protocol? OPC >offers so many benefits over Modbus including the transfer >of many built-in datatypes, as well as structures and data >quality status. /* De-lurking */ Why focus on one or the other? Is there a reason we couldn't or shouldn't do both? I happen to have a fairly sizable installed base of OPC based apps which would have to be scrapped if LPLC went to XML. On the other hand, I'd love to have a migration path... /* Lurking */ Jake Brodsky, mailto:frussle@erols.com "Nearly fifty percent of all graduates came from the bottom half of the class." _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Campbell, David (Ex AS17) on 12 March, 2001 - 9:28 am

Wallinius Mattias wrote: > For the record COM/DCOM exists on Linux but not GPL'd and > DCOM protocol doesn't change to much. *cough quietly* http://sourceforge.net/projects/freedce Project description: "A free implementation of DCE RPC, with development aimed at implementing DCOM for Linux (and other UNIX systems)." David Campbell _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 13 March, 2001 - 2:21 pm

Hi all, I am going to take my leader hat off and express a rare personal opinion that some may find offensive. Those who do can write it off to my personal anti MS biases and general ignorance. <rant=1> I think the whole idea of mixing office automation and factory automation is a solution with no problem and would be extremely difficult to justify on it's engineering and technical merit. The fact that it's extremely popular has more to do with the fact that it's one of the very few openings into the sealed black box of Windows than any notion that it is a good way to accomplish what it is used for. Since Linux doesn't have this crippling handicap, I would rather accomplish those same goals with any number of much more lightweight and simpler means available. I would prefer to change an industry with examples of better engineering rather than entrench poor decisions made in the past. The same goes for buzzword compliance. .NET will be ballyhooed and will be bought and paid for by everyone who uses Windows, thus it too will be popular regardless of it's merit or applicability to a given field. Widely used and "popular" entities forced on a population by a monopoly seldom equate with the best solution for the problem at hand. We have the enormous advantage of complete access and knowledge of our environment and the freedom to start with a "clean sheet of paper". To the extent that the work of others is better than what could be done with the OSS advantage, let's make use of it. If it's not how you would do it starting with a clean sheet of paper _for the purposes we need to accomplish_ then let's do it right. Where we break with whatever everyone else is forced to do will not be simply another proprietary fragment, what we do better is available to all. Some of the things being done as of late in this industry are so far removed from what rational solutions and methods for the purpose would be that practically anything else would be an improvement IMHO. There are some truly insane schemes that persist only because a large part of the population has no other choice. I have mentioned no names or trademarks of present day items on purpose. If you think you know which I'm talking about it's probably one of them in your own mind. <rant=0> Putting my hat back on, I recognize the value of integration to those of you who have to work with Windows. If you can write it or can get someone to write it and it can be GPL'd, we'll have it. I can't help out much as there are no Windows machines here or any place I work. There is a certain degree of standardization and the number of doodads that can be made to work this way is impressive. I'm not sure if it can be made native within our scope as I would expect it requires very specific knowledge, some secret. (Yes, I know it says open) A bridge or gateway would be an option if we could find an optimal intermediary protocol. Perhaps those interested could form a SIG and do some more research, that would be productive. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

Hi Curt: On Saturday 10 March 2001 03:51, you wrote: > I am going to take my leader hat off and express a rare personal > opinion that some may find offensive. > Those who do can write it off to my personal anti MS biases and > general ignorance. Go right ahead, EVERYONE deserves a chance to vent once in a while. > <rant=1> > I think the whole idea of mixing office automation and factory > automation is a solution with no problem and would be extremely > difficult to justify on it's engineering and technical merit. << rest of rant snipped to save space... >> > <rant=0> It's an unfortunate state of affairs that we live in. It all started with the dumbing down of computers. We have been in a rapid downword spiral ever since. As long as we continue to have computer users who aren't computer literate, we will have people who are sold on the use of buzzwords. Keep the faith pal, it's all we can do for now... > Putting my hat back on, I recognize the value of integration > to those of you who have to work with Windows. If you can write > it or can get someone to write it and it can be GPL'd, we'll > have it. I can't help out much as there are no Windows machines > here or any place I work. There is a certain degree of > standardization and the number of doodads that can be made to > work this way is impressive. I'm not sure if it can be made > native within our scope as I would expect it requires very > specific knowlege, some secret. (Yes, I know it says open) > A bridge or gateway would be an option if we could find an > optimal intermediary protocol. Perhaps those interested could > form a SIG and do some more research, that would be productive. Hmmm, maybe this is the perfect opportunity for me to step back into the foray. I certainly have been out on the sidelines for a touch too long and I do need to get back into a "major project". Coupled with the fact that I am no longer with GM (thank GOD!), I am unencumbered as far as "outside work" is concerned. Maybe I can even contribute something useful! :) I would like the opportunity to take this bull by the horns. I would like to lead the open source effort to build a truely open communications standard that can be used industry wide to communicate with the PuffinPLC (obviously) as well as most major "proprietary" PLC platforms (AB, Modicon, Siemens, maybe even Automation Direct). I envision something simular to OPC but completely open sourced (and LGPL'd) - including the mechanism behind the protocol (OPC relies on OLE technology, certainly not an open-source mechanism). I'll work on a basic draft document this weekend (I hope, 3 yr old son wants to go see Monster Truck show at the Silverdome this weekend). If not, it'll be shortly thereafter. What do ya think? Should I go forward with this or should I crawl back to my lurker status? :) -- Ron Gage - Saginaw, MI (ron@rongage.org) _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 13 March, 2001 - 2:34 pm

Hi Ron Sure, go ahead. You might even try to pull in some of those with strong opinions and get them out of lurkerdom as well. I don't know if we'll ever get a "other end" for a LPLC proto but we can try, maybe make our own IO as well. I recall a salesman who was enthusiastically selling me the "factory floor to the boardroom in Minutes" bit until he noticed we had no Windows PC's. I should have bet him lunch. I gave him a Linux CD and a smile and went back to work. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Jeff Thurman on 13 March, 2001 - 2:36 pm

Curt: I'm currently one of the learkers around this project and normally stay out of the discussions. This time I will inject some thoughts concerning items you have brought up. <rant=1> I do not disagree with your stance in many ways BUT! In many companies (mine as an example) MS products are viewed as the "ultimate" and everything else is rejected outright. Engineers are probable as bad about this as anyone else I've seen. I have in the past used mixing office automation and factory automation as a solution to a problem. The problem was "ignorance". People do not realize what can be done with a computer in the realm of equipment and controls. By integrating office automation products and factory automation products on small scales I was able to demonstrate what could be done in a manner that was acceptable. For many people MS is all they know. Some I know do not care what system is used as long as it gives them what they want. MS probable has the largest selection of software avaliable anywhere at this time and the vast majority of the population is familiar with it to some degree. For desk top applications MS wins hands down at this time. MS products have a lot going for them despite stability and security concerns. No I am not a MS fan, only when it fits the proper need of a job. I have had jobs that could of been done faster, easier and increased stability by a factor of 100 easily with Linux and C. Unfortunately this was rejected at this time. Instead the project was done using Windows, Dos and basic. This also increased project time due to writing code that would be totally unnecessary under Linux. Getting people to change or look at solutions in areas they are not familiar with can be difficult at best. By the way I use Linux probable 90% of the time at home and MS the other 10% <rant=0> Currently I'm looking into converters for Basic to C and Basic to Java to see what the possibilities are in converting some of the code I'v written. I really hate having to start from scratch and rewrite everything over again. I have done this in the past and it gets real old fast. Especially the debugging. jeff _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 13 March, 2001 - 2:49 pm

Jeff Thurman wrote: > I'm currently one of the learkers around this project and normally stay out > of the discussions. This time I will inject some thoughts concerning items > you have brought up. > > <rant=1> > I do not disagree with your stance in many ways BUT! > In many companies (mine as an example) MS products are viewed as the > "ultimate" and everything else is rejected outright. Engineers are probable > as bad about this as anyone else I've seen. > Engineers who can convince themselves that Windows is the ultimate are probably a lost cause as far as LPLC is concerned. Their quality standard is so low that we don't have anything to offer them. Certainly we won't provide a compelling reason by emulating MS or the large automation vendors. We need to be different, indeed opposite to the secret, quirky, "do it our way" mentality. Most technical people love to know what they're doing and dislike black boxes, especially when the black boxes keep them busy. > I have in the past used mixing office automation and factory automation as a > solution to a problem. The problem was "ignorance". People do not realize > what can be done with a computer in the realm of equipment and controls. By > intergrating office automation products and factory automation products on > small scales I was able to demonstrate what could be done in a manner that > was acceptable. > > For many people MS is all they know. Some I know do not care what system is > used as long as it gives them what they want. MS probable has the largest > selection of software avaliable anywhere at this time and the vast majority > of the population is familiar with it to some degree. For desk top > applications MS wins hands down at this time. MS products have a lot going > for them despite stability and security concerns. Again, my personal opinion, Linux is better for automation. I don't care what they print greeting cards or play golf or solitaire on. I consider the fact that few people can put the wrong software on a Linux machine an advantage. It surely keeps my testers running and no one has had to reload the whole machine because something "somebody" loaded hosed the registry or replaced the shared libraries. No, you can't run Office on it, thank God. What can't you run on Linux that belongs on an automation system? Believe me, an 80% reduction in support costs gets the attention of management. I am playing the Devil's Advocate somewhat, but what I am saying is the absolute truth. Any office automation IPC's that stay on the box are somewhat irrelevent as it's non optimal to run end user applications on your control machine. I am not going to debate the desktop. I am focused on LPLC and on people who can or will learn. Those who can't or won't are simply not relevant. If we get the automation system, I guarantee that someone will do the easy part (from our side) and hook it into their management's golf tournament server. Linux inherently connects to everything else better than Windows. > No I am not a MS fan, only when it fits the proper need of a job. I have > had jobs that could of been done faster, easier and increased stability by a > factor of 100 easily with Linux and C. Unfortunately this was rejected at > this time. Instead the project was done using Windows, Dos and basic. This > also increased project time due to writing code that would be totally > unnessary under Linux. Sounds like a winning argument to me. Let's sell Linux for what it is. I fail to see how LPLC running on Windows would improve anything. As a matter of fact, I am of the opinion that it would harm our reputation. > Getting people to change or look at solutions in areas they are not familiar > with can be difficult at best. We're not gonna win the marketing or PR war, If we penetrate these organizations it will be with superior technology, value, reliability, and goodwill. We have to show virtue where the others show only greed and averice > By the way I use Linux probable 90% of the time at home and MS the other 10% > Cool, I used Windows quite a bit last year, once to back up the data and once to make an install disk for Linux. This was on about 20 machines, the last holdouts :^) Our management should talk to your management. I'm not sure where I could find a Windows machine if I needed one now. Like I said, an 80% reduction in support costs really gets attention. Bad for the IS budget though, 2 people for a 500 person company. I'm permanently in automation now but that's OK. We had an advantage, our folks didn't know windows either. > <rant=0> > > Currently I'm looking into converters for Basic to C and Basic to Java to > see what the possibilities are in converting some of the code I'v written. > I really hate having to start from scratch and rewrite everything over > again. I have done this in the past and it gets real old fast. Especially > the debugging. You could run BASIC on Linux, the IO isn't very strong though. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Jeff Thurman on 14 March, 2001 - 10:20 am

Curt: I do agree with your stance. In my case by mixing and matching in an enviroment that "they" could understand I have been able to take my area from one computer on someones desk to nine computers running test in a three year period. People had to see what they could understand. Windows is not very stable for many applications, particularly controls. (I'm being polite here) Dos is good is some areas, but again it does have certain limitations. Before I forget! I have a question about some of the serial devices LPLC will have. Will each protocol use it's own serial port or will people be able to run multiple protocols down the same port? Currently I have applications that use one, two or three different protocols on the same 485 port. jeff _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 14 March, 2001 - 10:25 am

Hi Jeff That depends on what you mean by down the same port. I hope you mean one at a time :^) Yes, UNIX and by reflection , Linux were designed for terminals and serial devices and will allow you to do anything that makes sense and many things that don't. In fact, you could actually run several protos at the same time although that would confuse the connected devices. The port is a file to a UNIX system. The OS doesn't impose policy at all. In fact, you can replace the serial port with a pipe and the application will read from and write to the pipe which is handy. The way that ports are tradionally handled is that a using program looks for and creates a simple lock file to prevent simultanious use. It's entirely advisory. I hope this answers your question, if not, tell me a little more about what you are doing and I'll try to do better. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Jeff Thurman on 15 March, 2001 - 9:37 am

Curt: In some applications I will run multiple devices with different protocols on the same 485 link. As an example I may have some device that has 8 thermocouples attached for monitoring temperatures. It uses a plain ascii protocol. Next I may have an inverter on the same communication link which uses a different protocol. USS as an example. The thermocouple device is polled once every 30 secs to 1 min. The inverter is polled every so many seconds or a command is issued to start, stop, change speeds etc. Multiple protocols can use the same 485 link (ie; com1,com2 etc) in this manner. The program does have to keep up with which protocol it is to transmit and what the response format should be etc. jeff _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 15 March, 2001 - 12:37 pm

> Multiple protocols can use the same 485 link (ie; com1,com2 etc) in this > manner. The program does have to keep up with which protocol it is to > transmit and what the response format should be etc. That's really a non-problem. If the communications are properly modularized (i.e. the physical layer spits out whatever's in its transmit queue and injects into a receive queue whatever it receives) then it's just a matter of ensuring that the entire command for each protocol gets atomically injected into the queue. The trick is to make sure that devices don't speak until spoken to and also ensure that the protocols won't be mistaken for each other and cause either an "I don't understand" return packet or cause improper operation. Regards, Andrew _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 14 March, 2001 - 4:58 pm

> Before I forget! I have a question about some of the serial devices LPLC > will have. Will each protocol use it's own serial port or will people be > able to run multiple protocols down the same port? Currently I have > applications that use one, two or three different protocols on the same 485 > port. Personally I don't see any problem with having multiple protocols on a single port. The problem with that, of course, is how do other devices cope and do these other protocols have any kind of "maximum length" or "in-band emergency signalling" capabilities we would have to either work around or support? Regards, Andrew _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Jeff Thurman on 16 March, 2001 - 6:00 pm

Andrew: Normally devices ignore transmissions they do not understand. If there are three, four or more devices hanging on a 485 port each with its own protocol, device 1 will not respond to the protocol used for device 2, 3 etc. This is based on a master slave setup. To have emergency signalling the slave device would have to initiate the transmission. "maximum length" is also not a problem since each protocol typically will have different transmission lengths. jeff _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Jim Redman on 13 March, 2001 - 2:46 pm

I'm all in favor of a good rant and strongly held positions but I think that it emphasises a problem that I have with the LinuxPLC project. The issue was touched on recently when the question of the purpose of the project was raised. The responses to that were, in my opinon fairly weak. Linux is, to my mind, a great platform for factory automation, and my choice of OS on my notebook. However I think that I'd be just as disappointed with a world only Linux as I would be with only Windows. Platforms are good for some purposes and not for others, this covers the practical as well as the technical range. Diversity is good. And this is where I think the PuffinPLC has missed the boat entirely. At ErgoTech, we build Java components, and after using the language for quite a while it is hard to beat as a cross-platform solution. We can generate Java screens on Windows (or Linux) that can be downloaded transparently to embedded Linux systems. This is includes not just the displays (that much you could do with ActiveX), but also logic for historians, alarming, etc. The same code runs on Windows, embedded 8051 processors - the Dallas TINI product (http://www.ibutton.com/TINI/), on multiprocessor Sun systems, VxWorks, you name it. And yes, we provide solutions for OPC, ActiveX integration, etc. etc. etc. To me the idea of Open Source is to be inclusive, not exclusive. To exclude a platform unnecessarily is not useful. I think that clearly Java should be a part of inclusivity. For example an IEC editor that runs on anything (say Palm Pilot) would be a great addition to the project - can you devise any other way to do that simply? Technical arguments may say that the "core" should be in C++ and therefore relatively less portable, but it connectivity to other systems (as many as possible) and portablity to these systems is not considered we all loose. How much stronger is the PuffinPLC if it runs on Linux, VxWorks, Windows, and everywhere else. Then the product has one more clear advantage over any other in the marketplace, and wider adoption means more developers, better product which means .... Jim -- Jim Redman (505) 662 5156 http://www.ergotech.com _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 13 March, 2001 - 3:46 pm

Hi Jim I don't disagree with much of anything that you are saying. In fact let me add the bit that brings us into almost complete harmony. I am struggling to preserve focus in a hostile environment where the status quo is ultra proprietary and makes the general computing world look like GNU country. You, like I, seek to have open connectivity and interoperability. For both you and I the prospects are grim if we accept the status quo and let the powers that be call all the shots. OSS is our antidote, Java is yours. If you are not giddily rushing to embrace C#, I'm sure you can understand my reluctance to embrace all of their other "inventions" all of which are cunningly crafted to maintain and extend the status quo. If the promise of Java is fulfilled, the world will be open and competitive again and the status quo will have changed to be compatible with our goals. Since there are many, many, many more people bent on doing everything with Windows than there are on doing automation with Linux and OSS, if we can stay focused and do the Linux part right with OSS, it's a statistical certainty that the Windows part will happen and will, of necessity be OSS as well. If we lose focus and don't make a worthwhile alternative, it won't matter. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 15 March, 2001 - 4:02 pm

Jim Redman: > I'm all in favor of a good rant and strongly held positions but I think > that it emphasises a problem that I have with the LinuxPLC project. ... > Linux is, to my mind, a great platform for factory automation, and my > choice of OS on my notebook. However I think that I'd be just as > disappointed with a world only Linux as I would be with only Windows. Linux is not quite as monolithic as Windows, but that's neither here nor there, I guess... You're quite welcome to make a Windows port of PuffinPLC. [on Java] > For example an IEC editor that runs on anything (say Palm Pilot) would be > a great addition to the project You're quite welcome to write an IEC editor in Java. That's the real trick, I guess. In the OSS world as elsewhere, saying ``A, B and C should be done'' rarely carries anywhere near the weight of ``I've done A, B and C and here's the tarball''. Technical arguments can rage for weeks or months (see the archives); working code, preferably based on rough consensus, does wonders. Jiri -- Jiri Baum <jiri@baum.com.au> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc