Sign in to follow this  
Followers 0
g1vputhran

Retentive bits in SLC 500

9 posts in this topic

Hi thr, In one of my process i have to continue the process from where it left of after a power failure/interruption so i need to retain bits states inside the SLC 5/05 PLc. Can it be Done in SLC-500? If yes then How? it will be of gr8 help if anybody tells me how to accomplish this, waiting for a positive reply from all plc experts Regards G1(JEEVAN)

Share this post


Link to post
Share on other sites
Look in to the latch bits and here are some links on this topic. Enjoy the reading. http://www.plctalk.net/qanda/showthread.ph...highlight=latch http://www.plctalk.net/qanda/showthread.ph...70568#post70568 Bob O.

Share this post


Link to post
Share on other sites
As far as I'm aware all data memory in the SLC500 range is retentive.

Share this post


Link to post
Share on other sites
I am not an expert and I just proved that. I always thougth that a bianary bit would drop out on a power cycle so I just now tested that because of the last post and Spedly is correct at least in what I tested. Sorry for the bad advice, Bob

Share this post


Link to post
Share on other sites
no need to apologize, Bob ... the advice that you gave was perfectly on target ... what makes you think that it was wrong? ... if you're confused, just give us some specific details of the "test" you just made ... we'll be glad to point out any "deeper meaning" behind the results ... in the meantime, I'd say "relax" ... you hit the nail right on the head ... best regards, Ron just as a suggestion, try this ... put the rungs shown below in an "unscanned" ladder file ... specifically, do NOT include a JSR to jump to this subroutine file ... now manually "toggle" the bits ON ... they will stay ON ... now cycle power to the processor and see what happens when the power comes back up ... any questions? ... and just to keep things straight, Spedley is also correct ... with an Allen-Bradley the DATA itself is retentive ... but the type of INSTRUCTION that is used to control the data might make the data "drop out" when the processor is power cycled ... note that the "input" data (specifically, addresses that start with "I") might not appear to be "retentive" - because the processor usually refreshes the input data table with each scan cycle ...

Share this post


Link to post
Share on other sites
Is this deliberate behaviour or a bug?

Share this post


Link to post
Share on other sites
Greetings Spedley, the behavior is deliberate ... Allen-Bradley executes a one-time "prescan" routine for safety reasons every time the processor first goes into the "run" mode ... this will happen on a processor power cycle ... or if you just switch from "program" mode to "run" mode ... there are several functions of the “prescan” ... the part that we're interested in for this discussion revolves around this basic rule: on “prescan”, the processor executes (just once) ALL of the rungs in the program as if they were false ... EVEN rungs located in "uncalled" subroutines are executed during "prescan" ... so when the OTE is executed "false" during "prescan", the OTE writes a zero into the bit/box ... this turns the bit OFF ... note that this is normal operation for an OTE which is executed as “false” ... but when the OTU is executed "false" during "prescan", the OTU does NOTHING ... this leaves the bit in its current ON state ... note that this is normal operation for an OTU which is executed as “false” ... the point of all of this (as it pertains to the discussion at hand) is that both of the bits (B3/14 and B3/15) could be regarded as “retentive” ... specifically, the bits themselves (the ON/OFF “boxes” in the processor’s memory) will “retain” their ON/OFF status after a processor power cycle ... BUT ... the “instructions” (OTE and OTU) which control those bits, can give us either “retentive” or “non-retentive” control ... it depends on which types of instructions we choose to use in our program ... and for those who might be wondering ... note that the "prescan" happens BEFORE the S:1/15 "first scan" bit comes into play ...

Share this post


Link to post
Share on other sites
You know what ... you're quite right, I hadn't actually thought about that until now but I have seen that behaviour. ... so using SOR OSR B3/1 OTE B3/0 EOR then B3/0 is actually a "first scan" bit (I think I used this many years ago when I was learning)

Share this post


Link to post
Share on other sites
no ... not exactly ... the problem is that B3/0 will fire ONCE - and ONLY once - the very first time you run the program ... after that, B3/0 will always be OFF ... in other words, it will NEVER fire again ... unless you program in some other logic to "reset" the "one shot" action ... play around with the program I've attached below ... I think that you'll find it interesting ... note to PLC-5 users: if you try a similar experiment with the ONS instruction with a PLC-5 processor, the top rung will NEVER fire ... specifically, N7:0 will stay at "0" ... this is because the PLC-5 automatically marks the ONS as "fired" during the "prescan" ... but with the SLC-500 processors, the OSR is NOT marked "fired" during "prescan" ... best regards, Ron

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0