Hour counter in m340 plc

[vaidyanikhil24]

HELLO
i am working on a logic in which i have to record number of hours a DI bit is enabled and record it to vijeo citect 7.4.
in simple words i want to make a hour counter by enabling a DI in PLC.
can somebody help me with that?
i am using Modicon m340 plc and unitypro s software.

 

[Corsair]

Depending on the resolution that you need I usually use a SAMPLETM interval timer and count the output pulses. If hundredth-hour resolution is adequate the timer can time for t#36s. AND the output of the timer with your DI. When that is true increment a 32-bit unsigned double integer. The output of the SAMPLETM timer only comes on for one scan with each interval so you don't have to do any rising-edge (rtrig) detection on the input. Because of this the counting can be done with an addition instead of a counter instruction. I tend to struggle with PLC counters and rarely use them.

The SAMPLETM timer gives you much better long-term accuracy than using a TON and doing resets on it. There's more discussion of this topic in the PLC class outline on corsairhmi.com.

 

[MattUK]

This thread has piqued my interest as I've never heard of and therefore not used the suggested SAMPLETM function block within an M340 before. As you've stated it, with the 1/100-hour sample time, and without the mention of any precondition to allow the FB to execute, how would this be more accurate than just having a retentive timer that resets hourly and one shots an increment to a double integer every time it completes?

It seems setting the DI as a precondition to the SAMPLETM and then setting the interval to 1 hour would be more accurate? The only question then would be the issue of retention and if OP was looking for total hours or complete hours per activation...

Anyway, I'd like to hear your thoughts on this so I can better understand the FB. I'd test it myself but I'm currently working 8000 miles from home and don't have access to the required software.

 

[Corsair]

Clarification

A retentative timer that trips a counter would be much more accurate than using a SAMPLETM at 36 second intervals. Counting a 36 second time base yields a potential 36 second discrepancy with each change of the input state. The applications where I've been using it are run time totalization in wastewater where the precision is not needed.

Where the SAMPLETM function gets it's reason to exist is with long-term continuous time totalization. Lets say you are counting pulses from two timers. The first is a normal TON that resets itself every second. The second is a SAMPLETM timer set for a one second interval. Let them both run for a couple of days. The normal TON will lag behind. The reason is that it loses any timing that occurs during the reset scan. The SAMPLETM doesn't have that problem.

The PLC class outline at corsairhmi.com talks about ancient PLCs that did not have time of day clocks. If you were desperate for a clock you wrote one in PLC code,knowing that it would be wrong after a power failure. If you counted your timing based upon a 1-second TON that kept resetting at 1-second intervals the clock would run slow due to the reset scans. Running the TON for a minute was better but it still had the problem. One improvement was to let the timer keep running and subtract a second off the preset value every time it got over a second. That gave better accuracy. That's how the SAMPLETM function works. It's MUCH better for tasks like integration of a value where you want precise time intervals even with wandering scan times.

Different tools for different purposes...