PLC programmers have been faced with a steep learning curve over the last 25 years, as technologies have moved quickly and almost all industries have implemented programmable logic controllers as a standard. This means that good experienced programmers are hard to find, and while most companies offer programming services there are important features which are often missed out.
Firstly a PLC programmer should write code so that it can be easily understood. Documentation and structure are essential. This often involves a working knowledge of the plant or process, a good PLC should be able to solve engineering problems from a specification, not just produce lines of code. From my experience the best PLC programmers are always firstly engineers.
Secondly the end user should never need to look at the PLC programmer's code this might seem a contradiction of point one but a good program will perform without intervention. I work on the theory if something looks rushed and untidy it usually is.
Thirdly think robustness this means if a machine or process stops the operator/technician should know why straight away, diagnosing software faults should not require a specialist. With the implementation of field busses and integrated devices this becomes increasingly difficult as programmers often adopt the Idea of it works leave it, upon the first failure nobody can ever diagnose the issue. When using new technologies time should be spent looking at the functionality. In a recent project I managed to mimic the entire Profibus network with over 50 drives into the SCADA, two days later a drive faulted and an operator was able to show the maintenance guy exactly where the fault was, the drive was replaced and production resumed within half an hour. Think information and look at what can hang up the operation.
One good technique I have found on making code more robust is sequential counts; I have spent the last 5 years developing my own ladder sequential charts. After working with manufacturers own add -on packages ,at a premium, my opinion is ladder steps are more cost effective and usable.
Documentation - As a minimum every PLC code should include as a minimum an Operand comment, whether this is an input output or internal register. In my project I will also always try to cross reference this with the electrical drawing. Block Comment the first block in a PLC code should include important traceability information, a comment of any modifications the date and reasons should be quickly visible. Rung comment all rungs should give a functional description of what they are doing.
Structure - Structure should always follow the flow of the machine, for example a packaging machine should start a infeed, define each operation in a separate routine and end with the out feed. This technique seems to have been missed by many programmers making diagnosis and modification difficult.
It should never be underestimated how much machine/process availability can be increased through good programming techniques. Remember PLC programming is not a black art, just because something is not visible does not mean it should not be done correctly. Always demand more from systems integrators and PLC programmers.
Read more: http://www.articlesbase.com/programming-articles/what-makes-a-good-plc-program-1169532.html#ixzz1RUysHWwI
Under Creative Commons License: Attribution No Derivatives