How to intentionally make a program stop?

[scootabug 0]

Howdy all, I have a basic little ladder diagram, and when an emergency door is opened, I need to unlatch some outputs and clear the timers. What command do you use to clear a timer? I've tried 'RES' aka Reset but that didn't seem to work. Also, how can you stop the entire program? I'm feeling a little lost so if anyone has a spare minute, I'd be most appreciative! Cheers, Scoota

[AJ Melb 0]

It may be the reset only works if the timer condition is false/zero. If you the simpler TONs then having the logic feed them go zero/false will clear the timers. Additionally the accumulator or .ACC field is writeable in TON/TOF and I assume timers in many PLCs. Personally I dislike using latch and unlatch commands. It means drivers of the relay output are on separate lines, and its easy to do nasty things like oscillate contacts or leave latches in an indeterminant state. (Its the PLC equivalent of programming using if/then/goto = bad in my opinion) A cleaner/better technique is to have latching logic, where a contact holds itself in. Something like +---[ latch condition ]----------+----[ / Reset ]----------------( latch ) | | | | +-----[latch]---------------------+ If you will forgive the scrible. Latch holds itself in once triggered by the latch condition, until the Reset turns it off. So basically in your example I would have a whole lot of lines with a reset condition being your emergency door contact. "latch" can be a retentive contact or TON, if you need the state to survive run/program mode switches/power outages, or need delays. You can build up whole sequences and state machines this way (although I prefer numeric states for more complicated stuff) As for stopping a program - thats not a normal requirement either. You can stop execution of parts of a program by using subroutines, that you either call, or don't. Putting the entire PLC into program/stop is a one way trip if its even possible to do (forcing a fault like a maths overflow condition would do it in some PLCs but that ain't nice). When not limited by resources such as scan time, the normal/logical way to program is to have all the main logic run each scan, and just not do anything if not required. ie write your logic such that you expect it to be run all the time, with enough contact conditions on key lines that nothing happens when its not supposed to. Hope this doesn't confuse you further. Regards AJ

[paulengr 44]

First off, you said "emergency door". If you are trying to do safety circuits with a non-safety PLC, then you could be in trouble. It depends on your risk assessment procedure. In general, this is a very bad idea and best to be done in hardware unless you have some pretty exotic needs and understand how to do it correctly. The correct way is to do this stuff in hardware, but still supply the PLC with status bits indicating the state of the emergency circuit. This is necessary in order to meet the other part of the safety circuit requirement...that it doesn't do things unexpected. So you need to send signals to the PLC so that the PLC correctly resets it's state, exactly what you are trying to do. There are 3 basic strategies for doing this. First, you can rely on some of the magic of the way that "momentary" logic works vs. "latching" logic. OTE and TON instructions are "momentaries". In other words, if their input states are false, they reset. In addition, whenever you make a transition from program to run mode, they reset. In addition if they are located in an MCR zone, they will reset. I really, really, really dislike MCR zones because they lead to troubleshooting errors and problems down the road but if you are careful to document, document, document, and understand them, they can make it really simple to mass-reset all your timers and outputs. Alternatively, you can use a state machine and send your state machine to the reset/E-Stop state whenever one of the above mentioned conditions happens. This is a bit complicated to get into in one post but it is very effective if you use this style of programming. Finally, the most common method is the MAN/AUTO bit. In this style of programming, you usually have a machine AUTO and MANual state, or basically an "AUTO" bit in the PLC. In your logic this is usually implemented with SEALing or LATCHing logic around an OTE instruction. That way any time your PLC goes from program to run, it will automatically go to manual first. Do NOT use a selector switch (auto/manual). Use push buttons that say MAN and AUTO or a "cycle start"/"STOP" type button arrangement. That way you can drop the system back to manual through internal logic since you can't move a selector switch. All of your outputs get implemented with at least two branches. The first branch is the automatic one and it is essentially your normal logic. The second parallel branch contains what to do during manual operation. There are no timers or anything like that except for perhaps some interlocks. All manual functions use momentary push buttons, not latches. That way when you go to manual, operators can run/test every machine function but have to hold the buttons down. Now since every AUTO branch is checking the AUTO bit when you clear it (go to manual), all the outputs drop out. In addition if you use TON for almost everything and again, put XIC AUTO in front of it, all of your timers will automatically reset when you go to manual. There is one more way to do it. If you have multiple ladders and you don't execute a ladder, you can pretty easily disable it that way. You can also go in and clear it's outputs and timers externally. I do not recommend this approach as it is very confusing to debug. It's the one reason that I'm not a fan of SFC charts since that's exactly how an SFC works. SFC's tend to push you into using transition logic by nature. Reserve RES for special use cases or for RTO instructions. Same thing with OTL/OTU. By the way, avoid OTL/OTU also because unless you are careful about documentation and the way that you write your code, you can make it VERY difficult to troubleshoot. OTL/OTU code is transition logic, not state logic. It has it's place in certain applications but most of the time, it is easier to read and easy to convert transition logic into state logic. Last note: There is a problem with TOF and RES. It's a bit of a technicality but still important to be aware of. Let's take a classic example of how to use TOF. Say you want to add a delay to an output. So you original code may be.... XIC AUTO XIC INPUT_CONDITION OTE OUTPUT You then change it into XIC AUTO XIC INPUT_CONDITION TOF Tx:y XIC Tx:y/DN OTE OUTPUT This simple logic change will start like normal but then hold the output on for an additional period of time after the input conditions clear. When looking at a TOF instruction I like to think of the DN bit as "ND" or "Not Done". When a TOF instruction is enabled (input is true), the accumulator is ZERO and the timer is not done (DN=true, for "Not Done"). When the input conditions go to false, the DN bit stays true but the timer accumulator begins counting. Once it reaches or exceeds the PREset, then the timer stops and the DN ("Not Done") bit clears. At this point the accumulator doesn't reset back to zero until the input conditions go true again. Where you get into trouble is with the RES instruction. A RES instruction clears the accumulator and ALL of the state bits, including the DN bit. This is exactly what should happen with the other two (TON and RTO) timer types. With a TOF, this is technically an illegal state since the timer is done (ND=0) and yet also reset (ACC=0) at the same time. Since it is not enabled (EN=0), it should not start timing on you but nevertheless, it's not really the right way to do things. AB highly recommends that you do NOT use the RES instruction on TOF instructions for this reason. I believe things still work as expected (output would be disabled) in this example but not necessarily for all cases.

[BobLfoot 301]

I see you gotten some very good answers but I'll add one other. If you really want the program to CRASH Stop and not scan any more take an usused "spare" timer and when you see the emergency input execute a Mov or -1 into the timer preset. i guarantee that will fault the processor and crash everyting. I've used this little trick to catch "gremlin" conditions during startups, but never left it in a live system. You will need Logix PC access to clear the timer preset and restart the PLC.

[scootabug 0]

Thanks everyone for your extensive replies, this has given me some direction.