Once up a time about 1995 I spent every morning at Burger King. No, I wasn’t enamored with the Croissan’wich or even the Double Croissan’wich [They’re really good by the way – I’d eat them every day if I wouldn’t outgrow my pants in the first 3 days]. No, I parked myself there with the large coffee and I studied the DeviceNet specification.

And I studied the DeviceNet spec. And I studied the DeviceNet spec some more. Probably for 3 months in a row I camped out there every morning. It got to the point where I could tell someone what page to find the Duplicate Mac State Machine or the I/O State Transition Table. Instead of knowing something really fun or widely applicable I became an expert in one of the most arcane and smallest niche technologies in the world.

This all came back to me last week when Richard in far away Australia asked me about the difference between UCMM enabled and Group 2 Only DeviceNet devices. Wow, “Haven’t thought about that for a while!” I said.

And it’s true. It’s something that we don’t often deal with anymore. When you build EtherNet/IP devices, you just support unconnected and connected messaging. It’s no big deal.

But it is a big deal for DeviceNet. DeviceNet is designed to support for small, cheap, slow, under-resourced kinds of devices. How sophisticated do you want your photo eye or proximity switch or valve? Not very. Small, cheap and slow works perfectly well in a lot of applications.

Well, not so fast. It’s hard to be small, cheap and slow if you have to process all the messages running around a 500K baud network. Slow is a huge problem when you have a network of 64 devices all of them transmitting every 5msecs or so. That’s a whole ton of messages coming into your communication port every few milliseconds.

To get around this problem, the DeviceNet architects created a connection type that allows the CAN Message Filters to eliminate all the messages coming from or going to any other DeviceNet node. When these filters are set properly, a device only sees those messages that are pertinent to it.

Devices that only receive these specific messages are labeled as Group 2 Only Server devices. These devices only support connected messaging and something called the Predefined Master/Slave Connection set.

That was a mouthful. Let’s take it in pieces. Connected messaging. That’s messaging where two devices agree to open a connection with the expectation of transferring some number of messages over some period of time.

The opposite of that is Unconnected Messaging. Unconnected Messaging is messaging in which there is no expectation of sending any more than a single request. Now, that request may be to open a connected connection but even that message is still a single request.

The software component that manages this connection is known as the Unconnected Message Manager (UCMM). It accepts messages to open and close connections, processes them and returns responses as required.

DeviceNet devices are either UCMM capable or UCMM incapable. UCMM capable devices are devices that can support the UCMM and can receive requests to open and close fully capable connections. UCMM incapable devices are devices that don’t support the UCMM but instead support something called the Predefined Master/Slave Connection set.

The Predefined Master/Slave Connection set (why is there no acronym for this?) specifies a group of messages that lost cost, very low resourced, slow devices can use to support DeviceNet. This connection set describes a minimum set of messages that can be used for all the basic functionality of a DeviceNet device; allocation of connections, duplicate MacID processing, and Explicit and I/O data transfer.

The messages of the Predefined Connection set are organized such that a low level CAN device can use it’s filter to filter out all messages except the ones that it really needs to process. Messages to open or close connections on other devices, other device I/O messages or UCMM messages are all blocked from the Group 2 Only Server processor. And that’s the beauty of this feature. Low level, low cost, slow processors can be used to implement these devices because they won’t have to process thousands and thousands of messages that are not pertinent to its operation.

UCMM capable devices on the other hand must provide that kind of processing. Every single message from every device on the network might be processed, at least on a limited basis, in a UCMM capable device [The DeviceNet software actually has ultimate control of the CAN filters and can choose to only close the filters to only receive a set of known messages from certain devices.]

UCMM devices are generally higher resourced, higher performance kind of devices. These devices are capable of supporting not only the Predefined Connection set but an almost limitless number of other types of connections with resources and bandwidth as the ultimate limiting factors.

UCMM devices can support multiple, simultaneous connections. UCMM devices can open up peer connections with other UCMM devices. There are a lot of possibilities that a UCMM makes available.

But here’s a word to the wise – none of that means much. Unless you are building a device where two of your own devices need to connect and transfer data there is not much other use for UCMM enabled devices. This is mostly because DeviceNet doesn’t define the application layer data transfer over these connections. So, you’ll never be able to just open a connection with some other DeviceNet device and transfer data.

The ONLY place I have ever seen this used effectively is in a “poor man’s” universal barcode scanner. In this application, four scanners surround an object each with an open connected connection to the other three scanners. First one to read a barcode sends a message to the three others telling them to stop scanning. Each barcode reader is a UCMM capable device and only, repeat only, functions in this way because it’s a single vendor’s equipment with that vendor defining the application layer message that shuts off scanning.

My advice – do it fast and simple, use the Predefined Master/Slave Connection set. There’s more to this but I have to go. I’m kind of hungry for a big cup of coffe and a Crossan’wich…

If you are going to go about developing an EtherNet/IP device, what are the physical requirements that you must meet? Is it enough to just use off-the-shelf components? Can you just add some software and an RJ45 jack to your device and “TA DA”, you’re EtherNet/IP capable?

A key distinction that you have to make in your implementation is what level of reliability and ruggedness does your device and/or application require? You need to know how your device will be used, what kind of throughput is required, where it will be used…etc. The following is a quick summary of the ODVA standard but is not adequate for product development.

If your device simply exists in a clean, lab environment, or enclosed cabinet with no requirements for high speed operation (>100mb) a Commercial implementation will be adequate. In this type of implementation, you can use off-the-shelf components, support 10mbps and 100mbps and use a standard, non-sealed RJ45 or Fiber connector. Requirements for these kinds of devices can be found in the ANSI 802.3 and TIA 568 standard.

Devices meeting these commercial standards are often found in industrial environments. They usually perform well if the physical environment is not subject to temperature, vibration, shock, noise and other environmental extremes. The ODVA Physical Layer specification recognizes devices meeting commercial implementation standards as acceptable for use within the guidelines of the EtherNet/IP specification. However, products meeting these commercial standards are not eligible for the industrial conformance checkmark. These products are eligible only for the commercial conformance checkmark.

The ODVA specification goes to great pains to warn EtherNet/IP developers away from Commercial implementations. They prefer that developers follow the industrial standards and protect devices to the maximum against shock, vibration and other environmental extremes. They go to great pains in the specification to warn that commercial components and a commercial implementation can “degrade system performance” however the vast majority of EtherNet/IP device developers have followed the commercial implementation without problems.

Product developers, with requirements that exceed the 802.3 or 568 standards, should follow the Industrial implementation standard. Volume 2, Chapter 8 of the EtherNet/IP Physical Layer standard defines this standard. The standard defines the vibration, shock, humidity, temperature and EMI requirements for an Industrial Implementation.

These standards are all based on published standards. Vibration is based on IEC 60068-2-6. EMI is based on the IEC 61000-6 and IEC 61000-4. Temperature and Humidity standards are based on the IEC 60068-2 standard.

The ODVA Physical Layer specification also details the kinds of cabling that meet the Commercial and Industrial standards. The types of shielded and unshielded cables, the typical impedance, the wire color codes and the acceptable losses are all detailed by this standard. Sealed and unsealed RJ45 housings are both acceptable under the Industrial standard. Codings for the sealed housings are specified in the standard.

For more information on Physical Layer specifications you should contact the ODVA at its Ann Arbor, Michigan office. They can provide the most complete details on how to meet the Industrial standard.

Data Highway plus (DH+)

Data highway is pretty ancient technology. It was designed and built by Allen-Bradley in the late 70s. I think it was the first network ever used by an Allen-Bradley Programmable Controller and maybe any Programmable Controller. There was a lot of this stuff deployed in the 80s and 90s. Hundreds of thousands of nodes. Big numbers.

It’s still around in lots of factories around the world. If you do any kind of integration it’s likely that you will need to either get into a DH+ network or replace parts of one. So, let’s dive into what exactly DH+ is.

ELECTRICAL INTERFACE – DH+ uses Transformer Coupled Differential Signals meaning that stations do not have to be at the same ground potential (That’s a really good thing). Two wires are used to carry data and that data is represented by voltage differences between the two wires; known as differential signaling. Because the data is encoded differentially, noise that is common to both wires is ignored. Signal Level for these differential signals is typically 8-12 volts peak to peak. The Baud Rate is 57.6 kilobaud with Half Duplex transmission (when one node transmits, all other nodes go into receive mode)

TOPOLOGY – DH+ uses trunk lines with drops. That means that there is a main cable and at points along this trunk there is a small drop line that attaches a device to the DH+ network.

MEDIA – DH+ used Baseband Shielded Twin Axle Cable. In this case baseband simply means that all devices on the media are using a single frequency.

MEDIA ACCESS – DH+ uses a proprietary token passing protocol. In this protocol, every device knows its successor, its successor’s successor and its predecessor. It receives a message that indicates that it has the token. When it has the token it can send one or more messages to other devices on the network. After sending the message it passes the token to its successor. If the successor disappears it passes the token to its successor’s successor. Failing that it has to find another successor node. This protocol is referred to as a link layer protocol as it manages and maintains the network link. New nodes join the network when current nodes find them during periodic searches for additional successors.

PACKET – What’s in the DH+ packet. That’s another old protocol, PCCC (Programmable Controller Control and Command Language). Those are also proprietary messages that PLCs use to access the data tables of other PLCs.

We have plans to create a DH+ Device Converter. If you’d like to influence how the thing works, hit the contact button from any one of our product pages and let me know what you think.

John

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

Myth#6 – No Need for DeviceNet Gateways - DeviceNet is Dead (and Profibus too)

I made myself famous (infamous?) a number of years ago by pronouncing DeviceNet dead. It wasn’t one of my best moments. I was enamored with Ethernet and thought that Ethernet would quickly take over the world of Industrial Automation. Well, I was wrong. Seems I am wrong almost every day about something. I was a real bonehead on this one.

A good story came out of it though. I got a call from a Marketing Manager over at this 2 billion dollar industrial automation company. It was frothing at the mouth mad at me. I didn’t care much. They weren’t a customer and had bought anything from me in years. Why he thought I would care is beyond me. Here’s the punch line: “John, do you know how many customers of ours are calling asking us what our Ethernet strategy is? We’re spending all day talking to these customers.”

I guess that’s why I’m not running a two billion dollar operation. I always thought it was a good thing to talk to customers. I want to know what their thinking is. What their manufacturing strategy is. What kind of problems they have. [Note to self: Talk to Jeff about disconnecting the phone in my office]

In any case, I realize now that nothing changes all that much and all that fast in Industrial Automation. It’s not a fast moving industry. We make things and some of the basic things, like Flour, Medicines and a whole host of other things, won’t change much over ten or twenty years time.

If you’re using a network like an AS-i Bus, a DeviceNet, a Profibus DP or something low level like that those things are going to be around forever. They’re perfected. We all know how to implement them, troubleshoot them and maintain them. They’re low speed and perfect for a lot of the jobs we need doing.

And since we have those networks there are a whole host things we need to move in and out of them. Stuff like barcodes, tag data and weights from scales. And that’s where gateways like the RTA 435 and 460 lines come into play.

Myth#7 – Ethernet is Best

No, it’s not the best. Properly sized, correctly implemented, smartly architected and well maintained it does a good job. But inherently it is not better than DeviceNet, Profibus or anything else. A lot of Engineers look at this completely wrongly. You should never start with the technology. Start with the problem. We have these kinds of devices. They use this kind of power. They are located geographically like this throughout our facility or around this machine. We need this kind of repeatability, this kind of determinism, this kind of response. The majority of devices we have support these networking technologies. Now, in light of all that what makes the most sense for this automation application? That’s how you approach the problem. Not with “Gee we all like Ethernet here so we’re going to do an Ethernet application.”

I hear a lot that certain companies are all DeviceNet. Or All Profinet or all Nestles Crunch or other such nonsense. I think it’s ridiculous. There are excellent reasons for AS-i as there are excellent reasons for all the others. I think it is very shortsighted to short circuit the analysis and jump to a technology.

Myth#8 – Serial is Dead

This is along the lines of DeviceNet is dead. Cost is the key factor here. Serial will always be the least expensive and lowest common denominator for lots of devices. If you’re a mechanical engineer [please stop reading you gear heads] and you are the project manager for the new Glue machine you’re likely to have skipped the need for comms and just figured we’ll give the customer a serial port. And for the hell of it, you going to invent your own protocol. Something called AMY where commands look like $AMYx. The AMY, of course, being the old high school girlfriends name and x being the command number.

I jest a little bit here but that’s what happens more often than not. Lots and lots of device manufacturers are driven by mechanicals and they outsource their electronics so it doesn’t have a place in the internal design process. You end up with crap like $AMYx and have to use a gateway to convert it to something useful.

BTW (means by the way for you non-texters) our 460 line is excellent for this kind of work. We are able to easily program it to poll these kinds of devices and turn the data into something useful for a ControlLogix, PLC5E, a GE90/30 or pretty much anything else.

Myth#9 – Wireless Won’t Work

I have heard this a lot. In fact, I’ve said it a lot. I think that I’ve been proved wrong here. There are lots of reasons and lots of places where wireless makes a lot of sense. Depending on how long the machine was going to stay in production I’d probably stay with wired systems for long term projects but on a short term machine (think snack machine) – wireless would be my first choice.

Myth#10 – Gateways are all alike!

No – not even close. There’s pretty much two classes of gateways. RTA’s and everyone else’s. All the other pack hundreds of features into a small box and let you figure out how to get the one thing you want it to do to work. RTA packs nearly nothing into our gateways so there’s almost nothing that you have to do to figure it out. It’s a big difference. 

Myth#10.5 – Customization is Expensive

It usually is. Except that the smart guys that I’ve hired (that’s pretty much everyone I’ve hired, especially the females) have figured out a way where we can get custom projects done really quickly and pretty inexpensively. We do a lot of converting ASCII scale data to Floating Point, implementing custom message / response protocols and formatting, converting and totalizing data. We relieve the PLC of doing the processing which is so cumbersome in a PLC.

So, that’s my 10.5 myths of Device Converters. As always, please use the Contact Us page to send me any comments or thoughts about the things you see here. And remember the RTA staff has no control over the way I run my mouth off. The only thing they are allowed to do is to roll their eyes when I’m not looking.

Keep those card and letters coming!

John Rinaldi

Ever watched Myth Busters? That’s a cool show if you’re an Engineer like me (Yes, I still have my Engineering hat – I dust it off and put it on every month or two. It’s comic relief for the natives around here. They get a chance to laugh out load at me still pretending to be an Engineer).

Tell me. Isn’t it about time that we Engineers have a show that glorifies the Engineering profession? If you look at doctors, there are a million cool doctor shows (with great looking nurses). And a million lawyer shows (with great looking male and female lawyers).

Great looking doctors, nutty lawyers, brilliant young docs, sophisticated and pretentious lawyers and much more. Was there ever one show about good looking, cool, nutty, brilliant or pretentious Engineers? No, not even one. Maybe because we’re not, ah, beautiful? That would be a reason. Some of us look like we dressed up with the remnants out back of goodwill.

But, there I go – I’ve lost track of time again. On to the 10.5 myths of Industrial Device Converters and Gateways:

Myth #1 – Price Is Important

Let’s start with this - the biggest myth of them all. The price of a device converter is irrelevant, Nearly completely irrelevant. The time required to install the gateway device and get it working is far more costly to the system integrator or control engineer than saving a hundred or even two hundred dollars. The extra time to install the cheaper device will eat all those savings and usually a lot more. Think about it. If you have to call technical support, you’ve already invested an hour or two to try to figure it out yourself, you’ve consulted the documentation, looked at the website and some of the sites on the internet. I know you guys. First, you’re going to spend a few hours trying to figure it out yourself. How in the world is the price of the gateway relevant?

Myth#2 – Speed Matters

It’s sexy to have something that’s real fast. Everybody likes speed (velocity not the pill). One of my favorite stories is from the days I was working with an old-line extrusion molding company. This guy had 12 machines that dropped a part in the bin every 12 seconds. Every time the part was made, we shipped the data up to some database. No big deal except the guy wanted Gigabyte Ethernet! He could have just used 150 baud modem communications just as well. Speed matters in a few cases but not many at all.

Myth#3 – Functionality Matters

I bet that this one surprises you. What do you mean that functionality doesn’t matter? Well, it does but only partly. My point here is that you don’t want the complexity that a lot of functionality brings you because complexity follows speed like white on snow. The more features that a gateway has, the more trouble you’re gonna have to get it up [no – I’m not talking about that. If that was true, nobody would ever use a device converter or gateway]. The key here is that simplicity is everything.

I really admire Steve Jobs. The IPAD is the king of simplicity. Here’s what he’s said on the subject: [insert picture Steve jobs here]

“Jobs: If you read the Apple’s first brochure, the headline was “Simplicity is the Ultimate Sophistication.” What we meant by that was that when you first attack a problem it seems really simple because you don’t understand it. Then when you start to really understand it, you come up with these very complicated solutions because it’s really hairy. Most people stop there. But a few people keep burning the midnight oil and finally understand the underlying principles of the problem and come up with an elegantly simple solution for it. But very few people go the distance to get there. And that’s what RTA has done with its line of Device Converters”…

Alright, he didn’t mention RTA. I added the part in Blue. He didn’t compliment our Device Converter line. I am sure that if he knew about them he would have but, well, you get the idea. Simplicity, making sure that you get the job done fast so that you can get on the next thing. That’s the really important part of what we do at RTA.

Myth#4 – It’s Hard to Support

Alright, this can be true with devices from some manufacturers. But the support cost is directly related to Myth #3. The more functionality, the more there is to go wrong, more support and the more headaches that you are going to have. Simple devices that just get the job done are not hard to support.

Myth #5 – We Don’t Do Gateways

There are some companies that take this position. What they don’t know is that about 1/3 of all the devices in their shop have a gateway that is buried inside their box. Many, many devices don’t really natively speak whatever today’s hot protocol that your PLC speaks. The easiest way for them to get there is to bury a gateway inside their box. They just don’t tell you that it’s a gateway. It may not be external, it’s not a second piece of gear that you have to maintain but it’s still there – you just may not know about it.

Stay Tuned 6-10.5 to come later this week… Till Next Time

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…