Tag Value Temporal Filtering

Ignition
,
1

I'm somewhat new to Ignition, but I can't seem to be able to find an answer to this anywhere.

I have a UDT with a bunch of tags with history enabled. I am using the power chart to show their live history and looks like below.

image
image1026×602 82.4 KB

The problem is the Fault Active bit, which, depending on the circumstance, will continuously be turned off and then immediately turned back on by the PLC. This is something I can't change in the PLC, it's just how it needs to work. I was hoping I could figure out a way in ignition to filter this out, so that if this tag goes false then true in a short time, it just stays true. I was trying something with a different memory tag "FaultActiveFiltered" and a value changed script on the raw tag, but this doesn't work since it only runs when the tag changes and thus can't set the value of the filtered tag after the raw tag has been false for a certain time. Since I have the tag history enabled for the raw tag, I figured there might be a way to use system.tag.queryTagHistory and select the last 2 seconds or so and see if any value is true, but I can't seem to figure out where the script would be if I need it to run for every instance of the UDT.

Or maybe there is some other built in function I can't seem to find?

If there is a way to get tag history in an expression, then maybe I can make an expression tag instead of memory tag.

2

A lot of the times I have created a control tag such as [default]/currentTime and then made a memory tag that every update of [default]/currentTime it will go out and do some sort of compare.

values = system.tag.readBlocking(['someOPCTag','someMemoryTag'])
if system.date.millisBetween(values[0].timestamp, values[1].timestamp) > 2000:
      system.tag.writeBlocking(['someMemoryTag'],[values[0].value])

you would then have the alarm setup on the memory tag.

This approach may have a decent amount of overhead if you do not handle when to read and to write to the memory tag, so you could setup a tag change script on the opc tag to go out and enable the currentTime tag to actually run and change, but that all depends on if you are worried about that layer of complexity.

3

Try this:
Add a FaultFiltered boolean expression tag to your UDT.

Fault filtered
Fault filtered904×326 29.9 KB

Set the expression to,

if(
	!{[.]FaultActive} &&
	now(1000) - timestampOf({[.]FaultActive}) > 3000,
	false,
	true
)

This will check every 1000 ms and see if the timestamp of the FaultActive tag has been low for more than 3000 ms. (Adjust to suit.)

Now log FaultFiltered instead of FaultActive and use that in your chart.

4

This is clever, and I should have thought of this! Simple and effective.

5

I tought that this was the goal for "Min Time Between Samples" in the historian setup
image

6

History Config ≠ Alarm Config

No relation whatsoever.

Whoops! Thinking of a different topic.

7

saw your comment and I was wondering, where did he ask about an alarm

8

I always took that as a means of limiting database clutter. I don't think it will work though ...

Min historian period

I suspect that a series of half-second pulses would generate historian results as shown above.

9

so if the pulse change 3 times in a second, my understanding is that you will see it as a single pulse in history.

10

I expect that you would see the first transition and then it would record the change after the min time had elapsed.

Tag history 2

11

Blockquote
Try this:
Add a FaultFiltered boolean expression tag to your UDT.
...

I will try this out and see how it goes. How exactly is this checking that it is low for the 3 seconds? It seems like it is checking the current value and timestamp of the last value in FaultActive rather than if it is low. I guess it could be assumed that it should not repeat stored values, like (False, True, False, False). I currently have it set to a max interval of 1 hour, but I suppose this isn't all that necessary.

12

While the min interval might help reduce the amount of switching, my problem is that it goes on for hours on end, continuously switching about every few seconds.

13

The User Requirement Specification is:

if(
	!{[.]FaultActive} &&
	now(1000) - timestampOf({[.]FaultActive}) > 3000,
	false,
	true
)
  • OPC tag timestamp values only change when the value changes. For a boolean this is 1 → 0 or for 0 → 1. (It may also occur on gateway restart or OPC server restart but I reckon you should be able to live with that.)
  • The !{[.]FaultActive} part of the expression will be true if FaultActive is false. (Note the '!' prefix.)
  • now(1000) will trigger the expression re-evaluation and give the current timestamp.
  • timestampOf({[.]FaultActive}) will return the timestamp of the last status change.
  • The difference between the previous two is the time since the last change.
  • If FaultActive is low AND the last change was more than 3000 ms ago THEN turn off the FaultFiltered tag - otherwise leave it true.

The result is as follows:

Fault filtered timing diagram
Fault filtered timing diagram1121×547 29.5 KB

Try it with two test memory tags, FaultActive and FaultFiltered. Toggle the FaultActive tag in Tag Browser and watch the result in FaultActive.

14

Thanks, That seems to do the trick, at least with memory tags. I can't exactly tell my customer to shut down their site just to test this, which is when the problem was occurring before, but if it works the same as with memory tags, it should be exactly what I want.