latch/unlatch

hello, all

I have a question about latches and unlatches. I've encountered a line of code that had a latch and two unlatches that follow it (L)-(U)-(U). My question is how would the last unlatch ever get unlatched.

Thanks!

reinhart said:

hello, all

I have a question about latches and unlatches. I've encountered a line of code that had a latch and two unlatches that follow it (L)-(U)-(U). My question is how would the last unlatch ever get unlatched.

Thanks!

Click to expand...

Which software program did you see this in? Without this information its dificult to respond to your question.

There are probably two different sets of conditions under which the Unlatching should occur.

For example, in my code the sequence may have conditions to latch a state then conditions (the starting of the next state) when the state should be unlatched. E.g 'latch state 3', 'unlatch state 2'.

In another area of code (usually fairly close I may have a start-up (or 'first scan') condition to latch or unlatch states as needed.

So the code in front of the latch or unlatch probably holds the answer.

All three are likely using different tags. When the rung goes true, turn on one tag and turn off two other tags.

OG

Assuming you are referring to RSLogix 5000 software...

You don't seem to be questioning the fact that more than one output instruction is used on the same rung, so hopefully you are happy enough with that feature on this platform?

A lot depends on what tags are addressed to those instructions. There could be three separate tag addresses, or one tag address used on two of the instructions, or the same tag address for all three instructions. The latter being unlikely, but possible. In theory, this arrangement should be using three separate tag addresses or else the shared tag address value would be written to twice in the same rung execution.

Example 1:
If the instructions are using three separate tag addresses, then they will all simply execute once the rung-condition-in to the OTL is TRUE.

With the controller in RUN Mode, and the scan at this rung...

When the rung-condition-in to the OTL instruction is TRUE, the OTL will write a value of 1 to its tag bit address and then set its rung-condition-out. This sets the rung-condition-in TRUE to the first OTU instruction.

The first OTU instruction will write a value of 0 to its tag bit address and then set its rung-condition-out. This sets the rung-condition-in to the second OTU instruction TRUE.

The rung-condition-in to the second OTU instruction is TRUE, the OTU will write a value of 0 to its tag address and then set its rung-condition-out.

The rung is then finished being scanned.


Example 2:
If the tag address used for the OTL is the same tag address used for the second OTU. The first OTU tag address is different to tag address assigned to the OTL and second OTU.

The OTL writes a value of 1 to its tag address.
The first OTU writes a value of 0 to its tag address.
The second OTU writes a value of 0 to its tag address.

The second OTU has now written a value of 0 to the tag address that the OTL had written a value of 1, all on the same rung execution.

Example 3:
All three instructions use the same tag address.

The OTL writes a value of 1 to the tag address.
The first OTU then writes a value of 0 to the same tag address.
The second OTU again writes a value of 0 to the same tag address.

Each instruction is overwriting the value that the previous instruction had written, all to the same tag address. So the order of placement of the output instructions determines the final value of the tag address at End-Of-Rung (EOR).

Rule of thumb...

Output type instructions, such as OTE, OTL, OTU, in series on the same rung, will all execute. What the outcome of this will be, is up to the programmer!

Regards,
George

Geospark said:

Rule of thumb...

Output type instructions, such as OTE, OTL, OTU, in series on the same rung, will all execute. What the outcome of this will be, is up to the programmer!

Regards,
George

Click to expand...

Yup.

Reading between the lines, I can see how it would almost make sense for an output instruction that turns off a bit and it is no longer green, to also seem to need to branch out to the next rung...(this mistake is more likely to be made coming from a high level programming background).

It looks like it stopped cause it ain't green now...doh...

Output instructions don't get to decide what happens next, they just do their thing and pass the baton forward.

This is a good reason to edit that and waste a few branch instructions. Visually take the challenge away from the brain which is automatically following truth through very similar looking input instructions. I have done this myself for the same reason, twice I caught myself incorrectly analyzing the logic due to some series outputs fooling my tired eyes, so I just changed them. It had no effect on the logic solving, but saved me from chasing wild geese all over the ladder.

Just a thought, in nature the shortest/easiest/most successful route is the way to succeed. Apply this to engineering you will not go far wrong.

Geospark hit the nail squarely on the head.

To put it another way, each and every instruction that the processor scans knows only one thing, and that is whether the rung is currently TRUE or FALSE.

All instructions do not know what has preceded them, nor care about what succeeds them. All they do is act on the data they receive (the Rung-Logic-Continuity, posh name for true or false), and, if they are a "conditional" instruction they either maintain Rung-Logic-Continuity as true, or they set is as false. non-conditional instructions, those that just "do something", don't change the Rung-Logic-Continuity.

When examining ladder logic, that's all you need to know for fault-finding - is the "Enable-In" for an instruction true or false at the time it is scanned, and you cannot always rely on the green highlighting of "true" instructions, the bit may only be true for a few microseconds, and it will be rare to see it highlighted green on the screen, but it is certainly possible.

OkiePC said:

...This is a good reason to edit that and waste a few branch instructions. Visually take the challenge away from the brain which is automatically following truth through very similar looking input instructions...

Click to expand...

Paul, now you've gone and torn it!

The reason I said "hopefully" to the OP regarding their understanding of the use of multiple output instructions on the same rung, was me being hopeful that they didn't need to know more about why it's used, only how it works.

I'm sure we all remember what happened the last time the "multiple OTE on the same rung" floodgate was opened...

I'm no Neo (I'm Geo), but the way you need to look at the code is similar to the Matrix. The programming GUI is similar to the Construct. It is merely a human readable facade which allows us to create an ordered structure for our code. How the code is actually executing is decipherable through the GUI, but only once you understand the execution parameters and instruction set for the architecture you are looking at. For instance, each instruction has an execution time for its rung-condition-in and rung-condition-out operations, separate to the execution of it's primary operation. Similarly, rung start/end and branch start/next/end instructions have their individual execution times.

Allowing multiple output instruction on one rung reduces the number of instructions required. This is more efficient execution time-wise i.e. reduced scan time. This is the primary reason for this feature.

Whether you like it or not is another debate, but if you don't like it, and the scan time overhead is not an issue, then by all means available, structure the output instructions to your liking.

If you are using this feature, I always recommend to use descriptive rung comments to explain what the rung is supposed to achieve.

G.

"Why oh why didn't I take the BLUE pill?"

OG

Geospark said:

Paul, now you've gone and torn it!

Click to expand...

My specialty...

Geospark said:

I'm sure we all remember what happened the last time the "multiple OTE on the same rung" floodgate was opened...

Click to expand...

I must have missed that one.

Geospark said:

I'm no Neo (I'm Geo), but the way you need to look at the code is similar to the Matrix. The programming GUI is similar to the Construct. It is merely a human readable facade which allows us to create an ordered structure for our code. How the code is actually executing is decipherable through the GUI, but only once you understand the execution parameters and instruction set for the architecture you are looking at. For instance, each instruction has an execution time for its rung-condition-in and rung-condition-out operations, separate to the execution of it's primary operation. Similarly, rung start/end and branch start/next/end instructions have their individual execution times.

Allowing multiple output instruction on one rung reduces the number of instructions required. This is more efficient execution time-wise i.e. reduced scan time. This is the primary reason for this feature.

Whether you like it or not is another debate, but if you don't like it, and the scan time overhead is not an issue, then by all means available, structure the output instructions to your liking.

If you are using this feature, I always recommend to use descriptive rung comments to explain what the rung is supposed to achieve.

G.

Click to expand...

Right, right right, I get all that, but my dadgummed brain is hardwired to think it is looking at lines that conduct green truth ... I like the option to use series output instructions, sometimes I decide how to arrange them solely to present the most compact and organized looking rung on screen. Rarely are a few branches of any concern at all for execution efficiency. If I am that tight on system capability, somebody fouled up the design...

I'll shut up and go find another pot to stir now

OkiePC said:

...I must have missed that one...

Click to expand...

Paul,

You most certainly did not...

In the thread I was referring to, you were actually defending the use of multiple output instructions on the same rung. So you certainly do like to stir things up. You just reverse the direction of stirring!

OTE in middle of rung

However, you're right in both cases I feel. That's the beauty with this feature, and something I think most were/are overlooking. You have a choice...

If you want to structure the logic in a more classical way, then for multiple output instructions with the same logical preconditions, use branching, or use separate rungs.

If you want to consolidate multiple output instructions that are preconditioned by the same logic, then series them on the same rung.

For both these methods, I would only advise using them within reason, or else it can become excessively long winded looking.

If you have an exceptionally large amount of output instructions to execute from the same logical pre-condition, then I would advise looking at using other methods besides individual output instructions.

Example:
You have a DINT array mapped to 32 physical outputs. Under certain preconditions, let's say an initialization, you want to reset the 32 physical output addresses to 0, or OFF.

You could, for instance here, use a CLR instruction to write zero's to all of the DINT's bit addresses. One logical instruction replaces many Boolean instructions.

Using the multiple OTU on one rung method here could, to some, look cumbersome or messy with several rung wraps. This is what can, for some, give this method a bad name. Overuse of Boolean instructions, whether input or output, on one rung can, for some, look ill thought out when there are simpler ways to handle relatively large amounts of contiguous data. Of course, the trick is to make the data contiguous in the first place. That's where the real planning comes in.

This also demonstrates another good reason to buffer, or map your I/O, as you can arrange blocks of scattered, but related I/O, contiguously buffer tag-wise, for reasons such as the above. It's not always possible, and some rungs will have scattered tag references which cannot always avoid multiple Boolean instructions. But where you can, I feel it's a good practice to get in to.

Regards,
George

Geospark said:

Paul,

You most certainly did not...

In the thread I was referring to, you were actually defending the use of multiple output instructions on the same rung. So you certainly do like to stir things up. You just reverse the direction of stirring!

Click to expand...

Dude . . .
That was 2013.
I have slept like 3 or 4 times since then.

I went to my youngest son's Halloween themed wedding last night dressed as Tony Romo with a football duct taped to my hand and pushing a walker. I tried to find some tongue depressors, but they don't seem to sell those any more. I was going to write on them with a Sharpie the dates for all the upcoming games in which he might choke. Yes, I am a stirrer.