When running a web tour in PIML Web 2017, there needs to be an ability to lock keyboard input for values that are expecting a scanned input from a Barcode, QR code and RFID tag.  We realize that the scanned code is coming from the keyboard attached or on screen; so another way is to block any keyboard entry that has a string less than or equaled to three characters.  Thereby, forcing the acceptable keyboard string to be greater than three characters.

This allows the manager of the web tour to determine if a tag was visited legitimately or not.  With that feature we can couple it with the limit function and require comments when the tag was left blank or doesn’t equal the expected value.

Right now there is a PerfMon counter for Buffer Health.  It's either 0, 1, or 2.  That's not helpful because it doesn't tell you what is wrong.  There are other PerfMon counters for Remaining Queue capacity and Points with Post Errors.  The Buffer Manager allows you to change the threshold on when Remaining Queue capacity flags the Buffer Health as Warning and Error.  We set that tuning parameter to a crazy high value because we just have an Event Frame based on the Remaining Queue Capacity PerfMon counter tell us when the capacity is low.  Otherwise we have redundant Even Frames.  We would like a similar tuning parameter for Points with Post Errors so we can similarly disable it.

New tour runs with filtered URL
User wants to incorporate a direct link to each tour in their control round application. Hence, we need the links for each tour to open the tour immediately. It throws an error currently. It has been identified as a new bug in PI Manual Logger Web 2017 with the “list” parameter. When using the /tourruns?id=new&name=<tourName> method to directly open a new tour run, the tour filter is not applied correctly before attempting to open the new tour run. Because of this, the tour run will not be created successfully if a different set of tours was loaded by the previous filter that was applied.

Currently, the workaround is to instead link the user to the homepage with only the selected tour loaded. Unfortunately, this method adds an additional click, as the user will need to click “New Tour Run” to begin the run.

From a pharma/biotech user perspective, I am finding that the PI Auditviewer application is difficult to use and conduct an investigation with over an extended time period.  I believe the application needs an overhaul to allow for, at minimum, the following enhancements:
Mass import and scanning of audit source files.  A user should not have to individually browse to, add, and scan each individual log file.  Current functionality does not easily support an investigation that must take place over a broad time period.  Better yet, the application should automatically scan the log file directory, and all audit log files should be searchable by the user after the application has loaded, without having to manually add anything.In addition to the existing Start/End time search criteria that exists today, the search feature should allow additional text-based filtering options.  A user should not have to manually inspect multiple pages of returns, and re-set the filtering on a page-by-page basis as it works today. If the application is not enhanced to automatically scan all available log files when the application is open, there should be a way for the user to save their view/profile.  When the application crashes (for example when initiating a Print Preview with a large number of records returned in a search), you lose all of the added/scanned log files and you have to completely start over.  Also, if a user closes the application to log off the PI server, currently all work is lost as well. Organization of the data is not efficient to review, with each row returned containing at minimum one additional row of nested data, and in some cases multiple rows of nested data.  Each record should be in a single row without anything nested if possible.Printing capabilities require significant enhancement.  Printed output currently contains a summary page with information about the search, followed by a display of the audit records that is challenging to read.  For example, a report from my system showing add/edit of 23 PI tags results in a summary page plus 48 pages worth of audit information.  When a row/record spreads across multiple pages due to the page not being wide enough, there ends up being some blank pages and some pages with very little information contained in the printout.  Additionally, “Good Documentation Practices” type of requirements, including header/footer information indicating a title, the date/time of the print, and pagination in Page x of y format should be included.  This header/footer information is required to link each page together as a complete package without additional user effort.  If not automatically included on each printout, there should be a user option to add this information in custom header/footer fields. Thanks for your consideration in this matter.