Communication protocols - New events, was Communications protocols

R

Thread Starter

Roger Irwin

After all I have said about idiocy of OPC's DCOM approach, I have just found out that MS
have now officially abandoned COM technology in favour of their emerging .NET SOAP
architecture. This technology is NOT upwards compatible with the DCOM technology on
which OPC is fundamentally based, and is even less adept at interfacing to factory
environments.

So there we have it folks, the automation industry is falling over itself to adopt a
technology that cannot be implemented directly on most of its products, has an architecture which is the reverse of that required, and has now been abandoned by the only OS manufacturer who was promoting it in the first place.

Now I am off to start an industry group that will promote the deployment of IBM AS400's in
industrial automation..........don't laugh, at least they are reliable and stable;-)
 
D
Roger Irwin wrote:
> After all I have said about idiocy of OPC's DCOM approach, I have just found
> out that MS have now officially abandoned COM technology in favour of their
> emerging .NET SOAP architecture. This technology is NOT upwards compatible
> with the DCOM technology on which OPC is fundamentally based, and is even
> less adept at interfacing to factory environments.

Your statement that Microsoft's plans to abandon COM and DCOM was news to me and many other 250+ OPC Foundation member companies, so I decided to ask Ron Sielinski, Microsoft's representative to the OPC Foundation. Ron is also the Technical Evangelist for Manufacturing at Microsoft. Ron's response regarding Microsoft's plans for COM/DCOM is provided in the message below.

In short, OPC is based on COM. Microsoft has no plans to abandon COM. DCOM is one way to use OPC in a networked application, but DCOM is not the only way to exchange OPC data over a network. The OPC Foundation has a new initiative to use OPC to access manufacturing data via XML and possibly SOAP as a transport.

The OPC Foundation views OPC and COM as the best approach for tightly-coupled, high-performance applications and XML more for loosely-coupled applications.

Regards,
Don Holley
OPC Foundation Marketing Director
email: [email protected]

-----------------------------------------------------
This is Ron Sielinski's response regarding Microsoft's COM/DCOM plans:

Microsoft is not retiring COM or DCOM.

Ever since we identified XML as an important technology, we've been drawing the distinction between tightly- and loosely-coupled systems (DCOM and XML, respectively). There's a need for both, and we will continue to provide both.

Granted, there's been some misunderstanding about this since we announced the .NET Framework. At the PDC, we began to show what we are doing to
deliver on our vision of Web services and how we will enable developers to create and distribute software as a service.

The .NET Framework advances the features of COM but not some of the plumbing, resulting in a much higher productivity developer experience. For
example, the .NET Framework introduces automatic memory management, regardless of the programming language they're using. It also gives developers a single, unified programming framework that brings together the best features of the Windows Foundation Classes, the Microsoft Foundation
Classes, the Visual Basic classes, and augments them with other capabilities such as an advanced data access architecture.

Beyond that, the .NET Framework also uses the same underlying component services that COM+ provides today, with features such as transactions, queuing, object pooling, and, in the future, new features such as application partitioning. COM+ is the highest-performance, most feature-rich set of application services available. The .NET Framework will make these
features incredibly easy to use.

Microsoft will enable our customers to take advantage of their investment in COM as new features such as the .NET Framework improve on it. For example, the .NET Framework will support most of the COM plumbing for compatibility. That said, applications that use the COM plumbing wouldn't be able to take advantage of all of the .NET Framework's features. A developer using the COM plumbing won't be able to take advantage of automatic memory management, for example.

Microsoft will enable our customers to take advantage of their investment in COM as new features such as the .NET Framework improve on it. These applications will be able to benefit from the features of the .NET Framework while leveraging the existing COM components. A few of the features of the .NET Framework behave differently than existing COM components. Two examples include the .NET Framework's automatic memory management vs. COM's reference counting and the .NET Framework's XCOPY deployment vs. COM's registration. Taking full advantage of some of these features will require modifying existing COM components, but developers don't have to change: existing code will continue to work.

To reiterate, we're not retiring COM. What we are doing is making COM much easier and more productive and enabling a totally new kind of software - Web services.

Ron Sielinski ([email protected])
Technical Evangelist for Manufacturing
Microsoft Corporation
 
A

Alex Pavloff

> In short, OPC is based on COM. Microsoft has no plans to
> abandon COM. DCOM is one way to use OPC in a networked
> application, but DCOM is not the only way to exchange OPC data
> over a network. The OPC Foundation has a new initiative to use
> OPC to access manufacturing data via XML and possibly SOAP as
> a transport.

So if DCOM isn't the only way to exchange OPC (which is based on COM) data over a network, what are the other ways?

One of the concerns that I have with OPC is that as embedded devices become more and more powerful, there isn't anyway to tie them into an OPC network unless one is using Windows CE, and quite frankly, I don't think that Windows CE 3.0 is a suitable OS for the automation industry.
 
C

Curt Wuollet

The word from the Borg:

Resistance is futile, you will be assimilated :^)

Now you get to re write everything again.

cww
 
R

Ralph Mackiewicz

You don't have to embed OPC into a device to use OPC for communications with that device. OPC is a programming interface. Because OPC is based on MS' COM technology, you can separate an OPC
client from an OPC server over a network and use MS' DCOM protocols to do remote procedure calls (remote OPC calls). But that doesn't mean that you have to use DCOM in your device. In your case, where you wisely want to use a more suitable OS for your device, you would use an existing communication protocol (e.g. Modbus/TCP, Profibus, MMS, FF, etc. etc. etc.) for your device. A MS based host application can then make use of an existing OPC server that has an OPC interface on one side and a comm link to your system on the other. Until MS completely displaces all other OS, DCOM (or SOAP) will not be a replacement for all those industrial comms that we know and love. ;-)

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
C

Curt Wuollet

What does suitability have to do with it? None of the MS OS's meet industrial standards for uptime but hey, that's not what's driving it. You can embed data sources "from the the boiler to the boardroom"! Now, what's more important than that? And everybody already knows how to run all the processes and all about them because they're just Windows. Right? And, if it all tanks, you can blame it on Redmond and keep your job. Besides, what else is there ? Everyone in the place runs Windows, why should we use special software for a 1000hp flash boiler? And even if we use PLC's, we are entirely dependent on MS
because that's what all the tools run on. And if you want to communicate with anything, you have to use MS protocols. And nobody here knows how
to fix anything else, so you couldn't use anything else if you tried. If it's good enough for the CEO, it's certainly good enough for you. And while you're at it, train in this intern we got from the Community College, she really knows her Windows, so take an hour or two and show her all the other stuff you do. We got her cheap. In the face of all these excellent reasons, What
has suitability got to do with it?

This is not my rant, these are the actual reasons I got for using proprietary systems which kinda centered around MS for some reason. That's OK
because they are familiar to all and a fairly good example of the effects of single sourcing and proprietary mindset on business processes. Actually I couldn't have made up a better diatribe than the one I have been provided
with. All these things are simply accepted, without question. Yet, when you put them all together (as they normally are) I see two things that I can put my finger on.

1. This doesn't sound like engineers talking, this is business, not technology.
2. The barrier for alternatives is almost impossibly high as long as people think this way.

Because I am committed to offering alternatives, I can proceed in one of two ways.

1, I can show up in a three piece suit, meet only with management as much as possible, avoiding those nasty technical issues. Bring a model or two
along to demonstrate that anyone can tune a PID loop in simulation, etc. Show a bunch of power point slides of other suits watching trends as an
add-in for MS Golf and drop names like GM and Price Waterhouse and blame the hardware if the demo crashes.

2. I can talk to you folks, probe why things have gone so far one way and stress reliability and engineering values like efficiency, simplicity and
openness. I wear work clothes and solve problems for a living and I know things just aren't that simple. If I can get enough people interested, we
can do it right and put the emphasis back on engineering and merit based solutions that just work. Not much flash or multimedia, the kind that you can almost forget about because they just run.

Regards.

Curt Wuollet,
Wide Open Technologies
 
Curt:

Go to the OPC web site and look at the companies that are supporting the OPC specification. Your joke about the borg reminds me of the last guy standing around at the end of the 60s' saying, "Power to the people!". It is a nice sentiment, but it doesn't mean anything. What people want is technology standards that are backed by industry leaders, so that tools can be interchanged. OPC is the best thing this industry has going for it and the argument against it is based on a fear of the evil empire lead by Bill Gates. That argument makes no sense, because there will always be an evil empire. Would things be different if IBM still controlled the operating system market? How about Sun? Do you think Sun management would say to their stockholders we are going to open up competition at the OS level because we believe in "power to the people". I don't think so.

Resistance to OPC is not futile, but it isn't logical.

Sam
 
R
> > Your statement that Microsoft's plans to abandon COM and DCOM
> > was news to me and many other 250+ OPC Foundation member
> > companies,

I said DCOM, not COM, and I am amazed you have not been informed!

> > In short, OPC is based on COM. Microsoft has no plans to
> > abandon COM. DCOM is one way to use OPC in a networked
> > application, but DCOM is not the only way to exchange OPC data
> > over a network. The OPC Foundation has a new initiative to use
> > OPC to access manufacturing data via XML and possibly SOAP as
> > a transport.

But what does OPC actually do without DCOM? You need some transport and the MS reply does not deny that they are dropping DCOM, fact is things are to be dropped in favour of SOAP and/or XML, but this is not ready yet.

I think you should inform potential OPC implementers that this change implies a major architectural review of what holds an OPC network together, it is not a little detail!!!

> > The OPC Foundation views OPC and COM as the best approach
> > for tightly-coupled, high-performance applications

Read, not networked but on the same machine.

> and XML more for
> > loosely-coupled applications.

Or in other words all these network integration / SCADA packages etc which are boasting OPC are destined to be replaced by something using a completely different architecture and technology.

And I have this gut feeling that this eventual standard, when actually released, is going to
require everthing to be upgraded to Windows/Office 2000. No wonder the OPC liases with an MS 'evangelist' and not an application engineer!
 
R
Ralph Mackiewicz wrote:

> You don't have to embed OPC into a device to use OPC for
> communications with that device. OPC is a programming interface.
> Because OPC is based on MS' COM technology, you can separate an OPC
> client from an OPC server over a network and use MS' DCOM protocols
> to do remote procedure calls (remote OPC calls). But that doesn't
> mean that you have to use DCOM in your device. In your case, where
> you wisely want to use a more suitable OS for your device, you would
> use an existing communication protocol (e.g. Modbus/TCP, Profibus,
> MMS, FF, etc. etc. etc.) for your device.

You seem to have missed the point. Suppose I interface an S7-300 to the companies TCP/IP network such that any PC on the net may acess the data. Using the siemens OPC package I would, as you pointed out, go out of the 300 with Profibus and connect to an NT server which houses the DCOM
server, ie I need a third machine with a fixed connection, and this is obligatory.

Many IA field devices, including PLC's, now have basic TCP/IP messaging facilities. These may be used to implement the simple communications people
require, but they are far off being DCOM capable.

With a simpler TCP/IP message based system, you could read a TCP/IP enabled device from anywhere on the net, including directly from, eg, an EXCEL macro. I could also wrap that call in a COM object on the local machine (thus have identical
end user functionality without the third machine and the PROFIBUS link), or if I really wanted I could serve it up from a third DCOM server. OR I could wrap it in CORBA, seve it as XML, or whatever.

In my mind the big failing of OPC is to define COM/DCOM as their core technology, when it should be an optional wrapper to a simple universal TCP/IP based messaging system. Same goes for SOAP and XML.

These issues were raised in OPC's early days, but at that time MS were promising OS's specifically tailored for IA embedding. Where are they?
 
R
> Go to the OPC web site and look at the companies that are
> supporting the OPC specification.

Of course you could also visit CORBA and a dozen other standards websites to see even bigger companies. Big companies sign up to everything.

But how interested are they. Siemens, for example, treat OPC as an optional method to access the world of Profibus.

> OPC is the best thing this industry has going for it

why?

> and the
> argument against it is based on a fear of the evil empire lead by Bill
> Gates.

I am sorry, I think Curts closing remark was light hearted. There are good technical arguments against OPC, is anybody here capable of a serious technical discussion? So far all I have recieved is a copy of an MS evangalists reply saying that allthougth they are introducing a replacement to DCOM, they are not dropping the old technology.
Oh, quite. Like OS2 all over again......

Neither SOAP or XML are solutions to the problems that have been raised.

> That argument makes no sense, because there will always
> be an evil empire. Would things be different if IBM still controlled
> the operating system market? How about Sun? Do you think Sun
> management would say to their stockholders we are going to open
> up competition at the OS level because we believe in "power to the
> people". I don't think so.

Neither do I, so why make a protocol unecessarily depent on a particular manufacturers product?
 
P

Peter Whalley

Roger,

Would you consider Modbus/IP as a suitable protocol for use with Ethernet attached devices? This would seem to have most of the attributes you are looking for.

I think a good example of what you are talking about is the ISaGRAF soft logic PC control software. The run time will operate under MS-DOS, OS-9, VxWorks, Windows 95, 98, 2000, NT, and CE and others. All of these support Modbus over TCP/IP/Ethernet (not sure it complies strictly with the Modbus/IP standard) but if you want OPC it must run under WinNT.

BTW, does any one have example code for getting MS Excel to talk Modbus/IP directly?

Regards

Peter Whalley

Director
Magenta Communications Pty Ltd
121 King Street,
Melbourne, VIC 3000
Australia.
e-mail: [email protected]
 
R

Ralph Mackiewicz

> > > In short, OPC is based on COM. Microsoft has no plans to
> > > abandon COM. DCOM is one way to use OPC in a networked
> > > application, but DCOM is not the only way to exchange OPC data
> > > over a network. The OPC Foundation has a new initiative to use OPC
> > > to access manufacturing data via XML and possibly SOAP as a
> > > transport.
>
> But what does OPC actually do without DCOM? You need some transport
> and the MS reply does not deny that they are dropping DCOM, fact is
> things are to be dropped in favour of SOAP and/or XML, but this is not
> ready yet.

OPC is an API!!!!

OPC is not a protocol!!!!!!

Once you understand and accept this fact then what OPC does becomes intuitively obvious. It allows applications supporting the API to
completely isolate themselves from the protocol. A Fix node (or any OPC client app) can access data from an AB PLC, Modicon PLC, whatever
as long as there is an OPC server available for it.

The REAL value of OPC is the standardized API for accessing data. Given all the noise on this list about the lack of standards I amazed that when a really useful standard is developed that enables nearly ANY protocol to be used (even those that are home-brewed) transparently to the application that anyone would even want to resist it.

DCOM is simply an application level protocol for doing remote procedure calls with COM based APIs (like OPC). In spite of the assertions of some of the "leaders" of the OPC effort, DCOM is not a
replacement for any or all of the myriads of fieldbuses that are out there. SOAP will not be a replacement either. XML might be part of a
solution depending on how its implemented. Given the history of MS they will probably do SOAP/XML in a way that doesn't help this effort because they really don't care about industrial automation that much.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
F

Frank Iwanitz

Hi,
>
> In my mind the big failing of OPC is to define COM/DCOM as their core
technology,
> when
> it should be an optional wrapper to a simple universal TCP/IP based
messaging
> system. Same goes for SOAP and XML.

In my mind it is a huge advantage of OPC that something has been done at all! There are always better ways to solve a problem. But if you want to include all these proposals in a standard you will NEVER succed.

Take the fieldbus "standards" an an example.

There are a lot of OPC products, a lot of OPC Foundation members, a lot of request from
customers. This technology can't be totally wrong.

I do not know much people in automation which are dealing with CORBA in REAL products.

Regards,

Frank
 
I don't get where you have a third PC? You have a PC that has the OPC server on it. That PC can also house your application, like an MMI. If you want to share data from that PC then you can make DCOM connections to it to get data from many other PCs.

It would be nice if a control device, like a PLC, came with a module that supported OPC. The fact that OPC currently does not come as a part of the controls processor is not a show stopper for OPC.

If you really want, for whatever reason, to make a direct TCP application-layer protocol connection then why not use ModbusTCP? It works for me, but then I am a little bit biased. ;-)
 
C
> Go to the OPC web site and look at the companies that are
> supporting the OPC specification.

I've been to the OPC site, its MS only coding upsets my non-MS browser and sort of sets the tone for things to come.

> Your joke about the borg
> reminds me of the last guy standing around at the end of the 60s'
> saying, "Power to the people!". It is a nice sentiment, but it doesn't
> mean anything.

On the contrary, Open Source is very much about empowering people. And the people seem to like it a lot, well, at least open minded people.

> What people want is technology standards that are
> backed by industry leaders, so that tools can be interchanged.

Yes, I can trade MS tools for MS tools or even MS tools. And I _have_ to trade last years MS tools for this years MS tools or all the magic benefits go away. Who wins in this deal? It's simply indefensible to tie "standards" to one vendor, any vendor.

> OPC is the best thing this industry has going for it and the
> argument against it is based on a fear of the evil empire lead by Bill
> Gates. That argument makes no sense, because there will always
> be an evil empire.

I'm glad I don't live in your world, We have no emperors, with or without clothing. It's the most remarkable cooperative effort ever.

> Would things be different if IBM still controlled
> the operating system market?

Yes, We have the support of a large blue penguin now. Their behavior has been quite exemplary. Once you GPL something you can't take it back or extort money with it.

> How about Sun? Do you think Sun management would say to their

> stockholders we are going to open up competition at the OS level because we
> believe in "power to the people". I don't think so.

All of the important Sun protocols have been made available to anyone at no cost. StarOffice is free and will be GPL'd later this summer. Solaris source is now available and Solaris itself
is available at no cost for individuals. They are no fools, they want to interoperate and cooperate, even with competitors. Linux runs on their hardware with their blessing. I would say to your question, they choose to compete by giving "Power to the people". In short, of all the major vendors in the enterprise space, there is only one who believes in poor citizenship and non-cooperation. But hey, that's what is expected from a monopoly.

> Resistance to OPC is not futile, but it isn't logical.

When the goal is choice, interoperability, and reliability, it is logical IMHO. Why get in bed with the only poor sport out there? And regardless of who else uses it, it is extremely unlikely that I will. I don't design automation that needs to talk to office apps. It doesn't solve any problems or create any opportunities for a Linux shop nor would adding MS to our systems enhance either their functionality or especially their reliability. The incestuous coupling of PLC tools and software to MS products is a problem, but the Linux PLC will solve that and I can do anything I need to do with an Open Source database, sockets, and TCP/IP with a year or so of uptime between scheduled maintenance and no forced upgrades to stay in step with the office workers. And no one can change my protocols simply to extort money from the whole organization. What earthly good is a moving, changing, coercive, "standard" over the life of the project? And why work with people who want to screw you? The whole point is, without MS in the office, there is little or nothing to recommend OPC on its own and precious little if you do use MS tools. It limits you to only what MS wants you to do. I'm also fairly sure that I am missing nothing by ignoring those who buy in to Bill's dream of Windows everywhere. Where I am,
embedded systems, controls, test equipment, hardware is where they are not. And the non-desktop world is going my way fast.

Regards

cww
 
R
> Would you consider Modbus/IP as a suitable protocol for use with
> Ethernet attached devices? This would seem to have most of the
> attributes you are looking for.

Perhaps I should re-look. When I last looked it was more of an idea....

> I think a good example of what you are talking about is the ISaGRAF
> soft logic PC control software. The run time will operate under
> MS-DOS, OS-9, VxWorks, Windows 95, 98, 2000, NT, and CE and others.
> All of these support Modubus over TCP/IP/Ethernet (not sure it
> complies strictly with the Modbus/IP standard)

I know the ISaGRAF, it was presented to me by a local agent. Looking from the outside it is the sort of thing I am doing, but I have to do this (also) from completely abstract software. I asked the ISaGRAF person if the protocols were available and got a negative reply. I looked on their CDROM and website and saw no openess.

> but if you want OPC it must run under WinNT.

Well, OPC as it stands is a wrapper for windows software, so no surprises there.

> BTW, does any one have example code for getting MS Excel to talk
> Modbus/IP directly?

The winsock object available in VB allows you to send TCP/IP based messages, using this object Modbus/IP should be easier than 485, as you do not need to bother about the low level stuff. If
the object signals an error, just reset the connection.

The MSDN documentation for VB includes a very easy example of how to use this for messaging.

A word of caution, VB works fine for a single connection such as a client. When you get to a server that allows multiple connections with erroneous ones being stuck off and reinitiated I found VB soon got messy as it does not allow pointers so you end up with control arrays which you must then manage.

I find it much easier to do servers in C++ Builder; new connections generate new endpoint objects which I add into a TList. In some cases I have overidden the creation of a new endpoint with a handler then generates my own endpoint object, which is an object that inherits from Winsock and adds my functionality. In other
cases I have created my own object separately and linked it to the endpoint by stuffing a pointer to it in the tag.

For the same reasons I use C++ for complex clients that interrogate a whole list of data servers.

Note that Winsock wrappers (or perhaps I should say TCP/IP socket wrappers, because winsock is just a windows version of the classic Berkely sockets which, allthougth coming from UNIX, have
become the de-facto way of handling TCP/IP on all platforms), are available in most languages and environments, and although the VB winsock is very handy for EXCEL (as VB is the only macro language it is able to support), it is not necessarily the easiest solution. For example I have been using Python to build gateways between proprietary 485 protocols and TCP/IP, and have been amazed at how simple it is. The Python language always amazes
me, a pity it is not better known or supported.
 
R

Ralph Mackiewicz

I know what you are saying but to expect OPC to deliver protocol when it really is nothing more than an API is why you are frustrated with it.

In your scenario the OPC answer would be that all the remote applications across the net would use OPC client calls. You would then place a single OPC server to the S7 somewhere. The remote apps
would talk to the server by making OPC calls via DCOM.

> In my mind the big failing of OPC is to define COM/DCOM as their
> core technology, when it should be an optional wrapper to a simple
> universal TCP/IP based messaging system. Same goes for SOAP and
> XML.

OPC defined COM as their core technology. DCOM just came along for the ride.

What you are saying is that OPC failed because they only defined an API. What you wanted was a universal application protocol for IA. There are several suitable protocols already defined but little agreement on what is "universal". There is tremendous disagreement in the industry about what is needed from an IA protocol. There are
people that need intercontrol loop exchange for doing loop controls over the network. The "universal" protocol for them is Foundation
Fieldbus. There are people where nothing more than reading integer variables via physical addressing is needed. The universal protocol
for them is Modbus/TCP. There are people who need complex object models with multi-function service support needed. The universal protocol for them is UCA/IEC61850. There are people who want single
cycle high-speed I/O data exchanges over a deterministic serial link. The universal protocol for them is Profibus. There are people who want optimized servo motion control. The universal protocol for them is SERCOS. etc. etc. etc.

IMHO, the value of OPC is as an API that allows Windows applications to be isolated from the underlying IA protocols needed to communicate
with equipment which by necessity can't be based on Windows/DCOM.

The promise of XML is that everyone can write their own protocols using a common language that allows the elements in the protocol to be identified. It won't provide interoperability unless everybody agrees on the meaning of all the elements and how to process them. XML is just a more human readable way of doing what ASN.1 did.

Also, IMHO the closest thing to a universal messaging protocol for IA is the Manufacturing Message Specification (MMS). It is used
successfully in many different industries and applications. It is completely open and is not owned by anybody. It runs over TCP/IP using an IETF defined port number. However, it will take you more than a day to code it because it is more complex than a register access protocol. It does have features that a given application may not need because it was designed to be universal. If you don't want to make tradeoffs, you end up with a multitude of overlapping protocols that are optimized for one narrow niche of applications but
are marketed to the others because it is good enough for them. This is essentially the state of the industry right now.

And from another thread:

> OPC will end up as a fad. (Watch out! I am making predictions.
> usually a bad thing!) I suspect that it will go the way of DDE
> in a matter of 3 years or less.

OPC won't go this way because it is an API that is defined rigorously enough to work. OPC will fade when the use of the Wintel standard fades in the IA industry. I wouldn't hold my breath for that.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
C
> > In my mind the big failing of OPC is to define COM/DCOM as their
> > core technology, when it should be an optional wrapper to a
> > simple universal TCP/IP based messaging system. Same goes
> > for SOAP and XML.
>
> In my mind it is a huge advantage of OPC that something has been
> done at all! There are always better ways to solve a problem. But if
> you want to include all these proposals in a standard you will NEVER
> succed.
>
> Take the fieldbus "standards" an an example.
>
> There are a lot of OPC products, a lot of OPC Foundation members, a
> lot of request from customers.

If you use Microsoft, you really don't have much choice.

> This technology can't be totally wrong.
>
> I do not know much people in automation which are dealing with CORBA
> in REAL products.

Yet it makes every bit as much sense, what does that tell you?

cww
 
R
> I don't get where you have a third PC? You have a PC that has the
> OPC server on it. That PC can also house your application, like an
> MMI. If you want to share data from that PC then you can make
> DCOM connections to it to get data from many other PCs.

OK, there is a PLC with a 2 line LCD interface on it, and the customer is happy with that. He wants to interface that to the company network.

There is a machine with a DOS/Win3.1/NT3.51/W9x application on it (and a lot of IA W9x apps do NOT run on NT). It has to be interfaced.

There is an embedded axis controller that uses an RTOS such as QNX or WRS. It has to be interfaced.

There is a compressor monitoring system that uses Linux. It has to be interfaced.

None of these are suitable as DCOM servers and hence the data must pass thougth a third machine.

I work in the real world. People who have blank sheets and are a single source to provide a whole new facility can say put NT everywhere. The rest of us who must deal with existing facilities and equipment from many sources (decided by our customers, not us) must be prepared to deal with
anything.

There is no fundamental requirement to use NT, or exclude it, it is very easy to make TCP/IP transports that will run anywhere, that is what it is designed for.

> It would be nice if a control device, like a PLC, came with a module
> that supported OPC. The fact that OPC currently does not come
> as a part of the controls processor is not a show stopper for OPC.

On the other hand the reason PLC's do not come with OPC is because Microsoft have failed to come up with the operating systems they promised
at the outset. On the other hand it is possible to have COM objects that communicate with remote divces without using DCOM, or being dependent
on Microsoft. It is not a religious issue, as you seem to think, IA devices such as PLC's need OS's desgned from the ground up for control systems
not data centres. There are different design criteria involved. If Microsoft are not interested in this specialist niche market (or in any case, have not come up with the goods), why through everything into a standard that
requires their product? Would you standardise on appletalk for industrial communications? No, you accept dependence on Microsoft because they
dominate the desktop market, ignoring the fact that you could do better without that dependence.

> If you really want, for whatever reason, to make a direct TCP
> application-layer protocol connection then why not use
> ModbusTCP? It works for me, but then I am a little bit biased. ;-)
>

Because there is no reason why I should not go direct from the PLC to the application, with or without the COM object, which can be optional, but certinally not without DCOM which would seem to complicate the issue unecessarily. If you like ModbusTCP then you can put your COM wrapper directly on that.
 
P

Peter Whalley

Roger,

Thanks for your comments.

Re ISaGRAF, my local distributor promotes it because he tells me they distribute the source code for the run time environment as part of the package. So if he has a problem getting it to run on new hardware he can get in and hack the source code to make it work. He is not tied to the manufacturer in France to solve the problem.

The fact that it uses Modbus over TCP/IP is hidden deep in the documentation but having the source code should help to decode how it works.

BTW, the Open Modbus/TCP standard (Release 1.0, 29 March 1999) is published at
http://www.modicon.com/OPENMBUS/STANDARDS/openmbus.doc .

Regards

Peter Whalley

Managing Director
Magenta Communications Pty Ltd
121 King Street,
Melbourne, VIC 3000
Australia.

e-mail: [email protected]
 
Top