Re: [foxboro] Off platform communications
- From: "Glen Bounds" <gbounds@xxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 28 May 2002 13:22:02 -0400
Just to add another $.02 worth.
If you ever think you will need to transmit bi-directional data between
the Foxboro system and the "other" system, OPC is not a good choice.
By bi-directional, I mean the same data point being driven from both
systems. One direction will always be a slave to the other. You can
choose which one is the master, but you can not make them equal.
So, sometimes you will loose updates.
But from the sounds of your application, OPC may work fine. We use
a 3rd party system. http://www.matrikon.com/
Glen Bounds
Sr. Control Systems Engineer
Corn Products International, Inc.
4501 Overdale Rd.
Winston Salem, NC 27107
336.785.8826 (office)
336.785.8809 (fax)
email - gbounds@xxxxxxxxxxxxx
----- Original Message -----
From: "Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Friday, May 24, 2002 6:39 PM
Subject: Re: [foxboro] Off platform communications
>
> I will take this opportunity to point out a significant issue with using
OPC
> Servers on the I/A Series.
>
>
> Most current OPC Servers use one-shot sets to write values to the process
> CBPs from a remote OPC Client. This works pretty well as long as the
volume
> of data is similar to that of an operator's console. There is noise that
our
> OPC Server will offer connected writes as a high speed alternative.
However,
> as readers of this list know, connected writes have issues too.
>
>
> To refresh our memories:
>
> 1) One-shot sets in the worst case:
> a) generate broadcast traffic,
> b) are slow since they require the remote station to reply, and
> c) carry only one value per message.
> 2) One-shot sets in the best case, the broadcast is eliminated often at
the
> expense of the IMPORT table which
> by default is quite small. When it fills broadcasts are back in use.
> 3) Write lists secure the target C:B.P and the point remains secured if
the
> OPC Server or its station die. This
> makes backup OPC Servers with write lists problematic. You can do
backups
> with one-shots without issue.
>
>
> Now, consider Troy's note. He wrote that an older application had
> "successfully used the Data Poke utility to input data from spreadsheets
> back to DCS" and that it did "not need to pull large amounts of data back
> into the DCS."
>
> However, he went on to add that he is " looking for is a real-time
interface
> to display" process data for his operators."
>
> When I read those words, a red flag went up.
>
>
> If the data volume in such an application gets too high (10/20 points per
> second would do it), you will have a inordinate amount of traffic if the
> data is stored in a CBP and one-shot sets are used.
>
> This amount of data flow seems likely when I read the words "we are
looking
> for is a real-time interface to display a limited amount of SCADA data to
> our operators." Experience tells me that the need is higher than the
system
> will tolerate or will be soon after installation.
>
>
> So, the options are:
>
> 1) Use an OPC Server and store the data in CBPs with the network traffic
> that might entail.
> 2) Use an OPC Server and store the data in Shared Variables (no network
> traffic and the one-shot sets are faster)
> 3) Use an OPC Client on the I/A Series side and avoid the issue
altogether.
>
>
> Any of these options will work, but you need to understand the tradeoffs.
>
>
> In the first case, you could over burden your target CP and if broadcasts
> occur your CBLAN and otherwise uninvolved stations on the network.
>
>
> In the second case, you will need to create the shared variables at
bootup.
> a) Using the omcrt tool, this requires 12 seconds per SV. This is very
> slow.
> b) Using the ommcrt tool, you can create 20 variables of the same type
in
> one 12 second interval.
> This is 20 times as fast, but still slow.
> c) You will need to use the ICC to connect the SVs to blocks in the CP
if
> you want them alarmed or to have
> detail displays
>
>
> The third case eliminates all of these issues and lets you build blocks to
> hold the data.
>
>
> There is actually a fourth possibility using application objects, but
that's
> a story for another day.
>
>
> Regards,
>
> Alex Johnson
> Invensys
> 10707 Haddington
> Houston, TX 77063
> 713.722.2859 (office)
> 713.722.2700 (switchboard)
> 713.932.0222 (fax)
> ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx>
> Come to the Invensys Showcase: http://www.invensysshowcase.com/
> <http://www.invensysshowcase.com/>
>
>
> -----Original Message-----
> From: Mark V. Urda [SMTP:mvurda@xxxxxxx]
> Sent: Friday, May 24, 2002 12:38 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Off platform communications
>
>
> Troy-
>
> Assuming that your IA system has at least one AW51 (4.3 or higher)
> or AW70
> (6.1 or higher) with a second ethernet port, then I suggest that you
> use the
> AIM * OPC Server. AIM * OPC Server software can be installed on
> directly on
> an NT/2000 based PC or directly on Intellution SCADA node, if it is
> NT/2000
> and has adequate resources. IA OPC Server can be accessed by
> Intellution OPC
> client for read and write access to IA database.
>
> >From the Intellution OPC Driver Help File, is the following
> description of
> Intellution OPC I/O Driver:
>
> The OPC I/O driver is an Intellution version 7.1x I/O driver that
> provides
> the interface and communications protocol between OLE for Process
> Control
> servers and your process control software. Intellution version 7.1x
> drivers
> are designed with the following attributes to provide flexibility
> and
> ease-of-use:
>
> OLE Automation technology.
> FIX integration.
> Event-driven architecture.
> OLE for Process Control compliance.
>
> OLE Automation Technology
>
> Version 7.1x drivers incorporate OLE Automation technology and can
> therefore
> expose their features to scripting tools and other applications.
> Because
> the drivers are OLE Automation applications, you can:
>
> Create and manipulate objects exposed in the I/O Server from another
> application.
>
> Create tools that access and manipulate driver objects. These tools
> can
> include embedded macro languages or external programming tools.
>
> The I/O driver consists of the following OLE components:
>
> The I/O Server The core executable program. The I/O Server
> maintains the
> OPC server, group, and item objects, performs all required functions
> for
> communicating with third-party OPC servers, and exposes the methods
> and
> properties to other applications.
>
> The I/O Driver Power Tool A client application to the I/O Server
> with a
> graphical user interface. The Power Tool accesses the I/O Server
> and lets
> you view and modify OPC server, group, and item properties.
>
> You can also view and modify driver properties with a custom client
> application developed specifically for your system. Refer to
> Creating
> Custom Client Applications to learn more about creating your own
> client
> application.
>
> Integration with the FIX
>
> Intellution version 7.1x drivers let you automatically add addresses
> to the
> driver configuration while you are configuring your FIX database.
> When you
> add a block to the database that accesses a point in the OPC server
> that you
> have not configured, the point is automatically added to the I/O
> Server and
> polled for data. Refer to Feature: Creating Items Automatically in
> FIX
> Database Builder.
>
> Event-Driven Architecture
>
> Version 7.1x drivers are event-based rather than time-based,
> reducing CPU
> time and increasing performance.
>
> OPC Compliance
>
> The OPC Client driver complies with the OLE for Process Control
> (OPC) v1.0a
> standard. The OPC Client provides the ability to bring data from
> any OPC
> v1.0a server to Intellution's FIX Human-Machine Interface (HMI)
> software.
> The OPC Client driver is also compliant with the v2.0 standard.
>
> 1997-99, Intellution, Inc. All Rights Reserved.
>
> We have been using AIM* OPC Server for the last six months to
> develop
> solutions interfacing IA to OPC aware applications like Fix,
> WonderWAre and
> other third party HMI and other applications.
>
> The Foxboro part number for Real Time Data Access is Q0301UT, and is
> described as:
>
> FUNCTION: The AIM*AT OPC DA Server Is An OPC V2.04 Compliant Server
> That
> Provides OPC Client Software With Access To I/A Series Object Data
> And To
> Real Time Point (RTP) Data In The AIM*Historian. The DA Server
> Software
> Provides Read And Write Access To Object Data (C:B.P) In I/A Series
> Via Both
> The AW51 (Solaris) And AW70 (Windows NT) Platforms. The AIM*OPC
> Server
> Resides On A Windows NT Or A Windows 2000 Platform.
>
> PSS can be accessed via
> http://www.foxboro.com/iaseries/pss/21s6/21s6d10b4.pdf for more
> info.
>
> This should provide the most cost-effective solution since no new IA
> stations are required, and software runs on PC platforms.
>
> Best regards,
>
> Mark V. Urda
>
> Synergy Systems Inc.
> 528 West 5th Avenue
> Naperville, IL 60563
>
> phone: 630-778-1960
> fax: 630-778-7926
> cell: 630-248-9382
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx
> [mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Troy L Brazell
> Sent: Friday, May 24, 2002 9:03 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] Off platform communications
>
>
>
> We need to connect or I/A system to Intellution via the company WAN.
> We do
> not need to pull large amounts of data back into DCS. We us DataLink
> and
> Data for Windows on older systems to get information out of DCS and
> into
> Intellution. We has successfully used the Data Poke utility to input
> data
> from spreadsheets back to DCS, however, what we are looking for is a
> real-time interface to display a limited amount of SCADA data to our
> operators. Anyone have any ideas?
> Thanks
> Troy
>
> **************************************************
> A lack of planing and communication on your
> part does not constitute an emergency on my part!
>
> Troy L.Brazell
> Duke Energy Field Services
> Automation CCST
> Mid Continent
> Borger, Texas
> tlbrazell@xxxxxxxxxxxxxxx
> Cell 806-898-4340
> Office 806-275-5274
>
>
>
>
> _______________________________________________________________________
> 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
>
>
>
>
>
> _______________________________________________________________________
> 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
>
>
>
> _______________________________________________________________________
> 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
>
_______________________________________________________________________
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:
