There are all kinds of ways for Microsoft Windows users to get data in and out of ControlLogix and CompactLogix PLCs. Rockwell sells a of tool called RSLinx. There are a bunch of different models and ways to use it.

There are also OPC Servers. OPC  uses native Microsoft technology to move data between applications. With that technology, one application can consume data generated by another application. If for example, you have a database collecting user names that accessed your stockroom. With this technology you could automatically transfer today’s access list to a Microsoft Word document. It’s relatively easy to get data from one MS application to another MS application.

But what about those of us that want to use Linux. How can a Linux application read and write data in a ControlLogix or CompactLogix? Or even access some of the Legacy PLCs like PLC5E or SLCs? Rockwell provides nothing for that.

In that case, you have to take a look at our Linux EtherNet/IP Tag Client software. This is ANSI C software that runs as a task in your Linux application. Your App simply opens a connection to the PLC, fills in a structure with the Tags (variable identification in the PLC) you want to read (or write) and sends that structure to the Tag Client Software. You get a callback when the operation is complete.

The beauty of this software is two fold. One, since it is ANSI C, it compiles using any IDE. And two, the API is so simple, it is really easy to use. Most customers get everything running in an hour or two.

There is always more than one way to get something done. When it comes to work around my house, my favorite is not doing it at all. I take that approach with landscaping, flower beds, shrubbery, cutting the grass and everything else I can get away with. [Bruce somebody or other on the radio once said that you can always tell the house that is owned by a business owner – it usually has the worst looking yard in the neighborhood]

I’ve been working lately with a Machine Builder/Integrator in the HVAC business. There’s a couple of interesting points about this application.

One is that I constantly forget that many, many of the people that use our products are not Ethernet experts. It’s just another technology that they have to deal with. This morning I explained the different between a hub, switch and router again. We all have to remember, no matter what our business is, that our business is very intimate to us but very foreign to our customers. They don’t know the terminology, systems and operation of that slice of the world.

Another is that point above about the number of ways to get things done. These people are doing a HVAC Tent System that has 14 80-Ton Compressors each with a bunch of drives, soft starters, HVAC Controllers and such. They need to connect this stuff up to the main Tent controller. I designed a network of Modbus TCP subnets that make sense for this system but I know that there is probably another 5 or 10 ways to do it. I’m probably not doing it the cheapest way but this will work and it will be reliable.

One interesting aspect of this system is that these systems will be located all over the world and they want to monitor them from Michigan. This raises the issue I’ve been talking about for a long time; the need for remote monitoring. Remote monitoring of data and archiving operational data is becoming more and more important.

I spoke with another customer just a few days ago that has a machine with PLC controls that really is a stand-alone unit. They need to record data but can’t count on having an Ethernet network nearby. They don’t need if often enough or critical enough to go cellular or satellite so they are going to use some of our standard product with an 8 megabyte SD card. That’s something that you’ll see on our website in a few weeks.

Well, gotta go. The weeds out front have gotten to the point where the neighbors are picketing the house.

Many, many of our customers are interested in transferring data between their embedded or PC-based systems and ControlLogix and other Rockwell PLCs using EtherNet/IP.

A lot of these customers are building their own controllers on top of RA PLCs with their own custom HMIs. For example, I have a Timber industry customer that inspects logs and figures out exactly how the log should be turned for optimum production of wood planks. His system does two vision scans of the log and must write all sorts of parameters to the ControlLogix PLC after each pass.

If you are doing a system like this or if you just want to move some data in and out of PLCs, there are a few different ways to accomplish it. I’ve just written a paper that explains all the ways people misunderstand ControlLogix EtherNet/IP and how they can access the data table. It also provides a checklist for developers using a software solution to access a ControlLogix data table.

Here’s what to do to get it. Follow this link and fill out this form. Put “Access ControlLogix Data Table” in the question field to get it.

http://www.rtaautomation.com/forms/product_request.html

John

One of the most common questions I get from EtherNet/IP Automation manufacturers is on EtherNet/IP Production Testing.

This has been an issue for a long time. Probably since the first time a device was built with Modbus. And it continues to this day with Profibus, DeviceNet and now EtherNet/IP. With some of these buses you can buy an ISA card, a PCI card or a USB adapter.

The nice thing about those hardware solutions is that you can easily develop a Profibus, DeviceNet or other production test system using standard Visual C, Java or Visual Basic. These hardware devices usually come with well-defined software interfaces and sample programs.

But you can’t always count on it. I remember one time that I bought a German PCI card (yeah – it was a long time ago). The software interfaces all looked like this:

            Void Echo (int a, int b, int c, double d, int e, int f);

The little documentation that I did have was in German. Hopefully if you buy one of these now you’ll get something useable.

But back to EtherNet/IP Production Testing. What’s the best way to do that? Well RTA has just released a tool just for production EtherNet/IP testing. It’s an EtherNet/IP Client with an example program that can reads a number of registers from a device and displays those registers in a sample window that you can customize.

You can use this tool to either read data out of a ControlLogix or an EtherNet/IP adapter. It’s a good solution when you need a quick and dirty EtherNet/IP Production test tool. Contact me if you need more detail.

Every once in a while I use these pages to revisit the CIP Assembly. It’s really the most crucial aspect of a DeviceNet / EtherNet/IP / CompoNet / ControlNet object model. I’d venture to say other than the messaging modes, it is the number 1 key concept for CIP.

Object Models as we should all know are how CIP devices represent data. For those of us lucky enough (really?) to attend a Computer Science program it’s like old home week. At least in my day we heard all sorts of stuff about grouping data into some sort of object model. I don’t know (I could start every sentence that way) but I have heard that they don’t teach that sort of stuff in Comp Sci anymore. They just teach you to make applets for Iphones and crap like that. Suits me fine as it will keep my company in business for a long, long time if no one else knows how to write embedded software. But I digress (again).

Since I am digressing I just read a study that said women from the poorer parts of the world really like hunks – guys with that rugged masculine look. Women from more affluent places like the softer, gentler version, Man 2.0 I guess. (Drew tells me that studies say it based on birthconrol oil and the way the different hormones lvls affect choices) It was a blind study done over the Internet. I have more to say about that but back to our program…

Object models. CIP has its own way of representing data. It groups common data into objects. Every device has some identity data describing what it is; manufacturer, catalog number, description and so on. The Identify Object is part of the CIP Required Object set. There’s a number of these required objects; TCP Object, Router Object, DeviceNet Object and so on. Some of these are particular to one transport method (TCP Object implies CIP, DeviceNet Object implies DeviceNet) but all are required.

Application objects are optional. Most all devices have application data describing their real world I/O, things like Flow Rate and Flow Speed. These common data sets are also grouped into Objects. And if there are multiple of them, two sets of flows being monitored, you have Instances of that grouping; Instance 1 and Instance 2.

The data in these objects is referred to as attributes. Attributes have a name, a type, a value and other descriptors. The sum of all your Objects, Instances and Attributes is a CIP Object Model. And it’s the same for DeviceNet, EtherNet/IP and all the rest.

To facilitate the cyclic transfer of data, CIP has a special object, the Assembly Object. An assembly object has instances that are either Input instances (Target to Initiator) or Output Instances (Initiator to Target). That’s some of the formal language used in the spec but typically a PLC is the Initiator and a device is the Target.

The Input instances combine data from any number of application objects to form the data that is transferred to the Initiator. The Output instances describe how to divide the data that is received from the Initiator.

What many don’t understand is that you can have many Instances of the Assembly Object. You might have different Assembly Instances for different customer applications. Each Instance would support the particular data set that is important for that particular application.

For DeviceNet these choices are critical. DeviceNet cyclic data is limited to 8 bytes before the wildly unproductive and bandwidth hogging fragmented I/O messaging kicks in. Having different instances for different applications is very useful. With each different assembly instance supporting 8 bytes or less you can avoid paying the performance penalty for transferring data that isn’t important to this application.

Of course, that’s irrelevant for EtherNet/IP where you can have more than 400 bytes of EtherNet/IP cyclic data.

So there is my review of the Assembly Objects. Keep the cards and letters coming in. Until next time…

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 had one of those calls the other day. I’d actually love getting these out of the blue calls. You never know who they are, where they are or what they might say.

Most of the time these people are pretty capable and smart, sometimes they’re whack jobs.

One time a guy asked me if I could go to Malaysia. Well, I like to travel and don’t really know for sure where Malaysia is, so I said sure, I’ll go. If he thought I could help, who am I to deny him?

Then he tells me that I have to fly in on a helicopter. Oh – Oh. I am just terrified of helicopters. I have this perception that in a jet, we can just glide to a landing but in a helicopter I’m just gonna drop out of the sky. It turns out that I once, a long time ago, knew a dancer (ok, a stripper) that was a helicopter pilot. She assured me that they can “freewheel” or whatever the term is without an operating engine and land safely. In fact she practices that every week. I didn’t believe a lot of what she told me and I really didn’t want to experience a helicopter ride in which the pilot is going to turn the Engine off.

So the next thing out of his mouth is that the reason for the helicopter is that it’s too dangerous to go in on the ground. So, now I’m thinking that if I survive the crash, they’ll be a bunch of people who want to torture/eat/kill me. My rule of foreign business trips is to try to come back alive – you can’t tell a great story at a cocktail party if you’re dead. So, in the end I passed on the trip.

Anyway, the guy the called the other day asked me to tell him what the input and outputs were. “What inputs and what outputs?”, I said. He says he wants to implement his own embedded EtherNet/IP device and needs to know what the message in is and what the message out is.

After a few minutes of this it finally occurs to me that this guy thinks that EtherNet/IP is just some sort of Modbus messaging system. There’s a Master. The Master sends a message. The device responds to it. It’s no big deal.

Well I start to tell him about CIP object Models, Forward Opens, IGMP Multicasting, IO Messaging and all the rest but he doesn’t want to hear it. He just wants to know what  the GUZZINTOS and GUZZOUTTOS are. I tried to tell him that’s it a 6 or 8 inch specification of how all this works. That it took us almost 2 years to get it implemented and that we went through 2 years of field trials before we did this.

He was kind of shocked by that. But in the end, I really think he didn’t believe me. So I told him he could get the free version at the ODVA site. It’s not really up to date, there’s no one to tell you how to customize it for your device, how to build an object model with it or support you at the ODVA lab or when your product doesn’t work at a customer site.

Finally, he terminated the conversation. Probably to throw darts at my picture (which you can get at www.rtaautomation.com). Some folks just want to believe that life is simpler than it really is.

Recently, I’ve had some interesting conversations with a developer in Texas about EtherNet/IP. They have customers that are requiring their I/O device to speak EtherNet/IP. This company doesn’t have much of a presence in the industrial market so EtherNet/IP is something completely foreign to them. Having EtherNet/IP means they can meet this customer’s requirement but might not add a lot of other product sales.

Naturally they want it to pay for itself through additional product sales. And their not sure they are going to get those sales. That presents quite a quandary for them as our software isn’t exactly cheap. In fact, I am very honest with everyone that our stuff is usually one of the most expensive solutions that they can find. 

Why is that? To provide the very best product we can and the very best service is expensive. We travel to all the ODVA meetings, all the SIG meetings and we often provide assistance for customers throughout the lifecycle of their product at no extra charge. We also provide tools, extra software modules that extend EtherNet/IP capabilities, test lab support and object model design assistance. Customers sometimes come here and camp out to learn what they need to know to make their product successful.

It is really true that you get what you pay for.  My friend John Mendocha was just telling me yesterday how his wife bought him new flashlights (Chinese made – very low price) and how within 24 hours both flashlights had broken.

So, what happened? Well, I encouraged this guy in Texas to get the free EtherNet/IP software. I couldn’t possibly discount our software enough and still provide him with the service he will need in the future. I told him that the free stuff presents a lot of risks, but short term, nothing is cheaper than free.

Some of the risks with the free stack are:

·       Designing an Object Model that makes sense when you don’t really understand what an EtherNet/IP Object Model is

·       Implementing your application objects without breaking the EtherNet/IP stack

·       Finding a device to test your EtherNet/IP device. If you use a ControlLogix you’ll be looking at $5K for the programming software plus RsNetworx.

·       Getting a listing of the last 100 hex messages sent to your device at the ODVA test lab and not knowing what the hell to do now

·       Having a problem at your first customer site where you device intermittently connects and disconnects and now knowing what to do

Essentially these are mid term and long term costs that pale in the face of the short term cost for a proven, reliable Royalty Free EtherNet/IP Source code stack, the tools you need to test it, the support you need to get it implemented correctly and having someone to call who’ll work with you when your customer is waiting for a response.

In the end, Mr. Texas decided that the short term cost for an “expensive” EtherNet/IP source code stack wasn’t really that expensive after all. It was really just a prudent business expense. And I think that was the right decision.

And now a blatantly commercial message: we have a royalty free Client and Server solutions for lots of platforms and operating systems including: Linux EtherNet/IP, Netburner EtherNet/IP, VxWorks EtherNet/IP and Freescale EtherNet/IP.

Everybody is really busy today. Even with shrinking budgets, long time customers now in the witness protection program and postponed projects there sure seems to be a lot to do.

It might have something to do with the layoffs we’ve seen over the past 18 months. A lot of engineering staffs have been cut. IGT, one of the biggest makers of casino slots, just laid off its entire networking group. A lot of the Mass Flow device manufacturers have moved their developments to China. Rockwell has moved most of its Engineering to Singapore.

But for those of us still working here in the US, there’s still a lot of work to do. Companies have smaller budgets and smaller staffs. That means that we have the challenge of getting more done, faster for less money. It’s not pretty but who said life would be easy.

I get a lot of calls from Engineers that are looking at EtherNet/IP.  I can tell who they are right away because they ask “How much is EtherNet/IP”? That’s such a tough question for me because by nature I am a tease and a smart aleck. I’d like to look at their website, find out they make valves and say “Hey, how much does a valve go for today?” Or, “How much is a car?” All ridiculous out of context questions.

Luckily I am able to roughly grip the arms of my chair, restrain myself and be polite. I have to take them through the litany of questions that are important so that I can match our products and services to their needs.

Here’s those important EtherNet/IP Questions:

EtherNet/IP Client or EtherNet/IP Server?

This is the fundamental one. An EtherNet/IP Client makes connections with lots of servers and exchanges buffers with each of those servers. It controls the connection. Clients are devices like PLCs and PC Controllers. An EtherNet/IP Server is a device that accepts a connection from one Client and does the data exchange with that Client. Servers are end devices like valves, I/O Blocks, Drives and Motor Starters.

What RTOS or TCP/IP Stack are you using?

One of the ways that we make things simple is our RTOS and TCP/IP stack interface. Our EtherNet/IP software needs nothing, repeat NOTHING, from the RTOS. We are completely independent of an RTOS. We can easily run as part of a single control loop with no RTOS. All we need is some 10msec tick count so we can keep track of time. But we are not independent of a TCP/IP stack. We need that to get on the network. We support logs of them. I still get calls from people with proprietary, home grown TCP/IP stacks and its one of the challenges to implementing EtherNet/IP. By telling me what stack you are using, I can tell you whether you can easily import our software, if it will be a challenge or if you will need help from one of our experts.

What kind of device are you building?

It’s funny, some people protect the type of product their building like it’s a national secret. I remember a chiller company that wouldn’t release its list of register addresses without a signed license. Who knows what might happen if the Ruskies could get their hands on the inlet water temperature! All I need to know is if the device type you’re building is a common one that should follow one of the ODVA profiles. If so, then we have to talk about adding that profile. We’ve probably done it before but if not, there may be extra expense there.

When do you need to get this done?

My old buddy, the late John Lovallo (I have a hundred John Lovallo stories), used to tell me “John, you can have it cheap, fast or well? Just pick any two”. I hated that but it’s really true. If you have to have EtherNet/IP next week you really need one of our experts to do it. You need to get an Object Model done fast. You need to have a conforming EDS file done right away. You need the hooks into your TCP/IP stack. There’s a lot to do. On the other hand, if the project is a year away and you’re getting budget numbers that’s another story – we’ve got time to work out the issues and I need to know that.

How Expert are you on EtherNet/IP?

There are really three groups of people I deal with. There are the experts. They’ve done a lot of EtherNet/IP implementations. They’ve done DeviceNet and understand all the Object Model Stuff and how everything works. Then there are the people that have taken the time to educate themselves. They know a lot but not really how to get it done. Lastly, there are the people that don’t know the first thing and I’m the first resource they’ve turned to. I usually send them my book on Industrial Ethernet as a getting started gift. The point is that I can help you a lot better if I know what level you are.

There’s more but those are the top five questions you will get from me when we start talking about your EtherNet/IP implementation.

I don’t know everything. In fact, I’ll admit I am in awe of a few people that seem to know everything. I was wondering the other day about the last person who did know everything known to man or at least western knowledge. It was probably someone in the 15^th Century. That’s when the printing press was invented and knowledge could be more easily disseminated.  There were so few books that an educated person could have read every one. It’s Hard to even read every copy of one thing today.

There are a number of things I just don’t get. In fact, I am ignorant about a lot of things. This is my annual display of just how ignorant I am by cataloging the current list.

 I just don’t understand:

1. Why was the EtherNet/IP Application Layer Protocol designed as a completely Master-Slave system? Why not provide a framework for slaves to send data to other slaves? All it provides is the connection but you can do that with any TCP device.
2. What’s the value of carrying Modbus packets in a CIP container? Who is going to use that? I don’t get that application at all.
3. What’s the difference between a Soft Starter and a Drive? They do much the same thing as I understand it. Why doesn’t everyone just use a drive?
4. Speaking of drives, why do they call it an inverter? Where did that come from? What’s being inverted?
5. Anything mechanical…nuff said.
6. Will PCs cost zero dollars in the future? Will you get one with a pack of gum? If you buy software, will they throw in a free PC? How low can it go?
7. Why is it so hard to buy things today? Yesterday I wanted to buy 2 Modbus devices, so I called StoneL. Got automated attendant. Then a woman who put me on hold twice and made me call the distributor 100 miles away from me. Automated attendant again. Then the live guy put me on hold twice because he couldn’t find my part. I had to ask three times for the price of the unit. Then he didn’t have delivery info. What an awful experience. I bought them from ASCON and had them shipped to me next day and paid half as much.
8. What’s the attraction to Lon? It is a novel technology. Yes, it does not need a controller. Everything can talk to everything but what is the advantage. You do want centralized control. Something that knows more than the local air duct knows to tell the air duct to open or close. Why is it so popular?
9. Can someone tell me if switches are going to be gone in ten years? Or five? Won’t every Ethernet device have a switch in it in a few years?
10. Are there two better, more capable, personable, smarter guys working anywhere together than Mike Bryant and Carl Henning at the PTO? They are the best I’ve seen anywhere in industrial automation.

So, that’s my quick list of things I don’t know mid year 2009. I stand ready to be enlightened. Let me know what you think.