Re: [foxboro] Matrikon OPC Server for Foxboro I/A
- From: <dave.caldwell@xxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Wed, 16 Mar 2011 14:34:04 -0400
Thanks to all for the replies! I am learning a lot.
William Ricker's application most closely matches my own. The intention would
be to remove all OM loading for historians and DM or FoxViews from the I/A
system (a situation of each CP to many AWs and WPs), and replace it with at
least one collection server(maybe more)to serve data to many HMIs on a separate
network (a situation of each CP to one AW collector).
I have been told OM loading can in effect be reduced on the CPs, nodebus, and
so on... Provided limits are placed on the number of tags continuously scanned
and the frequency with which they update. This method of providing HMI still
leaves some challenges: single points of failure, latency, and maintainability.
That said, it appears to have been successfully achieved by William (well done)!
Now for more questions:
* For William: From the description all tags were read all the time. As Russ
points out, the option exists to read the historian tags all the time and then
the HMI tags as needed to decrease OM loading.
My hallucination is that "always-on" decreases latency and the
broadcasts/multicasts needed to open/close OM lists dynamically.
With "make-break" as Russ describes the number of points scanned continuously
is decreased, but the price paid is in "intial call-up" time,
broadcast/multicast traffic, and OM list operations.
Do I have this right? Is this why you chose the "always-on" approach?
* For William: Could you describe how you chose to handle alarms? It appears
that you have collected enough info from the Foxboro side to recreate alarms on
the WW side. How were alarms accomplished?
* For William: The issue of Client write back before OM list initialization
complete... Would this issue only exist when the AW collector / OPC Server was
first turned on as you collect all tags all the time?
* For William: Would the fastest_rsr parameter in the foxapi.cfg that Terry
mentions have purposely been set to 2 (1 second) in your application to provide
for the one second scan?
* For all: I read somewhere that FoxView updates at 1 second by default (not
sure about display manager). Does this mean the FV opens an OM list in the
source CP instructing that CP to scan the list every second and send an update
if it changes by more than the change delta configured for the graphic?
Otherwise, no data is sent. Or, does it mean the CP sends the data every second
no matter what?
* For all: I have been assuming that the bottleneck in my system (23 nodes
connected to the mesh via ATSs) would be the old CPs as the nodebus is good for
1,600 pkts/s, the ATS for about 1000 pkts/s, and the MESH should rock. Am I
thinking correctly or not?
Thanks,
_______________________________________________________________________
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:
