Configuration of Alarm Journal

Ignition
1

Hello,
I have a couple of customers on my Ignition 8.1 system. I have a separate database for each customer, so for alarms, I setup separate alarm journals for each customer. I used the Source field to only put alarms for that customer in the alarm journal tables for that customer. However, I think I am doing it incorrectly. Note that in each database, ignition has created the tables for the alarm journal so I know the connection is good.

Under Data Filter-> Filter by Alarm Source, I use the source identifier for each customer to only get those alarms. NOTE that the documentation does not state the format of the Alarm Source so this is the format I used, which is obviously incorrect.

I used: prov:default:/tag:Customer/'customerName'/:/alm:

I also tried tag:Customer/'customerName'/:/alm:

Where 'customerName' is the branch for that customer with their name.

Can you help me with what I am doing wrong?

Thanks,

Steve

2

If your 'customerName' is unique enough between customers, I have used the following filter without issues:

*customerName*

2 Likes
3

But I'm seeing the same issue. essentially on source if you use prov:whatever_name* it returns no results. Something must have changed in the way we're supposed to make this reference or it's a bug?

4

I just helped someone the other day with this ~ version 8.1.45, and it was working. Are you sure everything is spelled correctly?

5

Interesting. Yes, I'm like 99% sure I have everything spelled correctly.
In my case, I'm using a front-end gateway that isn't hosting the tags I'm trying to filter, the target tags are on two different gateways.

so what's interesting to me is that I can get the source filter to work with a string like

"*tags_in_provider_1*" - where that's the name of the folder on the remote gateway that contains all my tags.
and I can actually get the behaviour I want with:
"*tags_in_provider_1*,*tags_in_provider_2*"

But what doesn't work is
"prov:tag_provider_1*"

6

This does not work on "local/standard" gateways either.

7

Interesting. In the thread with the other user we were putting the wildcard after the tag, there may be some edge case problems related to a single wildcard when it is placed around the the start of a new : split - that seems to be what you two are testing.

It seems odd that wouldn't work for you if the prov:tag_provider:/tag:tag_name* did work for us on a recent version. I would want to do some more tests with various edge cases like a tag provider name that ends in a non-numeric character, including parts of the :/tag: , etc. to isolate when it doesn't work as expected.

Perhaps adding a * to both sides of the string does workaround the problem.

8

In my case, I have several filters on the display path:
"*prov:default:/tag:line1*, *prov:default:/tag:line2*,*prov:default:/tag:line3*"

I just added the splats before the prov and am currently waiting for some alarms to pop up.

Previous to this, all I had was splats after the line number and got no alarms over the last day, which is unheard of! :smile:

9

If you are saying this is a regression (behavior that used to work and no longer does), please let me know what versions before/after.

I have seen weird edge case behavior before related to * not working on one side of path filters in Vision, but it would always work on both sides.

10

I don't have any background on this, as this is the first time attempting to use filters on the Alarm Journal.

I just checked the alarm data tables and can confirm that no alarm events have been recorded using the filter "*prov:default:/tag:line1*, *prov:default:/tag:line2*,*prov:default:/tag:line3*"

So, now I will drop it down to just the provider with splats, as @matt.eaton did and see what happens.

Edit: I am assuming that you must include the double quotes. Should I be?

11

No quotes.

1 Like
12

For myself, I just started developing the requirement for combined alarms from two different providers, not sure if it worked before and doesn't now.

13

If you think you have encountered a bug that prevents behavior that used to work then please open a support ticket with the replication steps for that bug. I am not sure what the problem is you are describing.

14

Alright, here's the problem restated:
If I use the alarm status component in perspective and am configuring filters-active-conditions-source. Assuming I want to get just alarms from a tag provider called test1.

prov:test1*

does not work.

*test1*

does work.

prov:test1:/tag:*

interestingly does work.

So I think maybe what's missing is that the * wildcard doesn't play well if it's in the prov: part of the source filter?

15

This thread was about the Alarm Journal filters on the Gateway-level so I was only testing there. I agree it runs into issue when the wild card is around that second colon, but it seems like it can be worked around and still function correctly.

16

Looking for to separate between tag providers in diferrent databases, each one on its own journal profile, to storage all entire provider filtering in the gateway, also works with this, prov:PLC:/tag:*, configure in the 'Filter by Alarm Source' in Data filters section, where 'PLC' is the tag provider.

1 Like