OPC and DOTNET

P

Thread Starter

Per Thygesen

What is the future of the OPC specifications in the the light of Microsoft's new .Net initiative ? I would like to hear the opinion of the members of this list, as I'm not a member of the OPC foundation, and I don't know what's going on behind their doors. Thank's Per Thygesen
 
M

Mike Johnson

I am not so sure that COM is totally out of the picture. I think .NET uses ADO (ActiveX Data Objects) which is suppose to be a faster more efficient than COM. Plus, .NET is more worried about talking across different platforms, I think, via the web. COM based systems like OPC can not so, this could be a holly grail for Microsoft in order to challenge the possible business applications across platforms using Java and JavaScripting. I do not think COM is ever going away so, OPC is safe in the Microsoft platform. Maybe, the OPC foundation should think about using Java Beans technology to achieve RPC DCE across different platforms. Then maybe not since everybody are victims of the WinTel alliance. Will .NET be the evolution of distributed computing? Will Java have a way to out compute .NET? ( how about those smart cards and heart recorder cards, cool stuff, yea) It is amazing what object oriented programming theory has done to the computing industry and to the world at large. I guess this does not really answer anything! Sorry.
 
R

Ralph Mackiewicz

> I am not so sure that COM is totally out of the picture. I think .NET > uses ADO (ActiveX Data Objects) which is suppose to be a faster more > efficient than COM. Plus, .NET is more worried about talking across > different platforms, I think, via the web. COM based systems like OPC > can not so, this could be a holly grail for Microsoft in order to > challenge the possible business applications across platforms using > Java and JavaScripting. I do not think COM is ever going away so, OPC > is safe in the Microsoft platform. Maybe, the OPC foundation should > think about using Java Beans technology to achieve RPC DCE across > different platforms. IMHO: It seems likely that OPC will embrace the .NET method of RPC (remote procedure call) called Simple Object Access Protocol (SOAP). SOAP uses XML-based messaging to exchange RPC information across the network. SOAP will purportedly be platform independent. Given Microsoft's view of Java, it seems unlikely that Java Beans will become the .NET method of performing RPC. > Then maybe not since everybody are victims of the WinTel alliance. > Will .NET be the evolution of distributed computing? Will Java have > a way to out compute .NET? ( how about those smart cards and heart > recorder cards, cool stuff, yea) It is amazing what object oriented > programming theory has done to the computing industry and to the > world at large. I guess this does not really answer anything! > Sorry. The world is probably big enough for both technologies. Regards, Ralph Mackiewicz SISCO, Inc.
 
L
> -----Original Message----- > IMHO: It seems likely that OPC will embrace the .NET method of RPC > (remote procedure call) called Simple Object Access Protocol (SOAP). > SOAP uses XML-based messaging to exchange RPC information across the > network. ... I just wonder - SOAP and XML means back to ASCII text, ergo lots of network traffic. I cannot comment on how efficient DCOM is, but if Modbus/TCP can move 100 x 16-bit registers in about 209 bytes of TCP data, it seems odd to be moving to a "grand new technology" which may require 10,000 bytes of TCP network band-width to do the same thing? Is that progress or just charity for the high-tech companies developing gigabyte Ethernet and Pentium 4 CPUs and those trying to obsolete Windows 95/98 for good? regards Lynn August Linse, Senior Product Application Engineer 15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618 [email protected] www.lantronix.com Tel: (949)300-6337 Fax: (949)453-7132
 
W

Wallinius Mattias

OPC is COM and is binary code. .NET is about managed code and therefore has a garbage collector and a intermediate format called MSIL which is run trough a JIT compiler at runtime. I think that COM will be around for a while longer as I don't think .NET will cover all grounds. Also OPC is only a set of interfaces and hence they can be adapted to Java/Corba/.NET. I even think that they can be directly implemented in .NET, I haven't examined more closely. My only concern is that OPC uses COM a bit unorthodox and that some types in calls might be difficult to map to Java/Corba IDL. I have a small memory of that Siemens have something done called JFPC/JPC that is Java for Process Control. /Mattias
 
A

Alex Pavloff

> I just wonder - SOAP and XML means back to ASCII text, ergo > lots of network traffic. I cannot comment on how efficient DCOM is, but if > Modbus/TCP can move 100 x 16-bit registers in about 209 bytes of TCP data, > it seems odd to be moving to a "grand new technology" which may require > 10,000 bytes of TCP network band-width to do the same thing? > > Is that progress or just charity for the high-tech companies > developing gigabyte Ethernet and Pentium 4 CPUs and those trying to > obsolete Windows 95/98 for good? SOAP and XML are replacing COM, which is based on DEC's RPC (more acronyms!). This'll just lead to more insulation of any sort of factory-floor ethernet from the office, and a computer with two ethernet cards in it running the OPC/SOAP server talking ModbusTCP over one link, and all the fat office stuff on the other. It is progress... new network protocols make life easier all round by taking away the annoying bits. For example, DCOM works transparently for the user writing COM objects -- doing the same thing over a simple protocol (like Modbus), would be possible, but really annoying. SOAP allows the use of XML (an easily parsed standard for text transfer), over HTTP (the transfer standard that many people are used to). It probably takes more bandwidth -- but makes it easier for people to stick things together. I think in the grand scheme of things that saving costs in development and support is worth a slightly increased cost in hardware. Alex Pavloff Software Engineer Eason Technology
 
H

Hullsiek, William

> I just wonder - SOAP and XML means back to ASCII text, ergo > lots of network > traffic. I cannot comment on how efficient DCOM is, but if > Modbus/TCP can move 100 x 16-bit registers in about 209 bytes of TCP data, > it seems odd to > be moving to a "grand new technology" which may require > 10,000 bytes of TCP > network band-width to do the same thing? > From: Lynn Linse [mailto:[email protected]] It all depends on your application requirements. Modbus/TCP sounds good if you are moving alot of simple register values. However, XML simplifies the transfer of a bill of material or other more complicated data structures over a network. For instance, in terms of downtime reporting, I would rather have my machines send me: &lt;downtime> &lt;PLC>xyz></PLC &lt;event>Downtime</event> &lt;duration>15</duration> &lt;units>minutes</units> &lt;cause>Bad Ladder Logic Programming</cause> &lt;/downtime> Rather than a streams of 1's and 0's. - Bill Hullsiek MES software engineer
 
DCOM's binary protocol is FAR from dead. The following article discusses, in painful detail, remoting with .NET Microsoft .NET Remoting: A Technical Overview http://msdn.microsoft.com/library/techart/hawkremoting.htm In the introduction, the article states: "Applications can use binary encoding where performance is critical, or XML encoding where interoperability with other remoting frameworks is essential. All XML encoding uses the SOAP protocol in transporting messages from one application domain to the other" In other words, the DCOM you use today it going to be available with .NET. Further, applications and objects built for .Net will have the option of choosing the binary format or SOAP -HOWEVER- only objects and applications that are .Net aware will be able to use the SOAP channel. Jeff [email protected]
 
D

Dan Hazel, Allen-Bradley

Spoken like a software engineer. Practically speaking, though, the job of the controller on a machine is to control the machine. Not to format data. CPU cycles are cheaper on the MES side than the PLC side - so keep the machine code lean and mean - and parse the data elsewhere. Dan Hazel
 
F
Lynn Linse wrote: > I just wonder - SOAP and XML means back to ASCII text, ergo lots of network > traffic. I cannot comment on how efficient DCOM is, but if Modbus/TCP can > move 100 x 16-bit registers in about 209 bytes of TCP data, it seems odd to > be moving to a "grand new technology" which may require 10,000 bytes of TCP > network band-width to do the same thing? Lynn, Binary XML representations are a good answer to this. See the "WAP Binary XML Content Format", http://www.w3.org/TR/wbxml/. From the abstract: "This specification defines a compact binary representation of the Extensible Markup Language [XML]. The binary XML content format is designed to reduce the transmission size of XML documents, allowing more effective use of XML data on narrowband communication channels." Regards, Fred A. Putnam, [email protected], 978-470-0099 x231, http://www.labtech.com
 
M
The problem that XML tries to address is that the MES side does not know the details of the controller unless something tells it that info. The point of XML is that it is a universal language that describes the semantics of data. This allows the PLC side to be self-descriptive and means that all of the products from every manufacturer can work together so long as they use and understand XML. One day :) Keeping the required CPU load down on the PLC side is one way of saving money, it has no intrinsic merit beyond this (except in cases where there is a low power requirement). It may very well be cheaper to spend more on the PLCs and factory equipment if you can save money on writing bespoke software and drivers at the MES side. Mike Davies Senior Software Engineer Eurotherm Faraday Close Durrington Worthing West Sussex BN13 3PL Tel:- 44 (0) 1903 837908 Fax:- 44 (0) 1903 837939 [email protected]
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Keeping the required CPU load down on the PLC side is one way of saving money, it has no intrinsic merit beyond this (except in cases where there is a low power requirement). It may very well be cheaper to spend more on the PLCs and factory equipment if you can save money on writing bespoke software and drivers at the MES side. However, most PLC's do not have the text manipulation abilities that can be had in PC based scripting languages. The amount of effort required to get the same thing done in Ladder as is done in a simple VB script is sometimes herculean. I speak from the AB SLC-500 field. I recently had the 'pleasure' of setting up serial printers using the on-board RS-232 port on the processor. Trust me, text formatting is a royal pain. As I said in an earlier post, I think one of the only things that this has going for it is that it will make all manufacturers talk the same (high level) protocol. With luck and work, it may eventually be the way to getting some real interoperability. --Joe Jansen
 
J

Joe Jansen/ENGR/HQ/KEMET/US

At first blush, I was inclined to agree that the whole XML idea is bloatware. Why should software pass data to other software in human readable format? Taking the example above, are you (or more accurately, your users) actually going to be looking at the data stream? Not if you did your job right setting the apps up. The data stream is just to get the info from machine to machine. Why not do it in the most efficient manner possible, even if it is against the MS way? (Sorry, but I had to put that in....) But then I got to thinking. Yes it is bloat-ware. No, it doesn't make sense to do machine-readable-to-human-readable-to-data-bits-on-the-wire-back- to-human-readable-to-machine-readable (puff puff). All that parsing and encoding is ridiculous, *BUT*: It is a defined standard! Could it be? A light at the end of the tunnel? If MS can throw their weight around enough to get everyone to conform to a 'standard' XML structure, it could be the first step in the ubiquitous PLC network. Think about it. If all of the equipment is talking the same protocol (ASCII based XML), how far away is a single network? *EVEN IF* we needed an adapter for each processor to get DH-485, Modbus, or whatever onto the "PLC-OneNet"(c), it is a step in the right direction. Therefore, I guess I will grudgingly admit that this could be ...A Good Thing. --Joe Jansen
 
M

Michael Griffin

At 15:10 06/03/01 -0500, Joe Jansen wrote: <clip> >It is a defined standard! Could it be? A light at the end of the tunnel? >If MS can throw their weight around enough to get everyone to conform to a >'standard' XML structure, it could be the first step in the ubiquitous PLC >network. Think about it. If all of the equipment is talking the same >protocol (ASCII based XML), how far away is a single network? *EVEN IF* we >needed an adapter for each processor to get DH-485, Modbus, or whatever >onto the "PLC-OneNet"(c), it is a step in the right direction. <clip> I can see PLC manufacturer's offering "XML modules", much like the web server modules which some of them currently have - it seems like a fairly obvious idea. Perhaps they could even offer a combined web server/XML module. The web interface would be for direct human viewing, the XML interface would be for computers to pick up the same data. I don't see it used for I/O though - just for connecting controllers to plant wide information systems. The big advantage this has over register oriented schemes is that you don't have to know the register layout and scale factors for each application. As long as the text message formatting is defined, and as long as the data means the same thing, you should be able to hook a new machine into the network and start getting useful data out of it right away. With everyone using the same message format, the software should be fairly standard and re-usable. I expect to see this on PLCs, robots, CNC controllers, etc., as well as on PCs. We had a discussion on this subject a while ago. This isn't "a defined standard" as you supposed. These text "schemas" need to be defined for each area of interest. This work would need to be done by various interested parties, and of couse published as open standards. What will likely happen though is that some secretive groups will start publishing their own ideas as "standards", which will then proliferate because no one wants to pay to get something they can easily create for themselves. The problem with lack of common standards isn't one of technology, it is a social and economic problem. If people see ownership of a "protocol" as a good way to make money, then coming up with easier and cheaper ways of creating new "protocols" is going to result in more of them, not less. You're not going to solve this particular problem unless you address the root cause. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
P
>I think that COM will be around for a while >longer as I don't think .NET will cover all >grounds. But what is 'a while' in the software world ? Eventually I think it will all be .Net. >Also OPC is only a set of interfaces and hence >they can be adapted to Java/Corba/.NET. I even >think that they can be directly implemented >in .NET In the BETA 1 version it is not possible, with the available tools, to implement a .Net server in C# and expose it as an OPC COM server. The .Net interop can not handle pointer to pointer to struct. I can not understand why the OPC foundation keep defining new standards based on COM. Instead they should define a standard with 'generic' interfaces and define bindings for java, C# and COM. -- Per Thygesen
 
P
> DCOM's binary protocol is FAR from dead. IMHO it is dead... well maybe dying ;) > In other words, the DCOM you use today it going > to be available with .NET It is not DCOM, but .NET remoting which is a completely new ball game. -- Per Thygesen
 
W

Wallinius Mattias

It's quite common to declare things or persons dead merely to find out they have not even been pensioned. .NET will not cover all grounds. Any person who believes so will be a bit hasty. It has not been released yet! /Mattias
 
P
I guess it's all a matter of words and assumptions. If you look at the history, when COM arrived the Win32 Api was still used, but people stopped developing new stuff the API way (I know I did ;). If we assume that MS really means it and .NET succeed, I think the history will repeat itself - people will not stop using 'legacy' COM components, but most new stuff will be developed for the .Net CLR. -- Per Thygesen
 
M

Michael Johnson

Could you not use Visual Basic.NET instead of C# now adays? Could a pseudo-OPC data-server be exposed to a .NET platform by using a given PLC/DCS manufacter's OPC server and writing a client using OPC Automation specs written in Visual Basic.NET to expose the PLC/DCS data to a
.NET platform for data acquistion?
 
M

Michael Johnson

I though the purpose was to communicate across different platforms? Server to server of different operating systems different views/rules of computing. If company X manufacturers a product called X1. Company X believes in high
productivity so company X uses a control system that uses a SCADA package called X2 with a DCS system X3.
Company Y manufacturers a product called Y1.
Company Y believes in high productivity so company Y uses a control system that uses a SCADA package called Y2 with a PLC system Y3.
Company Z buys company X and company Y. Company Z thinks that management of company X and company Y was full of it, so company Z wants to monitor
productivity of both company X and company Y in real time. Company X is California, Company Y is in Brazil and Company Z is in Germany with the
analysis boys in Japan.
Solution, a platform independent tool base in order to communicate to the different platforms and build interfaces for acquistion and plant
representation using Internet technology across a wireless/wire private worldwide network between Company X, Y and Z talking between SCADA systems
X2 and Y2 and even PLC Y3 and DCS X3. People in Germany and Japan see what is going on in California and Brazil. And they live happy ever after because they get show the americans the errors of their ways.
I guess what I am trying to say is that even thou SOAP may not be the best way it is a way. One in many differnet ways in the world of Internet
technology.
 
Top