accumulating/storing run-time of devices

[chelton]

What is the preferred way to accumulate the run time/ hours of operation of pieces of plant/equipment? Do you accumulate in the PLC or the hmi/scada? How do you protect accumulated values? Some PLC's transfer memory and data tables. I work mainly with ab's or omron.

[BobB]

I normally do it in the PLC. Usually use a 1 second pulse into a counter to get minutes (60 seconds) and use the output of that counter to drive another counter. Another met5hod is to use @INC into a data memory - a little more work involved but times can be a lot longer than counters.

[KevinDuf]

64bit Counter.cxp I mostly do it in PLC, it's more reliable than computer,for an hourly meter i use 1 sec pulse increment a counter with #3599 for sv, counter reset by itself and increment a memory with @++L instruction. I put an example, you can use with a 0.01 pulse for more precision, or use ,DR and FOR NEXT Loop for multiple timer Edited November 3, 2011 by KevinDuf

[Ken Moore]

I usually do it in the plant historian.

[chelton]

Thanks for the replies. In the past I have accumulated in the PLC using increment or +1 every second. The site that I'm doing work for have machines that get serviced with 250/500 hour intervals. There has been some additional plant added, and another integrator has downloaded a modified program for the upgrade, this has modified the accumulated values of some 30+ pieces of equipment.

[OkiePC]

My preference is to periodically read a piece count or position value to update production expectations indicators, but tracking machine ON/OFF boolean states is a commonly needed bit of logic. Doing this in the PLC is obviously going to maximize the precision of the measurements. If, however, your minimum time measurement can afford to be inaccurate by a random value up to the scan rate of the HMI driver (with zero retires) plus the PLC I/O hardware and logic delays, do it with the HMI/SCADA. And as far as recording the times? If the HMI supports fast scanned alarm bits tied to alarm/event triggers in ordered tags in the PLC and you can tolerate +/- 0.5 second (typical worst case) errors in the time stamp it can save oodles of PLC code, especially if your target HMI supports filtering the alarms with timers and things like that. So utilizing an external device to log up time/ down time, without even editing the PLC logic, you can tie your HMI to higher level systems for logging the time when a DINT packed with bits representing the "AutoRun" state of up to 32 machines changes states and the time at which the HMI time stamps it can only be in error by the sum of the delays in the PLC hardware + the logic scan + the driver cycle rate in the HMI for alarm tags. This can be very much lower than 0.5 seconds. If your machines can stop and start frequently for, oh, I don't know, say 5 seconds or less, then this potential error becomes a huge % error and can harm the effects of totals of large numbers of short lived states. If your stoppages are always ten seconds or longer and the short stops and starts are few and far between, then it might be tolerable. Doing it in the PLC, you will want to utilize available time stamping techniques built into the system, and have an array of structures that include the data values and the time stamp, so they can be queued for external reference. I prefer a (never reset) circular queue. You keep track of the next available position. You have the data types required and available to store the time in a suitably sized array, and you have the data in another array (up to as many bits as you want to monitor status from packed into an INT or DINT). External devices can monitor this integer value for a change which would indicate at it's new index value the location of the newest data in the structure (or assembly of simple files in a simple PLC) to be read. They can even make up for long periods of lost communications (up to the time required to completely fill the queue) by reading each item between the last read index one the current one. The next problem can then become using that time data as the PLC stores it in your HMI level alarm system or higher level data base. My preference, where error tolerances allow, is to do in in the HMI/SCADA system. The HMI can easily monitor individual bits as well offload both the alarm filtering (de-bounce) and the time stamping, centralizing the clock and adheres to my KISS upbringings. Edited November 12, 2011 by OkiePC