set - reset
- Thread starter sapoleon
- Start date
wildswing
Member
I mean using a totally separate bit to break the seal so that your reset conditions are on another independant rung.msinclair said:
OkiePC
Lifetime Supporting Member
This thread has been very entertaining and brings to light the fact that the subject of latch/unlatch vs. seal w/OTE is still a muddy area for a lot of programmers.
I have seen the instruction severely abused by OEM programmers. I had to debug a 3000 line PLC program that contained over 1000 latch/unlatch instructions. After a few hours, I scrapped the whole POS and started over with "normal" logic.
I am not against the use of SET and RESET. They can clean up confusing logic. The are great for fault logic, parts tracking, sequence control and a lot of other things.
I try to only have one SET and one RESET per bit. I try to keep them next to each other in the program, but not always. As an example: I have a global bit "PICKUP_POSITION_OCCUPIED" that interfaces two different sequences. The bit is latched by one sequence and unlatched by the next. That helps identify for the troubleshooter how the two sequences interact. If I put the event from one sequence in the ladder file for the other, just to keep the instructions side by side, it would foul up the organization of both modules.
I use Set/Reset for things I need to keep track of during power cycles. I want to know if a piece of cut stock is awaiting pickup. I want to know that my indexing conveyor extend limit switch failed and a fault occurred.
I will use RESET all by itself somteimes. It may confuse the next guy who wonders "what turns this bit on?", but it's sometimes the right thing to do. I RESET HMI pushbuttons that are supposed to be momentary. (I've seen RSView and PV550s fail to turn off momentary bits, and comms can fail at any moment). I'd rather confuse a troubleshooter than risk damage to people and machinery.
I don't blame that occurence on the abuse of the SET/RESET instructions. There should have been an XIC Auto_Mode contact to prevent that motion from occuring, and yes, LOTO procedures were violated. But, the truth is, you MUST program the machine to behave in a predictable manner in every mode. No unexpected motion in manual mode is a simple one.
I see these instructions used more by people who learned to program with languages other than ladder logic. People who learned to "program" using relay logic with hand tools generally wire their ladders the same way. We expect to see very few latching relays in hardwiring compared to "sealed in" relays. I think we expect the same thing from our PLC code.
I first learned assembly, then several other "high-level" programming languages. Years later I learned relay wiring. Then I learned PLC ladder logic. I was shocked when I found out that the latest industrial machinery was being controlled by such seemingly crude techniques, but after using it for years, I understand why.
Programming styles will always vary as much as the people who use them. Just make sure you know exactly what happens when you cycle power, pull out a comm cable, etc. Make it part of your testing and you shouldn't go wrong.
I have seen the instruction severely abused by OEM programmers. I had to debug a 3000 line PLC program that contained over 1000 latch/unlatch instructions. After a few hours, I scrapped the whole POS and started over with "normal" logic.
I am not against the use of SET and RESET. They can clean up confusing logic. The are great for fault logic, parts tracking, sequence control and a lot of other things.
I try to only have one SET and one RESET per bit. I try to keep them next to each other in the program, but not always. As an example: I have a global bit "PICKUP_POSITION_OCCUPIED" that interfaces two different sequences. The bit is latched by one sequence and unlatched by the next. That helps identify for the troubleshooter how the two sequences interact. If I put the event from one sequence in the ladder file for the other, just to keep the instructions side by side, it would foul up the organization of both modules.
I use Set/Reset for things I need to keep track of during power cycles. I want to know if a piece of cut stock is awaiting pickup. I want to know that my indexing conveyor extend limit switch failed and a fault occurred.
I will use RESET all by itself somteimes. It may confuse the next guy who wonders "what turns this bit on?", but it's sometimes the right thing to do. I RESET HMI pushbuttons that are supposed to be momentary. (I've seen RSView and PV550s fail to turn off momentary bits, and comms can fail at any moment). I'd rather confuse a troubleshooter than risk damage to people and machinery.
I don't blame that occurence on the abuse of the SET/RESET instructions. There should have been an XIC Auto_Mode contact to prevent that motion from occuring, and yes, LOTO procedures were violated. But, the truth is, you MUST program the machine to behave in a predictable manner in every mode. No unexpected motion in manual mode is a simple one.
I see these instructions used more by people who learned to program with languages other than ladder logic. People who learned to "program" using relay logic with hand tools generally wire their ladders the same way. We expect to see very few latching relays in hardwiring compared to "sealed in" relays. I think we expect the same thing from our PLC code.
I first learned assembly, then several other "high-level" programming languages. Years later I learned relay wiring. Then I learned PLC ladder logic. I was shocked when I found out that the latest industrial machinery was being controlled by such seemingly crude techniques, but after using it for years, I understand why.
Programming styles will always vary as much as the people who use them. Just make sure you know exactly what happens when you cycle power, pull out a comm cable, etc. Make it part of your testing and you shouldn't go wrong.
Unregistered
Guest
U
Michael
its not that you shouldn't but it is bad practice as it makes
debbugging code a lot harder. remember that everything happens
left to right not top to bottom. therefore, an event might be happening somewhere
else that fools you
its like goto statement in basic - its there - it has its uses - but gosub is
better
also be careful with one shots - i use them - however, sometimes its better
not to use a bit level instruction but look to see if the result of an assignment based on an edge transition will effectively trap the event
sapoleon said:
its not that you shouldn't but it is bad practice as it makes
debbugging code a lot harder. remember that everything happens
left to right not top to bottom. therefore, an event might be happening somewhere
else that fools you
its like goto statement in basic - its there - it has its uses - but gosub is
better
also be careful with one shots - i use them - however, sometimes its better
not to use a bit level instruction but look to see if the result of an assignment based on an edge transition will effectively trap the event
Just back from commissioning a job where I have based the software completely on KEEP relays and SET and RSET. Sequential start and stop. Use shift registers to sequentially start and stop the plant. All the usual things that you have to watch out for in resetting the latches of course.
A couple of rungs even have several SET commands and then a KEEP command and later in the program several RSET commands to reset the SETs.
I absolutely hate having to base the whole program around these commands no matter how uesful they are. Somewhere along the way there is always a piece of reset logic that has been missed. Unfortunately, it was still the easiest way to do the project.
Lots of lines of logic to detect when something has to be started so that the shift register always starts at the top and steps through. Pain in the "A" job. It is only a simple commercial swimming pool but the stupid consultant insists on sequential start and stop with "appropriate" time delays and all "appropriate" interlocking. In other words the usual consultant "I will not be held responsible for how the system works". Should shoot these guys.
The biggest problem is that the pool operators are muscle bound life guards that have had what little brain they ever had burnt away by sniffing chlorine for years. Look good to the ladies though with very deep suntans, rippling muscles, body waxed and oiled etc.
A couple of rungs even have several SET commands and then a KEEP command and later in the program several RSET commands to reset the SETs.
I absolutely hate having to base the whole program around these commands no matter how uesful they are. Somewhere along the way there is always a piece of reset logic that has been missed. Unfortunately, it was still the easiest way to do the project.
Lots of lines of logic to detect when something has to be started so that the shift register always starts at the top and steps through. Pain in the "A" job. It is only a simple commercial swimming pool but the stupid consultant insists on sequential start and stop with "appropriate" time delays and all "appropriate" interlocking. In other words the usual consultant "I will not be held responsible for how the system works". Should shoot these guys.
The biggest problem is that the pool operators are muscle bound life guards that have had what little brain they ever had burnt away by sniffing chlorine for years. Look good to the ladies though with very deep suntans, rippling muscles, body waxed and oiled etc.
PhilipW
Member
At last we 100% agree on something... mmm maybe not...shooting is too quick for some of them.
TimothyMoulder
Member
Now, the chief complaints about set and reset are "they stay on after power cycling" and "they confuse people".
On the first, I always put a power-on task that wipes out all sets regarding outputs, either directly or related memory bits. Unitronics is nice in this regard, because you can set the power-up condition of every operand individually - 99% off, in my case. But enough about that...
As for the second, my philosophy on programming is "control the scan". I use all sorts of things I'm theoretically not supposed to, such as conditional subroutines, and set/reset (latch/unlatch, non-,retentive).
I use set and reset because I use conditional subroutines to determine active states. In my method, set/reset are the ONLY good way of controlling outputs, because you can (and have to) explicitly tell the output "go on" and "go off" at the right point in the sequence.
This actually makes my logic easier to trace. Go to the state that froze/faulted, and see instantly which output should have been doing what when the system locked up. Documentation is still critical though, since it helps to explain your intent for that state.
My point is, set and reset have different applications for different people and programs. When I first started, I would never have dreamed of using them. I still swear at guys who use them to track their sequence - the logic get disorganized. It takes practice and some good examples to put them to work well, so don't be afraid to experiment.
Just remember to turn out all the lights when you're done
On the first, I always put a power-on task that wipes out all sets regarding outputs, either directly or related memory bits. Unitronics is nice in this regard, because you can set the power-up condition of every operand individually - 99% off, in my case. But enough about that...
As for the second, my philosophy on programming is "control the scan". I use all sorts of things I'm theoretically not supposed to, such as conditional subroutines, and set/reset (latch/unlatch, non-,retentive).
I use set and reset because I use conditional subroutines to determine active states. In my method, set/reset are the ONLY good way of controlling outputs, because you can (and have to) explicitly tell the output "go on" and "go off" at the right point in the sequence.
This actually makes my logic easier to trace. Go to the state that froze/faulted, and see instantly which output should have been doing what when the system locked up. Documentation is still critical though, since it helps to explain your intent for that state.
My point is, set and reset have different applications for different people and programs. When I first started, I would never have dreamed of using them. I still swear at guys who use them to track their sequence - the logic get disorganized. It takes practice and some good examples to put them to work well, so don't be afraid to experiment.
Just remember to turn out all the lights when you're done
Clearer and straight
Basically recommendations ghosts (does not know the author or does not know is been real) and generic are created due to the not read people or absence of attention the variations of configurations [3] or is lacking of information detailed and complete in the manual
Observation unique scan
Start A=Transition to ON
PRG 01
RESULT B=ON
PRG 02
RESULT B=OFF
Philosophy
Generality: Instruction SET/RESET or LATCH/UNLATCH
First name : Put to top/down.
Segund name: To keep permanent ON or permanent OFF.
Of this two meanings, define it aplication.
Which purpose and reason? [2]
R: For situations where during the processing it is not possible to fix the finale state of variable.
This means, that status OFF/ON cannot be determined while not to finish the processing (sic. subroutines) or to find the END.
Application and use: [1]
But if does not line up the concept defined in [1] badly will be used.
[*]Status acquired in processing: It can be observed in
Terry , concept of glue finger in the switch is old and harmless.Eletric association it case not accordance.
Darrenj, understand you example.
Basically recommendations ghosts (does not know the author or does not know is been real) and generic are created due to the not read people or absence of attention the variations of configurations [3] or is lacking of information detailed and complete in the manual
Observation unique scan
Start A=Transition to ON
PRG 01
--------||-----+-----|\|---------( )
A | C B
--------||-----+
B
--------||------------------[SET C]
A
RESULT B=ON
PRG 02
--------||----------[SET B]
A
--------||----------[RST B]
A
RESULT B=OFF
Philosophy
Generality: Instruction SET/RESET or LATCH/UNLATCH
First name : Put to top/down.
Segund name: To keep permanent ON or permanent OFF.
Of this two meanings, define it aplication.
Which purpose and reason? [2]
R: For situations where during the processing it is not possible to fix the finale state of variable.
This means, that status OFF/ON cannot be determined while not to finish the processing (sic. subroutines) or to find the END.
Application and use: [1]
- STATUS acquired in processing
- Fixed memory - Meaning for human being, to vacant of the necessity to verify its STATUS.
- Configuration of range of retentive registers; Operation not differentiated for PRG01 PRG02 (ladders in top)
- Configuration of range of retentives registers; Retentive operation only when it uses PRG 02
- Configuration of permanent retentives (Frequent Lock in firware); The register "becomes retentives" when to use the instruction of PRG 02
But if does not line up the concept defined in [1] badly will be used.
[*]Status acquired in processing: It can be observed in
- Some conditions (parts of program) can modify the STATUS (sic.alarms, acks, events human)
- BIT [register] that guides the processing and can modify during the subsequent processing .
Terry , concept of glue finger in the switch is old and harmless.Eletric association it case not accordance.
Darrenj, understand you example.
Last edited:
Terry Woods
Member
- Join Date
- Apr 2002
- Posts
- 3,170
dandrade said...
dandrade, the result is B = ON for only 1 scan. Then it goes OFF on the next scan... I'm sure you knew this... but you didn't say so.
As far as the constant misunderstandings about SET/RST and LATCH/UNLATCH... well that credit goes to the bright guys that decided that SET/RST conditions could be better described by using the common electrical terms, Latch/Unlatch... how silly.
One of the problems with the Latch/Unlatch terminology is illustrated in dandrade's drawing (above).
Output-B is a "self-latching" bit. It is "latched" through a "self-latching" circuit.
What benefit is there in using terms that ultimately create more confusion than they prevent?
If I talk to a TI-guy and, referring to dandrades drawing, say...
"If A is closed and C is OFF then B is latched until C comes ON", the TI-guy will KNOW that the rung looks as indicated above.
An AB guy would assume that there is a LATCH instruction in there somewhere.
PRG 01
A C B
---| |---+-----|\|---------( )
|
B |
---| |---+
A
---| |------------------[SET C]
RESULT B=ON
dandrade, the result is B = ON for only 1 scan. Then it goes OFF on the next scan... I'm sure you knew this... but you didn't say so.
As far as the constant misunderstandings about SET/RST and LATCH/UNLATCH... well that credit goes to the bright guys that decided that SET/RST conditions could be better described by using the common electrical terms, Latch/Unlatch... how silly.
One of the problems with the Latch/Unlatch terminology is illustrated in dandrade's drawing (above).
Output-B is a "self-latching" bit. It is "latched" through a "self-latching" circuit.
What benefit is there in using terms that ultimately create more confusion than they prevent?
If I talk to a TI-guy and, referring to dandrades drawing, say...
"If A is closed and C is OFF then B is latched until C comes ON", the TI-guy will KNOW that the rung looks as indicated above.
An AB guy would assume that there is a LATCH instruction in there somewhere.
The ladder figures is not fix right in screen
Observation unique scan =>Is one scan
Start A=Transition to ON
PRG 01
--------||-----+-----|\|---------( )
A | C B
--------||-----+
B
--------||------------------[SET C]
A
RESULT B=ON
PRG 02
--------||----------[SET B]
A
--------||----------[RST B]
A
RESULT B=OFF
The standard of operation of instruction SET/RESET: Always can be modified of ON-OFF innumerable times in one SCAN.
If exists some PLC in contradiction it standard = BUG
All text is detailed and justified, doubts for discredited
Similar Topics
Hi,
i am using DVP-14SS2 PLC, after program written to plc, when power is reset, plc doesn't run. always need to connect to pc for the run mode.
Hi need help why this “failure 5 emergency stop “ appears at every startup in the morning ?
Have to shut off main switch at least 10 times on...
I was loading a program onto an XE1e2 PLC and it got stuck on these two windows and won't progress. It won't let me connect from the PC to reload...
Hi all, i have recieved some 4RF Aprisa SR+ ethernet radios from a customer to configure.
Issue is that they are used and have non-default...
Hi Guys,
I have a 1769-L24-QBFCB1 that has the OK light flashing on the embedded counter module. The manual states it is a resettable fault, but...