Somehow that project sounds familiar... Hey Ken!
I don't know any good way to look back in the archive for something like that. I think I've used ACE in the past but even then you have to manual select a time range and look through it.
It is a bit difficult to look back in the archive for the last good value kind of thing, since PE do not support loops. I would try something like this:
IF (badval('labtag')) THEN TAGVAL('labtag', FINDGE('labtag', '*', '*-1h', 0)) ELSE 'labtag'
What this statement does is
- test if the snapshot/current value of the tag is a good value
- if snapshot is a not good value, then use FINDGE to find the timestamp of the last value that is > 0 (which helps filter out bad values), and then use TAGVAL to find the value with that timestamp.
- if snapshot is a good value, then just return the value
Hope this would help =)
That's a good question... I'm afraid the ambiguous nature of the expression "good value" makes it a little difficult for PE: one would probably need a loop and a few IF statements but as Han Yong pointed out, PE does not support loops.
That said, how about you try to find and fix the root cause of the problem? (i.e. what's causing the "I/O Timeout" errors). You mentioned this is happening with the PI Ping Interface... due to the nature of the ICMP protocol (i.e. no acknowledgement), it is not uncommon to have a relatively high number of "lost packets" with PING commands. For that reason, a few years ago we implemented the Location2 and Location3 attributes for PI Ping points: they determine how many PING commands that the inteface sends to the remote machine and the minimum number of valid PING responses required to for the Interface to compute and write an actual value to PI. I found that Location2=4 and Location3=1 would solve most of my (well, my customers'!) PING issues.
I suggest you read more about this in the PI Ping Interface Manual, and contact Technical Support if you need further assistance with this.
Due to the nature of the devices being monitored (underground mining trucks) and the location in which they are being monitored (underground mine, rock walls), it is unavoidable that I/O Timeouts will occur. I do want to capture the I/O Timeouts so that I know when a truck is not near a wireless access point, but for the purpose of my ProcessBook display, I also require the last good value to be shown so that users know when the last time was the the truck passed by an Access Point.
I ended up creating event based PE tags that check whether or not the source value is good. If so I store the source value, otherwise I ignore the value coming in.
I will have to reseach the 2 methods mentioned above since they both seems like great ideas. If they do work, I will be able to remove the PE tags that I have created and free up my tag count slightly.
Thanks for the input!
Because of compression, at least one of the last two tag values must be 'good'. I bet you never have two successive Timeout values in the archive. So something like this should work:
IF (badval('labtag')) THEN PrevVal('labtag', PrevEvent('labtag', '*' ) )) ELSE 'labtag'
Or maybe you can substract 1 second from the time stamp passed to PrevVal (as in PrevEvent('labtag', '*')-1s )
(It is like saying get me the current value (if good) or the value prior to the bad value that is stored before the timestamp returned by PrevEvent )
Just a guess though. But if it works, it does not assume that there is a good value in the previous hour as assumed in FINDGE.
Whatever the current value of a tag will be writting out to the archive if the Maximum Exception Time (exmax) expires, so, if it is Time out, you may very well have it stored a bunch of times. There are other scenarios where and when this could happend, but I think this is the most common one.
You could pass a greater time range to 'findge' and that should work.
You could try:
TAGVAL('CDT158', FINDGE('CDT158', '*', '*-1d', 0))
note that if the value can be a negative then you should use a negative value there.