Project with a counter that needs count saved when powered down

Hello all. I have a project I'm building that will have two counters recording the number of parts made. One counter counts the parts made that day and does not need to be saved from one day to the next. The other counter will need to be saved from day to the next keeping a running total of how many total parts are made. I don't know how to store the running total count after the machine is shut off. Thanks

jndipworm: Hello all. I have a project I'm building that will have two counters recording the number of parts made. One counter counts the parts made that day and does not need to be saved from one day to the next. The other counter will need to be saved from day to the next keeping a running total of how many total parts are made. I don't know how to store the running total count after the machine is shut off. Thanks

Is there another posting that has all the details of your project? I didn't go look at what else you have posted.

Paul

I would say you have a couple of options..

using the EEPROM... * (although I believe it has a limited amount of writes to it?) or maybe an SD card add-on to log your data to.

https://www.arduino.cc/en/Tutorial/EEPROMWrite

jndipworm: Hello all. I have a project I'm building that will have two counters recording the number of parts made. One counter counts the parts made that day and does not need to be saved from one day to the next.

But do you want to save it to survive a power outage?

Adding to the replies above, i wouldn’t discount keeping track of the count during the day... what happens if the machine breaks, or there is a power loss... no parts today.

There are a couple of other metrics you should be keeping track of... Power loss, what identifies the end of day, and what identifies the start of a new day.

EEPROM is certainly the easiest way to go. Two non-volatile stored values - the accumulated Total (eTotalCount), and the ‘daily counter’ (eCurrentCount).

A local RAM counter (currCount) is reloaded at startup from (eCurrentCount), and continues incrementing as daily production progresses. When end of day is reached, add currCount to eTotalCount, and save back as eTotalCount. Zero the currCount and eCurrentCount values, ready for the next day.

If power fails, or other catastrophe, save currCount to eCurrentCount, and restore the value if/when the system restarts. Don’t touch eTotalCount.

If you want to see the current state of play at any time after a restart, the sum of currCount and eTotalCount always has your accumulated and current day tally. Easy.

The simplest means of detecting power loss requires a diode, capacitor and two resistors on the VIN pin - feeding an analog input of the processor. When the input goes LOW, the capacitor gives you a few milliseconds to quickly clean house (stop the equipment!), and save data to EEPROM. Do not use delay(), or your precious power-fail milliseconds may be spent sitting on your virtual hands,

For the daily counter: if you have high production numbers (depending on what you produce this number could range from one car to a million matches) you can't save every time to EEPROM, while you should do just that to keep track of the numbers and to be prepared for power outage at any moment. It's rated 100,000 writes - real life numbers are probably a couple million writes, but that's it, then your EEPROM is done for.

Instead you could look at the DS1307 RTC which has a handful of bytes of NVRAM which can be written to without limit (at least the data sheet doesn't mention a limit) and which is kept as long as the backup battery of the clock itself doesn't run out. As you probably need a good clock anyway, this may be a good option for your day counts.

If you have high production numbers (depending on what you produce this number could range from one car to a million matches) you can't save every time to EEPROM

This the point i was making with a RAM variable - only saved to EEPROM when needed (end of day, or power failure etc)

wvmarle: For the daily counter: if you have high production numbers (depending on what you produce this number could range from one car to a million matches) you can't save every time to EEPROM, while you should do just that to keep track of the numbers and to be prepared for power outage at any moment. It's rated 100,000 writes - real life numbers are probably a couple million writes, but that's it, then your EEPROM is done for.

That reminds me of something I read here: https://electronics.stackexchange.com/questions/21232/100k-eeprom-writes-per-bit-or-as-a-whole

If that is so, then you should theoretically be able to count all the way to 1,600,000 (if my math is right) using only a single 4-byte page of EEPROM. You can extend this by using additional 4-byte pages, each of which would increase the maximum possible count by 3,200,000. However, to do that would require that you have some means of writing to the EEPROM without it being part of an erase/write cycle. The basic idea is that, once you set a page to (in binary) 11111111 11111111 11111111 11111111, then you would be able to individually set each of those 1s to 0, and by using the 0s as tally marks you could count up to 32 before needing another erase. (An EEPROM page erase sets every bit in the page to 1, not to 0 as you might expect. That's why I start from all 1 bits.) Does the compiler provide a way of doing this?

That's load balancing. The problem here is: how will you store which page you were currently using?

wvmarle: That's load balancing. The problem here is: how will you store which page you were currently using?

Go through the pages one at a time until you find a page that is not all zeros. That is the page I am using.

Actually, using my "count to 1,600,000" scheme, you only need to use one page. Of the 32 bits on that page, use 15 bits to count from 0 to 15 in unary. (Inverse unary, actually: you start with all bits set to 1s and then one at a time set each of the bits to 0.) To count higher than 15, reset the page and then write the number of "sixteens" into the other 17 bits.

  Count        The bits in the page               Remarks
=======  ====================================  ====================================================
      0  00000000 00000000 0 1111111 11111111  The 1st reset to all 1's is just before this write
      1  00000000 00000000 0 1111111 11111110  Set one bit to 0
      2  00000000 00000000 0 1111111 11111100  Set the next bit to 0
      3  00000000 00000000 0 1111111 11111000  And so forth
      4  00000000 00000000 0 1111111 11110000  Each time setting only one bit to 0
      5  00000000 00000000 0 1111111 11100000
      6  00000000 00000000 0 1111111 11000000
      7  00000000 00000000 0 1111111 10000000
      8  00000000 00000000 0 1111111 00000000
      9  00000000 00000000 0 1111110 00000000
     10  00000000 00000000 0 1111100 00000000
     11  00000000 00000000 0 1111000 00000000
     12  00000000 00000000 0 1110000 00000000
     13  00000000 00000000 0 1100000 00000000
     14  00000000 00000000 0 1000000 00000000
     15  00000000 00000000 0 0000000 00000000  We cannot proceed further without a page reset
     16  00000000 00000000 1 1111111 11111111  The 2nd reset to all 1's is just before this write
     17  00000000 00000000 1 1111111 11111110  From there, we proceed as before
     18  00000000 00000000 1 1111111 11111100
     19  00000000 00000000 1 1111111 11111000
     20  00000000 00000000 1 1111111 11110000
     21  00000000 00000000 1 1111111 11100000
     22  00000000 00000000 1 1111111 11000000
     23  00000000 00000000 1 1111111 10000000
     24  00000000 00000000 1 1111111 00000000
     25  00000000 00000000 1 1111110 00000000
     26  00000000 00000000 1 1111100 00000000
     27  00000000 00000000 1 1111000 00000000
     28  00000000 00000000 1 1110000 00000000
     29  00000000 00000000 1 1100000 00000000
     30  00000000 00000000 1 1000000 00000000
     31  00000000 00000000 1 0000000 00000000  We cannot proceed further without a page reset
     32  00000000 00000001 0 1111111 11111111  The 3rd reset to all 1's is just before this write
     33  00000000 00000001 0 1111111 11111110
     34  00000000 00000001 0 1111111 11111100
     35  00000000 00000001 0 1111111 11111000
     36  00000000 00000001 0 1111111 11110000
     37  00000000 00000001 0 1111111 11100000
     38  00000000 00000001 0 1111111 11000000
     39  00000000 00000001 0 1111111 10000000
     40  00000000 00000001 0 1111111 00000000
     41  00000000 00000001 0 1111110 00000000
     42  00000000 00000001 0 1111100 00000000
     43  00000000 00000001 0 1111000 00000000
     44  00000000 00000001 0 1110000 00000000
     45  00000000 00000001 0 1100000 00000000
     46  00000000 00000001 0 1000000 00000000
     47  00000000 00000001 0 0000000 00000000  We cannot proceed further without a page reset
     48  00000000 00000001 1 1111111 11111111  The 4th reset to all 1's is just before this write
     49  00000000 00000001 1 1111111 11111110
     50  00000000 00000001 1 1111111 11111100
    ...  ........ ........ . ....... ........
  .....  ........ ........ . ....... ........
.......  ........ ........ . ....... ........   
1048574  01111111 11111111 1 1000000 00000000  So, why this weird storage format?
1048575  01111111 11111111 1 0000000 00000000  Because we're gonna need it right... about...
1048576  10000000 00000000 0 1111111 11111111  NOW!  (this is our 65537th reset)
.......  ........ ........ . ....... ........
.......  ........ ........ . ....... ........     
1599997  11000011 01001111 1 1100000 00000000
1599998  11000011 01001111 1 1000000 00000000
1599999  11000011 01001111 1 0000000 00000000  Technically, we should stop right here. (Why?)
1600000  11000011 01010000 0 1111111 11111111  This is the 100001st reset: our EEPROM craps out!

Every time you write even a single bit to the EEPROM the complete cell the bit is in has to be erased before it can be written to. Unchanged data will simply be rewritten to the same location.

Also by default all bits are set. Reading a never used byte from EEPROM always returns 255.

wvmarle:
Every time you write even a single bit to the EEPROM the complete cell the bit is in has to be erased before it can be written to.

How? Why?
Does the hardware disallow a write without an erase?
Or is it simply how the software (Arduino and/or GNU compiler) is set up?

Unchanged data will simply be rewritten to the same location.

Because that’s how the software is set up, right?

Also by default all bits are set. Reading a never used byte from EEPROM always returns 255.

I figured as much.

Wow this thread really took off. To answer Paul_KD7HB, there have been no other post regarding this project. I’ve been planning and building components for this machine for 3 years now and I’m close to being finished. I was looking for ideas on how to handle counting the parts this thing will make. I haven’t had time to read all the posts yet but it looks like I have several options. Thanks everyone for the input.

odometer: How? Why?

That's how EEPROM memory works.

While we’re here discussing EEPROM (and some other technologies), the technique is usually called wear ‘levelling’ to distribute utilisation over a larger ‘area’ of the memory.

I believe ‘nalancing’ is only partly correct.

jndipworm: Wow this thread really took off. To answer Paul_KD7HB, there have been no other post regarding this project. I've been planning and building components for this machine for 3 years now and I'm close to being finished. I was looking for ideas on how to handle counting the parts this thing will make. I haven't had time to read all the posts yet but it looks like I have several options. Thanks everyone for the input.

I just remembered another possibility: http://zedomax.com/blog/2007/03/20/mechanical-hit-counter/

battery with enough power to write on a power failure. lastFail = lastFail+1 to get how often it looses power time of write so you know when it failed and of course lastCount to you have a place to pick up.

in setup, just fill your count value.

as for wear leveling, can you create a new file each day ? with about 80,000 hours in a day,[ op's seconds a day, thanks wvmarle] you could write once per second and for those bits, stay under the 100,000 mark. and, the benefit is that you would be able to see your daily production over time.

dave-in-nj:
\with about 80,000 hours in a day

Which planet are you living at?

wvmarle:

\with about 80,000 hours in a day

Which planet are you living at?

Didn't you see Wrath of Kahn ? Saavik and Spock.... hours means days....

there are a bit over 86,400 seconds a day on my planet. how about yours ?