Ok, I've kept a sock in my mouth for quite a while now... as Curt (and those that follow the Automation list ) know I'm not very keen on Linux and Open Source. But with the recent rash of email on this subject it's become an eyesore looking at my inbox . So if I can remove some mud from the water of this discussion I think everyone will benefit. The ongoing discussions are dancing around the same problem but are trying to answer it in different ways. Creating a new protocol for the sake of standards control does not necessarily solve problems, but certainly does increase the workload and delays finalization of developing that component. That's not to say that a new protocol may not be needed, but simply if you can get by with Modbus (for instance) then you have reduced the amount of new code you have to write and test. Modbus does seem a good fit, as it works very well with flat tag model devices such as LinuxPLC. There is no reason to treat a Windows box, another LinuxPLC, a LinuxHMI running locally, or a LinuxHMI running on a remote box any differently. Supporting multiple protocols (DCOM, Modbus, the proposed Open Communications Standard, and/or any other protocol) complicates the situation without providing added value. LinuxPLC does not have complicated communications requirements. You're simply dealing with transferring register values from a LinuxPLC to a client (no matter what that client is). I strongly suggest selecting or developing one protocol that answers that problem. Again, Modbus does seem a good fit. DCOM is not a data exchange protocol, so for LinuxPLC's purposes it's useless without something like OPC on top. I really don't think one of the goals of OSS or LinuxPLC is to promote the use of Microsoft Technologies such as DCOM. Yes, the easiest gateway to existing MMI's is OPC - but why not keep the Microsoft specific code on the Microsoft box? Think about it... Do you really want OPC on Linux? I don't know anyone that loves OPC. Lord knows I've spent too many a night under the heat lamp trying to solve stupid problems related to OPC. If you want to deal with developing a Linux standard IPC mechanism for exchanging industrial automation data values, please don't start with that brain damaged model. In the short run, you'd save time and energy by relying on sockets loop back and treating everything as a network operation - again developing one protocol. On the recent discussion of Pipes. That concept first surfaced in VMS before my time - I believe they were called MailSlots or MailBoxes. The concept has progressed and now exists in Windows as Named Pipes. If you want to create a model like that, as much as you may dislike MS I suggest you read up on their implementation as it is years old and works very well. Pipes is mostly for bulk memory copies. A major drawback is that it hides protocol level timeouts from the caller - since it is a simplistic, atomic API this causes problems during network hiccups. The caller doesn't get to manage error recovery or retries very cleanly. In summary, I strongly suggest selecting or developing one protocol that answers all the situations. Modbus would seem to be a very good solution that you can create now, without much further discussion. But there may still be reasons to head down the path of developing a new protocol. Modbus certainly does leave things to be desired. Since Modbus answers the simple problem, use the new protocol as an opportunity to introduce features it does not offer. For instance, if I were developing a new protocol today I would use a publish and subscribe model taking advantage of multicast. You can do it without dealing with multicast, or UDP, though that is not as efficient. There are advantages to multicast you may not yet realize. If you head that route, investigate PGM (Pretty Good Multicast or Pragmatic Multicast depending on who you talk to) from the IETF Reliable Multicast working group. It's fixing to head to RFC and will solve many of the problems Ron Gage expressed concern with. (There are also open source/GPL implementations available - but then I wouldn't know anything about that) Ok, sock back in mouth.
Jeff [email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Curt Wuollet Subject: Re: LinuxPLC: Re: connectivity (OPC)
>Hi Juan
>
>There is another possibility that I like, > replace all that expensive stuff with Linux > stuff. I have to think that way, being a > peripheral on a massive NT network doesn't do > it for me. And I need to think that's possible > and a major improvement. Otherwise what are > we trying to do here? I am pragmatic enough to > see your point and I'm not criticizing you, but > we gotta have goals and it's my job to focus on > them. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Jeff Dean <[email protected]> wrote: > On the recent discussion of Pipes. That > concept first surfaced in VMS before > my time - I believe they were called MailSlots > or MailBoxes. The concept has progressed and > now exists in Windows as Named Pipes. I might be wrong here but in my opinion VMS' mail boxes are more advanced than a "simple" pipe. As far as I know (but my memory might prove me wrong here) MS' pipes are very similiar to Unix' ones -- probably because they are very generic and to some extend really convenient and because this Posix and Useless'99 stickers require them. Don't have VMS' mail boxes better semantics preserving messages (record) boundaries than ordinary pipes? Message boxes and pipes are a very convenient interprocess communication (IPC) means. As long as you stay in the same machine that's fine. What I consider to be interesting would be a performance shootout between IPC through pipes versus ordinary TCP/IP over 127.0.0.1. Today's operating systems are typically very good at short-circuiting local IP transfers, even Microsoft can do that pretty good on NT and W2K -- at least if you don't try sending UDP datagrams larger than 1024 bytes, then their network stack goes completely insane and takes more than one second for a simple send() call. To the group: what is necessary/wanted? Only IPC within the same machine or also network transfers? Then it would be probably easier to take one of the RPC packages. On top of the IPC technical question there's still Jeff's very good point: > DCOM is not a data exchange protocol, so for > LinuxPLC's purposes it's useless without > something like OPC on top. How true. DCOM is a transfer mechanism, with a fixed RPC interaction scheme. In addition it also provides a runtime environment for method call dispatching etc. (D)COM is much more than a simple RPC, it is an environment. However, it is a *big* environment with many nice things, as also CORBA has. But probably not everyone is keen on using such a sledgehammer for IPC. And then, *watch* the callback interactions, which can easily block a otherwise perfectly humming server if a client goes down or faces scheduler trouble. I've seen this already a few times... So if you don't need all the features you can probably stay with some of the "boring old" RPC packages -- they are not h2h (hype to hype) compatible, but then ... they work and they are well understood not only for their features but also for their flaws. From my own experience, DCE/RPC is the more systematic ISO approach. But ASN.1 and BER isn't the end of wisdom and as Mr. Tanenbaum mocked, the ISO already knew that their Abstract Syntax Notation ASN would have been to be replaced by something better -- so they added the version number to their acronym. Today BER is probably neither flesh nor fish: while it encodes some metainformation this is typically either not used at all or not enought metainformation, so it is done on the application layer 7 instead. Then there's Sun's ONC/RPC. Ad-hoc, straight and simple, very easy to implement (if you stay out of the DES cryptography part). ONC/RPC is part of all unices, there's a port for Windows NT/9x/2k, even OpenVMS supports it. And we (PLT) wrote our own implementation from scratch within one week (one person) for doing RPC over CAN bus with a 16bit uC. Personally, I wrote the RemoteTea package, which is a LGPL'd implementation for Java (pure Java). So even the JPLC could make use of this IPC means. If you want IPC over the network and don't need all the whistles and bells of object request brokers like CORBA and COM, ONC/RPC should be worth a look. But then, Jeff's point still is there: what do we want to do on the application layer 7? While modbus, profibus have some nice features, they typically suffer when MMI, SCADA, MES, etc. come into play. Especially Profibus and FF are both very handicapped if you need to need i/o values but not cyclically but on demand. But then, why not use the best-of-breed for several areas? I don't thing that one protocol fits it all... Harald _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Jeff, You don't have to be a fan of Linux and/or OSS to make sense and I value your well thought out opinions. Amazingly enough, we are in more or less complete agreement. We are caught in a twilight world where we _have_ to support some popular protocols, regardless of their open/closed status. As we have no recourse if a large automation vendor threatens us, I see having a backup that we own as strategic. But we are not really delaying anything with the work to do this. The work on the core progresses.and we add developers if we can support multiple development threads. Indeed, we are begging for people to come up from lurking and contribute what they can. If Ron wants to do this, I can't tell him no anyway :^). If you have hung around a while you know I am fairly big on Modbus as the closest thing to being open and standard in the automation world. We have done and should do Modbus. Recently Groupe Schnieder has done some things that worry me. I don't think they can stuff Modbus back in the bottle but they could shut us down with a nasty letter. Having our own that can be used for the same things is insurance. They wouldn't want to risk pissing off the whole OSS world if it has only minor effect and we go on. I am not sure about the multicast thing quite yet. The real world isn't even ready for IPv6. The automation world...........hmmm. Jeff Dean wrote: > Ok, I've kept a sock in my mouth for quite a while now... as Curt (and those > that follow the Automation list ) know I'm not very keen on Linux and Open > Source. But with the recent rash of email on this subject it's become an > eyesore looking at my inbox . So if I can remove some mud from the water of > this discussion I think everyone will benefit. > > The ongoing discussions are dancing around the same problem but are trying > to answer it in different ways. Creating a new protocol for the sake of > standards control does not necessarily solve problems, but certainly does > increase the workload and delays finalization of developing that component. > That's not to say that a new protocol may not be needed, but simply if you > can get by with Modbus (for instance) then you have reduced the amount of > new code you have to write and test. Modbus does seem a good fit, as it > works very well with flat tag model devices such as LinuxPLC. > > There is no reason to treat a Windows box, another LinuxPLC, a LinuxHMI > running locally, or a LinuxHMI running on a remote box any differently. > Supporting multiple protocols (DCOM, Modbus, the proposed Open > Communications Standard, and/or any other protocol) complicates the > situation without providing added value. LinuxPLC does not have complicated > communications requirements. You're simply dealing with transferring > register values from a LinuxPLC to a client (no matter what that client is). > I strongly suggest selecting or developing one protocol that answers that > problem. Again, Modbus does seem a good fit. > > DCOM is not a data exchange protocol, so for LinuxPLC's purposes it's > useless without something like OPC on top. I really don't think one of the > goals of OSS or LinuxPLC is to promote the use of Microsoft Technologies > such as DCOM. Yes, the easiest gateway to existing MMI's is OPC - but why > not keep the Microsoft specific code on the Microsoft box? Think about it... > Do you really want OPC on Linux? I don't know anyone that loves OPC. Lord > knows I've spent too many a night under the heat lamp trying to solve stupid > problems related to OPC. If you want to deal with developing a Linux > standard IPC mechanism for exchanging industrial automation data values, > please don't start with that brain damaged model. In the short run, you'd > save time and energy by relying on sockets loop back and treating everything > as a network operation - again developing one protocol. > > On the recent discussion of Pipes. That concept first surfaced in VMS before > my time - I believe they were called MailSlots or MailBoxes. The concept has > progressed and now exists in Windows as Named Pipes. If you want to create a > model like that, as much as you may dislike MS I suggest you read up on > their implementation as it is years old and works very well. Pipes is mostly > for bulk memory copies. A major drawback is that it hides protocol level > timeouts from the caller - since it is a simplistic, atomic API this causes > problems during network hiccups. The caller doesn't get to manage error > recovery or retries very cleanly. > > In summary, I strongly suggest selecting or developing one protocol that > answers all the situations. Modbus would seem to be a very good solution > that you can create now, without much further discussion. But there may > still be reasons to head down the path of developing a new protocol. Modbus > certainly does leave things to be desired. Since Modbus answers the simple > problem, use the new protocol as an opportunity to introduce features it > does not offer. For instance, if I were developing a new protocol today I > would use a publish and subscribe model taking advantage of multicast. You > can do it without dealing with multicast, or UDP, though that is not as > efficient. There are advantages to multicast you may not yet realize. If you > head that route, investigate PGM (Pretty Good Multicast or Pragmatic > Multicast depending on who you talk to) from the IETF Reliable Multicast > working group. It's fixing to head to RFC and will solve many of the > problems Ron Gage expressed concern with. (There are also open source/GPL > implementations available - but then I wouldn't know anything about that) > > Ok, sock back in mouth. Please replace sock with Virtual Beer on my tab. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

ught ohh, the sock fell back outta my mouth... Harald Albrecht wrote: >>I might be wrong here but in my oppinion VMS' >>mail boxes are more advanced than a "simple" >>pipe. As far as I know (but my memory might >>prove me wrong here) MS' pipes are very similiar >>to Unix' ones -- probably because they are very >>generic and to some extend really convenient and >>because this Posix and Useless'99 stickers >>require them. Don't have VMS' mail boxes better >>semantics preserving messages (record) >>boundaries than ordinary pipes? Actually you are right, VMS mail boxes are more than simple pipes. I believe they managed queuing among other things. I was strictly looking at it from a an evolutionary standpoint. Nearly every concept in Windows NT and beyond has evolved from VMS, though there may be parallels to Unix. Consider the source (Dave Cuttler). Therefore MS and Unix pipes may be very similar, but my exposure to Unix pipes is non-existent. >>What I consider to be interesting would be a >>performance shootout between IPC through pipes >>versus ordinary TCP/IP over 127.0.0.1. Any message box or pipe mechanism will very likely be slower than raw sockets when traversing the network because they are all built on top of sockets using generic protocols with significant handshaking. The question on a loop back comes down to how many times is the memory copied in the protocol stack. I suspect waiting for the process scheduler and a context switch would take longer than a trip down and up the protocol stack... so it probably doesn't matter greatly. It's simply far easier to deal with everything as a network connection and there is little penalty in doing so for data transfer. Using loop back a RPC style protocols may receive scheduler penalties on each call, waiting for the target process to (1) be scheduled and (2) receive and process the message. In that instance it's best to build local vs remote knowledge into the application or use a mechanism that knows when to use IPC and when to use RPC. (COM does this using Lightweight RPC - a perversion of short circuiting) >>While >>modbus, profibus have some nice features, they >>typically suffer when MMI, SCADA, MES, etc. come >>into play. Especially Profibus and FF are both >>very handicapped if you need to need i/o values >>but not cyclically but on demand. But then, why >>not use the best-of-breed for several areas? I >>don't thing that one protocol fits it all... In my suggestion to use a single protocol I was balancing (1) development complexity and time with (2) the actual requirements of a protocol and (3) the desire to have a simple system. You very well could use a separate protocol to perform the likes of block transfers, and another protocol for MMI data access, and yet another protocol for remote programming. I suggest that Modbus may not be the absolute best protocol for 1 and 2, but in a week (or two) you could have it up and running and move on to creating other critical missing components. So far as 3 goes, and I believe it was Curt that pointed out, why not use RLOGIN or TELNET - there are already remote admin tools for the platform... so don't reinvent the wheel. The premise of my suggestion is that it will not help win the war striving to do things perfectly the first time. It will only delay the availability of a complete/stable release. On the fringes of the design you can build stop-gap solutions, and once the entire system is in place you can focus on replacing the stop-gaps. Further, I concluded my last message with a discussion of a publish and subscribe protocol that fits very well with both MMI requirements and data transfer between PLC's. I'm not suggesting it out of whim, but because I have worked with similar designs before and have seen the benefits. But, they take time to develop and debug. It may also be worth noting that EtherNet/IP seems to support some publish and subscribe mechanism. (though I have only seen it blabbered about in trade rags) sock back in mouth, Jeff _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Curt Wuollet wrote: >>As we have no recourse if a large automation vendor >>threatens us, I see having a backup that we own as strategic. You may very well have a point here that is worth the extra development effort involved in a new protocol. I have not looked into the license restrictions on Modbus or Modbus/TCP or how real a threat having Groupe Schneider send ya' a cease and desist is. I certainly wouldn't put it beyond them given their latest action against Opto 22. The problem, as has been raised already, is that with your own protocol you now have to create the OPC server to bring existing HMI's into the fold. I haven't seen anyone terribly interested in OPC development. (nor do I blame them) >>But we are not really delaying anything with the work to >>do this. The work on the core progresses.and we add developers >>if we can support multiple development threads. I was thinking (in the back 1/4 of my mind) that the protocol work would go on, but that it would take the form of building the "ideal" protocol solution - not the stop-gap and that in the interim Modbus would be the perfect stop-gap. >>If Ron wants to do this, I can't tell him no anyway :^). I gotta say, I've been impressed with some of Ron's work to date. I applaud his talent in opening up some of the AB equipment and protocols. He's certainly one of the star members of group. In no way are my comments about the open protocol effort a reflection on what he as presented or his skills... I just know he can do more and better given the challenge. >>I am not sure about the multicast thing quite yet. The real world >>isn't even ready for IPv6. The automation world...........hmmm. Well, IPv6 is going to happen whether automation is ready for it or not. And (anyone feel free to correct me if I'm wrong) I read that AB's EtherNet/IP will use multicast. Multicast is available in the current IP. IPv6 only changes the multicast address ranges, offers DHCP support for multicast addresses, integrates QoS into multicast packets, &lt;thinks> umm... and a few other things. You don't have to learn about MBONE or any group formation protocols to do multicast. Just open the socket on the right IP and port send and receive a known packet format and whammo you're multicasting. Programmatically it's really only slightly different than unicasting. (kinda cool, 'ey?) And if you leverage the PGM that I suggested before it's even easier. Take a peek at this: http://pgm.tibco.com/ (open source tar ball - a little out of date, but still reasonable) I've looked at the 7 or 8 multicast protocols before the IETF Reliable Multicast SIG. While it's likely that 3 or 4 will make it to RFC and eventually be ratified, PGM appears to be the most appropriate for automation applications (in my humble opinion of course) Now either I got a big mouth or too small a sock... Jeff [email protected] _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

>you now have to create the OPC server >to bring existing HMI's into the fold. I do not understand why everyone insists that OPC is necessary for HMI's. I have not seen any HMI's that use OPC to communicate with the hardware. What am I missing? _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Dave Must be the same thing I'm missing. I'm sure they have something cooked up for Ethernet that we could use. I'm loathe to do MS protos, it only encourages them. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc