But - they look so pretty.... lol
On 22 October 2016 at 12:10, doucet427 <doucet427@xxxxxxxxxxx> wrote:
All that pretty 3D stuff slows down your display, deflects operator
attention from really informative information on the display and makes it
more difficult to respond in urgent situations. Where is the benefit?
-------- Original message --------
From: "Vandewater, Tom (HI Contractor)" <TVandewater.contractor@
parpacific.com>
Date:21-10-2016 9:46 PM (GMT-05:00)
To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
Subject: Re: [foxboro] FoxView Library Objects - Slow performance
Thanks for opening this thread Maks and thanks for the graphical tips Russ
and Alex. I have always tried to avoid building graphics like I would
avoid contracting the plague, so I wasn't aware of the "Complexity Index"
parameter found in FoxDraw.
For newbies, call up a graphic in Foxdraw and pick "File" from top menu
pull-down. Select "Display Properties" and then select the "Statistics" tab
to see the "Complexity Index" of the graphic.
At my current client site they have a lot of graphics with an incredible
amount of 3D detail. Pipe flanges with bolt heads, process ladders, 3D
vessels/pumps/blowers/pipes and much more. Additionally, they use generic
library elements as Maks is moving toward. I haven't done any specific
testing yet but I have a graphic that has a ton of static graphic detail
with very few generic library faceplates. The "Complexity Index" of that
graphic is 6.83 and it calls up in 5 to 6 seconds. Another graphic with
almost no static graphic detail with a similar amount of library faceplates
has "Complexity Index" of 1.60 and calls up in about 1.5 seconds.
Maks asked:
"Is it possible that library objects which use aliases are not
optimised the same way as normal FV displays?"
I am curious about this also. Generic faceplates and library elements are
quick and easy to implement and do make it possible to enforce a standard
look and feel. Do you still have a copy of the old style graphic and the
new one Maks? If so, can you compare the Complexity Index of the two?
Russ/Alex,
Does the Complexity Index relate only to the static graphic build
time or does it estimate the time it takes to secure the dynamic data link
connections with the CP's?
Thanks for any insight.
Regards,
Tom VandeWater
Control Conversions, Inc.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Maks Wilde
Sent: Friday, October 21, 2016 9:29 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FoxView Library Objects - Slow performance
I can confirm that the display timestamp does not change on call-up every
time.
I'm not sure what else can be done other than not using library symbols.
Should I be putting in a CAR for this or is there anything else that can
be done to improve the speed?
Thanks,
Maks Wilde
On Fri, Oct 21, 2016 at 2:22 PM, Russell Boulay < Russ.Boulay@schneider-
electric.com> wrote:
Yes, possibly lack of optimization could be part of the issue.issue.
Check to see if the display file is continually being updated/dated
every time it is called...
Only first few call-ups should change the date/time ....if it
continues with subsequent call-ups....then optimization is part of your
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Maks Wilde
Sent: Friday, October 21, 2016 11:19 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FoxView Library Objects - Slow performance
Russell, Alex,
Thank you for the suggestions, I forgot to add that in my original email:
The complexity index for the original display is 1.4, using library
symbols brought this up to 1.7, but the call-up time is ~6x longer.
We did not add any 3D rendering, in fact, have simplified things
including the colour scheme, following high-performance hmi guidelines.
Fast scan option is turned off and Scan Rate (1 sec) and Scan Delay (5
sec) are the same as on the original display. I tested the display by
lowering these value but the call-up time was the same.
Is it possible that library objects which use aliases are not
optimised the same way as normal FV displays?
Best Regards,
Maks Wilde
On Fri, Oct 21, 2016 at 1:01 PM, Alexander Johnson <
alexander.johnson@xxxxxxxxxxxxxxxxxxxxxx> wrote:
I'd like to second Russ' suggestion.
We once had a client take a bitmap pump picture from a demo, shrink
it down, make a library element, attach a connection to change color
based on a discrete status. He then built a graphic with about 100
pumps on it. It took more than 30s to call up.
Why? 100 connections isn't very much and the picture was small.
Well, as it turned out, the image he used was a spectacular 3D style
rendering lots of shading. It was megabytes in size. The workstation
spent most of its time rendering details that could not be seen.
Once a simple pump drawing was used, the display came up as expected.
The moral: Check the size of the library element and its complexity.
Best,
Alex
_________________________________________________________________________
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
