The dateFormat setting is “MM/DD/YYYY hh:mm a”. It works for Ack Time and Active Time but it does not work from Clear time.
If the value of the props.filters.active.conditions.source is fixed, the table shows only alarms matching that source immediately upon viewing. If the value is based on a binding, then the table will briefly show ALL alarms for a second or so when you first navigate to the view and on some refreshes. This is a problem for us since we house data for multiple customers and we cannot have any customer seeing data or alarms from the other customers.
I tried setting props.filters.active.conditions.source to a value which would match no alarms as the default before binding, in the hopes that maybe it would show nothing for that second before refreshing to show the proper data, but it still shows all alarms before the refresh.
Also, I’ve noticed there is no similar source filter under props.filters.shelved. Does the shelved display respect the props.filters.active.conditions.source? (I’ll probably test this myself later today, but I figured I could ask while I was here.)
There’s a little bit of a delay before bindings can be processed on startup, so what you’re seeing is what I would expect. Is there some way you can statically set the source filter? If there aren’t too many customers, you might be able to provide them with dedicated views showing only their alarms?
Perhaps other might have some creative solutions to this problem.
If there’s no better way, you could cover the table with a loading mask until binding is processed.
Definitely too many customers to create dedicated views for each.
It would be enough if I could set the property value used in that moment before the binding gets evaluated. Alternatively, I wonder if perhaps the table component could default to not trying to render itself until it had finished at least one evaluation of all bindings on it’s properties. It feels like the component is going through the effort to query/filter/generate the table when it’s just going to have to do it again a moment later with new properties. I understand it’s probably not that simple in actuality, but it feels that way.
@witman can you PM me a pointer to an example of how to implement a loading mask in Ignition?
We had the same problem.
I also tried to do this with “loading mask” but didn’t get it to work the way I wanted it to.
How I solved this:
I set the diplaypath filters binding to property and make a change script.
At the start of the script i set:
self.props.filters.active.conditions.displayPath = ‘NoAlarms’
This way the filter is set to “NoAlarms” for the duration of the script and at the end i just return the actual value.
I installed the version 8.0.2 but I’m not able to find the new alarm table control for perspective
How can I get it ?
Would you mind providing more details on your solution? I’m trying to make this work but I’m not sure how you did it.
Hi, is there a way to define Min Priority like the Vision component yet or is there any way to filter out certain priorities?
Well here is a short part of the code:
I have set a Property type binding on the “AlarmStatusTable.props.filters.active.conditions.displayPath”.
After this binding i set a Script-transform. On this transform i set:
self.props.filters.active.conditions.displayPath = 'NoAlarms'
Then I run my code that will fetch my users allowed displaypaths.
These paths i set in a variable called ‘spacePaths’.
At the end of the script is just set this:
No, not currently. But we are currently redesigning the filter UI to allow for filtering by priority as well, in addition to state. I’m thinking that should work for you.
I’m sorry but I completely forgot about the persistent flag on the binding. That should solve your problem.
Persistent : States that the value set on the property should be saved, and loaded when the view first opens. This effectively allows you to determine the initial value on a property when the view opens. While the property is enabled by default, bindings on a property will always execute after the view opens, potentially overriding the persistent value.
This has been fixed in the next nightly.
Exactly what I needed! I’m not sure I would’ve found that on my own.
I’m looking to setup a three column prioritized sort order on the columns like we could do in Vision. (See screenshot) I want to sort by State first, then Priority, then timestamp. When I enable sorting in designer for each of those columns, there is not a way to setup the sort priority. Is there a way to do this that I am missing?
We have a ticket to add that feature, along with quite a few others including more filtering functionality. Currently it multi-sorts in the order it is declared in the columns configuration. We will get around to updating the table (phase 2) very soon with these new features. You can watch for an update here.
I’m looking to replicate the “Marquee Mode” that existed in the Vision alarm table. I don’t see that option in Perspective, is this also one of the features coming for phase 2? Is there any workaround to get the table to scroll without that specific option?
Perspective eating up the RAM and CPU. Is anyone else getting this issue as well?
Hello this might be a silly question but how do i link this alarm status table to database any help would be appreciated