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