T
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Monday, August 28, 2000 7:35 AM
To: [email protected]
Cc: [email protected]
Subject: Re: FW: A message I posted on the Linux PLC forum that might be
of interest to you
Dear Tom,
Thanks for sending.
I've included some comments to clarify, correct, or acknowledge.
Best Regards,
Bill
>
>-----Original Message-----
>From: Tom Bray [mailto:[email protected]]
>Sent: Saturday, August 26, 2000 12:16 PM
>To: [email protected]
>Subject: A message I posted on the Linux PLC forum that might be of
>interest to you
>
>The group I am working with is attempting to put together a Linux based PLC.
>One problem with any computer based solution is that it needs real I/O to
be
>a viable undertaking.
>
>There has been talk of DeviceNet and I had other reasons to look at it so I
>filed a report on the subject.
>
>I thought you might be interested and I hope I didn't make too many
>mistakes. I am sending it to you primarily to express my opinions on what
I
>learned and to give you the opportunity to dispel any misunderstandings on
>my part.
>
>>>>
>From: Tom Bray [[email protected]]
>To: [email protected]
>Subject: Probably my last gasp on DeviceNet
>
>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.
The vendor ID is also the element that allows ODVA to police suppliers of
bad product. Customers expect to buy multiple
products from vendors and have them all work. With a network from multiple
vendors (typically 5-10), failures can be vendor
or installation related.
In a consumer or commercial industry, there are so many installations that
the buying public quickly sorts out what's good
and what is substandard....and the substandard vendors are punished by loss
of business. In the industrial electronics
market, the number of installations is so small that this sorting out
doesn't happen. Instead, a bad apple discourages use
of the technology. That's why the policing of vendors who make bad product
is a bigger deal. Also, the life cycle of
control systems is 5-10 years in discrete manufacturing (15-40 in process
automation), so customers don't switch
technologies so quickly.
>
>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.
Vendor IDs are free for DeviceNet.
For EtherNet/IP open source technology, the specs and source code will be
free; the vendor ID registration fee will be $100.
>
>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.
The interest in ODVA is to protect the customer who buys from multiple
vendors. Technically, the terms of use agreement
between ODVA and a vendor does not license embedded use of DeviceNet...there
are marketplace pressures to change that....as
soon as year end.
>
>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.
This is a direction that ODVA is moving....the Board of Directors is just
learning to move at Internet speed.
Five years ago when DeviceNet was launched, there was intense worldwide
competition in networks (50 different industrial
networks), so there were the usual protections of the technology so that one
of the other network organization did not
plagerize intellectual property.
I'll be the first to admit that today's business and technical climate is
different from five years ago.
>
>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.
Tom, you are correct in that DeviceNet is not easy to check out. The
DeviceNet audience is large manufacturers like General
Motors, Applied Materials, Hershey Foods, Anheiser-Busch, Toyota....who are
making major commitments to their factory
automation and manufacturing strategy. Their requirements are different
from the developers who are looking at fastes,
lowest cost implementation for projects that need proof-of-concept in 4
weeks or less. These large manufacturers want
assurances that the technology works and that their suppliers are commited
to supporting DeviceNet for ten plus years.
>
>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
From: [email protected] [mailto:[email protected]]
Sent: Monday, August 28, 2000 7:35 AM
To: [email protected]
Cc: [email protected]
Subject: Re: FW: A message I posted on the Linux PLC forum that might be
of interest to you
Dear Tom,
Thanks for sending.
I've included some comments to clarify, correct, or acknowledge.
Best Regards,
Bill
>
>-----Original Message-----
>From: Tom Bray [mailto:[email protected]]
>Sent: Saturday, August 26, 2000 12:16 PM
>To: [email protected]
>Subject: A message I posted on the Linux PLC forum that might be of
>interest to you
>
>The group I am working with is attempting to put together a Linux based PLC.
>One problem with any computer based solution is that it needs real I/O to
be
>a viable undertaking.
>
>There has been talk of DeviceNet and I had other reasons to look at it so I
>filed a report on the subject.
>
>I thought you might be interested and I hope I didn't make too many
>mistakes. I am sending it to you primarily to express my opinions on what
I
>learned and to give you the opportunity to dispel any misunderstandings on
>my part.
>
>>>>
>From: Tom Bray [[email protected]]
>To: [email protected]
>Subject: Probably my last gasp on DeviceNet
>
>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.
The vendor ID is also the element that allows ODVA to police suppliers of
bad product. Customers expect to buy multiple
products from vendors and have them all work. With a network from multiple
vendors (typically 5-10), failures can be vendor
or installation related.
In a consumer or commercial industry, there are so many installations that
the buying public quickly sorts out what's good
and what is substandard....and the substandard vendors are punished by loss
of business. In the industrial electronics
market, the number of installations is so small that this sorting out
doesn't happen. Instead, a bad apple discourages use
of the technology. That's why the policing of vendors who make bad product
is a bigger deal. Also, the life cycle of
control systems is 5-10 years in discrete manufacturing (15-40 in process
automation), so customers don't switch
technologies so quickly.
>
>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.
Vendor IDs are free for DeviceNet.
For EtherNet/IP open source technology, the specs and source code will be
free; the vendor ID registration fee will be $100.
>
>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.
The interest in ODVA is to protect the customer who buys from multiple
vendors. Technically, the terms of use agreement
between ODVA and a vendor does not license embedded use of DeviceNet...there
are marketplace pressures to change that....as
soon as year end.
>
>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.
This is a direction that ODVA is moving....the Board of Directors is just
learning to move at Internet speed.
Five years ago when DeviceNet was launched, there was intense worldwide
competition in networks (50 different industrial
networks), so there were the usual protections of the technology so that one
of the other network organization did not
plagerize intellectual property.
I'll be the first to admit that today's business and technical climate is
different from five years ago.
>
>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.
Tom, you are correct in that DeviceNet is not easy to check out. The
DeviceNet audience is large manufacturers like General
Motors, Applied Materials, Hershey Foods, Anheiser-Busch, Toyota....who are
making major commitments to their factory
automation and manufacturing strategy. Their requirements are different
from the developers who are looking at fastes,
lowest cost implementation for projects that need proof-of-concept in 4
weeks or less. These large manufacturers want
assurances that the technology works and that their suppliers are commited
to supporting DeviceNet for ten plus years.
>
>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
