When Alan Whiten signed on as corporate manufacturing engineer for Great Dane Trailers Inc. a few years ago, he quickly recognized a problem that he hadn’t faced in previous jobs.
At Great Dane, a manufacturer of over-the-road truck trailers, Whiten heads up a three-person engineering staff whose primary responsibility is to design, build and support custom automation equipment for the company’s factories.
That’s the same kind of work that Whiten had done for two previous automotive industry suppliers. But in those jobs, Whiten had responsibility for only a single plant. At Great Dane, by contrast, his three-person team is charged with handling all of the Savannah, Ga.-based company’s nine plants throughout the South and the Midwest.
“When I only had a single plant, it was easy to go out to a piece of equipment and troubleshoot it when necessary,” Whiten says. But in Great Dane’s multi-plant environment, he quickly learned that machine troubleshooting—and even minor tweaking—would be a lot more costly and time-consuming.
Blind troubleshooting
Several of Great Dane’s plants have machines requiring complex motion control. When Whiten arrived at Great Dane in mid-1998, he found that he and his Savannah-based staff were spending a great deal of time on the phone when something went wrong with one of those motion systems. The plants had no technical staff to deal with automation problems. And because the Savannah engineers had no remote access to the systems, they sometimes spent hours doing “blind” troubleshooting by telephone with operators at the plants. All the while, scrap could be accumulating, or the machine could be down entirely, costing the company money and lost production time.
In some cases, Whiten or one of his engineers were forced to make emergency trips to the plants, sometimes even for minor adjustments. “We’ve got a couple of pieces of equipment where accuracy is fairly critical, and because of mechanical wear, we’d have to change a start position or a move position by a few thousandths. Since they didn’t have anybody at the facility to do it, we had to hop on a plane and go make the change,” Whiten relates.
That got expensive very quickly. And because Whiten anticipated designing and installing a number of new automation machines throughout the plants, he knew that the problem would only get worse. He wasn’t on the job for long before he started searching for a solution.
His goal was to come up with a wide-area networking system that would enable the Savannah engineering staff to remotely access real-time data from equipment in the plants. Such a system would not only eliminate the need for blind troubleshooting, cutting machine downtime and travel costs alike, but it would also enable engineers to remotely monitor and control plant processes from corporate headquarters.
As Whiten looked into the issue, he discovered that Great Dane had recently completed a project running fiber optic cable throughout the shop floor at all of its plants, as part of a corporate Intranet. The fiber lines, which were linked to headquarters via T1 phone lines, had excess capacity.
Obvious choice
“Once I realized that, it was an obvious decision to set up an Ethernet, because the fiber was already there, and I wouldn’t have to spend any money, except to do drop points out to the machines, which is cheap,” Whiten says. Because Ethernet is an open networking standard, Whiten knew that he would be able to readily hook up programmable logic controllers (PLCs) and other gear from multiple automation vendors.
One potential hurdle was the fact that Great Dane’s corporate Intranet was running a Token Ring networking scheme, Whiten recalls. But when he brought up the issue with Great Dane’s IT department, Whiten learned that the problem could be solved easily by installing an Ethernet-to-Token Ring router, which would allow the two networks to communicate.
Great Dane already had PLCs from various vendors in its plants. But as Whiten began researching Ethernet PLC networking approaches, he quickly settled on an open architecture system known as the Transparent Factory, developed by Schneider Electric Industrial Automation, North Andover, Mass., supplier of Modicon PLCs. Transparent Factory is based on Modbus TCP protocol running over an Ethernet backbone for linking Web-enabled plant floor devices such as PLCs and input/output (I/O) devices using TCP/IP technology. Standard Web browser technology can be used in Intranet or Internet environments to access data and communicate with devices.
Whiten was impressed with Schneider’s commitment to the open architecture approach. “At the time, for the dollar, Modicon had the best product,” he says. Even Modicon low-end series Momentum PLCs had Ethernet built in, and were priced at significantly less than competing vendors’ Ethernet-enabled controllers. “Modicon could supply me with the broadest range of Ethernet-ready products,” he says. An added plus, according to Whiten, was that Schneider’s Modicon products at the time were the only PLCs that offered control modules for Serial Real-time Communication System (SERCOS), a motion control standard.
By mid-1999, about a year after Whiten arrived at Great Dane, his team had the networking system in place and had hooked up the first plant systems. Since then, they’ve added more than a dozen additional machines at various Great Dane plants, all controlled by Web-enabled, Modicon PLCs that are remotely accessible through the network. Older PLCs and other equipment from various vendors have also been linked using bridges and routers. A central Web server enables access to every factory device on the network and also feeds plant floor data to Great Dane’s office systems, where it can be monitored and archived.
With the network in place, Whiten and his staff find themselves hopping on planes much less often these days. Instead, “if a machine goes down, we get a phone call from the plant and we hop on our company network, and we basically do troubleshooting right over the phone for them,” Whiten says. Because the engineers can see real-time data from the machines, remote diagnostics work is greatly simplified, and needed adjustments can often be made by sending machine commands via the network.
The network is also making a difference for less severe problems on a day-to-day basis, Whiten adds. “We get some phone calls where the machine is not necessarily down, but the operator thinks that something is going on, and he isn’t sure what it is,” Whiten says. “It’s not anything that we would have flown out for earlier, but we can sometimes avoid either days of making scrap or having issues at the plant, because we’re able to fix it right away.”
Push it further
While the network has solved Whiten’s original problem related to remote machine troubleshooting, he now plans to push the benefits further. For example, Whiten’s team recently developed software by which complex production order information can be stored in a database, then pulled off the network by machine operators when needed. This approach saves time and eliminates errors compared to the previous paper-based method, by which operators were required to key the order data into the production system.
“The ability to troubleshoot long distance and solve problems quickly was an immediate need,” Whiten says. “But the whole reason I chose the Ethernet platform was because I knew that down the road, it would be easy for us to collect data, and that we could also use it to ease some tasks for the shop floor operators. We’re just getting into that now,” he observes, “and we’ve also got other things planned to improve our systems further.”
