Knowing length of time PLC was powered down

[Mspeck 0]

Good afternoon,

   I'm currently collecting runtime data from my production floor PLC's, 

Example:

Footage produced per shift, Uptime, Downtime, etc.

At the end of each shift the plc triggers a bit that goes high where Ignition, the data handler software, collects the data and stores it in an SQL database table. Ignition then writes back to the PLC and all data is then reset to zero to begin collecting the data again for the next shift. The issue I am experiencing, When the Machine is powered down for preventive maintenance so is the PLC, this causes two issues...

•    When the machine is powered down after running for a period of time the Downtime data will not be accurate once power is returned. I may be able to write some logic that monitors the system clock on the first scan and compares to the total time in the Uptime and Downtime counters and if there is a discrepancy then add that time to the Downtime counter. But this will be quite some logic to develop !! But can be done.
•    2nd scenario, When the machine is shutdown and not turned back on until the following shift the uptime / downtime and footage data has not been reset because it missed sending the trigger to Ignition,  now we continue to add data to these tags and add it to the following shift.

I'm sure someone out there has experienced this and hopefully can help, Some have mentioned to keep the PLC powered on when the machine is powered down. I do not much like this option due to safety reasons.

Thank You in advance for your support and comments,

Mike
 

[Joe E. 165]

Hmmm....that's interesting....

I've written code in the past to track downtime but it was a rough draft that didn't get to the point of handling power off conditions. One thing I did was use a GSV instruction to get the current wall clock time. You can make sure that your first scan or power up routine has a GSV for wall clock time that executes before whatever code you're using to track time-of-day. You would then build in code that would be able to "fill in" shifts that elapsed since the last time-of-day was updated. Code could get interesting with loops if more than a shift has elapsed, but should be do-able with loops. IOW, on power-up, grab your last "time-of-day", which should be one scan before it was powered off, and store it. Then see if you're still within the same shift. If so, elapsed time since last "time-of-day" to "now" will be added to your maintenance downtime register and then you just continue on. If you've spanned a shift, it gets more complicated.

I looked quickly through the major and minor faults and didn't see anything right away that would trigger when power is lost, but there may be something. If so, you may be able to use the fault handler to record the current time and set a "Maintenance" flag of come kind, but I'm not sure how useful that would be...hmmmm....

I'm out of time now, but I'll be thinking about it over night (whether I want to or not...;) )

[panic mode 144]

create logic that constantly stores current PLC time to a retentive data block. on powerup, using first scan flag you can read this value and compare this with present time.

if the data goes to some PC or database, comparison could also be done on PC end...

and constantly in this case means using some suitable interval (every scan or some other suitable interval, perhaps every second... or every 10 seconds)

[Mspeck 0]

Thank You Joe E. and panic mode, your replies provide good information as to writing logic monitoring the GSV, this will be a challenge and not looking forward to it.!!

[pop29684 12]

Perhaps a good application for a simple heartbeat bit? If the bit isn't seen, track the length of time it is missing. Probably not accurate down to the second but might be worthwhile.

[Mspeck 0]

Well, after explaining this issue to the Mechanical Engineer he stated, " Why not just use a 'centralized' plc that handles all the data and have it send the information to Ignition " This PLC could be mounted in my server rack and would never require being shutdown without being a planned shutdown

Ughh, I hate it when he has a good viable option, 

This is a good solution and will probably be the way I will proceed.

I will keep this post active until Monday, 1/11/2021,  in case anyone has additional comments,

Thank You all for your support,

Mike

[Joe E. 165]

My rough draft that I mentioned above did something similar except all of the PLCs were in machines on the line. IOW, one machine served as the data concentrator and gathered all of the information from the other PLCs on the line. The first word of data that was transferred was binary flags and the first flag was a heartbeat that the data generator flashed. The recipient then monitored its status to see if it stopped blinking. If your data collection PLC is always on and your network is reliable enough (ours wasn't down there), you can use the heartbeat to track when the machine is powered off. Of course, you're going to need an "extra" PLC which was another expense we didn't have the budget for. When I did it, all I could use was hardware we already had.

[panic mode 144]

well, whatever rocks your boat but... what happens when that central PLC goes down or there is power outage or some fault?

not that alternatives are to be ignored, just trying to get the original question answered.

so why is reading wall clock time hard? all it takes is to declare an array and add GSV instruction to write to it. in fact i would make more than one array for different purposes:

a) current time (need to be retentive and in AB PLCs that is pretty much all of the memory)

b) last powerup time and

c) last shutdown time.

 

so here program rung with GSV is constantly reading wall clock and writing to "a" (current time, which can be used for other things in the PLC)

and on the first scan, use copy instruction to copy entire array "a" (current time before PLC was powered down) to array "c" (last shutdown time), then read wall clock and if needed another copy instruction to save time to "b" (last startup time).

and that's it... both time stamps are captured.

now when ever is convenient (or right away if you like) you can calculate the difference between "b" and "c" and store it in a suitable format, perhaps using single CPT instruction. for testing and development you can go without CPT and just subtract individual array elements.

d.year=b.year - c.year
d.month=b.month-c.month

etc.

or in RSLogix where those elements are parts of arrays and not structure, that would be

d[0]=b[0]-c[0]
d[1]=b[1]-c[1]

etc.

obviously this is easily done in a loop too.

 

if result of any element is negative, correct for it the same way you would do long subtraction on paper using borrowing, for example.

if d.second<0 then 
  d.second = d.second  + 60 ; 1min  = 60sec. so here we add one minute...
  d.minute = d.minute-1 ; and here we subtract it to keep it balanced
endif

if d.minute<0 then 
  d.minute = d.minute + 60 ; 1h  = 60min so here we add one hour...
  d.hour = d.hour-1 ; and here we subtract it to keep it balanced
endif

if the result is expected to be in specific units (seconds or minutes or hours) just multiply or divide other array elements as needed and sum them up. 

 

[Joe E. 165]

panic mode's description is a more elegant version of what I had stewing in my head. It just wouldn't come out as coherently for some reason...

[panic mode 144]

thanks Joe,

 

i tried to make it that way, even expanded a bit.