Skip to main content

Networking and IT across a large-scale manufacturing setting presents serious challenges. The legacy equipment involved presents a difficult situation for achieving interoperability, and the sheer size of the manufacturing complex makes cabling a daunting task to say the least. Sometimes a company turns to a sneakernet solution—literally networking by way of shoe leather—wherein techs and designers tote USB thumb drives to transfer data between the design workstations and the CNC machines fabricating the products.

A sneakernet network poses all sorts of security risks, and saps productivity with all the extra walking that is needed in the manufacturing processes.

Read about how Paul Reissner, a New Jersey-based networking administrator specializes in IT for manufacturing, solved sneakernet for his industrial client, which had several Computer Numerical Cutting (CNC) machines deployed across a warehouse the size of a city block.

HardBoiled: Tell us about the client and the CNC machines you were working with for the project?

Paul Reissner: The client is a multi-site steel plate processing company. Essentially they get large steel plates shipped in, and they cut and sometimes fabricate parts. Primarily they use CNC machines to turn the raw materials into parts. Unlike something like a 3D printer, or even a normal CNC milling machine, these are computer-controlled plasma (or other) types of cutting machines. The largest was easily 12 feet wide by 36 feet long—I don’t know the standard size of plates, so that’s probably not quite right, I’m just ballparking here. There are two main parts of that type of CNC machine, the actual cutting parts—lots of stuff I don’t really understand—and then the controller that handles moving the head.

What about the onboard computers controlling these beasts?

There were a wide range of computers, some of them fairly new and running Pentium 4s and Windows XP Embedded; others had embedded 386 or even 8086/8 processors and likely ran on a modified version of DOS or CPM. All of them thankfully were the same make (Lincoln Electric/Burny) and the manufacturer’s support department was great about supporting these old systems.

Describe the problem your client was trying to solve.

The building is a very large warehouse, easily a city block long. The offices were on one side and the cutting machine was all the way across the building. Navigating through the rows of stock and walking the length of building takes a good 10 minutes to get from the officers to the machine—even longer if moving stock around the complex. Since these machines often have no local storage, or you may be making a new part, the CAD file would need to be either loaded onto a thumb drive, or in the case of the older machines, a laptop, and manually walked over to the machine to be loaded.

Sounds like a classic sneaker-net setup—lots of unnecessary legwork.

On top of this, there’s a good deal of prep work that needs to be done, and it’s very possible that the CAD file isn’t quite correct, so generally they do run a test run, and if anything needs to be changed it’s another few trips back and forth just to get production moving. Obviously this isn’t productive and reduces the amount of parts they can make in a single shift.

What was the existing networking and operating system infrastructure like in the warehouse?  

Some of the newer machines did have network connections and did run on a modern operating system so that was easy to interact with, but the majority of them lacked a traditional user interface so networking wasn’t always possible. With Windows XP Embedded end of life approaching, doing it right [securely] was a networking concern. Ideally the answer is to just go ahead and purchase a new control unit running a new operating system; however these machines can easily run in the tens of thousands of dollars, not including the changes that need to be made to the cutting device.

What solutions did they look at and ultimately reject, if any?

My initial suggestion was to just run RS-232 over Cat 5 or possibly Fiber (depending on the length of the run), as this was the simplest solution since it required no additional software or hardware, just wiring. This was ultimately shot down, since despite eliminating the long walks, it did require dedicating machines to tables, or an [additional] machine to transfer the data. From there we did float around other ideas like mounting rugged computers to the tables, but ultimately this would have required some training for staff and there were concerns about electromagnetic interference (EMI).

Describe the solution they decided on–what was the hardware and software involved?

It was a Goldilocks solution in a matter of price and training. Siemens makes rugged serial to Ethernet servers designed to operate in these types of environment that were priced reasonably and most importantly were backed by a large company—many similar solutions were small companies that didn’t have any real backing. The devices were small enough to be mounted right on the computers, and since they used Ethernet they were very easy to integrate into the existing network and CAD software.

Please talk about the challenges you overcame implementing the solution?

All too often the solution for getting legacy equipment to mesh with a modern network is to just replace hardware and software. While that does cost money it’s usually not a burden on most companies. However in this situation it just wasn’t possible. From a technical standpoint the sheer amount of copper required was, at least to me, impressive; I’ve never needed to worry about routing cabling to avoid running too much before.

How were you able to figure out the most efficient way to lay the cabling?

As far as overcoming those challenges, actually seeing the building and talking with the people working with the equipment it was eye opening and really helped me understand how these devices were used. Having to actually get up on the table and walk around—in dress shoes and nice slacks no less—and inspect the wiring path for the tables really made me realize how integrated everything was.

How is your client using the solution now? 

Everything is running smooth as silk, and as expected. The designers are doing their thing and simply telling the CAD software which table they need to drop the load. The guys on the floor actually don’t notice anything different—they just tell the machine what to load or run depending on the model.

Have you learned about any quantifiable results?

I can’t speak on any hard numbers since it’s only been a few months, but I can say for certain the designers are much happier not having to walk across the building to load files. It’s also a lot easier to get in touch with them as they’re much more likely to be at their desk. Production also seems to be higher, but it’s hard to tell if that’s just more orders coming or quicker turnaround.

Let us know in the comments—what sneakernet solutions have you deployed or seen in action?

Paul Reissner

Paul Reissner is a Network/Systems Administrator based in New Jersey. He has more than 8 years of IT experience.

Case Study: Solving Sneakernet with Serial to Ethernet Servers
Article Name
Case Study: Solving Sneakernet with Serial to Ethernet Servers
A sneakernet solution—literally networking by way of shoe leather—poses all sorts of problems in manufacturing IT. Here is how to fix it.
Adam Lovinus

Author Adam Lovinus

A tech writer and Raspberry Pi enthusiast from Orange County, California.

More posts by Adam Lovinus

What's your take?