# connectivity (OPC)

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

#### Jeff Thurman

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

#### Curt Wuollet

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

#### Curt Wuollet

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

T

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

#### Curt Wuollet

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

K

#### Ken Irving

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

F

#### Frank Gross

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

#### Curt Wuollet

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

K

#### Ken Irving

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

#### Jeff Thurman

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

C