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

Mike

You are wrong!

I have in front of me DL05 I just wrote one line code to see if the output go on when the power came back,and it dos.
This is serious stuff,I gusse you do no understand the point.
The option that things might start after power go on with out any warning,It might happen after years of proper work.
The default should be with out retentive relays.
 
Arik,

I beg to differ..

I use latching relays for the car & hall calls. I place them in a non-retenitave range. They go off when the power is cycled.

I also use latching relays to retain the last status of the smoke detectors. The smoke detectors set relays that are placed in a retneitave range. The status remains when the power is cycled.

Check you retenitiave range settings..on your DL-05.

Additionally, count to ten before restoring power to your DL-05.

Mike
 
I'm pretty sure that I've used a different PLC type that had the retentive and non-retentive memory areas too

From what I remember of the last project I did with a GE fanuc(it's been 3 years), there were some options that let you select whether or not certain items were retentive.
 
In GE Fanuc, individual bits can be declared as either retentive or non-retentive. Default is non-retentive.

Back in the days of Logicmaster software, you used a retentive coil
-(M)- or a retentive Latch -(SM)- instruction when you wanted retention. I was sorry to see that when they came out with VersaPro, they did away with the special retentive instruction in favor a variable declaration. To make matters worse, in VersaPro, the default declaration is retentive! To their credit, when they came out with Proficy ME, they made the default declaration non-retentive.
 
Ummm, maybe RTFM?

Let's see...
  • There are default retentive ranges in AD, which can be changed
  • Steve said that you have to pick what is retentive in GE
  • With AB, the default is EVERYTHING is retentive (at least in the ML processors)
  • With other brands, specific retentive ranges are preset
Whether or not it's clearly started and/or easily found in the manual, It up to the programmer to learn and understand how retentive bits/words/etc. function in each brand they choose to use.

Think of this just like understanding what buts/words/etc. are named in each specific brand (I, M, C, X, Q, %R, D, V, etc., etc.). There are no standards here either.

Personally, I prefer the ability to choose what is/is not retentive.

beerchug

-Eric

P.S. Many thanks to Ron for starting this topic, and the excellent explanation (as usual)... (y)
 
Mike
"In the world of DirectSoft, retenitave memory is memory who's status is retained through a power cycle. If your using retenitave memory for your application then you want to install a battery in the CPU"

I never installed any battery in my PLC its out of the box.
The DirectLogic defaults is the problem .

Before year or so one of my customers force me to use GE Versa Max.
The program was fine.
I never understand why the relays keep there position when power go off.
I never have this problem with LM90.
Then I realized the Ms come retentive by default.
I spend hours to get that.
 
Arik,

Most AD PLCs have a "super cap" that will retain memory for a few days or more without power, but if you turn off the machine for like a month or so you'll need the battery. However all bits that are NOT configured as retenitave will be reset no matter.

Additionally the NVram area, (DL-06 V7400-7577) is actually a EEPROM. With a mirror image in the RAM. So if you use the Move instruction, or DirectSoft, or HMI to wite to this area the value would be kept indefinatly with out the battery. When the CPU powers up the EEPROM will be imaged to the RAM. However, if you just OUT to V7400-7577 then the data will be only placed in the RAM mirror image, and on the next power cycle it will be overwritten by the data in the corresponding EEPROM.

Click here for more info in NV ram: http://support.automationdirect.com/docs/nonvolatilememory.pdf

VERY IMPORTANT NOTE:

You can only write to the EEPROM so many times. Like maybe 100,000. So do not use the move instruction in the main body of the program. Always place it in a subroutine that will only be used for setup or configuration purposes.

Another Note: The program code is stored in EEPROM and there for is not subject to any of the above.
 
Last edited:
Mike

I think you did not got what Ron saeid about the safety.
and the option to mistake.
Just think how Omron avoid that by calling the retentive area HR
not in IR area.
When you see HR you know its retentive coil.
The inputs and outputs are not in the DM area so the programer canot make mistake and use them for stoting data or calculation.
DirectSoft use V for all.So the chance to make a mistake is higher.
With DirectSoft you dont have any warning that a certain coil is retentive.

Are you in your office? I will give you a call later.let me know if you free.
 
ArikBY said:
Mike

DirectSoft use V for all.So the chance to make a mistake is higher.
With DirectSoft you dont have any warning that a certain coil is retentive.

Yea, your correct!! Thats why I posted the info on the AD stuff. I cut my teeth on Omron so I'm somewhat familliar, but it's been a long time.
 
Arik-
I think you are missing what Mike is trying to say. I believe Mike agrees that misuse of retentive ranges is a bad thing. I think his position is that the plc should not be able to hurt someone no matter what it does. Based on his background I can see his point. You don't want a screwwed up plc to drop 10 people 5 stories to their death. Some hardware (or at least redundant) system has to be in place to prevent this. So, while you may break the machine or some amount of product around it you won't hurt anyone if the machie goes crazy, assuming the hardware/structure is designed 'right'.

Now, 'right' is a bit tough to define. To fully capture the spirit that a plc can't hurt you may make the machine or process impossible to operate. This is that gray area where the plc 'might' need to be considered 'safe' or 'unsafe'.

Keith
 
Keith

Maybe I didnot clear my self well.
In short words.The way the retentive memory of AD PLCs design is dangerous.
The default of the retentive memory is dangerous.
The mix of every thing under The V memory is dangerous.
No warning for retentive coil.
with battery or without.
This way of design demand extra caution from as the programmers.
I think with all the respect to KOYO that is major lack.
I think they should at least change the retentive C memorey defaults.

Do you agree?
 
ArikBY said:
The way the retentive memory of AD PLCs design is dangerous.
The default of the retentive memory is dangerous.
The mix of every thing under The V memory is dangerous.
No warning for retentive coil.
with battery or without.
This way of design demand extra caution from as the programmers.
I think with all the respect to KOYO that is major lack.
I think they should at least change the retentive C memorey defaults.

Do you agree?

Arik, using the word "dangerous" to me means that somebody could get hurt. In some of my prevous posts on this thread I voiced my opinion about system design, (hardwaire) so that PLC code could not cause harm.

However.. I do agree with you that AD seriously lacks in addressing this issue in a way to warn you about unexpected results . In my opinion they should place a note, on the page explaining the SET/RST instructions, refering you to the section on retenitave memory.

Mike

P.S. I'll tell you that I found out about this becaue I had expieranced ...unexpected results.... :rolleyes:
 
Last edited:
I'm more in Mike's camp on this one. I think this is a discussion in semantics. I consider something dangerous only if it will hurt someone. High concentration hydrochloric acid is dangerous. If you make a mistake you WILL get hurt. A plc is dangerous only based on application. I wouldn't consider a plc and/or it's application program dangerous if it reduces a machine to a twisted pile of junk UNLESS people are directly exposed to it while it is killing itself.

That's where Mike's point comes in, and where I might disagree with Mike a bit. In an ideal world, a big cage would come down around any machine as soon as the start button is pressed and before the machine starts moving. THAT'S safe. In reality, many machines need to have people working around them while they are running. Take, for example, a paper machine calendar stack. In these cases, 'unexpected operation' turns into 'dangerous' real quick.

In either case, I think BOTH AD and Rockwell (and everyone else for that matter) should put BIG warnings in their manuals discussing how their memory structure is influenced by power cycling. There is no industry standard to this so you can't expect someone to know how it will act.

Keith
 
is there such a thing as being “TOO safe” ?

Greetings to all,

it’s good to see how much interest this thread is causing ... I’ve always found the issues involved to be interesting ... and I sincerely appreciate all of the kind comments ... but without getting too specific, I would like to insert just a friendly sideline ...

please don’t forget that many (most?) of the people reading these posts are NOT seasoned experienced programmers ... specifically, many BEGINNERS eagerly read this forum looking for hints and tips on “how-to-get-started” ... unfortunately these guys don’t have the benefit of all of the experience that you professionals have acquired over the years ... so I’d like to politely suggest that you please carefully read (and then re-read) the “safety” issues that are being raised here with a thought to the “impressionable” perspective of a reader who is just starting out ...

first of all ... we need to consider that many of our readers are not native English speakers ... what might seem to be a perfectly adequate “safety” warning to us, might not have anywhere near the same “impact” to someone who is less familiar with the language ...

another thing to consider: many of the “requirements” and “regulations” being discussed here DO have the weight of the law behind them – at least in the United States of America ... still ... if we make the assumption that “the law will always protect us” then we are also making the assumption that the law will always be obeyed ... and that, of course, is a faulty assumption ...

going one step further, I’m sure that many (if not most) of our foreign readers live and work in countries which also have similar “rules” and “regulations” and “requirements” to insure that their machines are safe too ... but then again, I’d be willing to bet that not ALL machinery EVERYwhere is equipped with enough safety features to be considered acceptably “safe” here in America ...

and of course, even machinery which was originally designed to be “safe” and was initially built to be in “full compliance” with every rule and requirement on the books is NOT guaranteed to stay that way forever ... design modifications are made by well-intentioned but inexperienced technicians ... “emergency” repairs are made which “temporarily” bypass built-in safety features ... and of course (even though it’s rare) “safety” hardware can malfunction through normal wear-and-tear and from operator abuse ...

quick analogy: a lot of what we do here is similar to teaching a teenager how to drive a car ... now we all know that the kid is ONLY interested in “gas pedal” and “steering wheel” to begin with ... but still ... as experienced and knowledgeable drivers, it is our RESPONSIBILITY to throw in a healthy dose of “brake pedal” and “turn signal” before letting the eager beginner get too far down the driveway ...

my biggest reason for this present little post is so that the rest of you guys will have a better idea of why I might seem to go “overboard” with anything and everything that I consider to be ! SAFETY ! related ... based on all of the issues that I’ve just raised, it’s my practice to lump EVERYthing that might possibly “damage-the-machine” or “damage-the-environment” or “hurt-some-person” or “cause-other-unpleasant-situations” under the catch-all umbrella of ! SAFETY ! issues ... maybe you don’t agree and I’m certainly not going to argue with you ... but just in case you’ve been wondering, that’s where I’m coming from ... so just ignore me if (in your experienced judgment) I tend to get “carried away” sometimes ...

finally ... my own personal opinion is that it is always better to err on the side of “too much” ! SAFETY ! – rather than run the risk of including “not quite enough” ... I’m quite sure that no one really wants to debate that point ...

and so ... party on ...
 
Last edited:
Good thread Ron

We, the engineers at Delta, have been following this thread because it high lights some of the differences in implementation of latches or set coils all in one thread. It is also nice to see what the users like and dislike. Finally, we have to consider what it takes internally to implement either scheme.

I like Keith's suggestion about the warning. It seems that either implementation will work if one knows how the latches or sets are implemented.
 

Similar Topics

Hi, I have a ControlLogix system with 1756-IF16 analogue inputs. I can't scale the inputs at the card as there is a requirement to facilitate...
Replies
14
Views
367
Dear community, I am trying to find a tool for Allen-Bradley PLCs similar to SiVArch for Siemens PLCs to automatically generate faceplates and...
Replies
0
Views
93
Hi everyone, new to forum. Since very long time i having issue with 1734-AENT module, after some period of time its keep stuck in error (simmilar...
Replies
16
Views
623
Hello, I am new here. I am trying to find good places to sell some surplus items that I have that isnt through ebay. Does anyone have any sources...
Replies
6
Views
441
Hi all, installed on chassis A17 an A/I from Allen-Bradley , problem is what ever I do , all channels are sticked on value 39.9 and cannot change...
Replies
1
Views
145
Back
Top Bottom