We've all been there, you have a customer that wants to upgrade their software in a discontinued processor to get features that are on a updated platform. This can be a difficult task sometimes because technology is changing at a rapid pace. This will give you a glimpse of what it actually takes to achieve this task.
The project
The current processor is a Micrologix 1500 PLC with RS-232 serial communications talking to a Maple Systems HMI5121XL HMI. There is standardized software written after the machines were installed that the customer would like to get on their 6 year old machines that gives them features that they currently don't have. The standardized machines used a Micrologix 1400 PLC with Ethernet communications talking to a Maple Systems HMI5121XL HMI.
Modifying the PLC program
Luckily the MLX1400 and MLX1500 use RSLogix 500 so changing the PLC type is just a dropdown menu away. Ideally the software will be written in a way that allows you to easily update the physical I/O and be on your way. That's why I recommend writing your code with input and output mapping. If you don't know what that is or how to use it you can read about it here.
That's it, right? I wish there was a magic button that would allow us to change the processor so easily. For this project I had to re-map a few of the physical I/O bits to match the machine's physical I/O layout. There was one less expansion card between the two system layouts that took some time to sort out and map to the 1500's I/O. The expansion cards weren't the same, so I had to move the extra I/O card to the proper data address and re-map it's I/O.
Modifying the HMI program
The HMI program is written in a way that takes advantage of a tag system so that changing communications isn't a weeks long process. Otherwise, you would have to go through each and every button in the project and make sure that it was mapped to the correct data address in the PLC. The communication setup is such that changing over from Ethernet to RS-232 communications can be done with a selection menu that changes the addressing of the tag data.
The problem with visualization is that there's all sorts of screens, input boxes, text boxes, and menus that need to be updated and changed so that the operator isn't looking at a HMI written for Ethernet that uses RS-232 communication. There's no need to give the operator the option of updating the IP Address of the HMI when there's no IP Address being used on the system. Most of your time when updating system software is going to be on the visualization side of programming time and therefore should be planned accordingly when estimating timelines. When all said and done, the time it took to make the HMI changes came out to almost 3 times what the PLC took.
Debug, testing, and Implementing the changes
If you don't have some sort of testing setup I would highly recommend trying to get one. Downloading and testing the PLC and HMI software on a physical setup before going out in the field will save you time and headaches when your in front of the customer.
Even with all the planning and preparation there's no guarantee you won't have to implement some last minute changes in the field. When I tested everything on the bench I was mainly testing the communication changes that were made in the software. Functionality on this project was a little harder to test. However, even when everything worked on the desktop, there were some unexpected changes to be made in the field. The analog scaling of the new system did not match the old system in the field, therefore I had to make some changes and do some debugging in the field while on site at the customer. At the end of the day it added about an hour or two of debug time in the field.
Hardware used
Micrologix 1500
Software used
Allen Bradley - RSLogix 500 v11
Maple Systems - EasyBuilder Pro v6.07.02.246
Final thoughts
There's more to changing over a software program than meets the eye. Hopefully by reading this brief summary of our project you have a better understanding of the process of doing programming changes on automation equipment.
It's just programming. - Mike Fryauf
A lot of the time OEMs don't want to deal with the effort to make these kind of changes in the field and would rather see the revenue produced by selling the customer new equipment instead of modifying and upgrading equipment in the field. When done properly with the correct resources this kind of project can save the customer money in the long run by extending the useful life of their equipment.
If you have a project like this one don't hesitate to ask us how we can help you save money on new equipment by bringing new life into your existing equipment.
Did you like this post?
