Skip navigation
All Places > PI Developers Club > Blog > Author: ldieffenbach

PI Developers Club

3 Posts authored by: ldieffenbach

Hello vCampus community!


I wanted to take a few moments to describe some of the OSIsoft presentations you’ll be seeing at the User Conference in San Francisco this year. In case you haven’t heard, the annual OSIsoft User Conference will be held April 23 to 25, 2012, at the Hilton Union Square in San Francisco. You can sign up today at this link. This year’s theme is: The Power of Data, so get ready for some data-driven presentations.


Naturally, we’re all hard at work preparing the content to be presented by OSIsoft this year, but I thought this would be a good time to give you an idea of what to expect. Feel free to post your questions and comments right here on the blog. At this year’s conference you’ll have the opportunity to see what’s new in the PI System as well as watch demonstrations of how to work with our products in meaningful ways.


In the category of Client applications, you’ll see:


·         Demonstrations of the asset-relative features of PI Coresight, PI ProcessBook, PI WebParts, and PI DataLink, featuring dashboard displays in Microsoft SharePoint. There are new versions of PI Coresight, PI ProcessBook and PI DataLink, which will have their own focused presentations.


·         Demonstrations of leveraging operational data in Business Intelligence (BI) and Reporting tools


·         More information on our plans for mobile device offerings


·         A review of past customer presentations of PI ProcessBook displays (aimed at our newer users) along with demonstrations of the new features in PI ProcessBook 2012


In the category of Server applications, you’ll see:


·         Demonstrations of the new PI Server


·         Ways to build up your PI Asset Framework content with typical usage scenarios and examples


·         How customers get value out of PI Notifications


·         An overview of how PI Analytics calculations are built and used


You’ll also see presentations on:


·         Research on cloud offerings


·         Cyber Security recommendations


·         Line of Business application integration


·         An update on PI Event Frames features


·         New possibilities with PI Interfaces


To learn more about the latest and greatest the PI System has to offer, plan to stay an extra day to participate in the OSIsoft Education Day. If you bring a laptop with a wireless adapter, you can participate in the hands-on activities using our cloud-based Virtual Learning Environment.


Finally, don’t forget the always-popular Product Expo, where you’ll have an opportunity to see even more product demonstrations and speak with the people who work so hard to produce them.


The full conference agenda is available now! Check it out….


See you there!

Recently, there was a discussion thread within the vCampus community regarding whether a facelift is needed for our beloved PI ProcessBook.


In the ensuing discussion, there were several comments on desired changes to PI ProcessBook functionality (which is not the same as a visual update in any way). Part of that commentary was an expressed frustration with not knowing how to get enhancement requests addressed. I wanted to take some time to be frank about proposed changes to PI ProcessBook as we know and love it.


It is no great secret that PI ProcessBook has been evolving from the original code base for about 15 years now. It is also no secret that the technology on which it is based is rather dated. Furthermore, as features have been added over the years, the code has grown more complex and difficult to maintain. As a result, the last few releases of PI ProcessBook have featured new capabilities that have added on to the existing features rather than re-writing them. One reason for this approach has been that we are ever sensitive to the investment existing users have made in PI ProcessBook content and we have no intention of releasing a new version that breaks their existing displays, to the best of our ability to prevent that. (I recently received anecdotal evidence that displays created 10 years ago or more continue to be used in PI ProcessBook today--not a bad testimony to the product's overall stability.)


The effect of this conservative approach is that we don't intend to make deep architectural changes to PI ProcessBook. So, things like changing the way symbols are drawn or rendered are not going to happen.


That doesn't mean there isn't anything useful to add to the existing capabilities.


Of those requested changes that do not represent deep changes to how the product works, there is a rather long list of things that could be done. Requests for change are weighed against one another as well as other factors. For example, those cross-product capabilities of the PI System that the company is focused on may take priority over smaller requests for changes that only affect PI ProcessBook. Problems customers have in making displays work the way they were intended (and for which there isn't any remedy) often take precendence over requests that would be handy but can still be done in some fashion. New versions of Microsoft technologies that have an impact on PI ProcessBook (e.g., a new operating system, new versions of .NET, etc.) need to be tested for compatibility and any issues considered. Capabilities that allow PI ProcessBook to be useful in newer markets (e.g., customers outside of North America) may also get precendence, if that is strategic for the company.


Whenever we plan a new release of PI ProcessBook, we look at the major new capabilities we plan to provide and then consider which of the outstanding requests would fit in with the planned work. Sometimes, priorities change between the initial planning and final release of a new version. Our PI System Roadmap, available on the Technical Support web site, characterizes those enhancements to which we've committed for an upcoming release and, often, the additional changes we've considered adding (but which may change). We don't list every single change we are planning (on the Roadmap) because that information can change more quickly as particular requests are investigated (for example), and keeping such a list truly up-to-date is difficult at best. We do try to mark the planned items when a release is started, but the work may get delayed for many reasons (there is a technical barrier, the developers don't understand the desired functionality well enough, another item with higher priority intrudes, there are conflicting requests from different customers, etc.). This process isn't designed to frustrate our customers, but it is a reality in a product-development company that serves many industries that have a variety of similar yet unique requirements for displaying time series data in a graphical fashion.


Hopefully, I've been clear about the sort of decison-making we go through at OSIsoft. I do understand that it can be very frustrating not to know when your particular request will get addressed, for sure, but that doesn't mean we aren't trying to provide new and useful features to PI ProcessBook.

PI ProcessBook 3.2 represents a transitional version of display relativity, where you can build one display and choose the equipment of interest dynamically. New tools for automating the migration of Module Database content to AF are in progress, but have not been released yet. As you consider migrating from existing Module Database-based ProcessBook displays to AF-based ProcessBook displays, note that both the existing Module Relative Display (MRD) add-in as well as the new Element Relative Display (ERD) add-in are provided with version 3.2 of PI ProcessBook. Because both add-ins are installed by default, you may have some questions about how and when to use each add-in. This article is intended to address those anticipated questions.

Use MRD if…

If you have not migrated your existing Module Database to AF, if you have existing displays that you continue to use that were built with the MRD provided with earlier versions of PI ProcessBook, if you use BatchView and want to create new displays with relativity, if you use the DataSheet Control, or if you use IT Overview, then you should use the MRD add-in to select a module of interest for the display or to create or edit new displays.
Note that there are some limitations to creating new MRD displays. If a Module database has been migrated to an AF database, then a new display no longer lists this Module database when selecting Available Modules for a new MRD display. There are no limitations for updating existing MRD displays.

Use ERD if…

If you do not have an existing Module Database or have already migrated it to AF, and have started to use and configure AF, you should (1) remove the MRD add-in using the Add/Remove Programs entry and (2) use the ERD add-in to create, edit and use displays that are element relative (different data appears when a different element is selected from the Elements of Interest list).
Note that the MRD add-in is installed with a separate MSI, so automated software deployment systems can be used to automatically remove it. In addition, the setup.ini file shipped with PI ProcessBook 3.2 specifies that the MRD.msi is included in the installation. If you use automated software deployment systems, you can customize the setup.ini or silent.ini to remove this item from the installation.


Migrating an existing Module Database to AF can be accomplished once the PI Server 3.5 EAM release is available (projected for 2010). This release schedule has an impact on how to decide whether to use the MRD add-in or the ERD add-in. When the Module Database to AF migration tools are released, there will be additional information about how best to implement them.
If you have both existing MRD displays and an AF database you want to use, you should use the MRD add-in to navigate existing MRD displays and you should use the ERD add-in to create new displays. Once you have migrated your Module database using the Asset subsystem in PI Server 3.5, you should (1) remove the MRD add-in using the Add/Remove Programs entry and (2) use the ERD add-in to upgrade the existing MRD displays to use their AF equivalents.


After you migrate a Module Database to AF, that Module Database tree is no longer visible in the user interface for selecting modules in the MRD add-in for new displays as described above. Existing MRD displays continue to work, but there is no user interface to build new ones. For most customers, this is not an issue, since you can remove the MRD add-in, automatically upgrade the existing displays to use ERD and continue building new displays with that way.

Limitations on migrating your Module Database to an AF database

If you use BatchView or the Datasheet Control or the IT Overview add-in for PI ProcessBook, there is an existing dependency on the MRD add-in for creating symbols with relativity that will be addressed in a later PI ProcessBook release. For those customers, migrating the module database to AF will have limitations until the updated BatchView, IT Overview and Datasheet Control functionality is in place. Until then, use the earlier version of PI ProcessBook (3.1) to create new MRD displays once the Module database is migrated. If the module database isn’t migrated, you can continue using the MRD as before.

Migration Validation

You may want to use the existence of the MRD and ERD add-ins to check the status of and verify your Module Database to AF migration (once that is available in PI Server 3.5). This is best accomplished by comparing two displays: one created with the MRD and one created with the ERD, looking at the same assets.

Important Note

Combining ERD and MDB references on the same display is NOT supported, even though there is no mechanism to prevent this. If a display contains both ERD and MRD references and the MRD add-in is removed from the computer, the ERD add-in attempts to convert the MRD references, with potential consequences for the existing ERD references. We strongly advise customers not to combine references on a single display. The PI ProcessBook 3.2 Release Notes explain that this is an unsupported feature.

VBA Implications

Many users have VBA code in displays behind buttons that change the context. An example of this would be code like:


Sub SwitchContexts()
     Dim mrd as ContextHandler


     Set mrd = ThisDisplay.Application.ContextHandlers.Item("Alias")


     mrd.CurrentContext(ThisDisplay) = "\\trenton\MyAssets"
End Sub


PI ProcessBook 3.2 (specifically, the ERD add-in) interprets calls to set the current context for MRD displays and handles them to make at least the simple displays work by providing an AF-equivalent path. This handling is provided when the MRD add-in is no longer present on the system.
More complex VBA scripts that do more than set the current context need to be rewritten to use the new AF-focused ERD add-in.

Filter Blog

By date: By tag: