connectivity (OPC)

  • Thread starter Juan Carlos Orozco
  • Start date
H

Harald Albrecht

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

Ryan Van Slooten

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

Harald Albrecht

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

Juan Carlos Orozco

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 [email protected] www.ace-lab.com _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
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 <[email protected]> _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

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

Andrew Kohlsmith

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