Probably my last gasp on DeviceNet


Thread Starter

Tom Bray

In case anyone is interested, this is what my research with Open DeviceNet Vendor Association (ODVA) has turned up.

The controlling group for DeviceNet is organized around vendors. Belonging to the group is not inexpensive, the cheapest membership is $1000/year and only for companies that are have less than 300 employees.

Each Vendor's implementation of DeviceNet requires a unique Vendor ID which gets registered with ODVA so that other vendors can report what the device is and report its characteristics. Its sort of a manual version of plug and pray. Both hosts and end devices must have the vendor ID so that network monitors can identify all the nodes on the network and relate them back to the individual vendors.

For a vendor to be allowed to play, they need to minimally buy one copy of the DeviceNet Specification Manual which costs $250/year for the
subscription. Then ODVA wants anything on DeviceNet to be conformance tested which, to have done officially through ODVA Labs, costs $1500.
Finally there is a cost for the Vendor ID which I haven't researched. This process costs enough that they don't just have a price sheet that itemizes these costs on a single page, or at least I didn't find it.

I asked about whether DeviceNet software could be developed in Open Source environment and the official word was "No Problem" but they then pointed to the Vendor ID and stated that this is required and the product needs to pass
conformance testing. They did acknowledge that doing private development and "stealing" someone else's vendor ID wasn't enforceable but you couldn't sell the solution.

How to get around all these restrictions, as I see it:
The simplest thing to do for a "paid for" project is to go and buy SST's "DeviceNet On A Board" solution using the Linux interface mentioned several messages back. At less than $1000 a pop, relative to the rest of a factory automation project, it barely shows up on the radar. At least that is the conventional reasoning. I realize that this won't always work for something
that has many hosts and has been competitively bid, with no room for this amount of added expense.

There is something called EtherNet/IP product which is available with "no strings attached". It apparently is an upper level network control
interface used for networking individual host computers, not factory floor devices so it probably doesn't help. See for the procedure to get it.

There is a DeviceNet example (that is excluded from commercial use unfortunately) in Steve Ciracia's Circuit Cellar, running a weather station. I don't know how complete it is but it apparently passed conformance testing back in 98. Maybe with permission of the author this could be used as the basis of a Linux driver which could be put in Open Source. Then for
projects that are for profit, it might be possible to simplify procuring the vendor id from ODVA.

Another choice it not to use DeviceNet at all, but pick Honeywell/Microswitch Smart Distributed System (SDS) as a solution (I haven't gone looking for a Linux solution for this so it may already exist). Honeywell has chosen to provide a simple host interface for their Smart
Distributed System (SDS) which assumes a standard CAN controller. The downloadable example (written in C for a 68000) would need to be completed and expanded for Linux, including supplying an API and interfacing to the Product Database. Honeywell/Microswitch makes a set of products that sit directly on SDS and Automation Direct sells an I/O rack adapter that talks SDS.

Now, my thought on ODVA:
I realize that ODVA needs to support all their members including ones that market software for PCs, which for them, my next statements may cause a problems.

My personal opinion is that they have it wrong as far as supporting computer based host devices. I think that ODVA should actually sponsor an Open
Source version of the DeviceNet Host software and API which uses a standard set of interfaces to CAN chips running under Linux. This would open up
DeviceNet to projects that now automatically use cheap PLCs or other products as the controls network. If anything this would have a positive
impact on the companies that sell I/O devices without really effecting host side software vendors and controller manufacturers since these are often integrated into complete packages or have other compelling features.

Why is their approach a problem? It really has to deal with politics and the way companies that aren't thinking about DeviceNet as a core product
will view the early phases of the proposal and design process.

Here is my example (based on real world experience):

The up front costs of doing a proprietary DeviceNet project have to be factored in before a project is often funded, i.e. no money to spend except the engineers time (I am faced with this right now but will probably get around it). In order to answer the question: "how hard is it to use DeviceNet in our system" requires buying the DeviceNet Technical manual, which requires signing an agreement to get it, which in turn requires the whole set of agreements be reviewed by the companies legal department (because the first agreement placed the whole process in view). The immediate response by middle and lower management is: "lets look at other
solutions first" if for no other reason that all the steps just stated fall into their responsibility.

Compare this to: I saw that there is a Linux driver and API up on the Web, let's get it, take a look at it, maybe slap together a simple demo system to show how easy it is to use (probably still spending a $1000 but now its real, not just paper and lawyers). I call this the engineering equivalent of the Puppy Dog Close in sales, it works and I use it regularly.

So much for my rantings and ravings on this subject. I think I have said enough.

Tom Bray
T.J. Bray and Associates
Email: [email protected]

LinuxPLC mailing list
[email protected]

Curt Wuollet

Hi Tom

Thanks for the research, I've spoke with these folks before, they just don't grok at all. They would rather have all of a small market they control than a big part of a larger market that they don't. The problem with SDS is they're a bunch of radicals, oops, wrong SDS. Actually, the problem with SDS is the same as the problem with rolling our own, There just aren't that many SDS
compatible products. I think Ethernet is our best bet along with Modbus/tcp or other published protocols. Ethernet is on the way in and support under Linux.couldn't be much better. For supporting other protos, we almost have to go with buying certified products and that is going to hurt us. A thousand dollars may not be much in a large project, but it will be the largest cost in the whole lplc by far. CAN is interesting, but not very well representedted in the US except for DeviceNet. A lot of the others are vendor specific and so useless for our purposes. We will have to talk to them but they are not good
candidates for our "native" proto. I think we should try to work something out with Optimation or some other low cost ethernet IO to release their proto under the GPL. Maybe the Automation Direct folks or some other independant that doesn't have their head in the sand (I cleaned that up a lot)

I am going to say this once more for the benefit of the companies that are watching this list. The money is in the IO, you can sell a lot more IO if it works with more than just your products. The protocol does not make money. Opening it up to sell IO is a smart business move. It certainly seems to have worked for Modicon and others who have tried it. There is more money in appealing to other customers than there is in locking in the ones you have. The handwriting is on the wall, it's better to be a leader in the revolution
than the loser. Open will prevail.



LinuxPLC mailing list
[email protected]
It really needs the existing protocols to use the products that are out there. I am not sure you could tamper with the protocol enough to open it
up and still allow it to interact with existing DeviceNet products. I am sure it would cause a legal flurry, especially if anybody ever claime to get hurt by a malfunction of an integrated system.

ODVA claims that 150 separate vendors support the standard and when the first one is Allen-Bradley/Rockwell it has some weight behind it.

The SDS products are a sort of reinvented wheel but the depth of the products supported isn't nearly as great, consisting primarily of a handful
of MicroSwitch sensors and the Automation Direct 200 series PLC I/O (I am sure there is more I just don't know what they are). If it caught on
though, I think vendors would probably support it since all they need to do is change program slightly to support SDS versus DeviceNet.

There is also an European standard but I can never remember which one it is though, I think it might be the ASI (the Germans say it like the slang name of an Australian) network. As I recall it is about as open as DeviceNet.

The real problem is that DeviceNet wants every node on the network to have a purchased and unique vendor ID and a sequence number, which is an idea stolen from ethernet board vendors. They are also worried about conformance, which is a very obvious Allen-Bradley mind set, but they were
instrumental in developing the system in the first place.

-----Original Message-----
From: Alex Holden [mailto:[email protected]]
Sent: Saturday, August 26, 2000 1:56 PM
To: Tom Bray
Subject: Re: LinuxPLC: Probably my last gasp on DeviceNet

On Sat, 26 Aug 2000, Tom Bray wrote:
> In case anyone is interested, this is what my research with Open DeviceNet
> Vendor Association (ODVA) has turned up.

Have you considered "reinventing the wheel", then releasing it as a truly open spec with an Open Source reference implementation and no strings

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- --------------------

LinuxPLC mailing list
[email protected]