Introduction

I was asked by a local manufacturing company to come in and help them retrieve production information from a department of nipple machines. The production information is gathered in real-time before being integrated into their existing AS/400 payroll system. Hardware wise, they needed twenty-four production monitors (one monitor for each machine) and one CAN-to-serial bridge for the central server. It was my job to design the hardware, program the firmware, and then write the code to aggregate the data before inclusion into the AS/400. Finally, I updated their COBOL payroll system to use the newly gathered data.

I had no idea what I was getting myself into when I started this project. I had only done personal projects involving embedded controllers, and I had no experience with the CAN protocol or LCDs. Finally, I had never worked with an AS/400 system, nor had I done any COBOL programming. All of this was new to me, but I agreed to do the project because the client needed the information to get a handle on production losses and I wanted a project to improve my programming and designing skills.

This was a multi-month project with a tonne of unique challenges. Below describes what I encountered and how I solved them. There are probably a few lessons in here for other people as well.

Requirements

The requirements for the project were as follows:

• Display current cycle count and previous cycle count to the machine operator.
• Store and report cycle information during power outages.
• Bring production data from out in the plant into the office.
• Integrate collected data into existing AS/400 payroll system.

Environment

Each Landis nipple machine is attached to a Syntron vibratory feeder. This presents a unique challenge, since the Syntron works by chopping a three phase 600VAC signal. During half the cycle the bowl is pulling in and during the second half the spring is released. This chopping action produces a huge amount of electrical noise in the area around where the production monitor needs to operate.

In addition to the electrical noise produced by the Syntron, the Landis machines themselves have large electric motors which are under a varying load. Multiple times per shift the machines are turned on and off, so there are power spikes during power-up.

Because the Landis machines are threading steel, there is a tremendous amount of steel filings everywhere, and all the machines are operating with large amounts of oil covering every part of the machine.

Finally, the whole plant is a delta plant, meaning no common ground anywhere. Therefore, all the EMI generated by all the motors and wave chopping units has no path to ground, so it radiates in all directions. This plant is a nightmare to keep electronic devices working. There are professionally engineered PLCs that are constantly losing their firmware because of the amount of electrical noise in the environment. This was my biggest challenge in designing robust micro-controller monitoring units, and in networking these units to a central server located in the office.

Design Decisions

I decided on using a Microchip PIC18F248 as the micro-controller for the production monitors because of it’s built-in CAN support. As mentioned, the operating environment is electrically noisy so I needed a network with a high common-noise rejection design. CAN looked like the best option, so I went with it.

With the micro-controller and network decision out of the way, I proceeded to design the motor load input system and the grip detection system. These Landis machines produce one part by threading one side of the part with one set of cutters, picking the part up, and then threading the rest of the part with a second set of cutters. Therefore, the client defined a “cycle” as a part moving through both cutters. This meant I had to track the status of both grips (which hold the part during the threading process.)

Fortunately, each Landis machine is controller by a small PLC, so I was able to tap into some of it’s outputs for tracking the grips, and to also know when the motor was running, and whether the Landis was in run-mode or manual-mode. Only run-mode cycles counted, so I had to know the difference.

To complete the data acquisition on the network I developed a CAN-to-serial bridge. It’s only roll is to listen for CAN messages on the network and to then translate them to a PC through the RS232 port. It also does the reverse (takes messages from the PC and places them on the network.) I designed the bridge hardware, wrote the firmware, and developed the interface code for the Linux PC that acted as the central data gathering and control point for the network.

The software on the PC was written in Perl and I utilized a PostgreSQL database to store and analyze the incoming data.

The last part of the project was the integration of this newly gathered data into their existing AS/400 COBOL based payroll system. Ultimately, it involved writing about 50 new lines of COBOL code in each of five applications. Finding what lines to add, and where to insert the new logic was a challenge since the majority of the code was not commented, variables were cryptically named, and the original author was no longer available to question.

Conclusion

The project took a lot longer than I had originally expected, but I learnt a tonne working through all the challenges. I now have a much better handle on hardened industrial design. I understand the CAN protocol much better, and how to work with LCDs. I have AS/400 experience (though I find it to be an odd platform) and I know how to program in COBOL (which I hope not to repeat.) All in all it was a fascinating journey.

I am also pleased to report that the customer is extremely happy with the results of the production monitors. They report that the material losses have dropped substantially since the monitors were installed.