set - reset

hi again.
just a philosophical question. why is normaly not recomended the use of set and reset instrctions?
i usualy take that advice, but there are some situations in wich i find it very comfortable to use these instructions.
is there really a reason?
i also hear that there are some issues in how these instructions are managed in some plc's.

the biggest issues with latch/unlatch are power faults & sub-routines. When the power faults, most outputs retain their state if you don't prepare for faults...and outputs in sub-routines retain their state when leaving the sub.

The main issue I have with them is that neophyte programmers tend to go overboard with them and use them indiscriminately all over their logic in order to solve sequencing issues.

1. Their behaviour at power-up and within conditional subroutines is different to simple OTE's.

2. If you are going to use them try to constrain their use to adjacent rungs. ie one LatchON event and one LatchOFF event right next to each other, so that the next programmer coming along after you can quickly see the nature of the structure you have created. This is just a style thing/rule I have followed for years.

I really wasn't aware that S/R are not recommended. But I suppose like any other instructions, they can cause problems when incorrectly used. But when used correctly, they can make your code much cleaner and more efficient. I can't even imagine writing code without them. And, a lot of people who think they aren't using S/Rs are probably creating the latches programmatically anyway.

And if someone can't apply a S/R correctly, then he/she just shouldn't be writing critical code anyway.

I use S/Rs bounding a group of code lines with no branching, kind of a Do While thing.
Never thought of the power fault possibility.

Will have to test that also.

Thanks,
Rod

PS, what do you use instead of S/Rs?

I'm guessing that people use relay-logic style latching instead, but they can still have the same problems with power-up. No matter what style of programming one uses, it's important to always restart in some sort of controlled, safe manner.

here is a perfect example of when NOT to use latch/unlatch!

A plant just put in a pallet strapper, There was a plblem with the straps so one of the guys flicked it over to manual and went in to fix (I know a little stupid..he should have pushed the EM stop) When he was in there he walked in front of an eye and the arm came out and hit him in the head..It moves slow so no big deal..I looked at the program and it was FULL of latched bits..So halfway thru the sequence even tho it was in man mode it was waiting for the eye to be blocked to move.. The programmer never Unlatched his bits when going from auto to hand..

I've never been against the idea of using SET/RST.

As Tom Jenkins has pointed out, over and over, and justifibly so, using SET/RST can make it harder to troubleshoot code.

However, just as any carpenter needs to know his tools and how to use them properly, so too a programmer needs to know all of the tools that are available AND how to use them properly!

My experience with programming started with Basic, Fortran, C, etc. In those languages, the use of SET/RST is more common than not.

If properly managed... the use of SET/RST can greatly simplify code.

As in all programming, one must take into consideration all possibilities and plan carefully.

There is absolutely nothing wrong with requiring that rungs be in the form of a self-latching circuit. Nor is there anything wrong with allowing SET/RST.

However, simply restricting the use of SET/RST for the purpose of forcing the code to be in the form of self-latching circuits is somewhat self-deceptive.

Simply restricting the use of SET/RST does NOT necessarily improve the quality of the program. Bad code comes in all forms... SET/RST and self-latching.

If the code is properly designed then SET/RST can be used without worry.

And yes, properly using SET/RST can really reduce the complication and the size of a program by a great deal.

Regarding Darren's comment...

I have hundreds of cases where SET bits remain SET when the operator goes from AUTO to MANUAL, or if the process goes into a Fault state. This is intentional! Under these conditions, it is really handy to KNOW what the process was doing at the time. If necessary, I can go into the code and SEE what was happening.

BTW, I never use SET on any real outputs. I do use RST in many cases (to break a self-latching seal), but never SET.

The bits remain SET until the operator goes back to AUTO. Upon going to AUTO the first thing that happens is that all SET bits are RST. Then the program looks to see what the current sensor status is. The program then SETs those bits that need to be SET before running.

In many situations, the program does not know what the operator is doing to the line while the process is essentially off. So, when going to auto, after resetting all of the SET bits, the first thing the process does is to do a head-count to find out what the lay of the land looks like before resuming. If the lay doesn't look right, then the program indicates where it sees a potential problem. The operator goes back to manual, fixes the problem and then attempts to go to auto again.

This means that the operator will be doing himself a favor if he brings the system to a known good-state (in manual) before going back to auto.

It all boils down to proper planning.

Just last week I was confrontef with 2 identical problems.

One was one a program writen by some European companie with a Mitsu PLC using Step ladder type structure.

The next one was from me on a SLC ladder program with sub-routine as the structure.

The Mitsu program was full and I mean full of S/R and the AB had none.

At first I was pi$$ed by the European program because it gave me great difficulties to find where the Set and Reset commands where coming from. I had to put blockers all over the 3000+ line to intercept them just to find what was or not triggering some events.

I thought to myself at that point "Exactly why they should be more carefull about using S/R functions"

Then again, a few days later I had to do the same thing on one of my own prgram.

I was re-ising some sub-routine from another program and had not cleaned it well enough. There was 1 osr bit left in it that was giving me all the troubles.

I had to block line by line until I found where the command was coming from.

I still beleive that the use of Set/Reset should be left to the more experienced programmers but then how would the newby learn?

Thanks, Terry. Now I don't have to reply to this one!

Serously, you should write your logic so that it is obvious what is making things happen and when. That means two years after you wrote the program, late at night, with a deadline, and three operators breathing down your neck. If you are going to use set/reset then you should document the heck out of the operation!

Check out here and and here for some more of this debate (largely AB based). I personally don't like to use Set and Reset except when writing logic for alarms.

Unless a safety issue on powerup is involved, I never use the Set in "normal" code. Like Terry though, I will use Reset occasionally to break a self-latching rung.

Where I do use Set and Reset (alarming), I always group the rungs together, and I always document them well.

Marc

Rod said:

PS, what do you use instead of S/Rs?

Click to expand...

I never said I didn't use them. But like was mentioned before, you have to prepare for anything.

once again, thanks for the replies, after looking for the previous posts, it seems that i have made a reiterative question, so i must apologize fot that.

in a second hand, it helps clarifie my mind. specially i post this question, after an argument with someone that... how can i say, treat me like an idiot for using some set and reset in my code.

now i feel much better.

thanks again

I'm in total agreement with Terry & Tom. The instruction set is there to be used. How to use each instruction in the correct manner is up to you. If you need a latching relay, by all means use it. Like anything else, just use it properly.

After I had read a previous post on SET and RESET functions, I looked at a program I was writing using several of them. I noticed that if the SET was SET and power was turned off and turned back on that I still had a SET condition. This was true even over night. I was amazed.

As my PLC was getting power from a battery, and there is the possibility of the battery going dead, I added a first pass function to reset ALL of my SETS. Now everything starts with an operator input.

I came to this site looking for better ways to program. I must say I have already learned a great way to protect my company and customers equipment.