T
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 www.devicenet.org 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]
http://linuxplc.org/mailman/listinfo/linuxplc
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 www.devicenet.org 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]
http://linuxplc.org/mailman/listinfo/linuxplc