BATCH PROCESSING AND BUILDING MATERIALS MIXING

Executive Summary:

Kredit Automation was contracted to retrofit the PLC and HMI (and the software programs for both) on a batch process that combines solid and liquid materials from silos and tanks to produce building envelope solutions and coating systems for building construction, maintenance and restoration. The original control program had a fundamental flaw: it was designed to do just one batch at a time, meaning that one batch had to run to completion before another could be started. But there were two main mixers, so this limitation squandered opportunities to optimize production. Kredit wrote a new program that achieved an unusually large improvement in production for a program change. The new program ran separate, concurrent batches for each mixer. The two batches ran the two mixers independently and each batch took advantage of opportunities to add ingredients to its mixer from a tank or silo when the other batch was not using those items. The result was a 40% increase in the number of batches that could be run in a day.

Project Details:

The customer is an innovative leader and producer of a broad range of cladding, air and moisture barriers and coating systems for building construction, maintenance, and restoration. These versatile solutions are well regarded in the marketplace and the customer was eager to increase production.

For example one product line is a set of air and moisture barrier systems that is engineered to create a waterproof air barrier membrane in wall construction. This fluid-applied waterproof air barrier protects the backup assembly and thus provides significant protection against moisture intrusion and air leakage. This results in significant energy savings in hot and cold climates. Over a million “buckets” of the various products are sold per year. This retrofit project was done at a time when any increase production went straight to the bottom line.

The customer had attempted to “modify” the PLC-5 program to stop waiting for one batch to finish before starting another. These attempts were futile. For one thing, a database with formulas and materials was a major component of the control. There was also scripting code in the HMI. It wasn’t that the system didn’t work; it was just complex and had a fundamental design limitation. It was eventually concluded that only a complete redesign of the control system application would make sense.

The Allen Bradley PLC-5 was replaced with a ControlLogix but the I/O cards and field wiring were left in place. The PLC-5 was removed from its chassis and replaced with a communication module. Thus the PLC chassis was turned into a remote I/O rack (actually two logical racks in one large physical rack). The new ControlLogix chassis with a new PLC was added into the panel. A new PC with the latest Rockwell Software HMI became the new operator interface. (Some auxiliary PanelViews were retained until subsequent projects updated them.) The main thing was a new PLC program was written to allow two batches to run at the same time. Each batch had to wait sometimes for a silo or tank to become unused, and so production was not doubled. But it was significantly increased, by as much as 40% depending on what was being produced that day.

A couple of other innovative simplifications were made. One was the interface to the enterprise IBM mainframe. The mainframe sends orders to the batch system. Rather than use a middleware solution, a simple technique was devised which worked flawlessly. It was realized that for purposes of telling the control system what to make, an order is a relatively simple thing that could be distilled to one line of comma separated items. The system devised was the mainframe sends an order to the control system simply by placing a text file into a specified folder on the PC running the HMI. This file contains the order specified by one line of text consisting of six field values separated by commas. The Rockwell software HMI has an events engine as a standard feature. An event was configured to run every 60 sec to look in the folder for a new order (which is just a text file). If it sees a file, it calls a VBA script. A Microsoft VBA engine is also part of the standard feature set of the HMI so the HMI software does not require any extensions or add-ons to use VBA. The VBA script called when a file was found opened the file, processed the order by doing some formula processing and error checking (also in VBA) and then populating various PLC registers. This VBA code is not trivial and in fact it is fairly complex in stretches, but a crucial point to understand is that it is part of the HMI and travels with the application to a new machine with no extra setup. The HMI software can be installed on a new computer and the application (including the VBA) will run without any extra setup steps needed. The VBA code is in one container and is well commented so it is amenable to being found, understood, and modified. The customer’s project manager reported being able to make a change to the VBA and was quite pleased with both himself and with the fact that the software was organized and commented enough to make this possible.

The 40% increase in production was unusual given that no changes were made to the process or the process equipment. The previously intractable limitation of one batch at a time was eliminated by writing a new program. Some other problems such as the complexity of the database and the link to the mainframe were also solved by doing this project. The HMI was dramatically improved from the standpoint of being redesigned to address numerous issues that had been thorns over the years. The retention of all the field wiring and I/O cards significantly lowered the cost of the project. The customer reported this was one of the most cost effective upgrades ever done at any of its five plant locations.