After spending the last several months working on some of my entrepreneurial ideas and teaching PLC programming classes, I just spent the last couple of weeks contracting on a machine and system startup/debug job. I feel very fortunate to have some great contacts in the integration and machine-building world who allow me to keep my fingers in the pie and play with the big toys despite my crazy schedule. It is fairly easy to get work if you are willing to devote at least six months at a time to a project, but when you only have a few weeks open at a time it can be more difficult to find meaningful hands-on work.
This project involves a system with about 23 different assembly stations controlled by 12 PLCs. There is also a central SCADA and control PLC that collects information and validates the product as it makes its way through the assembly process. As with the debug and startup process I described last February, this involved ensuring that the electrical and safety systems were correctly wired and going through all of the steps I described in ensuring that the machine performs as designed.
In this case the customer has a very specific PLC and HMI template that must be used in programming the machine. This template is derived very closely from a GM template that runs on an Allen-Bradley ControlLogix platform. The HMIs are PanelView+ SE units and the programs are integrated very tightly with the PLC template. When I first started working on other people’s equipment in the mid-1990s I was very critical of people’s programming styles and procedures, often because I didn’t understand them very well. They were often not well documented (or maybe I just didn’t receive the documentation…) and styles could be somewhat cryptic.
After looking at hundreds of other people’s programs and writing a lot of code over the last 20 years or so, I have come to realize that most templates and programming styles are at least adequate. They are usually designed to make it easier and faster for development, and hopefully documented well enough for a decent programmer to troubleshoot quickly. Of course I have my preferences when it comes to programming techniques, but programmers usually simply prefer what they are most familiar with.
Personally I think this template is a pretty darn good one. It uses a different organizational structure than I have described in my PLC series on this blog, but it truly makes it easier for development. Subroutines and add-on instructions (AOIs) are pre-written and well documented for easy modification. Since the customer uses very specific types of modules (nut-runners, torque drivers, servo presses, smart cameras, testers etc.), sections of the program are well tested and ready to be integrated. This makes it as easy as dropping a section of code into the program and assigning addresses and tagnames.
About a year and a half ago I worked on another template that had some similarities to this one. It was developed by another machine builder, but because I wasn’t working directly with the originator of the code it was much more difficult to figure out. The code was not very well documented so I spent a lot more time commenting the program. This of course took a lot more time and effort which cost the customer more money. On this project, since the customer provided a well-documented template, the process was much more cost effective, regardless of whether we programmers thought the programming style was good or bad. I think this reinforces the fact that having a standard method of programming common to all engineers who will ever work on the machinery saves the customer money over the lifetime of the equipment.
It was really enjoyable to have this little hiatus from teaching and product development. I am grateful to the companies that have allowed me to work on this project around my schedule. I will be spending a couple more weeks at this machine builder’s facility in January as well as teaching a few more classes over the next couple of months. Again, thanks to Jeff at nth and Kenneth at Evana!