#1: parky's solution is fine; this post looks at a minor semantic issue.
there may be some ambiguity in the problem statement:
> if value A is still Less than Value B
If this mean A is less than B when (at the moment) the timer expires, then parky's solution is perfect, as expected.
How-some-ever, if "still" means A has been less than B for the entire duration that the timer is timing, then adding the compare to the rung before the TON is all that is needed.
If the problem is to be solved with A-B hardware, then note that the TON.EN (timer enabled) and TON.TT bits (timer is timing => [.EN AND NOT .DN] ) are available as well as the .DN bit, although the comparison [ET>0] would be more or less equivalent to .TT in other manufacturer's environments. For example, using a rising edge on the .TT bit would trigger the ADD when the timer starts, including the first time it starts, as opposed to when it ends.
As I said at the beginning, the solution proposed is fine; I am not criticising it; I merely noticed an ambiguity in the problem statement that may require modifying parky's approach slightly.
That said, if .TT is used, then if the comparison [A>B] changes state every Ns where N<15, then the ADD will occur every 2Ns; and if .DN is used and N<30, then the add will never happen.
We cannot tell from the problem statement if either of those cases is desired behavior Maybe there needs to be a one-shot to detect a rising edge of the compare that starts the proces.
This is an interesting problem.