Fault finding

How does forcing out puts help find faults in the program?

Sorry i'm new to plcs, still learning the ropes

Clarify....

adamhigg1997 said:

How does forcing out puts help find faults in the program?

Sorry i'm new to plcs, still learning the ropes

Click to expand...

The word "Fault" is generally used when the proccesor has an error... and there are error codes that will be created, depending on what type of PLC you are refering to. Therefore, first clarify the word "fault" then let us know what type of PLC...

Nine times out of ten the "fault" is in the devices hanging off the PLC not in the program. One has to be very careful forcing outputs - things tend to go bang in the night if the "troubleshooter" does not know what he/she is doing.

BobB said:

One has to be very careful forcing outputs - things tend to go bang in the night if the "troubleshooter" does not know what he/she is doing.

Click to expand...

Bob is dead on here!

Forcing is good because it allows you to isolate actions (real world inputs/outputs) and diagnose them by themselves - outside of the normal process flow.

Forcing is very dangerous if you don't know what the force will/should do. You can force an output that might otherwise be interlocked (to prevent personnel/equipment/product damage) and cause damage to occur and/or cause unsafe conditions to exist.

So - it's a good tool, but be very careful with it . . .

Marc

I usually use output forcing in the initial startup to verify valves are opening. This verifies that everything is wired correctly. I have seen it used to bump a motor to insure correct rotation, but this also depends on what type of motor and there are also other methods to check rotation.

Some also use it to verify faults.

As noted above, utmost care should be used to prevent damage to the machine. When debugging a machine, it might be wise to disconnect output power before forces are used.

Typically, when doing the initial commissioning of a system, the wiring must be checked. These are typically called "P & ID checks," from the name of the drawings that are referenced (piping and instrumentation diagram).

Don't confuse the above with PID controllers.

So, if you want to know an input is wired correctly, you have someone go out to the device (like a limit switch) and either operate it or jumper or open the connections, or whatever is necessary to activate it. There will be someone with a computer connected to the PLC, monitoring the input to insure that it changes states.

Likewise, the one with the computer can force the output, while the guy in the field can verify that the proper device operates.

After commissioning, the forces are used (knowing the wiring is correct) to determine if the wiring has failed. If you force an output, and the correct response does not occur, you have an electrical problem. If you force an output, and the correct response does occur, then you have a different problem (like missing a necessary input or similar).

HTH,
Don

My biggest pet hate with PLC control systems is those bloody relays with latching mechanisms. Someone latches a relay, the PLC thinks it is off, applies all the usual interlocks in the program and swithces on another output and BANG!!!!

What the heck was that? Destroyed contactors, crashed machines.

In the meantime the maintenance/operator guy realises what he has done, unlatches the relay and blames the PLC/programmer. Then try and prove it was not your fault. Not a chance in the world quite frankly. Finish up being sued. You probably know what has happened but cannot prove it.

I have refused to implement a PLC system before where they insisted on those rotten relays. They are far more dangerous than the programmer forcing bits in the PLC IMO.

A Simple explanation...

When commisioning a system, we first do all the point to point checks (signed by the programmer and the plant) then we begin a systematic testing of the logic and every possible situation that could occure (also signed by the plant) we then have training, and maybe one week of supervised operation. After all this the plant accepts the equipment. If there is a "stange happening" I explain the PLC programming as this: (another reason why PLCs will not go away)

THe program of oa PLC simply does NOT change, once it is writen it is exactly like a hard wired cabinet, if there is a flaw in the logic it is understandable, but when a piece of equipment that was working suddenly starts doing strange things they should be looking at devices such as a faulty sensor, relay, fuse, or broken connection. The PLC logic simply does not change its mind one day and decide to do things different.

For us this is easy to understand, for plant operations and bean counters its just a black box and they have no clue.

The original question was...
How does forcing out puts help find faults in the program?

The question is obviously referring to Faults in the Process (not Processor Faults).

Process Faults are caused by two possibilities... a failed component in the field (input or output), or bad code (a PLC will do EXACTLY what you tell it to do!).

With respect to Outputs...

While the Process is in MANUAL... the careful application of a Force can be used to verify that a particular output device is working. HOWEVER, one must be mindful of what the forcing action will do.

Now, even if the Process is in MANUAL, there might very well be moving devices. For example, there might be a Motor (driving a Line Shaft). A particular device is driven by the line shaft through a Brake and Clutch arrangement.

While in MANUAL, the motor (line shaft) might very well be running. If not being manually told to do otherwise, a particular driven device would probably be stopped. That is, the Clutch would be DISENGAGED and the BRAKE would be ENGAGED. With respect to the particular signals controlling the clutch and brake, the relationship of the mechanical state of the device and the logical state of the signal depends on the particular circumstance.

In some cases, it might be desireable to have the Brake Engaged when the output signal is ON... in others, when the output signal is OFF... it depends.

At the same time, it might be desireable to have the Clutch Engaged when the output signal is ON... in others, when the output signal is OFF... it depends.

In any case, the relationship between the two needs to be considered carefully. A particular combination might provide a safer situation under a failure condition, however, at the expense of the hardware. Again, it depends.

So... back to the Forcing issue... If the Motor (Line Shaft) is running and you suspect that you have a problem with the Clutch and/or Brake then it is best to stop the motor (line shaft) before testing.

You might be able to get away with testing the brake only, while the line shaft is running... ONLY if doing so doesn't allow the device to go into any kind of free-fall.

Let's assume that you decide to stop the line shaft (good choice)...

Now, the normal code, AUTO and MANUAL, should be checking to see that the Motor (line shaft) is indeed running before allowing the Brake and Clutch to operate. If the motor (line shaft) is not running, then you can not exercise the Brake and Clutch by normal manual means (by the operator).

So, in this case, you can simply Force/Unforce the outputs to exercise the devices to see that the devices are infact operating as expected.

Again, be very mindful of what will happen if a particular output is Forced and it's relationship to other related outputs. Don't be afraid... be smart!

With respect to Inputs...

This too has to be considered very carefully. The purpose of Forcing an Input is to enact or to allow the enactment of subsequent logic activity in the program.

Forcing an Input while in MANUAL or AUTO might produce really bad results. CONSIDER CAREFULLY what you are doing!

If forcing an input causes any output activity to occur, or if it allows an output activity to occur sooner or later than expected, then... it's probably NOT a good idea.

Whether or not this has any benefit depends on how the code is written. For example, depending on the operating mode (Auto/Manual) forcing the particular input might cause all kinds of "internal logic" to be enacted WITHOUT causing any actual output activity. This could be used simply to verify that the "internal logic" unfolds as expected.

If you want to test a section of code and that section of code drives an output, then, you might be able to get away with Forcing the Output OFF before Forcing the Input ON.

Be mindful of what that particular Input might be doing in other sections of code.

Given enough time to work on a particular process, a programmer can build-in the coding necessary to provide for safe Force/Testing. It takes time, sometimes a lot of time, and a great deal of careful planning.

Instead of applying actual forces, the code could be designed to support device testing through the MMI/HMI. While that takes a lot of effort on the front-end, it could save great amounts of time and money when needed.

If properly designed, then even the operators and maintenance folks can do the troubleshooting through the MMI/HMI. You could stay home in bed!

It's all about developing a concept and providing the code to support the concept. The most important tool necessary for developing a concept is... IMAGINATION!

Of course, many other "tools" are required to develop a concept. But, without IMAGINATION, you're only building a switch-handler.