My Time At Kimberly-Clark

Once upon a time I was a development engineer for Kimberly-Clark. That was a fun time in my life. Our group built registration control systems for their converting machines. Mostly feminine care products. We did the development in Neenah at the Corporate R&D and then deployed those systems at various plants in the US and Canada.

I liked that job a lot. The people were great. Neenah was a nice place to live. And I was learning a lot about automation and the difficulties you encounter deploying automation in a real world environment. Operations people are the same everywhere; the only thing that counts is how much that machine produced during the last shift. If you get in the way of that, there is trouble.

Those were the days that I first discovered CAN – Controller Area Networking. It was an amazing technology in the late 1980s. The speeds, 125K, 500K, 1M, were unbelievable alongside 9600 baud serial channels. Remember that at the time line speeds for the converting machine were really slow compared to today. Products moved down the line like glaciers. Today, KC makes 200 diapers every second. We made maybe 5 every second in the old days.

CAN was a breakthrough for a lot of reasons. Here are some of the advantages of CAN in those early days:

1.       Much less troublesome wiring. Daisy chaining 485 presents all sorts of problems. If you have just one loose wire or one bad device, nothing works and it is impossible to find. CAN is much easier to wire and much easier to troubleshoot.

2.       Power on the wire. That was a godsend. We could power sensors and some actuators without bringing power to them.

3.       Standard interfaces. In those days, the silicon for CAN wasn’t in our 8-bit microprocessors like it is today. We had standalone CAN MACs from Intel and others. Those guys all had standard interfaces that once we figured out could be used over and over again.

4.       Fast I/O movement – as I said before; massively faster than anything we were used to using.

5.       Much better troubleshooting – our micro got a signal if there was trouble sending data out. We never had that with serial.

6.       And best of all, maximum bamndwidth utilitization because of the unique way it does bus arbitration.

The list goes on and on. CAN for us in those old days was this very fast pipe that we could use to move lots of data (in 1980 terms) from one place to the next with little overhead.  At first we just stuffed our own data in a CAN packet. Later we came to understand the power of adding an application layer protocol on top of it to give us DeviceNet, CANopen, J1939 and all the rest of the CAN application layers.

Today, CAN is the basis for a lot of our gateways. We have DeviceNet gateways the move data between DeviceNet networks and Modbus (https://www.rtautomation.com/products/460/mmds.html ), DeviceNet and EtherNet/IP (https://www.rtautomation.com/products/460/esds.html) and DeviceNet to many other protocols. Soon we’ll have a bunch of CANopen gateways and J1939 gateways.

The world had changed a lot from my early days at KC. Now, I’m no  longer living at plants like the ones in New Milford, CT, Memphis, TN and Conway, AR. Instead I’m helping a lot of guys like you get more done, in less time with the easiest to use, fastest to deploy and best supported gateways in the automation industry.

I enjoyed my time at KC as a development engineer but I really love making you more productive.

John