Compare and add

I would like some suggestions to help me compare 2 values and if value A is Less than Value B add a value to another tag. After this has happened wait 30 seconds then if value A is still Less than Value B Add the same amount again in 30 second intervals until Value A is Greater than Value B.

Welcome to the forum.
homework assignment?
you already have everything you need.
start a 30 second timer
when the timer is done, if a < b then e
reset the timer and allow it to start over and repeat the process.
james

I assume you being in the states you are probably using RSL I do not have this loaded at the moment but the logic below should give you enough information on at least one way of how to do it.
Caveats: on first startup the comparison will only happen after 30 seconds (or what ever time base you have. I have included a NOT first scan bit to reset the timer (ensure first scan timer sees a non true state) as some PLC's will not start a timer unless it sees a false to true transition on first scan).
The logic shown is set at10 seconds for testing purposes.
So every x seconds the timer done bit is triggered, this enables the comparison and if A < B then adds one to the variable C. on the next scan the timer done bit is still true so resets the timer, hence resets the done bit (one shot).

#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.

Yes I agree, if the first instance of A < B requires C to be incremented, then use a TT timer so compare, if A<B AND NOT Timer then increment C and start a TT timer. There was a caveat I put in that it has to wait for 30s before incrementing C.

parky said:

There was a caveat I put in that it has to wait for 30s before incrementing C.

Click to expand...

Sorry, yes, I should have mentioned that I had seen the caveat, and I was only mentioning that the .TT gives a slightly different behavior; I was not saying there was anything wrong with waiting for the first 30s expiry to do the first ADD.


My bigger concern was with the case where the state of the [A>B] changes state while the timer is timing, but is true when it expires.


Hmm, now that I think about it, either solution may not work:


Say [a>b] is true for 1s out of every thirty seconds, and that one second spans the timer expiring and restarting: in parky's base trigger-at-expiry example, an add occurs every 30s; in my rising-edge example an add also occurs every 30s. So in both cases the ADD occurs every 30s even though [a>b] is true for only 1s out of every 30s; I can't see that being the original intent.


If this is a homework assignment, and the OP does something to handle these special cases, then they should explicitly state how they interpreted the problem statement, and why the simpler approaches would not work.

Actually, the most interesting bit here is parky's [XIO First_Scan_Bit] in the rungs feeding the TON - that is the kind of experience one would rarely figure out until they got bit with it.

I think that goes for most posts, we often have to assume the way it was intended to work, and it often means we look too deep into it when a simple solution is all that is required, however, it is best to have a number of solutions & leave it up to the OP to decide. It would be nice to get all relevant information but then if they can give a full explanation there is no reason why they cannot work out the logic. catch 22 ?

parky said:

I think that goes for most posts, we often have to assume the way it was intended to work, and it often means we look too deep into it when a simple solution is all that is required, however, it is best to have a number of solutions & leave it up to the OP to decide. It would be nice to get all relevant information but then if they can give a full explanation there is no reason why they cannot work out the logic. catch 22 ?

Click to expand...

Good observation, definitely Catch 22: by the time someone completely types in the system specification, they have done duck debugging, so by then they understand and don't need to post.

LOL, yes I have, It was not my code, but a system had been running for some time, I was there to do a mod on someone else's code, I did the mod & the site engineer asked me about a problem they had on some occasions, they power down the system every week to do planned maintenance, sometimes a particular function would not work, if they did a couple of power downs then it would start working, the only thing I could see was that the function relied on a self resetting timer i.e. the not timer contact drove the timer a reciprocating timer that generated a pulse every x seconds. Some times when re-booted it worked, sometimes the timer would not start timing, I realised it may be that the timer does not see a transition from false to true, I did exactly the mod described & it never caused a problem again.

Btw, what the OP is trying to do is not very different from an I-only controller, which can be done with a PID controller with the P and D actions zeroed out, (or P very small), some I action, and a deadband.