Real Time Automation 1-800-249-1612 Contact Real Time Automation Contact Us Real Time Automation Product Support Support    
  Real Time Automation Homepage Real Time Automation Products Technologies We Offer Industrial Library Company Information

DeviceNet CIP CONNECTIONS

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…

One Response to “DeviceNet CIP CONNECTIONS”

  1. Richard Says:

    Thanks, now I can make an informed decision on this subject without needing to spend 3 months at Burger King ! Although that Crossan’wich does sound inviting.

Leave a Reply

RTA, Inc. - The Industrial Networking Home for DeviceNet, EtherNet/IP, Ethernet Drive,
Modbus TCP, Modbus RTU, PROFINET CBA, PROFINET IO, BACnet, IEC 61131-3,
IEEE 1588, AS-Interface, PROFIBUS, EtherCAT and other networks.
© 2009 Real Time Automation, Inc.
www.rtaautomation.com


 
Real Time Automation, Inc.
150 South Sunny Slope Road. Suite 130
Brookfield, WI 53005
© Real Time Automation, Inc. All Rights Reserved. | http://www.rtaautomation.com

(262) 439-4999 (V)
(262) 439-4989 (F)
www.rtaautomation.com