Every once in a while I get someone that just can’t understand why one EtherNet/IP node can’t talk to another EtherNet/IP node. It’s a common objection to CIP (Common Industrial Protocol) in general and EtherNet/IP in particular.

Why do they want to do that? Well, for lots of reasons. If one node detects a quality problem, other nodes may want to act on that. If a downstream impurity is high, there is no sense in injecting more expensive raw materials into the process. The best thing to do is to shut that injection process down.

CIP, EtherNet/IP, DeviceNet and the other protocols based on CIP are PLC-centric. That means that they are nearly always PLC based. Those systems have a PLC getting inputs from the network, processing logic and sending new outputs on the network.

Essentially, what these people are saying is that they want to eliminate the PLC. They don’t want to eliminate the logic – they still need the logic. They just want to move it farther down the automation architecture.

This is possible, even desirable in some applications. In fact, that’s what the CoDeSys Open Control Tool is designed to do. CoDeSys is an open PLC language that can be easily (within reason) ported to an embedded platform. You can then write logic for drives, valve controllers, IO blocks and anything else having the CoDeSys control engine.

OK, you do this and now you’ve eliminated the PLC. Great! Hooray – let’s all cheer. But now you’ve introduced a whole host of new problems. You need to keep track of all this low level code that’s distributed around the network, you need to have access to the I/O of the other nodes on the network – remember; you’ll need to make sure that outputs are only driven from one source. And how are you going to synchronize code that is running in 30 different processors.

Now, there is technology that addresses a lot of these problems. And there are people in universities and research labs that are trying out these solutions. Lucky for them, they have lots and lots of time and usually money to buy all sorts of stuff. But the short answer for the rest of us is to just use a PLC. Until there is a real easy way to address the backup, synchronization and management of distributed control we’ll just keep doing what we know works and has the least risk.

Appreciate your PLC more now? If so, just drop out to the production floor and give it a little hug…After all Valentines Day is nearly here.

I get a lot of questions from customers about replacing RsLinx in their automation systems. It’s something that I have always wondered about. RsLinx is a good tool and provides a lot of functionality so why are these customers trying to eliminate it?

Well, for those of you that don’t know, what the heck is RsLinx? RsLinx is a software driver that knows all about talking to PLCs. Every PLC RA makes as a matter of fact. It can read and write registers in the PLC5s, SLCs, Logix and more. It is a communication server that can talk to any RA PLC that has an Ethernet interface. Sorry, for you PLC2 fans, you’re still out of luck [By the way, got a call today from an OEM that has hundreds of PLC2s and wants to keep them running – I’m going to build him a little interface box].

RsLinx has the PCCC drivers to talk to the PLC5 series, the SLC series and the MicroLogix. PCCC is the Programmable Controller Command and Control Language. It’s a binary protocol that implements the Read and Write command set that every RA PLC uses. RsLinx also has a little known, proprietary driver for the Logix series. That driver allows RsLinx to resolve tag names into an address and then pull data out of a PLC in a block read.

That’s the biggest difference between the way 3^rd party devices access RA Logix processors and how RA devices access Logix processors. 3^rd Party devices have to use the open CIP Data Service protocol standard to access the data tables of PLCs. The CIP Data Service protocol is open but not widely distributed. It’s on the RA website but you have to really hunt to find it.

The biggest drawback to the CIP Service is that you have to send the tag names to a Logix PLC to read and write data. That sucks big time! The packets going to the Logix processor are limited to 514 bytes and if you have 20 character string names plus 10 bytes of overhead per tag you can only get 10 to 15 tags in a message. Best case you are only going to get 30 or so messages through a second so your limited to less than 500 tags per second. That’s really slow for lots and lots of applications.

Though it doesn’t work very well for data intensive applications. If you just want to build your own solution with smaller data sets or you don’t have a critical time constraints, 3^rd party applications like the RTA EtherNet/IP Tag Client work really well. From your app you simply build a structure full of tags to read or write and send it to the Tag Client. It does a call back when your data is ready. That software is really handy for a lot of non-data intensive applications.

So, why don’t people want to use RsLinx? Mostly it’s price. If you have an application that is a dashboard, a vision system or something else; you have to include the RsLinx in every runtime. If you use something like our Tag Client to access a Logix processor, you avoid that runtime cost. As long as you don’t have thousands of tags to access or need millisecond response you’ve saved yourself a lot of money over the long run.

But what if you need that kind of response or if you have lots and lots of tags? Well I have some thoughts on that and I’ll share them in the next article.

Moving DeviceNet Data to a MicroLogix…Yes It’s Simple

No, this isn’t a torture device used at Guantonamo. And no, it’s not an image I created using my MAC (Truth be told I wouldn’t know how to turn a MAC on). It’s the 100^th Anniversary of the Swiss Army Knife. It’s a certified Guiness Book of World Records, largest Swiss Army Knife ever produced. 80 Tools. 110 different operations. 110 operations – that’s probably how many you’ll need if your kids leave it on the living room floor and you step on it!

Quite a device. If a guy was talented (let’s me out), you could build a shopping center with this knife. Just drop him on a desert island with this knife, come back 90 days later and you’d find a shopping center.

But if you look at it, it’s really pretty hard to use. It would probably take me about 10 minutes to find and isolate the right tool. I’d have ten puncture wounds from futtsing with all the other tools. Not my first choice for a tool. Hard to use, complicated with too many features.

On the other hand I give you the lowly butter knife:

What an incredible tool this is! It’s a combination screwdriver, hammer, box opener, paper weight and butter and jelly spreading device. It’s incredibly easy to use. Even if you use it upside down or invert it you can still get the job done.

That’s the point I was making today to one of our distributors. Our newest 460 product takes data from a series of DeviceNet devices and writes them into a Micrologix PLC. It takes data out of the Micrologix PLC and writes the data into those DeviceNet devices. And no, it doesn’t take 2 days, a 237 page manual, 4 calls to technical support and your lucky rabbits foot to make it work. It’s all web server based. Just link files in the PLC to the DeviceNet data for each slave. Less than 10 minutes to setup and check out. That’s why we say “The Hardest Part is Opening The Box”.