OFFDTMR unexpected behavior

[mhw]

I used a OFFDTMR for the first time the other day. If the off delay time is set to 0 the output will never be true.

[Evilbeard]

I used a OFFDTMR for the first time the other day. If the off delay time is set to 0 the output will never be true.

True, but if your off delay time is 0, why do you need an off delay timer to start with?

[BobO]

Mixed emotions about that. I can perhaps see the merit in it turning on for one scan, but then the time wouldn't actually be zero. I would considering it to be working as designed though.

[mhw]

True, but if your off delay time is 0, why do you need an off delay timer to start with?

The customer wanted a variable to delay the off. Sometimes that variable will be 0.

Mixed emotions about that. I can perhaps see the merit in it turning on for one scan, but then the time wouldn't actually be zero.

The logic diagram shows the output being true when the input leg is true.

[Evilbeard]

Mixed emotions about that. I can perhaps see the merit in it turning on for one scan, but then the time wouldn't actually be zero. I would considering it to be working as designed though.

I can see what he's saying. If you put the off delay to 0, the output never goes active. It should toggle on/off with the input. It's just always false. The .done bit is always on, so the Output is always off.



In order to make it operate like it "should", you have to use logic like this:

[plcnut]

Hmmmm. I have several of these in the field right now...
I need to dig through some code to see what is going to happen if someone changes the settings to zero.
I would expect the output to always be true when the input leg is true, regardless of the time setting.

[Evilbeard]

Hmmmm. I have several of these in the field right now...
I need to dig through some code to see what is going to happen if someone changes the settings to zero.
I would expect the output to always be true when the input leg is true, regardless of the time setting.

That's what I expected to see. Here's what X0 driving timer T0 (set to output Y0) does with an off delay set at 0.

[Controls Guy]

I used a OFFDTMR for the first time the other day. If the off delay time is set to 0 the output will never be true.

I've used like 5 off delay timers in 3 decades or so of doing this stuff.  The rules on off delays vary from brand to brand. So the first solution to come to mind is invariably writing the rung logic inverted (or adding a NOT contact inline) and using a normal on delay timer.  NOW it occurs to me that I need to check and make sure TMR's work correctly with a zero setpoint.

UPDATE: TMR (on-delay) works just fine with a zero setpoint, so there's at least a short term workaround.

[plcnut]

I have always used normal timers for everything, but several months ago I started doing some programming for some systems where the OFFDTMR was the perfect fit. It made for cleaner code, so I went with it. I now have several systems that are spread out nearly coast to coast that are running these timers. I doubt that anyone will be in there messing with the values, but if they do, it will have consequences that I did not account for. At least it will not hurt anybody or any equipment...

@BobO Is this the expected behavior for the OFFDTMR?

[Evilbeard]

I have always used normal timers for everything, but several months ago I started doing some programming for some systems where the OFFDTMR was the perfect fit. It made for cleaner code, so I went with it. I now have several systems that are spread out nearly coast to coast that are running these timers. I doubt that anyone will be in there messing with the values, but if they do, it will have consequences that I did not account for. At least it will not hurt anybody or any equipment...

@BobO Is this the expected behavior for the OFFDTMR?

I think we broke BobO with this one. He can't believe all the things we break. It's why we can't have nice things.

[BobO]

I have always used normal timers for everything, but several months ago I started doing some programming for some systems where the OFFDTMR was the perfect fit. It made for cleaner code, so I went with it. I now have several systems that are spread out nearly coast to coast that are running these timers. I doubt that anyone will be in there messing with the values, but if they do, it will have consequences that I did not account for. At least it will not hurt anybody or any equipment...

@BobO Is this the expected behavior for the OFFDTMR?

I think we broke BobO with this one. He can't believe all the things we break. It's why we can't have nice things.

Nah. Just very busy.

Timers are really very simple code. This is just a quirky situation where two conditions overlap. I could easily be convinced that it *should* be changed...but we are very reluctant to change things that might break stuff in the field.

@Franj1 - You recently did the timing diagrams. Do you have any thoughts about this?

[Evilbeard]

I have always used normal timers for everything, but several months ago I started doing some programming for some systems where the OFFDTMR was the perfect fit. It made for cleaner code, so I went with it. I now have several systems that are spread out nearly coast to coast that are running these timers. I doubt that anyone will be in there messing with the values, but if they do, it will have consequences that I did not account for. At least it will not hurt anybody or any equipment...

@BobO Is this the expected behavior for the OFFDTMR?

I think we broke BobO with this one. He can't believe all the things we break. It's why we can't have nice things.

Nah. Just very busy.

Timers are really very simple code. This is just a quirky situation where two conditions overlap. I could easily be convinced that it *should* be changed...but we are very reluctant to change things that might break stuff in the field.

@Franj1 - You recently did the timing diagrams. Do you have any thoughts about this?

Yeah, my assumption was that the code looks for the .done bit and then toggles the output off, but since .done is always on, the output never actually comes on.

[BobO]

Yeah, my assumption was that the code looks for the .done bit and then toggles the output off, but since .done is always on, the output never actually comes on.

Essentially, yes.