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 problematic 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 sent 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 failed 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…[ad_2]
Sourced from by Mark Till