event timing

[PaulB]

There is a question to all audience. There is Allen Bradley SLC 05/5
I need to store time how long event, let say some fault, last. It would never last more then 8 hours = 8*60*60=28800 sec (if it more it will reset at end of the shift and start over). I can make timer TON with base time 1sec. to start timing when event starts, and use value in the ACC register. I need convert this value to Hours, minutes and seconds and store them in the words N7:0, N7:1, N7:2. Is anybody knows how to do this? There are probably some COMPUTE instructions involved.
Other idea is to use register S:4 – free running clock. Let say use S:4/2 (every 40ms) and start counter CTU and count 25 pulses of S:4/2. It will be equal to one sec. Then build cascade counters logic to count minutes and hours and move values of the ACC registers to the N7:0, N7:1, and N7:2.
I am wondering what would be fewer load on PLC. Right now I have average scan time 20ms and max scan time 30ms.
Thank you.

 

[Allen Nelson]

You could do the calculation, dividing by 60 and 3600 into floating point registers, moving the result into integers, comparing the results to verify that you aren't getting rounding errors....

...Or you could just have a 60-second timer that increments a 60-count counter, which in turn increments another counter (or even just use an ADD command), and you're done:

  EVENT    TIMER                  TIMER

---| |------|/|----+--------------(TON) 

             DN    |               60 sec  

                   |

                   +--------------(MOV TIMER.ACC >>> N7:0)



    TIMER

-----| |--------------------------(ADD: N7:1 + 1 = N7:1)

      DN



    TIMER

-----| |----| N7:1 >= 60 |----+---(ADD: N7:2 + 1 = N7:2)

      DN                      |

                              +---(SUB: N7:1 - 60 = N7:1)

`
You'll need to figure out when to clear the values in N7:0, N7:1 and N7:2.

 

[Steve Bailey]

Using your first scenario:

Hours = ACC / 3600

Minutes = (ACC MOD 3600) / 60

Seconds = (ACC MOD 3600) MOD 60

All three of the above calculations are integer arithmetic which is pretty fast, so there should be minimal impact on scan time.

 

[Steve Bailey]

Upon consulting my SLC manual, I see I have once again demonstrated my abysmal lack of knowledge of the instruction set. I see that the DIV instruction rounds the result rather than truncating and that there is no MOD instruction.

Forget my post. Do what Allen says.

 

[bernie_carlton]

You're OK Steve - just read farther in the DIV instruction. The UNROUNDED quotient end up in the most significant word of the mat register and the REMAINDER (MOD) ends up in the least significant word. With some strategic moving and continued math he should be able to pull this off.

 

[Bill Simpson]

Just a thought, but I would typically be more interested in when a fault occurred rather then the running duration of the fault. Knowing that a fault occurred at 8:12AM just seems more informative then being told it occurred 7hrs and 53 minutes ago. But then I'm pretty good at doing the rough math in my head<grin> Maybe your situation is different, but logging the time of a fault using your choice of the S:38 to S:42 registers is an option worth considering..

Bill

 

[PaulB]

Thanks to everybody for the reply. It seems I'll follow what Allen suggests. To address Bill concern - we would like to keep track of how long our equipment in various states: fault, idle, running, chageover during the shift.
Thank you again
Paul Bronshteyn.

 

[Terry Woods]

Bill,

Reading Paul's last comment reminded me that I too have written a similar Time Totalizer for my main process.

I wrote it to eliminate the "finger-pointing" game.

At anytime, the entire system or portions of the system might "go-down" by fault or be "brought-down" by intent.

For instance, every two-weeks we bring the system down for maintenance. The scheduled down-time is 10-Hours. That is, maintenance is given 10-hours to do their tasks. If the down-time goes over 10-Hours, then there is a "charge-back" on maintenance. In other words, the maintenance cost center is charged for the down-time beyond 10-Hours. That could be some big bucks!

Well, that led to all kinds of fighting between the production and maintenance departments.

The program is setup now so that when maintenance begins their work, the system is in a "maintenance time-tracking" mode. The display shows a 10:00:00 count-down... which goes RED and turns into a count-up if the time exceeds 10-hours.

Whenever maintenance is done, the leadman presses the button to indicate "turn-over to production". At that point, the total maintenance time is logged and the system is now in the hands of production. Now production is under the gun to get up-and-running. A timer keeps track of how long it takes production to "start-up".

It forces a certain amount of "accountability" on the players.

 

[Bill Simpson]

Terry, as usual I agree totally. Sounds like what I need on my desk to tell me when to go home<grin>

Just thought I'd open up an alternative option as it wasn't all that clear what the goal really was. If it's a running total then ignore my comments. If when the fault occurred, cleared, and it's duration was of interest, then:

Log Fault Clear as Hour, Min, Sec
Log Fault Occur as Hour, Min, Sec
Subtract = duration
If passing midnight or month then add days etc. from S:?? registers

Bill

 

[JDW]

UUU

 

[Terry Woods]

I'm at a loss, JD!

What's with the... UUU ???