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.

This is the second part of my blathering on OPC. Here I’ll describe what OPC really is and how it fits into Industrial Automation.

OPC is a standard way to pull information into PCs and other devices that run MS Windows. So that includes XP Embedded, CE and other Microsoft products. So, really we are talking about a standardized way to move data from some place out in the world into a Microsoft Windows application.

Those Microsoft Windows applications are not just apps delivered as part of Windows but there are also apps created by end users. They can be really sophisticated like Wonderware a package with very humble beginnings that is now a juggernaut in the Industrial automation beginning. These apps could also be real, quick and dirty Visual C++ apps that you wrote this morning before getting that first cup of coffee (probably in that dirty cup you’ve been using since Jimmy Carter was President).

In its simplest form, OPC uses a Microsoft standard called COM (Component Object Model) technology. COM is part of the communication infrastructure within Windows that lets different software programs talk to each other in a structured way. Using COM eliminates all the hassles of creating connections between two programs that want to pass data. It allows, for example, a MS Word document to easily get data from an Excel spreadsheet.

So, what does this do for Industrial Automation developers and end users? Well, you can think of OPC as kind of like a front end for COM. OPC is a software program that connects the real world to MS applications. Now, instead of a spreadsheet feeding data to Microsoft Word you could feed weigh scale data, a barcode, a valve position or a flow rate to that Word document, not in real time but close enough to suit a human operator.

An OPC software program that collects real world data and makes it available to COM and any application that wants to connect to it is called an OPC Server. An OPC Server knows how to talk to some real world device. It might talk to that device over a serial port, over USB, Ethernet/IP, DeviceNet, Modbus TCP or CAN. It doesn’t really matter how the data gets there to the MS Application program. The Server hides all the ugly, back door shenanigans of polling data, swapping bytes around and decoding complex messages to provide your application program with an easy-to-use, straight forward way to access that devices data.

The application programs that receive the data are called OPC Clients. Those guys are either standard Microsoft programs like Word, Excel or Access or they are programs you buy or something you create yourself. It’s not hard to create yourself, MS Visual C++ has a pretty easy to use IDE but you’ll need a foundation and understanding of C++ objects and all that junk.

Next I’ll tackle OPC UA or Unified Architecture. It’s kind of like the United Federation of the Planets but I’ll get into that later.

I’d like you to meet Derek, our newest addition to RTA. Derek’s a pure bred Greyhound and has accepted the position as the RTA mascot. And Yes, Derek is one of those racing Greyhounds. He’s retired now but luckily found a good home with Emily Brockman on our Engineering staff.

Greyhounds have a really interesting bloodline, actually an ancient bloodline. If you look at some of the ancient art from various museums around the world you’ll see dogs depicted that are extremely similar to today’s greyhounds. And if the pictures etched by hand on the walls of Egyptian tombs are an indication, Greyhounds must have had a significant place in ancient Egypt.

All around the world and throughout history Greyhounds have been revered. Some of the writings indicated that Arab princes celebrated the birth of a new greyhound only slightly less vigorously than they celebrated the birth of a son. A thousand years ago in England, laws were passed to restrict ownership of Greyhounds to those of the Noble Class.

Greyhounds were brought to America in the 1800s as a deterrent to jackrabbits which were destroying the crops of farmers throughout the Midwest. Their intelligence and gentle, loving nature made them very popular in the late 1800s.

The racing business started early in the 20th Century when Owen Patrick Smith invented the mechanical lure. That made racing around a track possible and spurred the growth of the Greyhound racing industry throughout the US. At its height Greyhound racing was a three to four billion dollar industry.

In the latter part of the 20th Century Greyhound racing and the wagering that goes with it started to decline and decline dramatically. In the early 90s alone, wagering dropped almost 50% in a five year period. This is similar to the decline that is being experienced in the casino industry today where the average age of a patron is over 65 years old.

But the dogs remain and are being retired and euthanized at a record rate. Unfortunately, they don’t get severance packages and they can’t be retrained to do anything else. A Greyhound runs. Runs all out for 2 minutes and sleeps most of the next 24 hours.

Well, RTA is doing something to help these animals. You’ll find a page on our website dedicated to Derek and his breed. We’ll be featuring Derek in some promotions and sending a portion of product sales to some of the organizations dedicated to finding homes for dogs like Derek.

But why do this? Well, it makes sense. Derek is a very good example of specialization. How, specializing in something makes it easy to understand and easy to use. Derek is designed for only one thing and is exceptionally good at that. Just like our Products, our Barcode to PLC gateway, our TCP to PLC gateway or our Modbus to BACnet gateway. We build products that only do one thing, do them very well and are easy to understand, just like Derek!

At this weeks CoDeSys seminar in Lund Sweden, Ken Ryan (he’s the guy with me in this picture), Director of the Mechatronics lab at Alexandria Technical College in Alexandria Minnesota, gave a very interesting talk on the evolution of manufacturing automation. As part of that talk he introduced the concept of Mechatronics; somewhat of a new term for me. I had heard it before but never gave much thought to it.

Ken started with a description of life before computers and microprocessors. If you’re under 40 now you probably don’t remember those days. We had garage doors that didn’t rise and fall on command, rotary phones (tied to a wall someplace where everyone in the family could hear your conversations) and worst of all, TVs that had only 3 channels. And you got off your butt and walked up and physically turned the dial to check out another channel. After a while, there was such a thing as a remote. They used infrared I think to transmit signals out of the remote and when you pressed the button, a stepper motor turned the dial for you. It was clunky and made a huge gnashing sound as you flipped through the channels.

It wasn’t any better in the factories either. Automation was a set of relays tacked up on a wall. There were literally acres of relays with wires from one relay to the next relay and that was how control functions were implemented. The relays looked something like ladders and some old wise guy electrician whose name is lost to history probably started calling it ladder logic.

In those early days about 95+ percent of a machine was mechanical. There might have been some lights and some switches but that’s about all. The ME (Mechanical Engineers) guys ruled. Even when I started in the 80s I remember that the Kimberly Clark converting machines had these monstrous line shafts that were 30 or 40 yards long. Every few feet there was a gear box that transferred power from the line shaft to some other mechanical device.

It was a real challenge to the mechanical guys. To start these huge shafts you had these huge motors. But as the motor started turning the shaft resisted it. A body at rest tends to stay at rest (Newton, right?). They had all sorts of problems with waves moving through those mechanical parts as they started it and tried to change speeds. Those waves caused product quality issues as material couldn’t be held in place very easily. And as those components wore down, the quality issues got worse and worse. There was some brilliant work done by those guys to overcome thoee problems and get maximum productivity out of the mechanical systems.

Now we’ve gone the other way. The majority of what happens on a machine is electronic. It’s all software. But that has just moved the problem and in some ways made it worse. Software is hard to do right, easy to screw up. It takes a lot of time to develop and debug it. Not many people have a real good handle on a process to design, implement and test it. It’s even hard to spec out what you want to do.

The “science” of working on this problem is called Mechatronics. That’s what Ken does in his lab way up there in Alexandria [It’s so cold up there that the only day they take off their long underwear is on the fourth of July – winter starts again on July 5].

A big part of the Mechatronics effort is using CoDeSys and other IEC 61131-3 software tools to make it easier to develop automation systems, produce higher quality software and reuse a lot of it so that you’re not starting from scratch every time.

If you have a chance, check out the Center for Applied Mechatronics website at http://www.camc-online.org/.

I’m spending today in lovely and I mean lovely Lund Sweden. And I’m not just talking about the Swedish ladies though I have found no where in the world with this concentration of beautiful blonde women. If the world ever ran short, it could be resupplied from here, probably without much notice. They’re like ants at a labor day picnic.

I’m here today to take part in the 2^nd annual Scandinavian CoDeSys conference. It’s an update for all the Scandinavian partners that are using CoDeSys in all sorts of applications.

Best Engineering is sponsoring the event. Best is the local supplier of CoDeSys programming services and application support. They help machine builders all over this part of the world develop applications. They’re a small company, just 3 or 4 Engineers but they have a real good handle on who’s doing what in Sweden, Norway and Finland.

I am really stunned by the advancements made in CoDeSys. They have added some significant advancements that are going to make KW, Isagraph and the rest get the willies. Here’s a summary of the new features in no particular order:

Distributed Applications – This is ISAGraphs claim to fame and 3S is slowly chipping away at it. I am not sure that ISAgraph isn’t still the leader in distributed apps. It’s 64 system demo is pretty impressive but 3S is showing signs of catching up fast.

Conditional Compilation – You can now not only use standard conditional compilation commands but they’ve added a ton of new Pragmas. You can use the new pragmas to check if a variable is defined, if it has a value, if it has a type and a whole lot more.

Fieldbus Configuration – They’ve done a lot of work here to unify all their fieldbus interfaces. They now normalize everything to XML and store all the configuration files in a common place. In CoDeSys V2 they are distributed all over your hard drive.

OPC Server – They’ve enhanced their OPC server offering. The same server can not connect to both CoDeSys V2 and V3 controllers. There is a demo available and I might be wrong, but I think it’s free. Imagine that!

PLC Handler – The OPC server is now based on some technology they’ve developed called the PLC Handler. The PLC Handler is a generic way of moving data in and out of CoDeSys based controllers. Now, non windows devices have an easy way to integrate and talk to CoDeSys controllers.

Soft Motion – 3S has done a great job of enhancing their soft motion offering in V3. It’s fully functional and contains a wealth of predefined function blocks that can be used in these sorts of applications.

Object Oriented Programming (OOPs) – They’ve added support for OOP interfaces in CoDeSys and it is really going to be beneficial for those of us who’ve grown up on true Object Oriented Programming.

There’s a lot more, like the ability to convert between different programming languagues, between Function Block Programming and Ladder without compiling. The demo was really cool. And there is even more coming! Dimitri Phillipe,m the 3S International Sales Manager, wrapped up the day with a preview of the future and I can tell you that it’s pretty exciting.

If you’d like to have CoDeSys on your device and take advantage of this fantastic programming environment, it’s possible. Visit CoDeSys PLC Engine to get more information and then call me. I’d be happy to talk to you about it.

I look at the world a little oddly, to say the least. It seems that I’m out of step on a lot of things. Name all the great social issues of the day and ask where most Americans stand and I’m on the other side of the tracks. Sometimes, on the other side of the tracks and lost in the tall weeds with my feet stuck in mud up to my ankles.

I’m that way on a lot of technical issues too but don’t think I’m too far afield on this one. I divide up the scanner world into three groups. The first are PLCs from the big PLC vendors like AB, Siemens and the rest. These are generic controls designed to handle just about anything. They’ll happily sell you one to control a Molson Beer process, an Injection Molding machine or a Viagra dispensing machine.

The second group is controllers for more dedicated applications. They’ll usually control a small set of devices with a pretty specific focus. The user usually has the ability to add and remove a node. Smaller, more dedicated, less adaptability over all a more focused operation. A robot is a good example of this kind of controller. The amount of I/O available to the robot varies within some bounds.

The third group is the real embedded controllers. These guys are buried within a process or a machine. They have very specific functionality defined by the system vendor. They are going to scan x devices no matter what. The control program is going to be hard coded and not altered by a user.

If these systems use EtherNet/IP the way the scan list gets defined varies for each of these applications. In the third, it doesn’t vary at all. It’s hard coded and set by the manufacturer. The scanner has a list of EtherNet/IP TCP/IP addresses and I/O buffer sizes. It’s gonna scan that list until the cows come home.

In the first and second group, we have much more variability. There’s actually three ways to configure that scan list:

1. Hard code it – just like the third group of controls. Unfortunately since the applications will vary, hard coding is just not an option.
2. Vendor Specific configuration – most vendors have their very own tool for configuring their device. It’s some sort of PC program and a lot of them just want to extend that tool to do the EtherNet/IP scanning. That’s OK but a lot of end users really don’t like that for good reason. Where is that tool going to be when they need it? How do they know they have the most recent one? How do I use it again?
3. Open Configuration Interface – This is really the best way to enter your scanlist. Using the EtherNet/IP Connection Configuration interface any off-the-shelf tool that supports that interface can configure a scan list for your EtherNet/IP scanner.

RTA just announced support for the Connection Configuration Object in all our EtherNet/IP Scanners. This interface uses standard EtherNet/IP Explicit messages to add and remove nodes from the scan list, start and stop scanning and revise the data sizes of the I/O buffers that are exchanged by the scanner and it’s servers.

This is a real benefit to the user. They don’t have to maintain some separate tool. They can easily add and remove nodes from the scan list using the same command set that they use to configure nodes on the network so no extra training or management costs.

This is a huge step forward for RTA EtherNet/IP technology that will benefit all our customers using our small footprint, fast, reliable EtherNet/IP scanners.

I’ve been doing a lot of work lately with Johnson Controls Metasys Building Automation and Control System. It looks kind of like an HMI but it’s a lot more. It brings all sorts of Building data together, wired data, wireless, sensors, actuators, systems and all sorts of other things. It is a data collector, data organizer and IT web interface for all kinds of building devices.

JCI through its integration and service division uses Metasys on lots of big Building Automation jobs. Hospitals, universities, business centers, large story buildings and more. They recently were awarded the contract for the Empire State Building. I imagine that you’ll find Metasys there too.

In these situations, Metasys pulls all the relevant systems together for easy access in one place. Metasys will have information on the Elevators, Fire Control and Alarm System, Access and Security systems, Lighting Controls, HVAC and more. It’s the place to go to find out what going on in your building.

If you’re a small device vendor or Building Automation System Integrator, it’s likely that you’ll need to connect your devices to Metasys. I just talked with a small drives vendor for example that needs to connect to 2 drives into Metasys as part of a small fountain in the lobby of the building.

Doing that can be challenging. You, of course, have the cost challenge. Everything and I mean everything is being commoditized and commodities are cheap. This guys drive systems are commodities and price is one of his best selling weapons.

But cheap does not extend to the network interfaces. There are several common ways of moving data to Metasys. One is Lonworks. Lon has been around for a long time now and has made some significant market penetration. Lon operates as a peer network with network variables called SNVTs (pronounced snivets). There’s also N2, JCI’s traditional network interface that has been around forever. And there’s BACnet. BACnet provides an object oriented approach to Building Automation networking.

Somehow my Building Automation System Integrator friend has to find a way to make his drive data (Modbus Registers) available on one of these three more common networks where they can be easily accessed by Metasys. That’s not a trivial task and requires more consideration than you might think. For example, you not only have to move the data but convert its byte ordering, precision and length. And then you need to supply strings that describe each data point and the units for each. No small task.

Luckily, my SI Drive guy has the RTA 460MMBS. With this device he can easily configure the Modbus registers to present to Metasys, specify how to transfer them and add the string data that describes them. It’s a perfect solution for that daunting challenge.

Metasys is a dominant factor in Building Automation. Luckily, system integrators now have an exceptional tool to move data from all these other kinds of systems and devices into it.

I often have people asking me about the free versions of software that are floating around the internet. And lately, I have been asked about a $500 version of EtherNet/IP that is available.

People ask me if this stuff is for real, if it works and what are the chances for success. I usually don’t spend a lot of time answering. Reason being that there isn’t really a good way of dissuading someone who perceives a short time benefit at no cost. If you have severe price pressures and your sales are eroding, people are going to take chances and assume risks that they would normally avoid. Sanity is something that some people have a really hard time to hold onto right now.

So what are those risks? Here are the major ones:

DEVELOPMENT RISK

Free may mean that you spend a lot more time in development. You don’t get tools with free software and you don’t get a lot of documentation. So you have to figure it out. Sometimes you can and sometimes you can’t. If it works (or at least seems to in you lab), you’re a hero. You’ve saved the company untold thousands of dollars. If not, you’ve lost a few weeks or months but you can buy something that works.

Sometimes people confuse free with Open Source. The Free software stacks on the internet are unsupported. There is no body updating the code. No one finding bugs, making enhances, or making revisions to conform to the latest guidelines from the ODVA. Open Source is source that has a wide following like Linux. Groups of people all over the world maintain that software and enhance it. There are lots of forums to go to if you have a problem. Lots of help. You don’t get that with the free Industrial Stack.

CERTIFICATION RISK

Assuming you can get EtherNet/IP working in your lab. Your next stop is conformance testing where they send 4 or 5 hundred thousands messages to your device. At the ODVA, problems show up from time to time and the tester gives you a very cryptic series of messages showing the sequence of messages that led up to the conformance issue. Now what?  You have to pull out the spec, all 6 inches of it, and start reading. You are now in a position where you have to get familiar enough with the technology to understand every last intricacy.  Believe me, if the problem is deep in the stack, you have a great risk of breaking something else.  As time Ticks away so does the development cost meter every hour costs around $195. The cost of free is adding up fast.

PRODUCTION RISK

If you get past certification and ship you’re first unit you are still not out of the water.  The risk actually increases greatly. You not only have to spend time on any problems that come up for your customer, you’ll probably have to tackle them on-site with a plant manager breathing down your neck. If resolution takes more than a few days, you could lose an order or worse an important customer.  You are stuck and have no one to call for help.  So you get the 6 inches of spec out, a big cup of coffee and go at it. The hours are adding up astronomically now. You’re boss is worried. You’re management is wondering who to blame for this mess. The cost of Free just went through the roof.

So what is the cost of free? It’s all risk. Time-to-market, Product Introduction, Company reputation, and your reputation are all at risk.  Free is pretty costly when you consider all the extra hours you’ll have to put into the project and the risk you take on to save a few thousand dollars.

There are the top ten questions I have answered lately. Let’s review them:

1. What do I need to connect to CANopen or DeviceNet?

To build any CAN device you need two things, a Media Access Controller (MAC) and a transceiver. The MAC is always silicon; either a standalone chip or a part of a microprocessor. The MAC unit handles access to the network. It decides when a bit can be transmitted over the network and manages error checking and things like inter-message delays. The Transceiver is the electrical interface. It converts the digital 1s and 0s to electrical signals on the bus. The transceiver is always a standalone chip in a CAN system.

1. Do I really need to have my EtherNet/IP product certified?

Yes. To get a vendor ID you have to sign an agreement with the ODVA (www.odva.org). The vendor ID is used to display the string name of the product vendor by configuration and diagnostic tools. One of the things the agreement specifies is that you agree to not sell any product that has not passed the ODVA certification tests.

1. What is the difference between an Ethernet Client and an Ethernet Server?

In an industrial system, a Client device makes connections with a number of server devices. Clients are typically devices like PLCs, HMIs and PC Systems. Servers are devices that wait for a Client connection. Servers exchange control and I/O data with a Client. Servers are devices like I/O blocks, Valve blocks, drives and other sensors.

1. How Can RTA’s Source Code Stacks work with so many different platforms?

When we built our CANopen, DeviceNet, EtherNet/IP, Modbus TCP and other source code stacks we built them for lots of different users in lots of different applications. We knew that some people would want to build systems around low end 8-bit controllers with no OS. Some would want to build systems using 32-bit systems with no OS. And others would want to build systems on high end processors with operating systems like Windows, Linux and VxWorks. To achieve that we implemented systems that used ANSI C, required nothing from the OS other than a 10-msec ticker and embedded all the interface code (CAN interface or Ethernet TCP/IP Stack) in a single C file. We built the system to support big endian or little endian and have absolutely no platform dependencies.

1. Where do I get EtherCAT source code?

This seems to be a common misunderstanding. EtherCAT is like Profibus, CAN and Profinet IRT. It requires a low level ASIC to handle all the network data exchanges. There is no source code. In fact, a processor is not always required. We’ve just implemented and EtherCAT system that uses a Freescale DZ to preprocess all the I/O and deliver it to the EtherCAT ASIC over SPI (Serial Peripheral Interface). Click EtherCAT Overview for my complete overview of EtherCAT.

1. Can I use BACnet IP to capture millisecond by millisecond power data?

No, BACnet is a request – response protocol. A Client device requests data from a Server device. The more data in the server, the more messages required and more time is required. With CSMA collision detection on busy subnets there is no way to predict when a message might be transmitted to collecting data with BACnet IP is difficult from multiple perspectives.

1. What is the difference between BACnet IP, BACnet Tunneling and BACnet MSTP?

The Tunneling version is a version of BACnet in which a device can send Ethernet messages without using a TCP/IP stack. The BACnet IP version is the one that uses Ethernet TCP messages to send and receive messages. The MSTP version is the RS485 version of BACnet. Click BACnet Overview for a complete description of BACnet.

1. How do I control how fast I send data to a PLC using EtherNet/IP?

The answer is that you don’t. A PLC is nearly always the Client in an EtherNet/IP network. When an EtherNet/IP Client creates a connection with a Server it indicates to the Server how often outputs will be transmitted to the Server and how often it expects the Server to transmit inputs to it. This timeframe is usually 10 or 20msecs but could be as low as 5msecs.

1. If I have a DeviceNet or EtherNet/IP device certified, when does it have to be recertified?

You really need to check with the ODVA but as I understand it, whenever you have a major new software release, you need to recertify. That means scheduling a retest and paying for another test. Unofficially, no one really does that. Instead, they buy the EtherNet/IP or DeviceNet Conformance test software tool and perform the retest themselves.

1. How often do you update your EtherNet/IP Source Code or DeviceNet source code?

In practice, almost never. The ODVA controls the specification and the specification only changes in the most dire of circumstances. Once you have a product that conforms to the specification there is no reason to make any upgrades or modifications. There is no new functionality. After all the years we have had this code there are rarely any bug fixes so updates to the source code are far and few in between.

Had a call from a really nice guy down south today who wants to implement EtherNet/IP. He seems to be really, really competent and sincerely wants to architect the right solution for his application.

The only problem is that this application isn’t appropriate for EtherNet/IP. This is a situation where it just doesn’t fit. He and his group are kind of enamored with the technology and the “thrill” of using a name technology.

It’s a classic illness that all us engineers are prone to get. We let are enthusiasm for some cool technology get way ahead of the problem we’re trying to solve. I did it with DeviceNet. Long time ago I created this really cool ISA bus coprocessor that was a DeviceNet Master. I got so excited by the technical challenge that I forgot completely about the business issues. The product was a big flop.

This guys problem is that he really has an Ethernet Peer-Peer system. He has a number of distributed application components and he wants to add and remove them at will without any reconfiguration.

His application reminds me of J1939. That’s a CAN based application layer protocol just like DeviceNet. Only J1939 is all broadcast. Each node publishes its data as needed to the network and who ever needs that data listens for it. There are no masters or slaves. If a node isn’t there the data isn’t published and the listener doesn’t receive it. It’s really simple and straight forward, used in transportation applications. I implemented a system for huge yachts one time. Catepillar engines use it extensively.

So this guy wants to do the same thing on Ethernet. One choice is to use CAN and J1939 but the physical distribution of the system prohibits that solution. CAN is good to 1000 feet unless you use extenders.

He could use Profinet CBA. But the size and complexity of that mother is just prohibitive. His data is pretty simple. Not sure that CBA makes a lot of sense in his application.

Another is proprietary. He could implement a J1939 like proprietary Ethernet application layer but is that the best solution?

One of the things he is looking at is Microsoft Robotics Studio. That a system targeted to students that makes it easy to program robots. It supports a bunch of different hardware platforms including PCs which is what our southern friend is using. It has simulation and tools for accessing sensors and actuators. It is designed for distributed systems where the robots can coordinate their actions. Here’s where you can get more information: http://msdn.microsoft.com/en-us/robotics/default.aspx.

I’ll have to admit that I didn’t have a good solution for him. Any thoughts from my “legion” of loyal readers? J