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.

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.

Our customers never fail to astound me. There are some things that are so unbelievable that you never expect them to happen.

For my Dad’s generation it was men walking on the moon. He was born on a farm in Italy with no plumbing, electrical or anything else. I’ve visited the place. It’s like visiting the Flintstones. Everything is made of stone. Every successive generation added another stone room to this “house”. You can tell by the different kinds of stones (rocks) that they used and the different way they put them together. For him, the first bicycle he saw was a shock.

Something happened to me this week that wasn’t as dramatic as that but it still knocked me back. I had a customer that wanted to pass data between two Modbus Masters. We’re building about 40 different versions of our Device Converter Product line but I honestly never in my wildest imagination thought to put on the list a Modbus Master – Modbus Master Device Converter.

We’re building units to move data from DeviceNet slaves into MicroLogix PLCs. Units to move Modbus data to DeviceNet Masters and lots of solutions to move sensor data of all sorts to BACnet Clients. But Modbus-Modbus – I never thought anyone need that.

I should have known. If you build something and there is any gap in product line, that’s the first call you are going to get from a customer. How do they know?

Lucky for us, we can easily handle this request. Scott, our ace applications engineer will get it done in an afternoon or less. That’s the beauty of the 460 Device Converter line. It’s darned simple to make what ever converter our customers can dream up.

So, I officially give up planning. From now on, all we’re going to do is to listen to our customers and build Device Converters that they really need.

I’m sure that won’t be the end of this story. There’s somebody out there that’s going to reach for the phone to ask me if we can do something equally unique and unheard of. But that’s what makes the job interesting and keeps me answering the phone.

Glad I’m not a Product or Marketing Manager for a Building Automation device manufacturer. Unless you’ve got a really sharp and clear crystal ball or you can read tea leaves (some prefer cannabis) you’ve got a really tough job.

The problem is knowing the direction of the Building Automation industry and aligning your products to follow that direction. Image you are the Product Marketing Manager for an energy metering company of say $10 Million dollars or so. You’re facing a real rat’s nest of thorny problems with huge dollars on the line based on your call.  You decision can literally make or break a company in these times. Let’s look at some of the issues.

Let’s start with the one you’ve got the least control over. Most buildings are government owned. Federal, State, Local. There’re post offices, police stations, prisons, schools, universities and a ton of others. In case you haven’t noticed the government is pouring huge amounts of money into projects all over the place such as wind, solar, energy conservation and all the rest. But that money is controlled by people with all sorts of different agendas and political constituencies to feed. They are pretty much not in the business of making the best call as the call that benefits their interest groups the most. If you’re the governor, your thinking about your next reelection campaign, judging how much money your gonna need and looking around for sources for all that cash. Projects will be started, stopped, suspended at the mercy of these kinds of people. Yes, it’s cynical but realistic, alas a topic for another day.

Then there are technology issues. What should we support in our power meter? We’ve got Modbus now but Ethernet is the standard. What application layer over Ethernet, well that’s a 2^nd question. Ethernet will cost us more than our Modbus solution.

Is there more we can add to the Power Meter to make it more valuable with an Ethernet link? Probably not. The distributors, integrators and customers that use these devices just want energy data. Fancy web interfaces and other crap isn’t going to add any real value to the customer, flashy yes, useful…not so much. Then we have to address the question of cost, will adding Ethernet increase wiring costs? Probably will.

Ethernet is still point-to-point, and you need a switch. Sure switch prices are have gotten pretty low but they’re never going to be free. They still require labor to install them, panel space to mount them, power to run them and lots of wire to get at them. All those costs add up. Making the case that the old Modbus way is not only just as effective but also cost effective. You actually save a lot with Modbus.  That’s why we created the a power meter gateway to move your legacy Modbus meter data to a BACnet or other EtherNet based network like our BACnet to Modbus gateway  (Part No. 460MMBS) to capture lots of meter data in one place and have a single BACnet interface.

Another dilemma for you is dual Ethernet. If you really intend to pursue an Ethernet solution you will need to embed a switch in your device. Now you’ve got daisy chained Ethernet and can cut a lot of those costs out. But your product is more expensive. Two RJ45 connectors, a switch, larger board, more complicated product…etc.

You’ve also got all the normal headaches associated with Energy meters. They are a highly regulated device that needs all sorts of certifications. If you make a mistake there isn’t a way to rush a fix out to the market. All your certifications have to be redone.

Yes, lot and lots of headaches for you, Mr/Mrs. Product Marketing Manager. At night, when I think of my problems it’s comforting to know that there’s someone else out there with lots bigger problems than mine.

I just had a birthday. Not much of a celebration around my house. In fact it passed virtually unnoticed. My step granddaughter’s birthday is the next day. She’s 7 and it’s a really big deal for her.

Much has changed in my 35 years, ooops I mean 53.  That holds especially true on the factory floor.  My first impression at Procter & Gambles Charmin Tissue Plant in 1981 was the sheer noise of it all.  Just a terrible drone that made it hard to hear, but it was kind of exciting.  All this clanging, clacking, products whizzing by, getting wrapped, put into boxes and moved into semis, it was overwhelming.  Incredible energy and flow to it all.

It seemed like a really cool place to work. You could actually make machines do things right before your eyes. Much more fun that writing some PC program that displayed characters and logic on a screen.

In those days there wasn’t DeviceNet, EtherNet/IP, Modbus TCP or even AS-i bus. We didn’t even have serial comms that I can remember. Just one big line shaft that drove the entire machine or a series of belts or chain drives. The Gear Box was the high tech wonder device and Mechanical Engineers were revered. They argued endlessly about those gear boxes. How many to use, how big to make them, how to prevent “backlash”…they were real gurus.

In those days, the PLC vendor ruled. You bought an Allen-Bradley system, a TI system, a Modicon system, and that vendor got everything. It was a completely captive customer market. No need for any other vendors stuff here. We’ll supply it all, they said.

It was the Wild West days of factory automation, especially in Detroit where the auto companies were making endless piles of cash. There was gold on the streets in those days.

Selling was also a lot different in those days. I was always told they used the philosophy “Get Em Drunk, Get Em Laid, Get The Order”.  I never witnessed it, but I don’t doubt a lot of that was true. Sales guys (and they were all guys as were their customers) had virtually unlimited expense accounts. I hear tell that the money flowed like water.

The pendulum has now swung the other way. GM is on life support, Chrysler may yet fall and Ford is holding on by its fingernails. Detroit is impoverished and I read today that even the bars are closing and dancers are leaving the business.

So what does the future hold? Given that I’ll be working for the next 20 or 30 years (What else would I do with myself?), where are things headed. We’ll, I’ll make a few predictions:

• Mechanicals had their time, Electricals had theirs.  Now we Software guys are having our time with 70% to 90% of a project being software.  Alas time will change that as well.   Everything will be reconfigurable in the future. There will be little to no software to write, it will all be included.
• Logic will move to the devices, there will be no central processors with thousands of lines of code.
• Over the next 20 years DeviceNet, Profibus and the rest will die off - lots of reasons for this including no silicon in chips to support things like Profibus and a move away from Master Slave systems.
• The big PLC companies will decline in importance
• Everything will be a PLC (or have logic capabilities) with I/O, communications, logic, HMI – even things like photo-eyes will be programmable
• Everything will be reconfigurable – machine concept to first production run in days not years
• There will be some new standard for communications that everything will use and it will be built right into the silicon. It will obsolete Profinet, EtherNet/IP and all the rest.
• LEDs will replace all incandescent. Windows will be able to let the sunlight in or generate light using LED technology.  Why, because that would be cool.

Despite our current problems Americans are still the most determined, innovative and resourceful people on the planet. I’m lucky to be born in the US. We’ll survive and continue to find ways to succeed. I for one am looking forward to it.

You can find me this week in Singapore. OK, honest now. Do you know where Singapore is?

Give up? It’s between the Vietnam and Thailand and Australia. It’s an island surrounded by Indonesia and Malaysia. An island with no natural resources that must import nearly 100% of its food, energy and every other consumable. It’s a great place but that’s not what I am writing about today.

I’m here working on a new University lab building. I’m part of a team integrating all the building systems. This includes Fire Systems, Access Systems, Elevators, Air Conditioning (it’s not HVAC here – 85°here every day) and Energy management.

So what did I find here? Well, a couple of things. One is BACnet. What’s BACnet? It’s a building automation industry standard network for moving data around a building.

Like CIP (the ODVAs Common Industrial Protocol) it’s object based.  That means that every device on the network is composed of a bunch of objects that can be accessed by Client devices.

Unlike CIP there is no concept of an I/O message, there is only Explicit message support. Every data point must be accessed independently. Because most data changes infrequently this explicit only message support is acceptable.  In a factory automation setting explicit only messaging would be death. Imagine having to interrogate a filling device to see how much liquid has been injected.

Another thing I find here is Metasys. Metasys is the high-level HMI from Johnson Controls. They’ve just released a new version and it’s really slick. Lots of cool new features but a bear to get your arms around. It’s also really expensive. $10K US. I asked my customer for a demo. No demo available. So I asked for a real copy. Uh, No John we’re not giving you $10K worth of software. (I’ve learned that if you keep asking someone will say yes.)

Of course, we found Modbus RTU here all over the building. Lot’s of automation devices have RS485 Modbus. Why you ask? Simple, every processor comes with a UART. A 485 transceiver is cheap. You can put it on a board for next to nothing along with a 3 pin connector (TxD, RxD and Gnd). And the code is easily obtained and small. You can run Modbus on any processor.

My earnest, naïve assistant Emily Brockman and I did get our end of things all straightened out and ship shape (she actually did all the work – She was the brains of out team and I was the “Eye Candy”, the “personality”). We left knowing a lot more about BACnet and putting Building Automation systems together.

Maybe in another report I’ll tell you some of my experiences outside the office. Most of the PG rated stuff anyway.

There are a couple of idiosyncrasies of the human mind that never fail to amaze me, especially in myself. One of the big ones is how we all perceive that everything we know is common knowledge to everyone else on the planet. Actually, we all have specialized knowledge in something that would be very valuable to someone else. For example I met a guy a few weeks ago that’s 67 years old and looks like he’s 35. Jet black hair, smooth skin…etc. Honestly, he has the fountain of youth. When I asked him about it he tells me that it’s a vitamin regimen he started when he was 30 years old. That’s valuable information though he doesn’t recognize it as such. Even guys like my brother-in-law that knows how to fix a broken washing machine. That is sure valuable to me when the time comes for that. Everyone has their own valuable information, specialized knowledge or “Magic”. Something that they know more about than 95% of the rest of the population.

For me, my “Magic”, is how to build highly tailored, custom PCBs that communicaste over networks like DeviceNet, Profibus, EtherNet/IP, ASi Bus and a bunch of others. We make custom DeviceNet PCBs, Highly Tailored EtherNet/IP IO Modules, AS-Interface Boards for valves, conveyor lines, drives and and lots more. (You can click any of these links to see examples of the kinds of things we do.) What I always fail to realize is how incredible most of the rest of the population thinks that is. I went to an Entrepreneurs forum a few weeks back and held up this little Freescale Coldfire processor based board and these folks looked at me like I was Moses coming down the mountain with tablets.

I never think about this as specialized knowledge but my mechanical friends sure think it is.  He makes the great point that when he builds a mechanical system, people look at it and say, “Well, of course you did it like that, it’s obvious”. And then he fumes asking them why they didn’t propose that solution before he put it together. On the other side of the fence, he complains that when I build a PCB, people ooh and aah about it, like the people I just mentioned, because it looks so difficult and mysterious to them. His stuff just looks like obvious. “It’s just not fair” he complains. My response to him, was that he could have been an electrical guy…but he choose mechanical so DON’T COMPLAIN.

What is your specialized knowledge? What “Magic” do you possess? It might be something as important as parenting or something mundane like how to tune up a bike after a long winter. No matter what it is, it’s a good thing to ponder what you know that other people would like to know and how you should go about letting people know that you have that Magic.

I remember about four years ago getting some severe criticism for an email I sent out that Ethernet would eventually replace DeviceNet, Profibus and the rest. His point was that we’ll never replace those things because they are linear topologies and Ethernet costs so much more because of the star topology.

We’ll guess what? I was pretty farsighted on this one. In case you don’t know it, there is a huge effort underway to do daisy-chained Ethernet. There are a couple of ways to do that. One is that embedding a switch right into the device. That’s a 3-port switch with one incoming port, one outgoing port and a port for the device. It’s not as fast as connecting 32 devices to a single switch. In that case, your message goes immediately out the port connected to the target device. Instead, in the linear Ethernet sytstem, you have to go through all the downstream or up stream devices to get to your target device. But in exchange for the more complicated, more expensive daisy chained node, you save a ton of wiring costs and the cost of the big switch. It’s a good tradeoff as your network is simpler.

Another way to approach this is to huge a very fast processor with dual Ethernet ports and embed the switch software right in the processor. That is a simpler architecture but the cost of the faster, more high end processor is offset by the loss of the standalone switch IC.  We’re doing a couple different applications in this area. Mostly related to conveyors and material handling. That’s the kind of stuff we do for our OEM, custom product development business. You can check it out here: Custom Networking.

There are, of course, Ethernet protocols with this stuff built right in; Profinet IRT, EtherCat, PowerLink to name a few.  I’ll have more to say about those in a future post.

JR