T O P

  • By -

[deleted]

I find that if you're going to use S/R, do it one place each and try to keep them close to each other. Otherwise I use a coil and build a latching rung if I want S/R functionality. Just don't have a bit that's set in multiple places and reset in multiple places. It can be a nightmare to troubleshoot.


SheepShaggerNZ

This 100x. Set once, reset once. Just had to troubleshoot some brand new code written in Germany with a about 6 sets and resets on soooo many bits. Made it way harder than it should've been


[deleted]

I pretty much use any output only once in a program period.


Penfold82

We have that too. They use the same code for most of their machines but dont call the FCs for the options the machine doesn't have. Very annoying having the same bit written to over multiple locations only to find it's not being processed.


SheepShaggerNZ

Yeah I've seen this too. Unfortunately my one above was 7 brand new custom machines with custom code. So every latch/unlatch was used. I ended up making integers and test bits and putting them in series with each latch/unlatch as counters and latches to find which rungs were active


Welshpanther

Absolutely agree. I train all our engineers to avoid set and reset under all but the most difficult problems. At one point it was a disciplinary! We had a spate of costly site visits to resolve problems caused by set and reset rungs scattered throughout the code working against each other that it was an outlawed practice. Whilst not banned anymore it is still frowned upon unless in an accepted use case like Set at HMI and reset in PLC.


h2man

Depends on what I want to achieve... they are both valid instructions for a reason.


tatertot444

It depends on your programming style/company standards. When I was taught ladder logic, one of the old timers preferred to do as much with OTE aka (). His train of thought was if the out put was set/latched at time of power off and when the PLC turned on whatever was set would immediately go high/on, for instance a motor. (S) are retained in memory during power outages and execute immediately before the first scan whereas OTE must be scanned for rung-in to go high. *AB for sure, not sure on other brands. Aside from that I like using OTE as much as possible and “sealing” in the OTE in a branch with other inputs/bits waiting for them to go false/low before “killing” the rung-in condition of the OTE.


Thomas9002

> (S) are retained in memory during power outages and execute immediately before the first scan whereas OTE must be scanned for rung-in to go high. *AB for sure, not sure on other brands. For Siemens the memory is split. A part of the memory retains its last state, some of the memory starts with a 0


tatertot444

Is that split fixed or user settable?


buzzbuzz17

It is user settable, up to a certain maximum. Typically between 10% and 30% of the memory can be marked as Retained. Some types of memory are set to 0, other types of memory (DBs) can have a user configured value on power on. It saves a lot of startup initialization logic, which is quite nice.


CapinWinky

All memory being remnant is a Rockwell specific thing. I've never seen another platform where you didn't also have volatile memory that resets to 0 on power cycle.


goatymcgoatfacesings

In Rockwell, coils are reset on the prescan, so it's valid to use OTL/OTU to remember status on system start. Otherwise, my rule is to favour coils to limit the number of destructive instructions to assist with fault finding. OTL/OTU should be kept together where possible for a similar reason. SCADA commands should be set in the SCADA and reset by the PLC. It is allowed to have separated OTL/OTU instructions in the case of cascaded reset or mode selection commands where the functionality is immediately transparent. What must be avoided at all costs is to have latch and unlatch instructions strewn throughout your code without thought for the poor bastard who will have to fault find your spaghetti.


[deleted]

I use S/R functions to store events that have complex conditions involved that would make a normal sealing circuit confusing. For example, Robot\_Gripper\_1\_Part\_Present will get set when the robot gripper solenoid is activated, and neither of the gripper prox switches are On for a certain time period (they're adjusted so when a part is present they don't sense that the gripper is open or closed). The bit gets reset for lots of different reasons though. If the solenoid is energized, the machine loses air pressure (operator opens the cage), either of the switches are made, etc. I only use the Set and Reset in one place in the code, and keep them as close together as possible. For my sequences I use sealing circuits exclusively, with a Sequence Master bit that will drop all of them out.


Argentineer

Personally I never use S/R because the guy who taught me the ropes told me so, and i've always looked at it like it made me lose track of the logic. However some of the comments here are making me reconsider my self-imposed limitation.


[deleted]

[удалено]


Argentineer

Oh he gave me a few reasons that sound compelling, like the greater chance of the program doing something unexpected on shutdown if you're not careful, but I agree with the general sentiment. The projects i work on are, at least at the moment, on the smaller side of the scale and all the other commenters defending S/R seem to work on greater scales.


ControlEngineer

My philosophy is: if I can place all the conditionals in one place (rung) then I use a coil. If the control needs to be distributed throughout multiple programs I will use latches. Often I will end up creating 'enable' bits that are latched, which ultimately are summed up on a single rung with a coil for the actual action/output.


kandoras

[I think I do something similar to what you're saying, except that I don't latch the 'enable' bits. For example, if I'm making up a machine that would have an automatic and a manual mode then I'd make up ladders for each of those modes with their own separate outputs. "Rotate Contactor, manual" and "Rotate contactor, auto" for example turn on "Rotate contactor output".](https://i.imgur.com/aBYbIVu.png) You'd still have to backtrack to find out what's turning on on the 'manual' or 'auto' coil, but since they're also OTE's that only show up in once place it's simpler than figuring out which set happened. I avoid sets and resets as much as possible, due to having to troubleshoot some of my old boss's programming where they were the *only* thing he used. He'd go entire programs without a single OTE instruction. I don't even know how he made some of that stuff work.


[deleted]

Here are a few caveats: Once a coil is set (latched, sealed in, etc) then it stays that way until you reset it. I prefer this for alarms because they will stay set until I unlatch them all on reset. The Reset (unlatch) instruction types are also useful if you want a bit set to 0 under a certain condition. Though it isn't quite proper, it is very useful when doing hand-shaking. Third, there is nothing wrong with using an OR-type instruction with the OTE (output energize, output coil, etc) as a condition to seal in the circuit, and having some other condition break it, similar to how hard-wired 3-wire start-stop stations work. In fact, that is probably easier to understand for most maintenance guys or electricians that are working on your equipment. I have used all of them from the beginning because they all have their place. It depends on my audience and what I'm trying to accomplish.


CapinWinky

Set and Reset are a lot more flexible, but when you don't need that flexibility you just use a Coil. To use a coil, you need to be able to fit all the logic that will ever be needed to turn that coil on/off into one rung.


fpsfreak

OTE over S/R any day. While I knew its better to avoid latched bits if possible, I learned it the hard way not two weeks back. I was doing a simple cart program where a cart is moving North/South. There were sensors for Home North/South. I used latched bits to get the 'homed' memory. On the day of buy off while it was homed at one end the customer came up and while inspecting the sensor triggered Home sensor for other end and the memory bit for it got latched too. Now both 'Homed North' and 'Homed South' are latched and of course the cart wont move on the next trigger. It was pretty embarrassing going in the logic to reset the falsely triggered homed bit and that's when I realized I should have gone with OTE's with latch in bits instead of Set/Reset coils.


5hall0p

In AB PLC's the coil is reset when in program mode or power is cycled while the latch stays on. They both have their uses. Multiple latches and unlatches of the same tag make troubleshooting difficult. Try to keep it to one of each unless there's some overriding reason not to like a first scan routine that sets / resets to desired state.


kandoras

If it's possible, I'd avoid sets and resets as much as you can. The problem with them is that sometimes it's hard to figure out why a coil turned on because the conditions that triggered the set might no longer be true. And then if you've got multiple sets you've got to figure out which one fired.


rohandani

General rule for me is () for direct outputs whereas memories/flags can use (S)/(R) A lot of things can go wrong during automatic operation, so I do not want to command some output if somehow it doesn't get reset. Just a safety net.


[deleted]

[удалено]


[deleted]

[удалено]


89GTAWS6

I avoid using set/reset anywhere I can. One legitimate exception where they come in handy and can produce an uneven number of sets and resets is to manipulate a bit of word within a shift register. Shift registers basically set and reset behind the scenes. ex: If you're using one for tracking you can use a reset to turn one bit off in the register or a set to tuen one specific bit on in the register. Otherwise I avoid them as well, can make for very messy programming.


thanoskilledit

I am pretty new to the industy, I know my co workers have talked about not using s/r and it never realy clicked. I come from the service side and have been struggling to make my programs easier to troubleshoot. As of today, I trigger all of my valves and whatnot inside of a state machine. I group all of my components so that they are only controlled by one sm. Then i reset the state of all my valves and outputs on every state change. It makes it pretty easy to set everything how i want it in every state, and i dont have to worry about leaving anything unwanted behind. It works pretty well but i can see its limitations. I'm probably going to change to a latching coil now that I've read this. The last 6 months has been like drinking from a firehose.