Step 7 troubleshooting

[haygood2]

Is there a way to find out where to program stops?
Lets say an operator forgets to put a part in the machine and Step 7 is looking for that input. How would someone not familiar with the process troubleshoot the problem?

 

[PLucas]

haygood2

are you Johnnie at PLCs.net?

Paul

There are 10 types of people in this world.....
Those that understand binary and those that don't!

 

[jacekd]

One solution is to monitor this input with timer at relevant point of the sequence and when time has passed trigger an alarm.

Regards,

Jacek

Do it right or don't do it at all.

 

[zulmajdi]

hi dude,

Do u have any drawing?.. if yes, pls try find what is the input address. Whether I0.0... Ix.x???

then open the prog. Search the input and force the value to ON or energize.

Goodluck dude!!

 

[28021973]

If you write your program in such a way that you increase or decrease a register when certain inputs are on or off you can then compare the register bits and comment them well, or if the programs are any good in the first place comments would have been made anyway.

 

[skiier]

You have to think of the ergonomics of the operating system.
You have to design the system so that the operators have some sort of feedback so that they know what is going on with the machine at any one time. Did you forget that the operators are "part" of the machine?

What I tend to do is use lights that indicate certain machine conditions have been met. For example, interface the operator with the machine by giving them indicating lights to show them "safety gates closed" and "part present" and "machine armed" and "in cycle" and whatever other lights give the operator the feedback to know that his machine is functioning correctly and safely. If the operator forgets to load a part at a certain time, or within a certain time, then create a "part fault" light and make provisions in your program for the operator to load and restart the machine safely. No need to call a Tech. Oh yes, and make all these lights "push to test" so the operators know that these lights are good at all times. Let them change the lamps if they like when they burn out. Makes em feel part of the process. Makes em more productive overall. What happens is the operator tries to resolve problems instead of just calling a Tech. Makes everyone's job easier. Just make sure you cap how far they can actually troubleshoot.
The lights make the operator part of the machine. This is how the machine talks to the operator.You will have less down time because the operator and the machine are constantly in communication and the machine runs more efficiently. When you do have a problem with the machine the opearator is invaluable in troubleshooting because the operator knows what lights should be on/off under all machine conditions.

The problems you describe are really not problems at all.
Any good structured program takes into account operator input AND feedback. The operator and machine can't work properly without feedback as you have discovered. You need to correct this and add code to allow more feedback to the operator.
I programmed a hydraulic brake shear that had 2 operators. The 2 operators had to load parts from either side of the shear. The 2 operators couldn't see one another and in a noisy plant they couldn't hear one another other either. So how did the 3 of them communicate? 3 being the 2 operators and the machine. Easy. Each operator had an operator's station with an E-stop and a GRN PB light. When an operator on either side of the shear loads a part they break a safety light curtain while inserting the part. Either of the 2 operators can load a part first - there is no set order of operation. They then pull back out the way of their respective curtain and press their own GRN PB. Pressing the GRN PB indicates to the machine that either operator has made a "shear request". The GRN PB at both operator's station would then light "slow flashing" indicating to either operator that the other operator has loaded a part and has made a shear request. The operator that has loaded his part now waits to see when his GRN PB goes from "slow flashing" to "fast flashing". When the slow flashing commences the other operator has 5 sec. to press their own GRN PB or the shear request will time out and both operators GRN PB's would go off. (The shear request was also "reset" on time out). The transistion from "slow flashing" to "fast flashing" indicates to the waiting operator that the second part has been loaded and the second operator has pressed his own GRN PB. Fast flashing aslo indicates to either operator that the shear is "armed" and will shear in 3 sec.

The system works well because either operator knows what is going on simply by the use of one GRN PB light. If the slow flashing light goes out at your operator station and you are still ready to shear than all you have to do is press your GRN PB again. The other operator is safely protected by a light curtain - no need to worry.

Don't add "code" to your program add more common sense "logic". Get in there and operate the machine - or observe the operation - for a while and see what the ergonomics of the system are. Think like an operator and your programs will improve greatly.