First of all I want to make an apology. I have offended people who I know nothing about. I have no excuse, it was bad behaviour. I also apologise to Phil, next time I will watch my manners on your forum.
Recent posts on this thread have mentioned passion and this is a very apt word when talking about peoples opinion of their own profession. I have very strong views about the way a PLC program should be constructed with relation to the section of industry in which I work. These views are based not only on personal experience throughout the whole project lifecycle (specify, design, implement, commission, and maintain). But also from listening to the views of others. I would judge myself as a professional (outbursts on forums aside), I am passionate about my work, I know my obligations and I believe in doing the 'right' thing.
My biggest obligation is my family and of course it is the most important one. I must care, nuture and provide for them. In order to provide for my family I have a second obligation. This obligation is to the company that employs me. They must profit and grow, they pay me to achieve those goals. The company employs me because they believe that my skill, knowledge and ability are what they need.
That's me, I'm British, I have lived in Japan for 4-5years, my wife is Japanese.
Looking at Terry original post one more time, and ignoring the word "art", he writes of the importance of writing software to "think" like an operator so that faults can be found and displayed. I would like to raise an alternative view.
Logic faults in ladder logic (or whatever flavor you prefer) are defects in the program that are caused by programmer error or by poor specification/design. They don't appear as if by magic, or by memory corruption, or by CPU failure. These logic faults can be prevented, to a limit. The limit, to which steps will be taken to prevent a logic fault, depends on the application (e.g. a nuclear power plant will require more effort than a baggage handling system).
If there is a fault in the logic of the PLC program it should be corrected. The cost of correcting a defect increases the further along the lifecycle of the project. So I would go for prevention rather than cure when it comes to logic faults in PLC programs.
Secondly, I/O failure and how to detect it. How to combat, or whether to combat this, should be decided by risk assessment. Identify the hazard, decide the severity and specify whether steps should be taken and if so, what.
Thirdly, process faults. The purpose of many machines is to reach a certain state in which production takes place. This could be by opening valves, starting motor or regulating a temperature for instance. Instrumentation is necessary to monitor the state of the machine. Too little instrumentation and there is a risk that the product quality will suffer, too much instrumentation and the machine will not be financially viable. The process state must be displayed and in some cases recorded. Terry gives a good description on the requirements for displaying the process state, so I won't contradict him on this.
