Which DeviceNet devices are compliant with SEMI standards SEMI E54 and SEMI E54.4. Answered by Dan Judd, Chairman of the Semiconductor SIG, e-mail:danjudd@alum.mit.edu A172) The SEMI standard is broken into parts: E54 is an umbrella document. E54.1 is the common device model (required for all devices) E54.4 is the network model for DeviceNet E54.3 is a specific device model for a Mass Flow Controller (the only approved Specific Device Model so far) Q175) Bus Comparisons (BC). One of our customers would like to use CAN-Open and DeviceNet modules on the same network. Is it possible to serve both bus-type stations via one CAN-Master? Answered by William H. (Bill) Moss, previous ODVA Executive Director, e-mail: odva@powerinternet.com A175) No, we advise against having CANOpen and DeviceNet devices on the same bus. The devices are not logically interoperable, and their physical layers are very different (DeviceNet has a special mis-wiring protection because the physical layer was designed to support signal and power on the same cable...CANOpen is not the same). They share the same CAN chips, but the application layer and physical layer designs are very different. The application layer^s use of the CAN ID field is totally different between the two networks. There would most certainly be conflicts that could result in nodes getting incorrect data, which could have disastrous effects. Q316) Bus Comparisons (BC). 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: pierod@ch.etn.com 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