Allen-Bradley “Latches” vs. Direct Logic “Sets” ... round 1 ...

[msinclair]

Here is my personal take on this:

The PLC should be programmed as though it was THE safety device. All coding (in this specific discussion sets/resets) should be done as though there were no "real" safety devices in the field.

The "real" safety devices MUST be there as Mike says, but can fail and/or be over-ridden like Ron said. It doesn't take too many "well intentioned fixes" before one of the "SAFETY" controls is compromised ("Real" OR "PLC"). With that in mind - the more redundancy the better!

PLC's should ALWAYS be programmed for "SAFE" operation.

Marc

 

[elevmike]

Here is my personal take on this:

The PLC should be programmed as though it was THE safety device. All coding (in this specific discussion sets/resets) should be done as though there were no "real" safety devices in the field.

The "real" safety devices MUST be there as Mike says, but can fail and/or be over-ridden like Ron said. It doesn't take too many "well intentioned fixes" before one of the "SAFETY" controls is compromised ("Real" OR "PLC"). With that in mind - the more redundancy the better!

PLC's should ALWAYS be programmed for "SAFE" operation.

Marc

Ok Mark, I'll go along with that...

 

[mellis]

Hello,

I've been monitoring this forum for several months but haven't participated in a discussion yet.

I just wanted to clarify a point about exactly how the retentive vs. non-retentive coils work in AB plcs. As Eric pointed out, all memory is retentive in AB plcs. The difference between a normal coil (OTE) and a latched coil (OTL & OTU) doesn't depend on the type of memory involved, it is determined by the prescan actions for those instructions. If you assign an internal bit to an OTE instruction, it is cleared on prescan. If you assign an internal bit to an OTL instruction, it is not cleared on prescan.

The point is that for AB plcs, prescan actions are very important to understanding behavior when power is cycled.

 

[msinclair]

Mellis,

Correct. For anyone interested, have a look HERE to see how prescan works in certain AB processors.

Marc

 

[Ron Beaufort]

Greetings mellis,

and welcome to the forum ... you correctly said:

I just wanted to clarify a point about exactly how the retentive vs. non-retentive coils work in AB plcs. As Eric pointed out, all memory is retentive in AB plcs. The difference between a normal coil (OTE) and a latched coil (OTL & OTU) doesn't depend on the type of memory involved, it is determined by the prescan actions for those instructions.

perfect ... absolutely correct ...

you also said:

If you assign an internal bit to an OTE instruction, it is cleared on prescan.

perfect ... absolutely correct ...

you also said:

If you assign an internal bit to an OTL instruction, it is not cleared on prescan.

perfect ... absolutely correct ... in the context of this discussion ... but ... where this statement gets tricky is when you assign !BOTH! an OTE and an OTL ... then the statement becomes a trifle ambiguous ...

question: what happens when we assign an OTE and an OTL to the same bit? ... answer: the OTE prevails ... specifically, the bit will be cleared to an OFF condition on prescan ... but let’s go ahead and play hardball ... what if we stick the OTE way back in an “unused” subroutine that will never be scanned? ...

[attachment]

here we have what I personally call a “stealth OTE” ... this little “gotcha” bug usually pops up when a programmer decides to take a piece of “I-won’t-need-this-stuff-anymore” code and stores it away in an unused subroutine file ... the basic idea is that if he ever DOES need the code again, he can just copy-and-paste it right back into the active part of the program ... usually the intention is also to “clean-this-junk-out-someday” once the existing program has been working satisfactorily for awhile ...

the fact is, if a prescan DOES come along, then the desired “latched-on” effect in the “active” program will FAIL to bring the output back on again ... because the Allen-Bradley prescan routine executes ALL of the rungs in the program as false ... (and here’s the secret handshake) EVEN rungs in “UNUSED” subroutine files ... oops! ... and so the sneaky little “stealth” OTE – in the “unused” subroutine file – DOES get USED after all ... true, it’s only “used” once during the prescan ... but that’s enough to bring the desired “latched-on” construction crashing to its knees ...

finally ... to mellis ... PLEASE don’t think that I’m trying to run you off after your first post to the forum ... your post was extremely insightful and TOTALLY ACCURATE in the context of the discussion at hand ... thank you for posting it ... but everyone here knows that I delight in finding these little “gee-I-never-really-thought-about-that” types of things and bringing them up for discussion ... it’s just a part of the magic that is me ...

PLEASE come back ... and visit and contribute often ... I’ve got a hunch that you can add a LOT to our discussions ... and incidentally, are you the same "maellis" on the Rockwell forum? ...

 

[mellis]

Hi Ron,

I'm in 100% agreement with your comments. There is a lot of potential for gotchas in the prescan.

Yes, I am maellis on the rockwell forum.

 

[David_Emmerich]

Hi Ron et all, great thread, came at just the right time to answer a nagging question I had in a new program..now I will be using a different approach to some potentily troublesome latches...thanks for the info.

David

 

[koliliko]

I am looking for free interactive ladder logic on internet.could help me out

 

[akreel]

This is an old thread, but since it's been bumped...

It seems to me that a GOOD programmer should understand retentive vs. non-retentive memory (or battery-backed vs. "unbacked"(???)). He/she should be anticipating a power failure at some point, and understand that RAM looses track of itself after a power cycle. Anyone who uses a computer (an important PLC programming tool) should notice, even if it's a subconscious observation (in the beer-damaged parts of the brain), that Windows does not restart where you leave off if the computer gets a hard reset. How intuitive do you need to be, then, to think that maybe a PLC suffers from the same problem.

I think the issue(s) here are training, testing, and experience more than anything else. You SHOULD test what happens when the PLC loses power. In which case, you'll be fixing the "problem" if you understand the issue, or calling tech support if you don't.

AK