We are frequently asked to work on PLC systems for clients that we did not develop. The job could be troubleshooting an issue or adding a new feature to the system. Working with unfamiliar code has its own unique challenges, although we take pride in our ability to do so. Here are some things you should keep in mind when asking an integrator or even your own internal maintenance staff to take a look at your PLC system.
Source Code
Almost every PLC system I've worked with does not store the complete source code with variable names and comments on the actual PLC itself. These comments and names are very helpful for understanding how the system works and what each piece of code does.
Unlike other programming environments, the PLC code is not really 'compiled', so it is possible to see the logic. However, all of the helpful comments, variable names, input and output names, and other descriptors are missing. For a basic PLC program this is not necessarily a problem. However, for complex PLC applications this can be a major concern, potentially adding a significant amount of time to the project. It all depends on the application and what you are trying to do (for example, troubleshoot a simple IO problem or add a new complicated feature or sequence). Keep in mind that not having the source code is not necessarily a show-stopper. Experienced, skilled PLC programmers can often wrap their mind around a system even without variables.
Some companies have a policy of keeping backup copies of the original code on-site. If you bought a turn-key system or used out-side resources to program your system, it is often worth a quick phone call to see if they have a copy of your original code. At DMC our policy of keeping backup copies of the code we create has saved our clients on many occasions.
Simple Solutions
If a system that has been running for months or years just recently started having issues, it most likely will not require a change to the PLC code to fix the issue. A sensor or actuator (pneumatic cylinder, for example) may have recently gone bad, a wire may be loose, or there may be a mechanical part that needs maintenance. Sometimes the PLC hardware itself may need to be replaced, such as a CPU, a battery, or an IO module.
Still, for a complex system isolating the problem may be difficult. Sometimes it is worth the expense to bring your integrator in to locate the issue if downtime is expensive. An integrator sometimes can watch the logic in action and quickly determine which input is not turning on in time. Even without looking at the PLC code, just using an IO list and watching the input and output LEDs on the PLC turn on and off as the system runs can often give a helpful clue.
Structure!
The quality of the original PLC code can have a big impact on how long it takes to troubleshoot an issue. It can have an even bigger impact on how long it takes to modify the PLC code if you need to add a new feature.
Low level PLC programming is fairly intuitive - almost anyone with a laptop and an understanding of basic logic can pick it up. The downside to this is that some moderate to complicated systems are programmed by people who give very little forethought to top level architecture. While all PLC code should be written with some type of structure or design, unfortunately it often is not. There are many options for structure depending upon the application - step sequencer, other state machines, stateless simple interlock system, usage of User Defined Types (UDTs) and function blocks. What should be used depends on the application, but the important thing is that structure is used and is planned out ahead of time.
A well maintained structure is much easier to debug and much easier to modify than a large, kludgy 'rats nest' program. For starters, it's easier to find the problem or determine what needs to be changed. Secondly, it is easier to make changes without impacting other portions of the program when each structure is easily encapsulated.
As a related anecdote, one of our clients had a system built by a machine builder that was not strong on integration and PLC programming. The system had no structure no structure and no comments. After the machine builder was relieved of duty, DMC was brought in to 'pick up the pieces'. Over the years several new features and changes were made, but it was always a struggle for the client to decide if they should continue with band-aid fixes or scrap and reprogram the entire system. The kludgy code base made by the original programmers that a change that should take a couple hours to make could sometimes take anywhere from four hours to two days.
Password Protection
PLC systems can be password protected. Sometimes the client is not given access to the source code and the underlying system. This is particularly common when the client has purchased a productized turn-key system. Unfortunately you will probably have to get access to the password before anyone can modify your code. All may not be lost! - if the system is old and/or if you have given the vendor a fair amount of business, you often can convince them to give you access.
Lean more about DMC's PLC programming services.