Putting 0 in Pre for TON and CTU in RSLogix500

[AndrewG 13]

I am troubleshooting a SLC system. The operator says they can't enter in values of "0" into certain fields on the HMI. They can enter very small numbers like 0.1 but not 0. So I traced back these fields, they go to the "Pre" values of TON and CTU instructions in RSLogix500. I can't find anything about this in the instruction help, is it possible that you cannot put 0 in the "Pre" of TON and CTU instructions? I cannot test it on an actual PLC right now. Thanks.

[Ken Roach 194]

A zero in the .PRE register for a Timer or a Counter will just result in them being completed immediately after they are enabled. It won't fault the processor like a negative preset value will. I don't know for sure if a Timer's DN bit would be true on the very next rung, or if it would take one scan cycle to become true. Either way, a timer or counter with a zero preset isn't very useful. The PLC logic might not accept HMI values that are equal to zero, or the HMI itself might have limits for the input entries. I often use PLC logic to range-check HMI entries and reject negative or zero values.

[AndrewG 13]

Thanks

[daba 4]

If they can enter a floating-point number like 0.1, but not zero, then the HMI input data field, or the tag itself is being limited. This will be in the HMI application, not the PLC. Then we must consider that if the numeric input allows a decimal (like 0.1), there must be some conversion to an INTeger taking place somewhere, because an SLC Timer's preset value is an integer, not a floating-point. Also there will be some scaling involved to make that value fit the timebases available (1.0 sec, 0.01sec, or 0.001sec). This scaling might be done in the HMI, or the SLC. My suspicion is that the HMI tags themselves have been limited. You can put any value into the .PRE for both Timers and Counters, however if a timer with a negative preset becomes enabled, a Major Fault occurs, and the processor will shut-down Ken said "I don't know for sure if a Timer's DN bit would be true on the very next rung, or if it would take one scan cycle to become true.". The timer's .DN bit would be set during the first execution of the timer instruction, when the rung is true, it would not need another scan to set the .DN bit. It is effectively a "zero-time timer". For a counter, the .DN bit will be set if the .ACC value is greater than, or equal to, the .PRE value. This will happen regardless of whether the counter is enabled or not

[enfermot 0]

Either I'm misunderstanding you, or that is incorrect, as well. You can do the same test as above, but put a condition in front of the TON that is always false, and examine the .DN bit (and not the inverse this time) on the next rung in front of the same ADD. (MOV or type a value into the .ACC which is greater than the .PRE) The .ACC clears to zero on every scan, and the number value never increments. Edited 13 Mar 2015 by enfermot