I'm looking for some help and advice with a processbook Module Relative Display I'm working on.

The display has 40 Aliases on it. For each Alias tag there are 4 properties also read from the MDB and displayed, making a total of 200 value symbols. There's a Trend Element to show a trend of the selected Alias tag and an MDB tree element to change the module context. The display can and does operate in ActiveView as well as in Process Book. Everything is working correctly.

But its as slow as a wet week. It takes around 60 seconds to open and around 20 seconds to update after changing the module context. If I build a test display with no VBA code and around 20 Alias Tags performance is fine. Is this normal or is something wrong ? Any hints or tips on getting the best out of a the module database would be much appreciated.

OSIsoft vCampus is a subscription-based, online offering that consists of providing everything people need to develop applications on the PI System.
We invite you to take a "tour" of the OSIsoft Virtual Campus - also feel free to consult the FAQ  or contact OSIsoft vCampus for more details.

I have as little VBA code as I can get away with.

The VBA code sets the Module Context depending on the value of a PI Tag (ie. If current Grade is "X", set module context = "X".) From everything I can figure out in the code, the ContextResolver takes about 100ms to resolve each tag on the display. Hence, it is not a noticeable problem when there are only 10 tags or so, but its very obvious when there are 200 tags.

There is also code to loop through all the MultiState symbols in the Symbols collection and reset the limits of each multistate as required. This routine works correctly and is reasonably quick, (but it has problems because it is triggered before the Context resolver has finished properly, but that's a different story) and code to update a trend symbol. In total maybe 150 lines of VBA code


The end user has PB version 3.0.15.7, but I have version 3.2.0.0 and the problem is the same on both versions.

No, the end user does not have AF, so I cant get round the issue by migrating away from MDB

Assuming we have no real network issues is a big assumption. We already suspect the performance of the network (or at least the connection between PI clients & the Server) as it takes quite some considerable time to load large quantities of trend data - ( to the point where some OSI guys have commented "Hmm, it shouldn't take that long. I wonder whats wrong", before wandering off onto the next issue. )

Everything I can see points to the context resolver being horribly inefficient, but "why" is a different question.

I haven't tried excel because the whole point is to use a PB display. The display will eventually end up embedded on our DCS using ActiveView so an excel solution is no use to me unfortunately.

I have an open support case with OSI. We have eliminated suspected network issues by installing the same PB display on a couple of different PI systems at the customers other sites. Performance is terrible everywhere.

There are only 2 calls to the context resolver in the code - one for properties and one for aliases. So if it is trying to make a new connection for each of the 200 tags it is not something I can control.




There are a lot of modules as well and it seems the context resolver gest exponentially slower the more possible contexts and tags there are on a display.