Tag Up-Time Counter

Ignition
,
1

Hi there! Right now I’m attempting to create a status page for all of our RM systems that we have active (about 14). In addition to having the simple Up/Down indication- which i have- I was asked to have a counter next to each system indicating how much time that system had spent up or down. I’ve run through several different ways to attempt this, but I’m a bit stuck.

All I would need is a simple counter for hours, minutes, seconds…but I’m a bit of a novice when it comes to scripting.

Help!

2

If you want to know how long since the last change you can do that through an expression tag using:

dateDiff({[.]tag.LastChange},now(),"seconds")

That would find the time since the tag changed last. If your pointed at a running bit it would give you a count for how long its been running or how long it has been down. You can also put it in an if statement if you want to limit it to only when it is running or stopped.

To turn it into a time format you can do something like.

try(toStr(dateFormat( 
	setTime(dateDiff({[.]tag.LastChange},now(),"seconds"),
		round(floor({[.]DownTime}/3600)),
		round(floor(({[.]DownTime}/60)%60)),
		round(({[.]DownTime}%60))),
			"HH:mm:ss"),0),'00:00:00')

I put it in a try so it would return 00:00:00 if your time is 0 seconds.

3

IMO, I would use a transaction group set to whatever time resolution you want. Usually, 30 seconds is more than good enough. You can then use this data to tally up/down time as well as have have context on when up and down time happens. Easily chartable for management types.

I also have our transaction groups set to purge at 14 days, since no-one at my facility ever seems to look back any further.

4

I assumed he wanted simple indication. If he wants a running tally the transaction group would work better for logging the data. I’m using a similar tag to what I mentioned just for a downtime counter on some equipment tied to an alarm if it reaches a set value. For downtime reporting I do the same using transaction groups.

5

Perhaps so, but the next logical step is historical data, even if they don’t know they want it. May as well design for it from the start. :grin: