# A-B latching and memory retention



## Mike in Canada (Jun 27, 2010)

I'm just getting into Allen-Bradley PLCs, and my first project is a relatively big one (will probably be 3 or 4 hundred rungs when complete) on a SLC 5/01. I'm curious how the memory retention works on these units. Is it simply that the battery maintains ALL of the memory as long as the battery lasts? So you never have to think about retention for your bit variables (B3:0, etc.)?

Also, if an output is unlatched using the -(U)- instruction, can it be re-energized with a standard -( )- instruction, or do you have to latch it with -(L)-? I have some situations where I want to actively shut things off in a subroutine, and want to make sure I can turn them back on when I return from the subroutine. I could just use a null rung to turn them off, but an unlatch instruction seemed cleaner than "if false then 'output'".


----------



## electric_avenue (Aug 7, 2010)

Mike in Canada said:


> I'm just getting into Allen-Bradley PLCs, and my first project is a relatively big one (will probably be 3 or 4 hundred rungs when complete) on a SLC 5/01. I'm curious how the memory retention works on these units. Is it simply that the battery maintains ALL of the memory as long as the battery lasts? So you never have to think about retention for your bit variables (B3:0, etc.)?
> 
> Also, if an output is unlatched using the -(U)- instruction, can it be re-energized with a standard -( )- instruction, or do you have to latch it with -(L)-? I have some situations where I want to actively shut things off in a subroutine, and want to make sure I can turn them back on when I return from the subroutine. I could just use a null rung to turn them off, but an unlatch instruction seemed cleaner than "if false then 'output'".


http://www.youtube.com/watch?v=zlsJxSK8tPE


----------



## lefleuron (May 22, 2010)

Mike,

You have to be a little careful with the (L), (U) instructions in a 500.



In a 500, L and U are indeed retentive!!!! So you must be careful when using these, power comes back on and that motor (or whatever) is going to spin right up.


To keep the program clean and safe, I always use a regular OTE and a memory, power drops out, output goes off and must be restarted manually.


Only time I would feel comfortable, if after long thought, would be a deep well pump or something that absolutely must run constantly, because if it did not it would be a bigger safety hazard then a sudden automatic start.


----------



## lefleuron (May 22, 2010)

Mike,

As that you are just starting to get into it in a good sized way here is some advice.

Forget a clean looking program. It might be super nice to look at, and people may "ooh and Ahh" over it, but the guy looking at it will be a guy like me......at 3 AM. And if I cant follow your logic, it wont be happy words I will be saying.


Make it easily understandable, use a butt load of rung comments, try and keep "one shots" to a minimum, (L) and (U) can also be more difficult to follow while trouble shooting.


The hardest part of using a PLC for troubleshooting is trying to understand what the guy who wrote the program was thinking when he actually programmed it.


Here are examples of nice rung comments, and input/output statements.

Use a lot of clean, well defined sub-routines, absolute time savers.


THIS RUNG IS THE BEGINNING OF CONVEYOR 122 (if its not a SBR)

THIS IS PROX 5434 THIS IS PROX 6879 THIS IS HAND SAFETY 56


I once knew a guy who thought rung comments were a waste of time for him, what he didnt quite understand was the amount of time others had to waste trying to understand his program when they had to. 5-6 hundred rungs of logic without 5 comments, and maybe one sub-routine. Almost impossible to follow.


----------



## Jmohl (Apr 26, 2011)

Ditto what leflueron said. Latching bits can be extremely dangerous so have a care there. example being an output to a motor starter... I will latch a fault bit in with a reset button Unlatch but that's about it. Use the K.I.S.S. principle, keep in mind some poor schmuck is gonna have to try to figure out WTF you had in mind when you wrote it and at oh-dark thirty isn't the time to play guessing games with a ladder.


----------



## MDShunk (Jan 7, 2007)

And for heaven's sake, use as many small routines as possible and don't program the whole thing in the main program. Name your routines something meaningful for the next guy.


----------



## lefleuron (May 22, 2010)

MDShunk said:


> And for heaven's sake, use as many small routines as possible and don't program the whole thing in the main program. Name your routines something meaningful for the next guy.


Spot on perfect advice right there.

EDIT!

Someone help me remember here, you can have 256 (0-255) subroutines ?

That just came to me, and now its bothering me. I think the 5 had a whole lot more available, but that is going back into the foggy area of the mind. Anybody remember this?


----------



## MDShunk (Jan 7, 2007)

I like to make a routine all of its own that sets a dummy output that just has every single input in one big rung (or several rungs). Makes a convenient place to toggle or force a bit for troubleshooting. Also lets me see the status of all my inputs in one place.


----------



## Mike in Canada (Jun 27, 2010)

I hear what you all are saying about subroutines, but the problem with this particular system is that there are several 'watchdog' routines, and they need to be active all of the time watching for trouble. I have three subroutines so far, but the body of the system will be a routine that takes hours or even days to complete, so if I put it in a subroutine then I need to mirror the watchdog routines in that subroutine, which almost defeats the purpose. Maybe putting the watchdog routines in subroutines would be appropriate, but they have timers that are watching for events that must occur on a regular basis (no more than three seconds between events), and I wasn't feeling comfortable with them being able to work properly if they were being loaded and unloaded from memory.

Oh yeah... so what's the actual answer to the question of whether a bit can be activated with -()- after it's been unlatched with -(U)-?


----------



## RIVETER (Sep 26, 2009)

Mike in Canada said:


> I'm just getting into Allen-Bradley PLCs, and my first project is a relatively big one (will probably be 3 or 4 hundred rungs when complete) on a SLC 5/01. I'm curious how the memory retention works on these units. Is it simply that the battery maintains ALL of the memory as long as the battery lasts? So you never have to think about retention for your bit variables (B3:0, etc.)?
> 
> Also, if an output is unlatched using the -(U)- instruction, can it be re-energized with a standard -( )- instruction, or do you have to latch it with -(L)-? I have some situations where I want to actively shut things off in a subroutine, and want to make sure I can turn them back on when I return from the subroutine. I could just use a null rung to turn them off, but an unlatch instruction seemed cleaner than "if false then 'output'".


So, you are not really familiar with it.


----------



## lefleuron (May 22, 2010)

Mike,

I think you have confusion over a watchdog timer. Now I could be wrong here, and someone correct me if I am.


A watchdog is used to check processor condition. When you set up the processor, you will have some "total scan time"options. If the time it takes for the processor to make one complete scan of your program exceeds this value, you will fault the controller.


You could set this to some over the top value, and almost never fault. But thats a bad idea, that timer is there to protect equipment and people from a PLC that has locked up. It faults itself.

A scan is: check inputs, load inputs into image table, configure logic, load outputs into output image table, unleash outputs, start again. Those are my own words there, and not exactly correct but they will do. If the total amount of time it takes for those steps to happen exceeds your processor set time, the watchdog timer faults out. A LONG scan time is 1/2 second.

Of coarse there are other forms of watch dogs, especially in integrated systems, an "Im O.k., and a reply of Im O.K. too" kind of thing. But thats different.

It does not matter how long it takes for an output or input to be used, it never has to be. As long as a scan makes it through in the allotted time, your fine.


Now, you want to know about the (u). Any time a (U) is used to unlatch a (L), the only way to re-latch the (L) is make that line of logic true again. So you could set up an internal bit -()- to simply make the (L) true whenever you want to. But first, you must make the (U) line of logic true. Like a flip flop.

This crap is hard to make sense out of without the actual program in front of you.:blink:


One more time.
---------! 22!--------------------(33)-----
---------!33 !--------------------(L)------

---------!44 !--------------------(U)------

If 22 goes true, 33 goes true, you are latched. Now 22 goes false, 33 goes false, but your are still latched.

44 goes true, you are unlatched, even if 44 immediately goes false, you are still unlatched. You must true 22 again to re-latch.

I hope this is what you are after, I am no artist.


----------



## Mike in Canada (Jun 27, 2010)

Apparently A-B uses the term 'watchdog' for a special purpose. That wasn't what I was referring to. Okay, I'll call them... 'verification timers'. I have several events that must keep happening regularly, so I have verification timers that need to watch for them to happen, otherwise I drop the MCR and the machine stops (well, I have a bit that I call MCR, and if it goes false then the machine can't do a thing... it has nothing to do with the A-B MCR instructions, it's just 'Machine Control Ready' and that's what I'm used to calling the state of 'everything is okay, so we can do stuff'. So my timers are making sure that if the motor is running to turn a wheel then that wheel is actually turning. It's closing the loop, sort of, on a few outputs.
Anyway, these timers need to be in memory all of the time.

I suppose the question to be asked is whether subroutines are run independantly. If the PLC is running a subroutine using [JSR] then I assumed it will not run the main program again until the [RET] instruction returns it to the main program. Am I wrong? 

Also, Lefleuron, I appreciate the answers you're giving me. I really do. I seems that I'm not expressing myself properly. What I was asking is whether an unlatched bit can be made positive using -()- or whether an unlatch can only be undone by a -(L)-. In essence, look at this code:

|--]true[---------------(U)--|
|--]true[---------------(x)--|

So, the first rung unlatches bit 'x'. Now in the second rung I want to make 'x' true again, but I don't use a Latch, rather I just make it true using the non-retentive method. I just want to know if the bit will behave normally if I do this, or if the program will fail becase only a Latch can turn a bit on after an Unlatch.


----------



## Mike in Canada (Jun 27, 2010)

I did a sample program to answer my own question, and yes I can control an Unlatched bit as easily as one that hasn't been Unlatched, so that question has now been answered. The research that I have done has certainly indicated that a JSR suspends scanning of the calling routine until the called routine has activated the RET, so doing my procedures in subroutines is not looking like a clever way of doing things at the moment. Is there a way to 'include' code so that it's in a separate file but part of the main program?
This stuff is a LOT more limited than the Siemens S7-300 stuff I was working on previously. Or at least, I haven't found ways to do a lot of things that were easy on the 300's.
Using the RSEmulate software is downright *punishment* compared to the Siemens stuff. Hopefully it will get better as I get more used to it.


----------



## lefleuron (May 22, 2010)

Mike in Canada said:


> I did a sample program to answer my own question, and yes I can control an Unlatched bit as easily as one that hasn't been Unlatched, so that question has now been answered. The research that I have done has certainly indicated that a JSR suspends scanning of the calling routine until the called routine has activated the RET, so doing my procedures in subroutines is not looking like a clever way of doing things at the moment. Is there a way to 'include' code so that it's in a separate file but part of the main program?
> This stuff is a LOT more limited than the Siemens S7-300 stuff I was working on previously. Or at least, I haven't found ways to do a lot of things that were easy on the 300's.
> Using the RSEmulate software is downright *punishment* compared to the Siemens stuff. Hopefully it will get better as I get more used to it.


 
Mike,

Dont feel lost. When I first looked at the Siemans stuff after getting used to AB I just scratched my head. The AB contrologix is much closer to what you are used to.


Your MAIN routine could easily be programmed like this.



------------------------------------------(jsr, one)-----------

------------------------------------------(jsr, two)------------

------------------------------------------(jsr, three)-----------

And so on. When the program goes to a sub, and comes back on a RTN, it immediately starts the scan at the END of the last line scanned in the MAIN.

Do you follow me? Its not going to scan SUB 1 over and over, but it will go right to #2, then #3, and on down the line. When its through all the subs it will again start at the top of the main all over.


Try to avoid JMP and LBL instructions if you are worried about watchdog times. These instructions allow you to skip portions of a program, or even back way up in a program using an RTN. They are hard to follow, and waste scan time.

Again, try your best to keep this simple. Use a holding contact instead of a L or U. Avoid ONS (one shots) if you can. A little extra thought and time by you now, is going to save a lot of hassle and debugging later.


----------



## Mike in Canada (Jun 27, 2010)

lefleuron said:


> Mike,
> 
> Dont feel lost. When I first looked at the Siemans stuff after getting used to AB I just scratched my head. The AB contrologix is much closer to what you are used to.


I'll look forward to getting into RsLogix 5000, then. 




> Your MAIN routine could easily be programmed like this.
> 
> 
> 
> ...


I agree entirely. However, how is my verification timer, which is in the main program, going to run to keep watch on what it needs to watch if the subroutine runs for 12 hours? I'd have to put copies of all of my verification timers in my subroutines to make sure they get run. This is the problem - the subroutines can run for hours and hours, which means the main program won't be scanned for hours and hours, which means my verification timers won't be scanned for hours and hours. Not acceptable. I don't think I can put my verification timers in subroutines, either, because they need the timer to keep working all of the time to make sure nothing happens to the processes the timers are watching.



> Do you follow me? Its not going to scan SUB 1 over and over, but it will go right to #2, then #3, and on down the line. When its through all the subs it will again start at the top of the main all over.


I follow this perfectly. The problem is simply that I need multiple processes running at the same time, and subroutines suspend the parent process.



> Try to avoid JMP and LBL instructions if you are worried about watchdog times. These instructions allow you to skip portions of a program, or even back way up in a program using an RTN. They are hard to follow, and waste scan time.


I've used a few already to make sure the initialization routine is only run once. I suppose I could have a binary value that I set to indicate that it has been run, but how do I initialize that variable once and only once without jumps? Right now I'm using the tried-and-true:

jump to [initialize]
[top]
main program
jump to [top]
[initialize]
initialization stuff
jump to [top]

This is very old-school, but it works. If I put the initialization stuff in a subroutine then I could get rid of one label and two jumps, but I'd still need to jump.



> Again, try your best to keep this simple. Use a holding contact instead of a L or U.


I don't actually use L. I use U just to set my binary variables to zero.



> Avoid ONS (one shots) if you can. A little extra thought and time by you now, is going to save a lot of hassle and debugging later.


Why the dislike of one-shots? I use them in my verification timers to make sure that if the sensor fails in a true condition it is still detected as a fault.


----------

