ProSoft Technology ProSoft i-View - Manual (Page 86)

Security ProSoft i-View ♦ Mobile Process Monitoring and Control Application
User Manual Version 2.0.2
Page 86 of 106 ProSoft Technology, Inc.
September 29, 2011
9.3 Performance
ProSoft i-View is designed to offer great performance and a satisfactory user experience
with good interface responsiveness. Integrators do not usually need to take particular
actions to improve performance. The app carries out a series of optimizations on tags
and PLC communications that in most cases are enough to relieve integrators from
having to adopt particular actions or design patters.
Still, understanding what optimizations ProSoft i-View performs can be useful to find out
why, if ever, a performance issue arose and what you can do to improve on it.
Performance matters tend to be a complex subject and extensive discussions can be
made; ultimately, testing is the only way to have a trustable answer. We will just
enumerate some of the techniques used in ProSoft i-View to maximize performance and
will give some tips to help you getting the best of the app for your particular project.
ProSoft i-View automatically performs the following optimizations:
Only the minimum set of tags necessary to display the interface is polled at a given
time. Particularly, tags that are not used in expressions and which values are not
shown on the interface at a given time are not polled at all.
Therefore, the less tags you link with expressions or use in expressions the better. In
fact, having a large number of tags for the single purpose of showing their PLC value
will not incur in any performance penalty because most of the time they will not be
polled out from the PLC anyway.
If a particular PLC address needs to be read at a given time, it will only be read once
per polling cycle regardless of how many instances of tags tied to that address are
found in the project.
Consequently, you can repeat the same PLC tag address as many times as you
need in your project without having to worry about any performance penalty.
The list of candidate tags to be read at a given time is applied a minimal cost
algorithm to determine the less and shorter available communication frames for the
relevant protocol which fulfill the entire request. The optimal solution may include
reading unsolicited tags if this justify a better performance figure. The simpler
scenario is reading several, almost contiguous tags, with a small gap in between.
Reading all of them and then discarding the unused ones may be faster than only
reading the solicited ones.
To help on this, you can use tags as contiguous as possible and leave the shorter
possible gaps between them, however note that if you have spared tags that are
used in expressions, or your users make extensive use of the plotting feature, this
measure may not be as effective as you might expect or even contraindicated,
because basically you may not always beat the already optimal set of commands that
ProSoft i-View would generate anyway.
Tags used in alarms or used in expressions are permanently polled to guarantee
interface consistency. These tags are also candidates to automatic optimization and
applied all the above techniques, but since they are read very often they offer the
best opportunity for integrators to optimize their project in an user noticeable way.
As said, this is by far the best thing you can do to optimize your project. The key is to
have as few as possible tags tied to expressions and to keep them in contiguous
PLC memory addresses, specially with no intercalations of tags that are not used in
expressions (i.e. tags that are candidates to be stripped off from readings). In other
words, keep the tags used in expressions or alarms as packed as possible in PLC
memory and do not interlace them with the remaining tags.