One Shot's and Latched bits.

I am working on a AB PLC5/40. There is this subroutine I was working on that used one shots to (ons) as part of the rung to mov values to words (4 words). This happens twice.. the first time I added another branch and included a Latched bit (to signify that the values had been moved so I could start a On Timer (TON)... well.. when I was testing it out the bit didn't latch..
Each time I move (MOV) the data values (it happens twice) I put the 4 mov statements in the same rung.. could that have something to do with why the bit didn't latch? The values changed, but the timer didn't initiate its sequence.. and the only conditional for the timer is the latched bit...
Since I've taken out the one shot (ONS) and replaced it with an XIO (for the timer done bit value) it works fine. So now that rung is true until the timer (which is supposed to initiate once the data moves) finishes its sequence. The latched bit goes high just like it is supposed to....
But I still don't understand why it didn't go high for the one shot (ONS)...

hmmmmmm....
Thanks,
Russ

What address were you using for the ONS instruction? Not the timer Done bit, I hope!

It's very hard to follow the logic from your desciption. If I followed correctly, there are two rungs of logic.
Rung 1: Some conditions, then a one-shot, then 4 MOVes and a Latch.
Rung 2: A -| |- of the Latched bit which drives a Timer.

Am I close?
You say the bit didn't latch. What causes it to Unlatch? Perhaps both the Latch and Unlatch logic happened at the same time, and so it only appeared not to latch.

We're going to need a lot more to go on. Try drawing your logic in ASCII, using the <input type="button" value="LADDER"> button. Use the Practice Forum if you need to.

When and how do you "unlatch" the bit. I would think that the timer would be TON, then the TON/dn would unlatch the bit. Make sure you're not unlatching just as soon as you latch it. The bit should and will latch with the ONS if it is branched unconditionally like the moves--but something must be unlatching it. Search the progran for more occurances of the same bit address to make sure something else is not stepping on your code (or you're not stepping on anything else)

you're right there is some conditional that sets off the one shot..

the one shot does 4 moves and supposedly latches a bit too (b3;33/3)

then that latched bit xic starts a TON ...(in this case T4:37)

later on (there's actually another timer too).. the bit is unlatched..

but not until the T4:37/DN bit goes high.. there's a (timer done bit) xic in the unlatch rung...


Could it be because of the number of words being moved and then trying to latch a bit at the same time (with a one shot)? That doesn't make much sense to me.. but right now it's the most feasible explanation I can think of..



Thanks for the feedback..
Russ

No, not even remotely feasible. I've had worse monster rungs than you're describing all execute on a one-shot. Once the logic is true on the far side of the oneshot, everything else will execute.

Back to basics. One of two things is happening. Either the Unatch is also firing, or the MOVE that you think is happening is not the one that is. You say you do this Move-of-4 twice? Could it be the OTHER Move-of-4 is puting the data in, and that there's truly nothing going on after the oneshot.

Some things to try.
1) Put an AFI on the rung with the Unlatch. See if it the one-shot works then.
B) Replace the one-shot with -|/|- B3:33/3, your latch bit. This will function as a one-shot (since that instruction will become false once the latch fires, and so you won't do the Move-of-4 a second time (unless the but get's unlatched.)
iii) Do a Cross-reference search on the B3:33/3 and your One-shot address. Make sure that the only places you are using them is where you think you are.
4) Are the Move-of-4 addresses consecutive? If so, consider a COPY command instead. If not, consider redesigning the data table layout so that they are. This won't help the problem, but I'm starting to smell spagetti (and it's dinner time!)

If you replaced the ONS with -|/|- T4:37.DN, then that's not a one-shot, and the Move-of-4 is happening every scan, along with the latch. Why are you doing a one-shot MOVE? Is the data changing?

Somethings not right here But then, you knew that....

The 4 move statements are changing the values of a combustion chamber temperature setpoint. The idea of the one shot was to minimize processor usage. Since I only need to data moved there once to initiate a "soak timer." Now those values are moved for a total of 4 seconds. The second set of move statements replace the actual setpoint values (except for the ramping setpoint which is an actual value that I obtain in the beginning of this subroutine).
What I don't understand is that the one shot did move the values (1050) to the setpoint (which is normally 1550). I could see that on the panelview... But wasn't engaging the timer.. (now the timer is the very next rung and the latched bit was supposed to start it).
This was all written on the fly (no pre-planning).. I just started writing it... which was my first mistake. (though it works, I could have worked it out on paper first).. but I'm used to just writing the stuff into the processor......
I'm just trying to figure out what might have prevented that bit from latching while the other data was moved? If the same one shot bit address was used in an unlatch rung that could explain it couldn't it? the timer was set with 1 second increments so if it did actually go one cycle through and then the bit unlatched the timers accum value shouldn't have increased right? (it's only about 10msec's per cycle). Maybe that's what happened.. I don't know.. I'm not sure..
What the logic does is trick the unit into believing it has reached setpoint so the unit initiates the soak timer.. then it moves the preset value to the soak timer accum (so that the timers done bit goes high signaling that the unit is ready to go online) and then it places the unit online (about 500 degree's and 97+ minutes sooner) . It was written to minimize downtime and save possible penalty fee's. Also it replaces the need for the laptop since it can be initiated by the hmi screen or by telephone (through the autodialer). But it probably would have been a good idea to have worked it out on paper first (rather than create the logic while the unit is online).
I'm just puzzled at what I must have messed up to have gotten the results I did. I've learned my lesson. Even if it's on a scrap of paper I will at least write down the bits I'm using when writing the code.


Regards and thanks!!
Russ

Russ,

Is it possible for you to attach the logic to a post. Maybe just copy the latch rung, timer rung and unlatch rung. That might give us a better chance to see what is happening.

Also, do a cross-reference on the one-shot bit and make sure it isn't being used anywhere else. Plus cross-reference the latch bit B3:33/3 make sure it is not being affected elsewhere (other than the OTU). Then just to be sure, cross reference B3:33 as an entire word.

It really sounds like their is logic causing that unlatch to fire or logic elsewhere resetting that bit. The quantity of moves and other instructions should not cause this.

Just as one last test, throw another latch around your existing one using another B3 bit. See if that one latches when the move occurs. Don't bother with an unlatch, just use the latch and manually toggle it to unlatch it.

OG

I didn't read every post in this chain. I was looking for ladder to look at so I could point out the problem.

My two cents: Remember that a oneshot needs to solve false before it can solve true. Some times people get themselves into trouble using oneshots in subroutines that aren't solved every scan because of this.

1)I have seen quite a few programs where a subroutine was called via logic and the oneshot never had a chance to solve false. Also, remember that during prescan, a oneshot's bit is set to a one. This means that the subroutine needs to solve at least twice in order for the oneshot to ever fire. Once false, then true, then false again.

2) Don't put the first scan bit in front of a oneshot or false-true instruction.

3) generally speaking, don't use 1 ons preceded by multiple parallel'd contacts. Use a oneshot on each branch. Using only one oneshot would necessitate all of the contacts to go false before the oneshot could ever fire.