Jordan_Sellers
My feedback
-
143 votesJordan_Sellers
supported this idea
·
-
154 votesJordan_Sellers
supported this idea
·
An error occurred while saving the comment -
209 votesJordan_Sellers
supported this idea
·
-
30 votes
An error occurred while saving the comment Jordan_Sellers
commented
The ability to customize the visibility of the attribute name and path on a trend (both minimized and maximized) is highly desired by users.
It is pretty frustrating when you have something like "Tank 1|Level" and "Tank 2|Level" and when someone maximizes one of them, it just shows "Level". When navigating the display in a group setting, you'll hear a lot of "Which one are we looking at, again?" Currently it will only display the parent element if you have multiple attributes on the trend from different parent elements. This is not an issue in Processbook since there are never any ambiguous labels.
Jordan_Sellers
supported this idea
·
-
351 votesJordan_Sellers
supported this idea
·
-
110 votesJordan_Sellers
supported this idea
·
-
13 votes
This idea has been answered.
Jordan_Sellers
supported this idea
·
An error occurred while saving the comment Jordan_Sellers
commented
In response to Stephen Kwan, "Are you referring to PI System Explorer ..."
I was referring to Vision. It would be great to be able to return descendant elements events (not just descendant child event frames) on the search criteria for Event Frame Tables in Vision. Asset Comparison Tables have this option, but Event Frame Tables do not.An error occurred while saving the comment Jordan_Sellers
commented
This would be extremely beneficial to us to be able to display plant wide events by Area when passing asset relationships via navigation links. Currently you have to create a separate (pre-filtered) display for each area.
-
93 votesJordan_Sellers
supported this idea
·
-
152 votesJordan_Sellers
supported this idea
·
This would be extremely useful to us.
Client has a table of product material dependent constants. The table is structured with material IDs on columns and constant_types on each row. There is a Material ID PI Tag that updates with materials that align with the column headers. The material specific constants are needed in various analyses. There are couple hundred materials and even more constant_types. All constants have an element from a constant_template.
Currently, the only way we know how to do this is to create a couple hundred table lookup attributes for each material, then create a lookup analysis with a couple hundred lines for each attribute input and then a massive piece of logic to emulate a select case using individual compare functions on each attribute vs the Material PI Tag.