Re: [foxboro] OPC in General (was: AIM OPC Server)
- From: "Corey R Clingo" <clingoc@xxxxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Tue, 8 Mar 2005 13:17:23 -0500
I can't really say I'm an expert on Ethernet/IP either; I just threw that
out as an example. I presume Ethernet/IP offers some kind of status and
time information. It uses the same application-layer spec (CIP) as
Rockwell's ControlNet, and one would think that status and timestamping
would be requirements there. I believe the A-B Ethernet interfaces use
Ethernet/IP.
I agree that if you must do OPC, the "embedded OPC" approach is a good
one. Too bad more vendors aren't going that route (e.g., FDSI FBM). I'll
still likely have to have a Windows PC somewhere, but it doesn't have to
sit on my nodebus (Foxboro's future direction notwithstanding... :-)
As for Andreas' comment about not confusing .NET and OPC-XML, I realize
they aren't necessarily one and the same, but M$ has made noises about
dropping DCOM support in future Windows versions, and so the only standard
IPC option in .NET could end up being XML/SOAP. Besides, that's where
Micro$oft wants you to go today (that "at their mercy" thing again).
Corey
"Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
03/07/2005 03:46 PM
Please respond to foxboro
To: foxboro
cc:
Subject: [foxboro] OPC in General (was: AIM OPC Server)
Re: OPC Future
Looks like OPC is moving to their Unified Architecture (OPC-UA) which is
web
service based.
The impact is basically that we are back to the future (ASCII text files -
aka XML - moving using file transfer - aka HTTP/SOAP). :)
Gist of this is OPC is moving to less efficient, but more independent
delivery of data.
It's great for certain classes of problems, e.g., asset management of
device
configuration data, but not so hot at others - HMI support. That is, as
the
object becomes more complex and needs to update less often OPC UA shines.
I doubt that it will be used where OPC DA is today. Our small process
control objects (value, status, time tag) are pretty inefficient if you
have
to convert them to and from ASCII to move them.
Re: OPC DA
I'm not a big fan of OPC DA becoming the lingua franca of our business
which
it is. DCOM has no business in field equipment.
But OPC has a big advantage - status bits in a standard format and time
tags
and lots of folks want them.
So, if one it going to do it (and vendors must) our FDSI FBM is the right
platform (lesser evil?) since it isolates the other system from the
control
network which is full of Windows boxes.
I suspect that isolation will be very valuable over the next few years.
Re: EthernetIP or Alex displays his ignorance
I'm no expert. Does it offer status bits and time tags for its values?
Regards,
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
Behalf Of Corey R Clingo
Sent: Monday, March 07, 2005 2:55 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] AIM OPC Server
-----Original Message-----
From: Johnson, Alex (Foxboro) [mailto:ajohnson@xxxxxxxxxxx]=20
Sent: Wednesday, March 02, 2005 2:02 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] AIM OPC Server
Free advice?
Put the AIM*OPC DA Server on the client machines and use NetAIM*API to
connect to the source AW (AW70 or AW51). This is equivalent to =
Matrikon's
"OPC Tunnelling".
Why do it?
Easy - the setup is much simpler - no DCOM.
Worth the time and money, I promise.
Regards,
=20
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
