Off delay (TOF) and E-stop logic - Logix 500

[radfahrer]

I browsed the forums a bit but couldn't find an exact response to this issue. In most cases people seemed to recommend using TON timers instead of TOF. But then I saw the R. Beaufort quiz PDF which explains how unexpected issues can happen there too.
So curious if anyone has a better solution than what I found. It's one of those things that feels like it shouldn't be this hard, but I haven't been able to crack it.

Functionality I'm looking for is pretty simple. Have a hydraulic system which needs to keep some valves open for a few seconds after the command is removed to depressurize the cylinder (there is a separate build pressure valve which closes right away). So I have a TOF timer after the command is removed, I hold the output for a few seconds. The issue is when the e-stop is pressed, the TOF goes, if the e-stop is reset quickly, it's possible the output will re-energize. Granted I'm being a bit anal with this, this timer only needs to be a few seconds, and the chance of an e-stop being cleared that quickly is very small...if it really was an emergency situation, I doubt they're going to be ready to go before this TOF finishes anyway, but I want the code to be as safe as possible...accidental restarts are bad.

My solution was to use the E-stop (interlock in my code) to set the ACC equal to the PRE so the timer stops right away. Just wondering if there is a more elegant way to do this using DN, EN, TT bits. Or if this is a solution others have used.

Can anyone see any download/first scan issues that might come up with this code?

 

[kolyur]

You can run your MAIN_PISTON_FWD output solely from the DN bit of the off-delay timer. This bit goes true when the timer is first enabled and stays true through the off delay. In other words, you don't need the parallel combination of B30:4/1 and the timer TT bit.

Regarding the quick-estop-reset issue, the way I've dealt with this in the past is to add a rung with a RES instruction that resets the off-delay timer when the controlling logic (MP_FWD_INTERLOCK in this case) goes false.

 

[radfahrer]

Logix 500 help indicates not to use RES with TOF...but not sure why exactly

John,

Thanks for the reply. The reason I didn't use a RES was that in the Help for the TOF instruction in Logix 500 they have a warning not to use RES with TOF because the accumulator gets reset as well. I just did a quick test to see how it behaves with a RES and it looks like it behaves fine as far as the bits are concerned. As soon as the input goes positive, the ACC is reset to 0 anyway, so not sure why the help says not to use RES, unless you're reading the ACC in a CMP block somewhere, I can't see it causing issues.

Any idea why they have that warning or where it would cause a problem?

-Greg

 

[kolyur]

Very interesting... I had never come across that warning before and I don't know what the concern would be with using RES with TOF. I've done it a number of times over the years to solve the exact problem you're having, and I've never encountered any "unpredictable machine operation."

Here is my guess: Suppose you are driving an output from the DN bit of a TOF. If the TOF is in it's timing phase (input signal has been removed) and you hit it with a RESet, it not only resets the ACC but also immediately disables the DN and therefore the output. This is in contrast to a TON, which in order to be timing requires the input logic to be true. A RESet in this case would reset the ACC but not the running state of the timer itself. So, I guess in some cases this difference could lead to "unpredictable machine operation" but only if the programmer doesn't fully understand how timers work.

 

[daba]

I may be shot down for this, but my understanding of an E-STOP is that it removes power from ALL field devices, and that holding some outputs ON isn't technically an E-STOP.

Just stop and consider the following scenarios...

1. The PLC Major Faults and stops controlling outputs.

2. The power goes off.

3. The output card fails.

If there is an absolute need to do what you want, then my guess it needs to be provided externally, and you can't do it in the PLC code.

 

[pal]

You've opened a can of worms there daba - under some circumstances , for instance high inertia motors and loads , a timer may be needed to be safe , but I agree a normal PLC should not be part of an active safety circuit . A safety timer should be used as an integral module of the safety relay .
What is used should be determined from the risk assessment of the machine .

Paul

 

[radfahrer]

PLC e-stop logic is not primary in this case

Thanks for the feedback...I probably should have been careful using the word E-stop. Maybe code interlock is a better word. But be assured, I am not relying on my PLC logic to stop the devices, we have a hardwired circuit for that, with safety rated relays and a manual push-button reset requirement. I just wanted to make sure my code cleared all the bits as well, so that after they have pulled out the E-stop and pressed the manual reset that everything stays off.

-Greg

 

[daba]

You've opened a can of worms there daba - under some circumstances , for instance high inertia motors and loads , a timer may be needed to be safe , but I agree a normal PLC should not be part of an active safety circuit . A safety timer should be used as an integral module of the safety relay .
What is used should be determined from the risk assessment of the machine .

Paul

Opening cans of worms is my way of making people realise that their expensive PLC is not the be all and end all. In terms of safety you have to consider the PLC program is the least safe, the PLC hardware the next, and correctly installed and configured safety devices and relays as the most.

It seems like radfahrer has his bases covered....

 

[jdbrandt]

Very interesting... I had never come across that warning before and I don't know what the concern would be with using RES with TOF. I've done it a number of times over the years to solve the exact problem you're having, and I've never encountered any "unpredictable machine operation."

Here is my guess: Suppose you are driving an output from the DN bit of a TOF. If the TOF is in it's timing phase (input signal has been removed) and you hit it with a RESet, it not only resets the ACC but also immediately disables the DN and therefore the output. This is in contrast to a TON, which in order to be timing requires the input logic to be true. A RESet in this case would reset the ACC but not the running state of the timer itself. So, I guess in some cases this difference could lead to "unpredictable machine operation" but only if the programmer doesn't fully understand how timers work.

When I teach my PLC classes, I tell students that TOF's are simply a goofy instruction, and, unless the entire program uses them, they just confuse electricians and make life difficult.
You've proved the point with this whole point.
I still don't like TOF, and, at this point, after not liking them for 34 years, I probably never will change my mind.
Mostly because I have yet to be shown ANY application where the use of a TOF couldn't be replaced by a TON, and be much clearer in the process.

 

[OkiePC]

There are a few rare situations where a TOF can simplify the logic, but it seems backerdz when you monitor one and the DN bit starts out DN until the timer is DN. I think I have only used the TOF once to put 9 bit examine instructions in series when the TON would have needed them in parallel, and some other clutter would have made it even uglier.