Re: [foxboro] Off Mesh Galaxy database
- From: sssmith1@xxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 24 Mar 2010 09:31:44 -0500
We have used "off mesh" GR since 1.1.
Lots of caveats with off mesh architecture.
You are "supposed" to be able to run dual core processors. We did for
quite some time. Did not see any real benefit. In fact quite the
opposite. While on still on the staging floor, Foxboro reverted our
system back to \onecpu as they empirically determined that was causing
severe delays and slow downs when running direct access script operations.
( Direct access is known , and by design,runs at a higher priority.
Supposed to as described in multi user support section of B0750BM IEE
scripting reference). We were told and shown that the direct access
scripts that needed to be run against our database for repairs, either ran
incredibly slower, and or failed /errored out with memory problems, when
multiple cpu's were enable. It appears that there are some issues with
GRAccess and multi threading. We still are running with /onecpu on our
production server. The short of it is, applications have to be written
and optimized to properly take advantage and use dual CPU technology. It
appear that not just that the IA software is at fault. In my experience
Archestra has issues as well. I know wonderware made lots of changes
system platform 3.0. I believe Infusion components though are 2.0/2.5.
Second caveat is that your second NIC card has to first in
Microsoft network registry binding list. This should be a simple enough
thing to manage, but seemed to plage us throughout commissioning. It was
almost like the Microsoft setting occasionally got stepped on and
"automagicly" changed. Unknown if this was just QA snafus, or if
Undelpoys/deploys could have had effect.
Third issue, when using off mesh galaxy, which was still present
as of 1.22, and I believe is still resident from what I read in 2.0, is
that individual platforms ( workstations, eng, hist,.... any archestra
component on the MESH have to be configured and referenced by their
private ip address rather than by letter bug or name.
Care has to be taken in maintaining the host and lmhost files through the
system, as the off mesh IP and not maintained by sysdef and committal.
There have been other issues and CARS submitted around problems with error
reporting, heart beat, diagnostic information service to the HMI in off
mesh, but believe they are slated to be addressed.
Sheldon Smith
Mailto: sssmith1@xxxxxxx
_______________________________________________________________________
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:
