Maks,
Have you tried the OMMO option? I have not yet, but have been wanting to when I
have the opportunity. Here is what I found in the documentation. Not sure if
this will affect display call-up or not.
Object Manager Multicast Optimization (OMMO)
For Windows-based workstations with I/A Series software v8.6-v8.8 or Control
Core Services v9.0 or later, a new option called the Object Manager Multicast
Optimization (OMMO) feature is available to reduce the network processing
overhead on The Mesh control network and I/A Series Nodebus as well to reduce
the OM processing overhead on the Foxboro stations (Application Workstations,
Control Processors, etc.). When enabled, OMMO reduces the number of multicast
network communications initiated by the Object Manager. OMMO is disabled by
default.
To enable Object Manager Multicast Optimization (OMMO), refer to B0193BC-N for
Object Manager Multicast Optimization (OMMO). Info below.
The file "usr_loadable.cfg", located in D:\usr\fox\exten\config\, contains the
OMMO parameter. It is not recommended to change "usr_loadable.cfg" directly as
a Day 1 installation would regenerate the file and override your changes.
To change the value of these parameters, edit the file "opsys_usr.cfg" located
in D:\etc\fox\. Change the value of parameter "OM_MULTICAST_OPTIMIZATION %"
from 0 to 1. Next, open a command prompt window in D:\usr\local\ and execute
command: verifier -V c. There should be no error returned from the execution
of this command. The "usr_loadable.cfg" file should be updated with the
change. If not, add the line DM_VLEVEL=1 to the "init.usr" file located in
D:\usr\fox\wp\data\. Reboot server.
Repeat on all stations as necessary.
Tony Stankiewicz
X2stanki@xxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Maks Wilde
Sent: Monday, October 31, 2016 4:29 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FoxView Library Objects - Slow performance
Hi List,
We have been doing some more experimentation with the displays last week.
Key Findings
- The slowness appears to be independent of library vs standard objects
We recreated the exact display that was using library objects and
manually typed all the connections in. Still slow. No bad connections, no
objects outside of viewable area.
- There is a direct correlation between the number of connections that each
object has and the loading speed of the display
We proceeded to take out one connection at a time away from the symbols,
and the display became faster with each iteration (eg: from a GDEV:
.BLKSTA, .INTLCK, .MA, ALMSTA, etc)
No single connection/parameter was found to be the culprit.
We replaced the polygon symbols for valves/pumps with plain squares to
reduce the complexity. No improvement was found.
- Complexity index is a poor predictor of loading speed.
We have plant overviews with a complexity of 3.7 (insanely crammed) which
load quicker than displays with a complexity of 1.7.
A display with 25 valves and 5 pumps (zero analog for this test) yielded
a complexity index of 1.26 and was still noticeably too slow.
Questions:
Are there any guiedlines as to how many connections a single display should
not exceed? Or perhaps the maximum #'s to compare to those seen in Display
Properties in FV?
Are there any special configuration parameters for FV that can be used to
optimize performance, say of OM lists, or similar?
Thank you again for all the feedback,
Maks
--
Maks Wilde, P.Eng
Senior Control Systems Engineer
Cell: 519.536.6310
mwilde@xxxxxxxxxxxxx
www.kicsystems.ca
Confidentiality Warning: This message and any attachments are intended only
for the use of the intended recipient(s), are confidential, and may be
privileged. If you are not the intended recipient, you are hereby notified
that any review, retransmission, conversion to hard copy, copying,
circulation or other use of this message and any attachments is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately by return e-mail, and delete this message and any attachments
from your system.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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
