THUMBWHEEL AND MOMENTARY PB

[BURCHSKI 0]

Hi, I have a PLC 5/01 in a machine that is about 13 years old. Yesterday a person almost got hurt because the thumbwheel can be moved to various numbers while the momentary pushbutton is held down and actions occur. Immediately everyone thought that anti-tie down logic would be a great idea. I my self think it is going to be a huge program if I do that given there are 32 bits on this thumb wheel. A better idea i think would be to say that you cannot go to another function while the pb is depressed...here's the problem. I am having a brain fart and need some help with addressing that logic. Can someone suggest something?

[Ken Moore 23]

You don't give a lot of information, so this is just a guess. Use a one shot after the momentry pushbutton input for what every you're doing.

[BobLfoot 302]

To answer your question: Taking Ken's excellent suggestion just 1 step further try the following: 1. Pick two Unused Flag Bits B3:0/0 and B3:0/1 for example 2. Replace the PB Input with B3:0/1 at all locations in program. 3. Use PB Input to drive two timers 3a. A TON Timer like T4:0 with a 5 second delay 3b. A TOF Timer like T4:1 with a 5 second delay 4. Use the rung SOR BST XIC T4:0/DN NXB XIC T4:1/DN XIC B3:0/0 BND OTE B3:0/0 EOR 5. Use the rung SOR XIC B3:0/0 ONS ??/?? OTE B3:01/1 EOR This means it will be 5 seconds after a press of the button before anything happens. You can sound as many bells and whistles as you want in this time. Then your action will occur. Finally the button must be released for 2 seconds before it is recognized and processed again. Now my humble two cents. If this is a press of some sort and you are "upgrading the controls to make them safer" be aware you may be legally required to bring the machine to current ANSI/OSHA standards/regulations as they apply to this machine. DO NOT LET YOURSELF END UP IN THE POSITION OF BEING THE FINAL AUTHORITY!

[panic mode 246]

if someone "almost got hurt" then this can and will happen again. using anti-tie down is valid safeguarding method but it requires certain compliance, not just standard PLC (you can use safety plc and it's built in certified anti-tie down blocks but may be overkill for your application). there are plenty of anti-tie down control relays (safety rated device) and buttons that can make this safer. note if electronic buttons are used (such as banner opto touch etc.) they also have to be properly rated, selfmonitored etc. kit with controller and pair of buttons is about $600. relay alone is some $250-300.

[paulengr 44]

This isn't true either. What level of safety is required depends on what your risk analysis says it must be. I've run through it on a number of occasions and found myself in the two extremes (needs to be safety grade but self-monitoring, manual reset, etc., not necessary; or control redundancy territory...in which case we re-engineer to reduce the risk rating). There is often even an occasion when you hit the minimal risk level where PLC-implemented anti-tie down with ordinary off-the-shelf push buttons are adequate. If someone "almost got hurt" because of a particular PLC function, then someone probably never did a risk assessment (you hardly ever heard those words a decade ago). I'll bet even if you "fixed" the PLC, there is probably a scenario involving failures of certain valves or drives which can duplicate the same "almost got hurt" conditions WITHOUT an errant PLC problem. I have run into this exact same scenario time and time again in a plant with control equipment that is roughly the same vintage. This is the primary reason that except for the newer "safety rated" PLC's, general controls (and general PLC's) are not considered "safe" in the first place using current industry standards, depending on the level of risk involved. It's the reason that safety functions are treated as a totally separate entity. I seriously doubt that changing the push button to a "safety button" no matter how much extra crap you attach to it is the answer, or this may indeed be all that is necessary. It may indeed be the case that this is considered safe, but it all depends on what falls out of your risk assessment as the control system requirement. Risk assessments are not complicated. They can be expensive if you hire a "safety consultant" (and usually have all kinds of problems if done in a vaccuum, which consultants usually do). Or they can be some simple common sense sort of things. What is needed here in terms of safety is to start with a complete risk assessment of the machine. It sounds like guarding/access control wasn't considered. I'm not suggesting fenced off robot work cells are the answer, but someone has to do the risk assessment where the control system is a CONSEQUENCE, not an answer to a safety issue. Making minor changes to the logic to avoid the thumbwheel problem will make the equipment safer to control but it does not make the equipment any less dangerous, as in it still won't meet any industry consensus standard for what is considered "safe" and what's not. Getting back to the problem at hand, I'm going to give suggestions but they are based on good operator control designs. They have nothing to do with safe designs. There is a basic problem with thumb wheels. They are good devices for inputting a value (0, 1, 2, 3, 4...) for the day when the number of outputs makes a rotary switch infeasible. They are lousy though for machine mode selections. The problem is a matter of ordering of states. Imagine an automatic transmission in a car if instead of "P, R, N, D, 3, 2, 1", the ordering was changed to "P, N, R, D, 3, 2, 1". More than once I'll bet someone gets into an accident. The ordering was changed to the "standard" arrangement specifically BECAUSE people accidentally put the car into reverse several times and many transmissions were destroyed. From the description, it sounds like to me that they are allowing machine settings to be changed during a cycle, which is generally a huge no-no specifically because of the problem that is happening, and not just because it's a thumbwheel. I'm not sure that "cheap" thumbwheels made sense even 13 years ago but the implementation needs to separate the two actions of selecting a thumbwheel position and loading a setting. The key is to first divorce the machine "operating parameters" from the "setting parameters". Since you probably have everything tied directly to I:x.x values, first thing is to pick some unused bit WORDS some place else. For example, B3:x. Since you said there are 32 bits, you will need two 16-bit words to do this. Then in your logic, COPY the value of the thumbwheel only when the push button is RELEASED. Do nothing while it is pressed down. You can do this with one shot logic: XIO <push button> (if push button is not made) ONS <any available bit> (fire this rung only once when the push button is released) Create a branch and put the following two outputs on the two branch rungs: MOV I:x B3:y (move the first physical word of the thumbwheel to B3:y) MOV I:x+1 B3:y+1 (move the second physical word of the thumbwheel to B3:y+1) Now go through searching for all occurrences of I:x.z and I:x+1.z and replace them with the corresponding B3:y.z and B3:y+1.z. The search functions in Logix 500 are smart enough that if you only specify the search to the word level, you will find everything that you are looking for. Interestingly enough, this sort of logic also provides a side-benefit in terms of ergonomics. There is no longer a need to hold the push button down. Pressing the button once is a "set" button. You may also want to think in terms of "safe" vs. "unsafe" states and implement a solution that way instead. A recipe system frequently works this way. In this example, a recipe is ONLY allowed to be changed when the machine first starts a cycle or when the machine is in idle or manual mode. The three "safe" states are idle, "start", and "manual". All others are unsafe. In this configuration once you start a machine cycle, the machine uses the current settings until the cycle is completed. On the very next cycle, the machine will use the new settings. Again this allows operators to make changes at any time even with a machine that is continuously cycling but under normal circumstances, changes made while the current cycle is running have no effect. They kick in during the NEXT machine cycle. It usually means that you need some extra "reset" logic at the beginning of a cycle but this is normally necessary anyway. If this is your implementation logic, for a thumbwheel, you would use the same code as above except get rid of the one shot and replace the XIO with a check for which state the machine is in. This way it continuously copies the thumbwheel settings whenever it is in a "safe" state. Otherwise, changes are not allowed. Final suggestion: Get rid of the thumbwheel altogether. For example, you can buy a small monochrome HMI with the programming software (Cutler Hammer/Eaton brand) that directly connects to the DF-1/RS-232 port of your SLC for under $300 from Omega. Thumbwheels cost more than that in most cases. And HMI's are event based...there are no mechanical "intermediate" steps. If you wanted to make "no" changes to the PLC code, then first program your HMI to output the require bit patterns to match your thumbwheel. Normally you'd write to some place in data memory but in this case, write directly into the input data table in the same I:x.y locations that the thumbwheel currently occupies. Now disable the I/O card so that it no longer writes to input data memory. You can now supply the same data from the HMI and you never had to alter a single line of ladder code. Edited 3 Dec 2008 by paulengr

[panic mode 246]

actually you are right, i misread original post. this isn't safeguarding application but data entry issue. now that i re-read it again it seems to be that product/setup change is permited while machine is enabled or possibly in cycle. is that correct?