recover operation after power failure based on elapsed time

Skidood

Member
Join Date
Oct 2016
Location
Ontario
Posts
213
Hi group,

I am trying to figure out how to calculate time elapsed during a power failure. If the PLC is off for more than 30 minutes, when the power is restored I want to enable a bit. If the power is off for less than 30 minutes, the bit is left alone.

I believe I previously saw a logic example where the amount of time that has passed since the beginning of the year is constantly stored, and then upon power restoration, the current time/day is compared to that somehow but that strategy seems a bit wonky.
I know that I will be working with the First Pass bit.
I can also tell you that my program already writes the current day, hour, minute and second to their own integer files 4 times per second.

Any takers?
 
What make and model of PLC ?

Some have a Real-Time Clock and a power-down routine that will allow them to store the time of the power failure.
 
I did this on a laminating hot press to continue the cycle if the power was off less than 20 minutes and the hydraulic pressure was not lost. The customer specified it to abort the cycle if the power was off more than 20 minutes.



What I did was power the PLC by the UPS for the HMI computer. The PLC watched for the main power to drop and recorded that time. When the power came back on if the PLC was still running, or just restarted at the power coming back on was calculate the lost time.


Calculating the hours and minutes was fairly easy, but if the power dropped during a cycle that continued into the next day, maybe month and year, got complex.


If the power restores after midnight the next day see what day of the month it is, the number of days that month (leap year Feb's have 29) and the year to calculate how many days/hours/minutes the power was off.


Along with these calculations I just added a 20 minute timer to time out - as the UPS keeps the PLC running for almost an hour.
 
Yes, if midnight is not going to ever be an issue that would work.


However keep in mind that when a timer gets /DN it skips a scan before starting back timing. For this I would run your timer for 120 seconds, then do a compare GEQ T4:x.ACC 60 then add 1 to n7:0 and SUB T4:x.ACC 60 T4:x.ACC and you will get more consistent timing.
 
In case you were replying to me, I'm sorry, I deleted the post you were referring to.
I thought I had a solution and posted it but then realized it wasn't good.
Thank you for the answer.


Yes, if midnight is not going to ever be an issue that would work.


However keep in mind that when a timer gets /DN it skips a scan before starting back timing. For this I would run your timer for 120 seconds, then do a compare GEQ T4:x.ACC 60 then add 1 to n7:0 and SUB T4:x.ACC 60 T4:x.ACC and you will get more consistent timing.
 
You could explicitly calculate a Julian Date (the Day of the Year), then calculate the number of seconds equivalent to it. Then you could compare the last-copied value to the powerup value.

The Free-Running Clock zeroes out at power-up, so it's not going to be useful.
 
OK here is what I will try.
PLC writes a zero to N7:0 every night at 00:00 and adds 1 to N7:0 once per minute.
It already continually stores current RTC year, month, hour, minute and seconds to integers.

ON power up:
-if current day, month, or year is greater than the last stored day, month, or year respectively, set the 'abort" bit.
- if hour difference is >1, set abort bit
- if hour difference is LEQ 1, THEN:

Multiply current hour of day by 60 and send to N7:1
Add current minutes to N7:1
If N7:1 exceeds N7:0 by more than 30, set the abort bit.
 
Also, for the logic scanned on the first pass, I was wondering if its better to place the first pass rung(s) at the beginning of the main ladder or at the end of it. Seems to me that putting it at the end makes more sense since all the other ladder logic in the program will be over-ridden by whatever is in the first pass rung. If the fist pass is at the top of the main ladder, the ensuing logic instructions in the rest of the program could over-ride it what i want to accomplish in the first pass. Am I out to lunch here?
 
Also, for the logic scanned on the first pass, I was wondering if its better to place the first pass rung(s) at the beginning of the main ladder or at the end of it. Seems to me that putting it at the end makes more sense since all the other ladder logic in the program will be over-ridden by whatever is in the first pass rung. If the fist pass is at the top of the main ladder, the ensuing logic instructions in the rest of the program could over-ride it what i want to accomplish in the first pass. Am I out to lunch here?

If there is a chance what is written from a First-Pass could be overwritten later in the scan I would put a XIO First-Pass on the other rungs so they were not processed on the first scan.
Also, Since the First-Scan writes 0 to your N7:0 it could do that first, then the rest of your calculations could be completed the same scan without causing any problem.
 

Similar Topics

Hi. I'm testing a few communication bits to monitor the communication health between InTouch 2023 and a L71 PLC. To do so, I disable OI.ABCIP...
Replies
2
Views
538
We have a PanelView 1000 2711P-RP1A Series E Rev G that failed and won't power up. Unfortunately, this is a large and complex application and...
Replies
5
Views
680
I don’t have the original project file from a Siemens ET200SP. The program is still running on the PLC. Is there any way I can upload the...
Replies
1
Views
1,608
So, a WW PC's hard drive decided to go bunk. The local tech did use Windows 7 Back and Restore to save an image. However, the restored image...
Replies
0
Views
1,004
I am getting a fault from a plug in module that is causing the PLC program to halt. When I manually clear the fault and switch back to RUN...
Replies
9
Views
5,341
Back
Top Bottom