Re: [foxboro] Need help

Re: Incidentally, I believe Foxboro OEMs the Matrikon OPC server, and maybe
the OPC client, for its Aim OPC server and client; don't know about the I/O
Gate.

This is incorrect. Matrikon labor was used in the first release of the OPC
Server, but it our product and there are differences between the two.
Matrikon was not involved in the AIM*OPC Client or the AW70 OPC DA I/O Gate.


Regards,
 
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (operator)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
For the latest information on ArchestrA, go to
http://www.invensys.com/Archestra.html.
 

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Corey R Clingo
Sent: Monday, April 19, 2004 9:52 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Need help

Aspen IP.21 and DMC,  and PI as well I believe, use their own data 
collectors.  Aspen and OSI both have native collectors for FoxAPI/AimAPI 
as well as for OPC.  These collectors typically run on the DCS server 
(AW51 or AW70), but they can probably run remotely with NetFoxAPI.  They 
also both have collectors that act as OPC clients.
Since our AW70 I/O Gate is an OPC client, I don't think you could use this 
with an Aspen or OSI collectors; you would need something like the Aim OPC 
server or Matrikon's product .  Interesting comments you have about 
Matrikon and their software quality, customer support, and their and 
Foxboro's "reputation".   Incidentally, I believe Foxboro OEMs the 
Matrikon OPC server, and maybe the OPC client, for its Aim OPC server and 
client; don't know about the I/O Gate.

We use the Aspen native FoxAPI collector running on an AW51.  I would 
choose this over an OPC collector on I/A simply because there is one less 
layer of software to contend with.  As for the MVC, I'd run it on a 
separate box if possible.  We've had several instances here on an Aspen 
collector that's shared between IP.21 and DMC where we needed to restart 
the collector to fix an IP.21 problem, but couldn't because the DMC was 
running, or the box was restarted to fix a DMC problem and no one notified 
the IP.21 admin to reinitiate collection for IP.21.

Corey Clingo
BASF Corp.






Mark David <mdavid0404@xxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
04/19/2004 11:19 AM
Please respond to foxboro

              To:  foxboro 
              cc: 
         Subject:       [foxboro] Need help






We intend to install a real-time database historian such as IP21/PI  and 
potentially, an MVC and an intelligent tuning application on a FOX I/A 
with an already installed AIM license.

Here are the Options we are considering, and please tell us whether it is 
feasible:

1.  Use an AW70  with the OPC I/O Gate.
Such box will read data from the FOX I/O blocks and transfers it to the 
Historian( PI or IP21), which means the historian should have an OPC 
server as well.
If this is doable (transferring data from the FOX I/A to the historian 
using AW70),  we will then interface the future MVC (most likely DMC) to 
the OPC sever of the historian where the AW70 OPC client will read the 
setpoints from and transfers them to the FOX I/O blocks.

Considering an AIM license already exists, what are the consideration we 
need to take concerning the CP loads by adding the AW70  which will serve 
as the gateway for the future Historian?
What do you think about this approach?  Is it feasible?

Based on your experience how long would it take to install the AW70, the 
relate software and the required configuration?

2.  Install the OPC server for AIM on top of the AIM server.

We presume a simple PC is suitable.  Or is there a standard Foxboro 
hardware we need to recommend? If yes why?
We presume the OPC server of AIM comes with an AIMnet  API that connects 
to the AIM-API over TCP-IP.

In he future, if we decide to go for the MVC we will write points to the 
OPC server of AIM.

Such configuration will not create any overload on the DCS network CP load 
as we will be using AIM as a shield or buffer zone.  Is it correct?

However, the issue comes from the fact, what if AIM fails?  Then we will 
stop any communications to all applications.

We have a single point of failure.


3.  Install the OPC server of Matrikon.

This could be attractive.  However we would need to understand of the DCS 
load.
At the same time, our experience with Matrikon and many customers confirm 
the same, their support is very poor and products are buggy.  In addition, 
it takes them too long to fix anything and get back to customers.

The idea of buying a solution from Foxboro is more attractive to us. 
Foxboro has a good reputation.

4.  Install the Native FOX I/A bridge of the Historian such as PI.

This could be an attractive solution as if the network fails, both 
Historian we will buffer the data.  Do you have any comments on this?

Later on, what will happen if we add an MVC?

Also, if we had applications to fine loop controllers for example, we will 
just add an OPC server to the historian.

What do you think?

Best Regards,
Mark David
Joint Gas
Costa Rica


---------------------------------
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Créez votre Yahoo! Mail

Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !



_______________________________________________________________________
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:             http://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:             http://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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: