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.
