I am currently trying to decide whether to support a Group II only DeviceNet Slave or a similar configuration in CANopen. I have been unable to get a clear picture of the differences in the two application layers and when to use which. They both seem to do about the same thing. Do you know of anyplace where I can get a good comparison of the two? Answered by Don Pieronek, e-mail: A316) It^s been a LONG time since I looked at CAN Open, but here is how I would make my decision. What systems would you like to connect to? If in the US, use DeviceNet, Group II Only. This will give you access to the largest market. DeviceNet is MUCH more than a protocol, it is a device and system architecture. For example, there are certain objects ALL nodes must support; Identity, Connection, DeviceNet, Message router. These objects are required to provide a certain level of "plug and play" within the system. Depending upon the type of device you are building, you should review Chapter 3 of Volume II for a Device Profile similar to your product. If you fall into one of the defined devices, the profile will provide additional information, like the DEFAULT IO Message structure your product is required to support. Once you build a product, you must also provide an "Electronic Data Sheet", which is an ASCII file that lists various interfaces you support within your product. This is used by other vendor^s configuration tools to configure your product and scanners, controllers, and such to interact with your product. In this way, you avoid creating your own configuration tool, and allow your product to be easily integrated with your competitor^s products. Once you have this complete, submit your product to ODVA Certification lab, to ensure you comply. I recommend your purchase the "conformance test software" and the "EDS checker" software and use them during your product development. This will ensure you submit a conformant product to the labs. Remember, ODVA provided this architecture and testing so that the product vendors perform these activities and not "push the work" on the end users. The other items you may want to consider is that there are currently over 300 ODVA vendors, and that the DeviceNet protocols are also being used on EtherNet/IP. The reason this would be of value is that if ever you envision supporting Ethernet, you won^t have to rework your product firmware, except for the communications related code. I could go on, but this should provide some idea of the coverage provided within ODVA. I would compare this to CANopen.