Allen Bradley counter HELP !

I just read up on the I Historian package. It appears that it's optimized for collecting lots of data and writing that data to a database.

The documentation did say that the data can be timestamped, so I think that my suggestion about a rollover counter could work. I Historian samples the cumulative value once per hour, timestamps each sample and writes it to the database. Once the data is stored, it seems to me the task becomes one of designing a query to present the information in whatever format you need.

Steve,

I-Historian does indeed do that. It controls its own timestamp. This goes back to what I mentioned about doing the work in Excel. I-Historian comes with an Excel add-in, allowing uses to access the data, per tag searching on time and date stamp. I could write some basic code within Excel to look at the cumulative value of the data and take the 10am reading away from the 9am reading and get the hourly usage, with just a simple check to determine if the counter had gone back to zero.

I was trying to do the work in the PLC to make the spreadsheet as easy as possible for its users and to allow the raw data in the database to make more sense to people.

The Excel solution would be perfectly acceptable, but it does still seem like a copout, not that I want to make work for myself, but I felt that the problem would be best addressed prior to the database. It would provide a system that was a little tidier.

The other disadvantage is that if the user wants to search data over a month, the PLC counter may have reset a number of times. Therefore the spreadsheet would have to examine every data point, every hour between the starting and ending date to check for resets. If this was run over the year to get the total usage per year, the working space in the spreadsheet would be 8,640 rows long, (24 hours, 365 days) Not really a nice setup.

Actually, of all of the methods considered in this thread, this may be the cleanest, and the least likely to lose data.

Consider what would happen if the I Historian could send a reset pulse back to the SLC. Any KWh pulses accumulated between the initial request for data and the receipt of the reset pulse would be lost.

If you could have used the S:2/5 bit, there could still be some discrepancy between the value that got transmitted to I Historian and the accumulated value when the bit went from on to off. This would almost certainly be less discrepancy than in the first scenario. The other problem with using that bit rear its ugly head if you ever needed I Historian to fetch two different pieces of data from the same SLC. There would be no way of correlating a transition of the bit with a specific data request.

I'm sure we could have come up with any number of acceptable strategies if I Historian had the ability to write a cinfirmation signal back to the SLC, but given the constraints that you have to live with, this may be as good as it gets.

It has been an interesting exercise, though. Thank you for posting it.

Could be Scheduled task in Windows, when application stars,
executes and Unload itself.
Sets feedback Ones per Our by Poke, Basic-code:

'Read value from N7:0
txtRead_val.LinkTopic = "RSLinx|Counter" ‘Define DDE appl.&topic
txtRead_val.LinkItem = "N7:0" ‘Define DDE item
txtRead_val.LinkMode = 2 ‘Open DDE link (manual)
txtRead_val.LinkRequest ‘Req. data from RSLinx
txtRead_val.LinkMode = 0 ‘Close DDE link
open “C:/LOGFILE.LOG” For Append As #1
Write #1, txtRead_val.text
Cloce #1

'Writes feedback to N7:10 for Counter, PLC resets it when
'set: N7:0 = N7:0 – N7:10
txtWrite_val.text = txtRead_val.text
txtWrite_val.LinkTopic = "RSLinx|Counter" ‘Define DDE appl.&topic
txtWrite_val.LinkItem = "N7:10" ‘Define DDE item
txtWrite_val.LinkMode = 2 ‘Open DDE link (manual)
txtWrite_val.LinkPoke ‘Poke Data to RSLinx RSLinxtxtWrite_val.LinkMode = 0 ‘Close DDE link

Could be Scheduled task in Windows, when application stars,
executes and Unload itself.
Sets feedback Ones per Our by Poke, Basic-code:

'Read value from N7:0
txtRead_val.LinkTopic = "RSLinx|Counter" ‘Define DDE appl.&topic
txtRead_val.LinkItem = "N7:0" ‘Define DDE item
txtRead_val.LinkMode = 2 ‘Open DDE link (manual)
txtRead_val.LinkRequest ‘Req. data from RSLinx
txtRead_val.LinkMode = 0 ‘Close DDE link
open “C:/LOGFILE.LOG” For Append As #1
Write #1, Now; txtRead_val.text ' Time Stamp and Counter value
Cloce #1

'Writes feedback to N7:10 for Counter, PLC resets it when
'set: N7:0 = N7:0 – N7:10
txtWrite_val.text = txtRead_val.text
txtWrite_val.LinkTopic = "RSLinx|Counter" ‘Define DDE appl.&topic
txtWrite_val.LinkItem = "N7:10" ‘Define DDE item
txtWrite_val.LinkMode = 2 ‘Open DDE link (manual)
txtWrite_val.LinkPoke ‘Poke Data to RSLinx SLinxtxt
Write_val.LinkMode = 0 ‘Close DDE link

Steve,

I agree. I guess the best way would have been to use a cumulative counter in the PLC, get the software to poll the data and then process the data prior to saving it in the database. Oh well.!

At least there is a workable, reliable solution.

Seppoalanen:
I can follow what your suggesting, but in view of the discussing above about not lossing data between polling and reset, I feel the Excel route is the best.

Thank you all for your support.