Help for Latch/Unlatch and toggled bit in RSLogix 5000

colorofwind

Lifetime Supporting Member
Join Date
Jun 2012
Location
Edmonton, Alberta
Posts
38
Hello everyone, I have two questions that confuse me.

1. In the ladder logic, I found some switches that cannot toggle bit when the program is online. But I can toggle it offline, why is that?

2. My program structure is like this:

In the main program,

------|switch A|---------------(coil enabled)-----

------------------------------------ JSR------------

In the subroutine that we jump to,

------|coil enabled|----------------(latch output)---

...same as above, just different output to latch

...

When I force switch A to be on(cannot toggle its bit), the latch outputs turn on and off like crazy. Did I do something wrong?

Please share your thoughts with me, thanks!
 
Last edited:
Some has talked about avoid using latch/unlatch in this forum. The reason I use latches in the subroutine(means a running mode) is because we want to turn on/off some valves. And even if the switch is off, the valves will remain their last states. If I use normal output, that means every valve, including those we don't care their current states, will be turned off.
 
Last edited:
Yes, you most likely have done something wrong, but without seeing all of the application logic I can't say for sure.

What I can say is that you need to get a grasp of the idea that there is no such thing as a "latch output", as you call it.

PLCs work with memory locations, and two types of instructions - those that inspect the memory locations to see if the rung evaluates as true, and those that can change the memory locations depending on the true/false state of the rung as it is scanned.

So back to your problem.

You are executing a rung in a subroutine that has an OTL instruction that, if the rung is true, will "turn on" or write a "1" to the address or tag specified. And that is what appears to be happening, since the output does something when you execute the subroutine.

But you find that the output is going on and off "like crazy". If you read the help for the OTL instruction you will see that it can only turn ON the address or tag that it refers to, it can't ever turn it off.

Conclusion : there must be something else in your program that is turning it off !

There could be lots of ways this output bit is being turned off again. The usual culprits are :-

1. An OTE instruction on a rung that evaluates as false, addressing the same memory location....

2. An OTU instruction on a rung that evaluates as true, addressing the same memory location....

3. Several more possibilities I won't go into.

You now need to find what is turning this output off after your subroutine turns it on, it is time to get the tools out...

Best tool to use is the cross-reference... Right-click the tag that is attached to your OTL, and choose Cross-Reference.

The cross-ref window will appear,and then the first thing to do is find the column headed "Destructive", and double-click it until you see the letter Y at the top of the list.

All the entries in the cross-ref with a Y in the Destructive column can change the value of the tag, one of those entries will be your OTL, ignore that, and go and investigate the others, you will very quickly find what is turning your output off.

It is now up to you to re-design your logic to fix this problem.
 
1. In the ladder logic, I found some switches that cannot toggle bit when the program is online. But I can toggle it offline, why is that?
I'm guessing that the 'switches' are physical inputs? If so, then that's why you can't toggle them while online. They get overwritten with the current state of the input on the next scan. As you found out, the only way to manually override them is to FORCE them on or off.

Regarding your second question... If the logic is exactly as you have drawn, the 'latch' (OTL, not OTE), once set, should remain on (forever). You might want to post your actual program.

IMO, based on your other posts, I think you're heading in the wrong direction by trying to use conditional subroutines for this application. Might want to investigate one-shots.

🍻

-Eric
 
Is it possible that you are using the same address for more than (1) output? That's what it sounds like to me...
 
Some has talked about avoid using latch/unlatch in this forum.
You are having all these problems, and you still can't see why you should avoid using TOO MANY latch and unlatch instructions?

The advantage of the simple OTE is that, used correctly, it only occurs one time (for each memory bit) in the program, and the location of the action is easily found. As you are seeing, an Unlatch can be anywhere, but still effects what you did in a remote subroutine. Now you will have to find all the Latches and all the Unlatches for that one bit, and try to figure out when, where, and if they are ALL correct. What a mess!

A bushel basket full of Latches and Unlatches does not make up for the lack of clear thinking and concise logic.

Usually beginners who cannot see how to avoid latch/unlatch over-use - cannot make the latch method work either! Understanding the logic rings a bell with clear and true tones.
 
Last edited:
You made me curious with that Daba. What are some others you are thinking of? You covered the meat and potatos.

This might be a god list to have from everyone for future reference maybe?

Copy instructions, indirect references, values modifications at the world level, assignments to tags, etc.
 
You made me curious with that Daba. What are some others you are thinking of? You covered the meat and potatos.

This might be a god list to have from everyone for future reference maybe?

DamianInRochester got in before I did, although I think he meant "word level" when he said "values modifications at the world level".

To make a list of all instructions that could change the state of an "output" would take a while, and it depends on what the "output" is..

The OP used the word "output", I don't know whether he meant a physical output, an internal BOOL tag he called an "output" (because he attached it to an OTL), or a BOOL element of a larger tag)..

OTE, OTL, OTU, and ONS are the only instructions that can change the state of a unique BOOL tag, (if we ignore the "pre-scan" that will reset the BOOL tag when attached to an OTE instruction).

When it's not a unique BOOL tag, then there are many instructions that can change the state of a single bit (BOOL) of the tag. Here's a few.....

MOV
CLR
FLL
COP
CPS
ADD
SUB
MUL
DIV
CPT
FAL
SQR
LN
LOG
XPY
BSL
BSR
FFL
FFU
LFL
LFU

.... and there's many, many more, I got bored going through the instructions that have a "Dest" argument. All of them can change the state of single bits that could be used elsewhere in OTE, OTL, or OTU instructions.

And let us not forget that the memory location can also be changed by MSG instructions, reading data into the tag database, or by another machine writing into the tag database.
 
Yes, you most likely have done something wrong, but without seeing all of the application logic I can't say for sure.

What I can say is that you need to get a grasp of the idea that there is no such thing as a "latch output", as you call it.

PLCs work with memory locations, and two types of instructions - those that inspect the memory locations to see if the rung evaluates as true, and those that can change the memory locations depending on the true/false state of the rung as it is scanned.

So back to your problem.

You are executing a rung in a subroutine that has an OTL instruction that, if the rung is true, will "turn on" or write a "1" to the address or tag specified. And that is what appears to be happening, since the output does something when you execute the subroutine.

But you find that the output is going on and off "like crazy". If you read the help for the OTL instruction you will see that it can only turn ON the address or tag that it refers to, it can't ever turn it off.

Conclusion : there must be something else in your program that is turning it off !

There could be lots of ways this output bit is being turned off again. The usual culprits are :-

1. An OTE instruction on a rung that evaluates as false, addressing the same memory location....

2. An OTU instruction on a rung that evaluates as true, addressing the same memory location....

3. Several more possibilities I won't go into.

You now need to find what is turning this output off after your subroutine turns it on, it is time to get the tools out...

Best tool to use is the cross-reference... Right-click the tag that is attached to your OTL, and choose Cross-Reference.

The cross-ref window will appear,and then the first thing to do is find the column headed "Destructive", and double-click it until you see the letter Y at the top of the list.

All the entries in the cross-ref with a Y in the Destructive column can change the value of the tag, one of those entries will be your OTL, ignore that, and go and investigate the others, you will very quickly find what is turning your output off.

It is now up to you to re-design your logic to fix this problem.

Daba, thank you so much for the detailed explanation. Followed your instruction, I found there's another task that turns off the OTE outputs that are supposed to keep energized by the latch switch. Well to be honest, I didn't know OTE could turn off OTL before. I thought only OTU could. anyway, the program works good after I inhibited that task. You saved my job :D!!!
 
You are having all these problems, and you still can't see why you should avoid using TOO MANY latch and unlatch instructions?

The advantage of the simple OTE is that, used correctly, it only occurs one time (for each memory bit) in the program, and the location of the action is easily found. As you are seeing, an Unlatch can be anywhere, but still effects what you did in a remote subroutine. Now you will have to find all the Latches and all the Unlatches for that one bit, and try to figure out when, where, and if they are ALL correct. What a mess!

A bushel basket full of Latches and Unlatches does not make up for the lack of clear thinking and concise logic.

Usually beginners who cannot see how to avoid latch/unlatch over-use - cannot make the latch method work either! Understanding the logic rings a bell with clear and true tones.

As you can tell, in fact I am a beginner :D, who's very happy to get some feedback from this great forum as I learn programming PLC. Regarding to the Latch/Unlatch function, I did really want to avoid it. I changed to OTL/OTU from OTE because it will reflect the requirement better in my opinion. In the program, we need to select between different controlling schemes from the logic. In each scheme, we turn on and off some valves and pump. But still, there are some outputs that we want to keep their last states (don't care, but don't want to shut them down either). So unless the coil receives a OTU, it will stay in latched on even if the switch XIC is not energized.

I don't know if this is a right approach. Please share your thought, thanks!
 
I'm guessing that the 'switches' are physical inputs? If so, then that's why you can't toggle them while online. They get overwritten with the current state of the input on the next scan. As you found out, the only way to manually override them is to FORCE them on or off.

Regarding your second question... If the logic is exactly as you have drawn, the 'latch' (OTL, not OTE), once set, should remain on (forever). You might want to post your actual program.

IMO, based on your other posts, I think you're heading in the wrong direction by trying to use conditional subroutines for this application. Might want to investigate one-shots.

🍻

-Eric

Thanks Eric! Can you explain a bit more about replacing conditional subroutines by using one-shots?
 
Daba, thank you so much for the detailed explanation. Followed your instruction, I found there's another task that turns off the OTE outputs that are supposed to keep energized by the latch switch. Well to be honest, I didn't know OTE could turn off OTL before. I thought only OTU could. anyway, the program works good after I inhibited that task. You saved my job :D!!!

Your response indicates to me that you still haven't completely understood what I said.

To re-iterate : outputs are memory locations :-: OTE, OTL and OTU are instructions that can change the memory locations dependant on the logic that precedes them.

This concept is fundamental to the understanding of, and being able to write/debug, PLC logic that it is a must to get it under your belt asap.
 

Similar Topics

Hi all, my first post here, I've been lurking for a while. I'm a beginner and I hit a wall on one of my first projects I'm working on. I know it...
Replies
6
Views
2,550
I am not a novice programmer but I have never used the N7 registers the same way I would use a B3. However I am modifying a program for a customer...
Replies
17
Views
6,461
I Need to make a one touch Flip Flop ( Press On) (then Press Off) I can do it with a counter however I thaught there may be a simpler way of doing it.
Replies
1
Views
1,783
Need to set and reset latch by single touch input from several 550 touch screens and scada package. My logic seems to be evading all of my...
Replies
1
Views
5,152
Hi all, hope you are having a great day, I am in need of your help to create a AOI or program that does this kind of job: I have a IO Link...
Replies
0
Views
52
Back
Top Bottom