Terry Woods
Member
- Join Date
- Apr 2002
- Posts
- 3,170
Much of what has been said lately reflects a lack of interest in the "art" of PLC Programming.
Certainly, one must understand the mechanics of programming PLCs and configuring the associated hardware. But, the true power of the PLC is not known until one looks at PLC programming as the ART that it truely is.
To pursue the "ART" of PLC Programming means to understand what is really necessary to program PLCs to think as humans do.
To many programmers, a PLC is nothing more than a faster version of an operator, or worse, a simple switch-handler designed to reduce real relays and wire count.
A PLC program can not be like an operator unless the programmer had the foresight to create his code in a manner that resembles an operator. He would do well to consider mimicking a very good operator.
One major defect in operators is that they do not know what is happening when failure occurs. Of course, they see the result of the failure. But, usually, they do not know why the failure occurred. All they know is that a FUBAR happened.
Of course, the failure occurred because of some condition. It could be because of a logic fault or an output device fault. In many cases one can not determine that the fault occurred because of an output device, at least, not directly. In that case, one must be able to look at the logical conditions at the time of the fault and then look at the physical results of the fault to determine the cause.
It all depends on the ability to analyze evidence. In some cases the evidence is clear to the PLC and can be easily indicated on an HMI. In some cases, the evidence is less than clear.
In any case, the program should always be able to indicate what it was doing at the time of the fault. Knowing the process, one should always be able to know what the process was expecting to happen next.
Only in this way can the PLC Program hope to have a chance to indicate the true nature of the fault.
A working program is not a problem. A faulted program is a problem... the question is... why did the program fault?
Is it a logic issue? Or is it an output issue? Or is it an Input issue?
You can not KNOW the cause of a problem unless you develop the process in such a way that it can KNOW!
Devopling a process is as much about fault-handling as it is about process-handling. Having a system that can identify its own faults is remarkable!
That is a system that will cure itself! ... eventually... if the programmer is paying attention.
That is attainable though the ART of PLC Programming!
Comments?
Certainly, one must understand the mechanics of programming PLCs and configuring the associated hardware. But, the true power of the PLC is not known until one looks at PLC programming as the ART that it truely is.
To pursue the "ART" of PLC Programming means to understand what is really necessary to program PLCs to think as humans do.
To many programmers, a PLC is nothing more than a faster version of an operator, or worse, a simple switch-handler designed to reduce real relays and wire count.
A PLC program can not be like an operator unless the programmer had the foresight to create his code in a manner that resembles an operator. He would do well to consider mimicking a very good operator.
One major defect in operators is that they do not know what is happening when failure occurs. Of course, they see the result of the failure. But, usually, they do not know why the failure occurred. All they know is that a FUBAR happened.
Of course, the failure occurred because of some condition. It could be because of a logic fault or an output device fault. In many cases one can not determine that the fault occurred because of an output device, at least, not directly. In that case, one must be able to look at the logical conditions at the time of the fault and then look at the physical results of the fault to determine the cause.
It all depends on the ability to analyze evidence. In some cases the evidence is clear to the PLC and can be easily indicated on an HMI. In some cases, the evidence is less than clear.
In any case, the program should always be able to indicate what it was doing at the time of the fault. Knowing the process, one should always be able to know what the process was expecting to happen next.
Only in this way can the PLC Program hope to have a chance to indicate the true nature of the fault.
A working program is not a problem. A faulted program is a problem... the question is... why did the program fault?
Is it a logic issue? Or is it an output issue? Or is it an Input issue?
You can not KNOW the cause of a problem unless you develop the process in such a way that it can KNOW!
Devopling a process is as much about fault-handling as it is about process-handling. Having a system that can identify its own faults is remarkable!
That is a system that will cure itself! ... eventually... if the programmer is paying attention.
That is attainable though the ART of PLC Programming!
Comments?