# Item Counting and Item Rates Question **URL:** \ **Category:** Ignition\ **Created:** [May 21, 2012, 9:04pm UTC](https://forum.inductiveautomation.com/t/item-counting-and-item-rates-question/4506 "2012-05-21T21:04:36Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![DennisWomack](https://avatars.discourse-cdn.com/v4/letter/d/51bf81/32.png) [@DennisWomack](https://forum.inductiveautomation.com/u/DennisWomack)\ **Post date:** [May 21, 2012, 9:04pm UTC](https://forum.inductiveautomation.com/t/item-counting-and-item-rates-question/4506/1 "2012-05-21T21:04:36Z")
This question edges into overall system philosophy… Which is better: 1. To have a continuously increasing counter in a PLC, say a 32 bit UINT, or a 64 bit UINT and… 2. Poll once an hour and take the difference for the hourly rate. or 1. Reset the counter in the PLC once an hour, based on the PLC’s clock, and … 2. Poll every couple of seconds, looking for the change to zero. The problem is how to get the hourly rate recoded in the history db without recording every case, but without missing any in the totals. I think the first has the most merit, because you will always have an acurate count over any interval. Any comments or hints? Thanks, Dennis ---
**Author:** ![Travis.Cox](https://avatars.discourse-cdn.com/v4/letter/t/b9bd4f/32.png) [@Travis.Cox](https://forum.inductiveautomation.com/u/Travis.Cox)\ **Post date:** [May 21, 2012, 11:08pm UTC](https://forum.inductiveautomation.com/t/item-counting-and-item-rates-question/4506/2 "2012-05-21T23:08:49Z")
The first is better cause you will probably get a more accurate reading. It is more closely modeled to our OEE / Downtime rollover counter. However, I would take a step further and have two values in the PLC: one for the last hour and one the accumulates up. Every hour you can move the accumulation to the last hour tag. We can read in the value on change into the database. That way you are guaranteed the value is accurate. ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [May 22, 2012, 10:19am UTC](https://forum.inductiveautomation.com/t/item-counting-and-item-rates-question/4506/3 "2012-05-22T10:19:35Z")
We use two PLC counters, one for an actual count and one for pace. I log those values every so often (usually our assembly targets are at about the 15-25 second range, so I tend to log every ten seconds) to a table. I can then use this table to extract: [ul]-Calculate efficiency (ratio of actual parts to the pace) for the shift or over a time period (in this instance 60 minutes) and show a trend. -Hourly counts[/ul] Hourly counts I get by using this query: `SELECT concat(if(hour(t_stamp)>12,hour(t_stamp)-12,if(hour(t_stamp)=0,12,hour(t_stamp))),':00',if(hour(t_stamp)>11,' PM',' AM'))as Begin, concat(if(hour(t_stamp)+1>12,hour(t_stamp)+1-12,if(hour(t_stamp)+1=0,12,hour(t_stamp)+1)),':00',if(hour(t_stamp)+1=24,' AM',if(hour(t_stamp)+1>11,' PM',' AM'))) as End, count(distinct(actual))-1 as Parts FROM 3702_fipg2_prod_trend where t_stamp>='{Root Container.Hourly Count.Calendar.Shift1}' and t_stamp<'{Root Container.Hourly Count.Calendar.ShiftEnd}' and actual<>0 group by hour(t_stamp) order by t_stamp ` I also have a really long script to do the same thing for lines that have odd running hours or are down for lunchtimes, etc. EDIT: Oh! Just as a side note, the numeric displays are showing zeroes because the line wasn’t running when I took the cap. 🙂 ![](https://us1.discourse-cdn.com/inductiveautomation/original/2X/c/cbd083bd054188dde35f75a0b5eb81dd030ade37.png) ![](https://us1.discourse-cdn.com/inductiveautomation/original/2X/b/bb2a790e8c28b51dee6bb9cbfa724f29178b87c2.png) ---
**Author:** ![DennisWomack](https://avatars.discourse-cdn.com/v4/letter/d/51bf81/32.png) [@DennisWomack](https://forum.inductiveautomation.com/u/DennisWomack)\ **Post date:** [May 22, 2012, 12:59pm UTC](https://forum.inductiveautomation.com/t/item-counting-and-item-rates-question/4506/4 "2012-05-22T12:59:51Z")
Thanks for you replies. Jordan, it looks like your Efficiency\_60 is a rolling 60 minutes window, hence the 60 minute delay in the data, and then fine grained data. Dennis ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [May 22, 2012, 1:19pm UTC](https://forum.inductiveautomation.com/t/item-counting-and-item-rates-question/4506/5 "2012-05-22T13:19:45Z")
Yep. That bit of fun only happens at the beginning of the shift, when the counters are reset. Luckily, it would have otherwise just followed the normal efficiency trend, so it’s not too much of an issue for us here. Now that I think of it though, the 60-min calculation is done within the transaction group. I’ll have to see about calculating it through the query. Someday… ![:mrgreen:](https://us1.discourse-cdn.com/inductiveautomation/original/1X/d23659b203d2d24d394be983a52adb2fa6fe23d4.gif "Mr. Green")