Slow faceplate control
The system is V5.1 Rev.E (update from Rev.A). The callup time of a grafic display is quit good (Diag_Display). If I open a faceplate, the faceplate frame open quick (FaceplateOpening). But for the control it take some time (FaceplateOpen, Diag_Faceplate). This is also true for normal AI (Diag_Faceplate_AI). If I use the VB6 control in the AI faceplate, it is much faster then the standard PG2 control.
If more programs are open on the client PC then the effect is more dramatic, is takes more time. It could depend on memory, it is only 32bit windows version.
Any idea why "get graphics data" in an normal AI takes so much time?
Voted best answer
PG2 has more overhead than VB6. You can't do so much about it other than supplying top-of-the-line thick clients with closer to 4 GHz CPU speed and SSD disk. Workplaces hosted by a Terminal Server running 2.4 GHz cores and thin clients will be noticeably slower.
I've been told that future versions (beyond the present 5.1 RevE and 6.0.2 will become a bit faster due to recently identified improvements)
Workplace callup speed is affected by many factors:
1) CPU and memory resources available in aspect server and workplace client
2) OPC server performance (AddGroup/AddItems are synchronous operations)
3) First data connection since start of workplace need to create network connections
4) First data subscription since download/engineering lacks cache (but will leave one for the benefit of subsequent calls of the same display).
5) Number of items and complexity of data types (simple, structured, cascaded)
6) Type of connectivity (some are faster some are slower)
7) Design (LateBindings WILL reduce performance)
#1 can be kept under surveillance using Windows Performance Monitor (e.g. Total CPU load and Virtual Bytes in use by AfwWorkplaceApplication.exe and AfwADServer.exe). Never let workplace exceed 1500 MB virtual bytes (see product bulletin 3BSE085158)
To rule out #3 never measure first callup in any newly started workplace.
To rule out #4 never measure a (in this client) previously not presented graphic display (always "dry iterate" all displays to test before commencing test run).
Each connect have its own specification. AC 800 Connect is benchmarked to roughly 800 items per second with active connection and valid subscription cache. A 4000 items display typically takes 5 seconds to call up.
After rule out most of the things if found one strange behavior. From time to time messages appear in the system log "No OPC Data Source..." from Object MB300 DI. This object exist for each AC450 controller as group and in the ObjectTypeStructure as template.
I can force this error if I i.g. try to open the template faceplate. This make sense because there is no real OPC connection availible.
But under normal operation nobody do that. What could generate this message? I have investigated some faceplates and graphic items with the reference tool but everything seems ok.
One reason for the "No data source ..." messages can be due to a certain behavior by process graphic designers.
1. They begin with dragging in a handful of e.g. MB300 DI indicators from the Object Type Structure into a display
2. The majority is dragged to their final destination and given an object name (reference)
3. The display is saved & approved.
If step 2 did not cover all elements dragged into the display you will receive "No data source" messages when the display is called.
I've even seen such elements been dragged outside the viewable area of a graphic, like a painter's "palette". All elements in the palette will create "No data source..."
I suspect you can hunt these elements down by using the Consistency Checker tool and find them as "Broken References".
1. Use Find Tool to search for "Aspect Category=Process Display PG2"
2. Drag result into Consistency Checker tool
3. Check Consistency
4. Repeat steps 1-3 for remaining categories of graphics (Graphic Element PG2, Faceplate Element PG2, Process Display VB6, Graphic Element VB6, Faceplate Element VB6, etc. etc.)
Avoid checking VB6 if not used by operators. Try to get rid of unused graphics by asking your vendor for a VB6 free library, or you may use the Extension Library feature "Enable" to disable (hide) them. See attached document.