Tag History - system.tag.queryTagHistory DurationOn

Ignition
,
1

Hello,

I am trying to track machine uptime via tag history. I have seen quite a few posts about this type of tracking, but none seem to reference this tag history. Based on what I have read, this setup should allow me to use code similar to what is pasted below. The end goal is to build a custom data set for a report over a 24-hour period with a returnSize=24 . Like I said, this seems to be a common topic, but I have yet to see one that deals with my issues with the DurationOn aggregation.

image.png792×383 22.4 KB 

starttime = system.date.setTime(startdate, 10,40, 0)
endtime = system.date.setTime(enddate, 11, 00, 0)
qdataset = system.tag.queryTagHistory(paths=['Tag'], startDate=starttime, endDate=endtime, returnSize=1, noInterpolation = True, aggregationMode="DurationOn", returnFormat='Wide')
uptime = qdataset.getValueAt(0, 1)

# Using the range function, we can come up with a range of values that represents the number of columns.
for row in range(qdataset.getRowCount()):
    for col in range(qdataset.getColumnCount()):
    # Will print out every item in our dataset, starting on the first row and moving left to right.
        print qdataset.getValueAt(row, col)

I can see the data properly populating in my table, and aside from the first 10 records which I assume are some sort of initialization, I am seeing records for each “On” and “Off” of the boolean bit I am toggling. I have it programmed for 50 seconds on and 10 seconds off so that I have a predictable result. If I use the “CountOn” aggregation for a duration of 20 minutes I get a result of 19, which is believable if the PLC 20 minutes is not perfectly sync’d with Ignition’s 20 minute window, but when I use “DurationOn” I get a result of 18… If I change the returnSize=10, I get 18, and then a bunch of zeros instead of the same duration for each period. I am using the print to see my results in the debug window.

Is there something that I am missing. Sorry for the long post, but I wanted to get as much information up front as possible. Like I said, it is only the DurationOn function that is causing me confusion.

Thanks

2

I’ve got a very similar situation occurring with the durationOn aggregate type. It seems to only sometimes correctly count the duration the tag was on, and sometimes gives a number that is definitely not correct.

Have you found any workaround or resolution yet?

3

Transaction groups ended up working. I think this is more of a work around than what should be possible with a historical tag, but since the functions don’t work as described I had to seek other solutions. I am currently using a transaction group to store data every second in with items configured as hour meters in a temporary table. There is another transaction that stores the data hourly and resets the hour meters.

In the picture below, each of these pieces of data is a column in a holding table with only 1 row… Depending on the amount of lines and amount of data, you might prefer to use more than one table/transaction for keeping your hour meters.

image.png1868×731 57.8 KB

The picture below shows the data collection, triggered every hour on the hour. This stores the data queried from the holding table and stored into a table in my historian database. The last action is to set the hour meter values in the temporary storage table to 0 to begin collecting for the next hour’s data.

image.png1866×732 71.3 KB

This is not what I had originally intended, but I was unable to wait any longer for assistance. This does work, with consistent time stamps every hour. The historical table will be used for my reports and manager interfaces.

Hope this helps.