Latching and unlatching within one scan

kyone

Member
Join Date
Jun 2013
Location
Sydney
Posts
3
I am looking at some AB RSLogix5000 controllogix code.

A very simplified sample of code written within the same ladder:

--]A[------(L)-

--]B[------(U)-

When A is on latch output. When B is on while A is also on the output will unlatch. As it is now the output will be OFF even though A is ON.

This is how the programmer is expecting the logic to work.

I would not have a latch bit unlatching within the same scan. This sort of logic is all throughout the code. I have heard of programmers doing it like this but as a general rule I don't.

While it does work is this poor programming or is this type of programming generally acceptable ?
 
I am looking at some AB RSLogix5000 controllogix code.

A very simplified sample of code written within the same ladder:

--]A[------(L)-

--]B[------(U)-

When A is on latch output. When B is on while A is also on the output will unlatch. As it is now the output will be OFF even though A is ON.

This is how the programmer is expecting the logic to work.

I would not have a latch bit unlatching within the same scan. This sort of logic is all throughout the code. I have heard of programmers doing it like this but as a general rule I don't.

While it does work is this poor programming or is this type of programming generally acceptable ?


In order to fully understand the programmer's thinking, we would need to see the whole application. If you can post it (zip it first, forum rule), we can take a better guess at whether the logic does what it is intended to do.

There is nothing inherently wrong with latching and unlatching the same bit within the same scan, it all depends on how the bits are used, both between the (L) and (U), and outside of them.
 
This is a reset dominant latch. If you reversed the order it would set dominant. It's a pretty common function. I wouldn't use it to write directly to an output on a ControlLogix because of the asynchronous I/O update, but we did it on PLC5's all the time.
 
I've seen this a lot. No matter what, the bit is off when B is made. I've seen it used on run permissives for conveyor and chain applications.

It is no problem to run on asynch IO as long as you map your IO to memory to mimic a synchronous scan cycle. As to why, that depends on the situation entirely.
 
I've seen this a lot. No matter what, the bit is off when B is made. I've seen it used on run permissives for conveyor and chain applications.

It is no problem to run on asynch IO as long as you map your IO to memory to mimic a synchronous scan cycle. As to why, that depends on the situation entirely.


That statement is totally incorrect. If bit A and B are both true, then the latched/unlatched bit will be toggling on and off. Latched ON when the rung with the OTL is scanned, then unlatched when the rung with the OTU is scanned. Between them, the output bit will most certainly be ON !
 
Another use for this type of construct is to "call" a rung of logic from multiple locations in a Program or L5K Task. For example:

Code:
     A              X
----] [--[ONS]-----(L)---

 
     B              X
----] [--[ONS]-----(L)---


     X              X
----] [------------(U)---
              |         |
              |         |
              -- { R } --

where "R" represents the "called" logic, effectively as a one-shot on X.

If used in the Logix5000 environment, this will need to be in the same task
to ensure the intended behavior.

In this example, the multiple latches on X would likely be separated by many other rungs, where conditions A and B -- which trigger logic "R" -- are locally relevant to their surrounding code. Conditions A and B are typically more complex than a single XIC, and are either inherently one-shot, or [ONS] will be in the latching rungs as shown. This can make a program more readable if the description on X is clear about its use as a one-shot "call" or "request" to execute a certain function.
 
There should be a one-shot after the A bit to do as your saying, so once A comes, it enables the output on that scan. Whenever B comes on, it will unlatch the output. The output will never come back on until A turns off and then back on, re-enabling the one-shot.

I agree with Daba, the output will continue to flicker if both A and B are on; I've tested this on some valves. Talk about a light show.
 
Another thing to consider is what do you want the output bit to be when the processor is turned off and back on again ?

Using OTL and OTU like you have it, it could be either, depending on when the processor power went off, and the states of A and B when it re-starts.

Too many people forget to consider this when designing "latch-up" logic...
 
Mispeld,

I strongly urge everyone to avoid this practice !
I had to debug a program that had 14 rungs that latched bit say B3/234
there was 23 unlatch locations.

and no, I am not joking.

the machine got out of time and was a royal pain. the oem person who wrote the program left the company.

we decided to rewrite the entire program. downtime went from 4 hours per day to less than 1.

we had 1 latch and 1 unlatch.
multiple contacts to latch the bit and we had that bit turned on when an error occurred, so it was easy to debug.

james
 
Mispeld,

I strongly urge everyone to avoid this practice !
I had to debug a program that had 14 rungs that latched bit say B3/234
there was 23 unlatch locations.

The intention of the request-from-multiple-locations construct is to have exactly one corresponding OTU: at the rung conditioned by the latch bit, which unlatches it and executes the requested logic. If there needed to be another OTU (to "cancel" the request), a different approach may be advisable.

Of course, latching is not really necessary for this functionality. Separate OTE instructions with parallel corresponding XIC on the input side of the requested logic would work similarly.

I agree that it is a red flag whenever a find-all or cross-reference turns up multiple destructive OTL/OTU references for a single address, unless they are unbalanced (i.e., many OTL with a couple OTU, or vice-versa). A large number of OTL/OTU on the same bit is probably trouble, and avoidable. Twenty-something is extreme.
 
That statement is totally incorrect. If bit A and B are both true, then the latched/unlatched bit will be toggling on and off. Latched ON when the rung with the OTL is scanned, then unlatched when the rung with the OTU is scanned. Between them, the output bit will most certainly be ON !

But isnt the table storing the bits, only updated at end of scan?
So that if the bit is switched on and off in the same scan, it's value never changes in the register?
 
The Logix5000 family of controllers utilize an asynchronous I/O update. The I/O is updated at the requested packet interval, irrelevant of scan. It's not like the traditional read/scan/update you might be used to.
 
But isnt the table storing the bits, only updated at end of scan?
So that if the bit is switched on and off in the same scan, it's value never changes in the register?


There was never any mention that the "output" bit in the OP was a physical output, or an intermediate output.


Regardless of that, the "output" bit on the rung will be going on and off at scan speed if both A and B are true.


If the "output" bit on the rung is a physical output, then as stated above, with asynchronous I/O in Logix5000 systems, the I/O can be updated anywhere in the logic scan, so it could easily be going off periodically, depending on when the I/O update occurs.
 

Similar Topics

I'd like to get some feedback on the use of latching/unlatching relays. (Something I've never used in my limited programming experience.) I've...
Replies
15
Views
4,812
Hello everyone. I'm new to TwinCat 2 and was wondering if someone can tell me the AB equivalent of a TwinCat Latch and Unlatch? Also, is the...
Replies
5
Views
2,314
Hello again, everyone. Could anyone help me understand the best way to handle state transitions in ladder logic programs with Studio 5000? I...
Replies
9
Views
3,192
Nubee question on latching and unlatching relays I have a customer with a Data center configured like below: What I am trying to do is: If...
Replies
1
Views
2,780
I am having a problem with unlatching bits locking up. This on a SLC 500 series 5/04 processor.This is not happening all the time. I was wondering...
Replies
2
Views
2,781
Back
Top Bottom