Counter increments by itself?

Hi everyone,

(Picture below and zip file with .rsl file attached). I'm on the RSLogix tutorial's batch mix counter simulation, and I'm having trouble. I can not, for the life of me, figure out why I'm getting the following strange results: upon finishing the mixing, C:5/1.ACC suddenly jumps to 30 from 20, and since I need to base the emptying process for this simulation on the counter, and not the low-level indicator, the tank is completely empty at 10 (after decrementing 20), and the motor burns up, since the pump runs dry. Can anyone point out what may be wrong in my program? I appreciate any help!

-Patrick

S:4/4 is part of the free running clock. It will increment and make the counter increment "automatically". Why is S:4/4 in there?

I'm guessing here but I think C5:1.ACC is jumping to 32, not 30. On first glance I would say it's rung 6. It looks like you are taking C5:0.ACC, converting it to BCD and putting it in C5:1.ACC. Since you are moving between equivalent data types I would say you don't need to do a type conversion. Just use a move (MOV).


I think you can also use the same element in both the CTU and CTD. So delete rung 6, replace C5:1 with C5:0 in (current) rung 7, replace C5:1.ACC with C5:0.ACC in the EQU in (current) rung 8 and condition (current) rung 8 with XIC of O:2/3. Also, make the TOD in rung 3 unconditional and delete rung 9.

Keith

TWControls said:

S:4/4 is part of the free running clock. It will increment and make the counter increment "automatically". Why is S:4/4 in there?

Click to expand...

That's what the simulation outline suggested I do. I know, it's not a practical exercise at all.

kamenges said:

I'm guessing here but I think C5:1.ACC is jumping to 32, not 30. On first glance I would say it's rung 6. It looks like you are taking C5:0.ACC, converting it to BCD and putting it in C5:1.ACC. Since you are moving between equivalent data types I would say you don't need to do a type conversion. Just use a move (MOV).


I think you can also use the same element in both the CTU and CTD. So delete rung 6, replace C5:1 with C5:0 in (current) rung 7, replace C5:1.ACC with C5:0.ACC in the EQU in (current) rung 8 and condition (current) rung 8 with XIC of O:2/3. Also, make the TOD in rung 3 unconditional and delete rung 9.

Keith

Click to expand...

Thanks, Kamenges! I was using TOD because that was all we had been exposed to so far; didn't know it would corrupt the data upon transfer. Now, here's another question: reversing the count leaves a little bit of water left over in the tank, and after several cycles of fill/drain, the water gets up to the top and overflows the tank. Any idea why I have this slight but significant enough difference in fill and drain amounts?

I kind of depends on how your simulator is modelling tank level. Just based on how the S:4/4 bit is timed to you logic you may end up with a slight time mismatch between the fill and empty cases. Also, just by dumb luck S:4/4 may be on when O:2/3 turns on. This will cause an immediate count down.

This is a hack, but you might try to add one to the count when full is detected. Or add a short timer after C5:0.ACC equals zero. Without knowing how the simulator models tank level it is a little tough to know where the discrepency comes from.

Keith

kamenges said:

I kind of depends on how your simulator is modelling tank level. Just based on how the S:4/4 bit is timed to you logic you may end up with a slight time mismatch between the fill and empty cases. Also, just by dumb luck S:4/4 may be on when O:2/3 turns on. This will cause an immediate count down.

This is a hack, but you might try to add one to the count when full is detected. Or add a short timer after C5:0.ACC equals zero. Without knowing how the simulator models tank level it is a little tough to know where the discrepency comes from.

Keith

Click to expand...

OK, that's what I suspected... thanks again!