connectivity (OPC)

  • Thread starter Juan Carlos Orozco
  • Start date
J

Thread Starter

Juan Carlos Orozco

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 [email protected] www.ace-lab.com -----Mensaje original----- De: [email protected] [mailto:[email protected]]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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

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 [email protected] ---------------------------------------------------------------------------- The box said it requires Windows 95 or better, so I installed Linux _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
W

Wallinius Mattias

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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Ryan Van Slooten

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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
K
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 <[email protected]> _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Campbell, David (Ex AS17)

C

Curt Wuollet

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. &lt;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. &lt;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 [email protected] 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 ([email protected]) _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J
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. &lt;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% &lt;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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Juan Carlos Orozco

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 [email protected] www.ace-lab.com _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J
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:[email protected] "Nearly fifty percent of all graduates came from the bottom half of the class." _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
W

Wallinius Mattias

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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

> 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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
W

Wallinius Mattias

-----Original Message----- From: Harald Albrecht [mailto:[email protected]-aachen.de] Wallinius Mattias <[email protected]> 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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

> [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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Top