24 HOUR COUNTER

[renzoduran 0]

Hi all, We have 4 pumps that have to be activated for one hour each, but not at the same time. The hour is different for each pump. The cycle is 24 hours. Does anybody have the code of a 24 hour counter? We don't have the budget to buy a plc with RTC. Thank you for your help.

[b_carlton 61]

How about someone otherr than Allen Bradley or are you already committed to the Micrologix 1000?

[renzoduran 0]

Hi, Unfortunately we already have the PLC and management will not accept to buy a new one at this time.

[BobLfoot 301]

Don't have the code but can layout for you fairly easily. Start with a always running timer T4:0 with a timebase of 0.001 and a preset of 2000. If T4:0.acc is greater than 1000 then increment a seconds counter and subtract 1000 from the .acc. If the seconds counter is equal to 60 then increment a minutes conuter and reset the seconds counter. If the minutes counter is equal to 60 then increment an hours conuter and reset the minutes counter. If the hours counter is equal to 24 then reset the hours counter. Try coding that and posting your work and others will have improvements I am sure.

[renzoduran 0]

Thanks for the help. I will post the code as soon as I can.

[Shiner 2]

If T4:0.acc is greater than 1000 then increment a seconds counter and subtract 1000 from the .acc. I have read a bit of the posts on this and I know that the end result of a timer running its course and being reset is a value greater than the timebase you set so incremental increases (deviation) in used time occur, but the explanation for why what you have works still is not clear to me. Why subtract that value from the timer. Is the math function faster than the reset function? Isn't there going to be deviation already, you are not performing the math when one second is reached, the expression is when it is greater than 1000 (1 second)

[BobLfoot 301]

Shiner the reason for this approach is to minimize accumulated error. Let's assume for a second that we used a preset of 1000 and reset the timer and incremented the seconds counter. Let's also assume for argument that the scan time is 25 ms. This means we can encounter our timer done bit anywhere between 1000ms and 1025ms after starting the timer. Taking the worst error 25ms and diving by 2 to get average error this means each second will be off by 12.5 ms. With 86,400 seconds in a day we've introduced 1080000 ms of error or 1080 seconds of error or 18 minutes of error in a day. Now with what I propsed no matter what the acc reads we subtract the 1000 ms and increment the seconds couinter. Any error is used as preload for the next second and doesn't accumulate. So in a day we have only 25 ms error. if that. To elaborate with my example lets say that due to scan we encounter our first second at 1013 ms. We increment the seconds counter and start counting through our second second at 0013. What would have been 13ms of cumulative error is eliminated. Now lets say that due to scan we encounter our second second at 1003 ms. We increment the seconds counter and start counting through our third second at 0003. What would have been 3ms of cumulative error is eliminated. Hope this helps.

[Ken Roach 194]

Bob, that is simple and brilliant. Thank you for sharing and for explaining it in such a straightforward way.

[BobLfoot 301]

Appreciate the confirmation Ken - coming from you that's no small encouragement.

[Shiner 2]

Thank you that is perfect. I understood that there was an incremental increase, and that it causes accuracy problems, but I did not see what your function was accomplishing. Now it is perfectly clear and thank you for sharing a very simple method of coping with scan time delays.