“DeviceNet is an open networking standard. Specifications and protocols are open – vendors don’t have to pay for hardware, software or licensing when they connect devices to the system; anyone can supply from open DeciceNet for a nominal copy cost (currently $250 + postage) Business Association (ODVA) obtains the DeviceNet specification.
Author: Zhang Ji
DeviceNet is an open networking standard. Specifications and protocols are open – vendors don’t have to pay for hardware, software or licensing when they connect devices to the system; anyone can supply from open DeciceNet for a nominal copy cost (currently $250 + postage) Business Association (ODVA) obtains the DeviceNet specification.
1 Communication adapter hardware system design
1.1 Function introduction
DeviceNet is a bus protocol standard based on CAN bus. Therefore, DeviceNet slave device adapter hardware should first realize the basic functions of CAN bus, mainly including: message sending and receiving, access control and many functions of other physical layers. In addition, in order to realize the DeviceNet protocol, the hardware should have a large enough program storage space and a fast enough running speed to ensure the smooth execution of the protocol program.
1.2 Hardware principle
DeviceNet node hardware is mainly composed of the following parts: power supply, microcontroller system, watchdog and power failure protection circuit, CAN controller SJA1000, CAN transceiver 82C251, DIP switch and status LED Display, dual-port RAMIDT7005, AnyBus interface. The overall design block diagram is shown in Figure 1. For detailed hardware circuit diagrams, please refer to the supplementary version of the website of this journal.
The following is an introduction to the main functions.
(1) Single chip microcomputer
The DeviceNet adapter selects the high-performance 8-bit microcontroller W78E58 of Winbond Company. W78E58 is fully compatible with 80C52 in function and pin, and provides 256 B of internal RAM and 32 KB of Flash EEPROM, so that the system can meet the capacity requirements of DeviceNet protocol programs without expanding external program memory. W78E58 can run under the main frequency of 40 MHz at most, and the processing speed fully meets the real-time requirements of DeviceNet node communication. In order to reduce the number of chips and hardware cost, this system only expands one 8 KB dual-port RAM, the first 7 KB is used for external data storage, and the last 1 KB is used to provide the communication interface with other application circuits.
(2) CAN controller SJA1000
The sending and receiving of DeviceNet bus message and media access control are all based on CAN bus protocol, and these protocols must be realized by CAN controller. The DeviceNet communication node selects the popular Philips CAN controller SJA1000 at present. Because the DeviceNet bus protocol uses an 11-bit identifier, the SJA1000 should work in the BasicCAN mode.
(3) CAN transceiver 82C251
The main function of the CAN transceiver (transceiver) 82C251 is to send and receive signals on the CAN bus: on the one hand, the bus signal is converted into the signal required by the CAN controller; on the other hand, the output signal of the CAN controller is converted into a CAN bus signal.
(4) Dual-port RAM IDT7005
The DeviceNet adapter provides a communication interface with other application circuits through a dual-port RAM IDT7005 with interrupt function. IDT7005 has 2 sets of completely independent data lines, address lines, and read and write control lines, allowing 2 CPUs to read and write the same unit of dual-port RAM at different times; it has 2 sets of completely independent interrupt logic to achieve 2 Handshake control signal between CPUs. The highest 2 bytes 1FFEH and 1FFFH of IDT7005 also serve as the interrupt logic unit of 2 ports respectively.
(5) AnyBus interface
As a general field bus communication node, AnyBus provides an interface standard for data exchange with other application circuits, and defines the pins of the interface strictly.
2 DeviceNet bus communication protocol
The DeviceNet protocol specification is a set of protocols that describe the connection and exchange of data between DeviceNet devices. The DeviceNet communication protocol is defined in the DeviceNet specification, which details connections, information protocols, and objects related to communication.
(1) DeviceNet is a connection-based network
Connections in DeviceNet provide a path to exchange information between various applications. When a connection is established, an identifier is assigned to the transmission of connection-related information, which is called a connection identifier CID (Connection Identifier). If a connection requires bidirectional data exchange, 2 different connection identifiers should be assigned.
The DeviceNet communication protocol is a protocol based on the connection concept. Once a connection is established, I/O data can be transferred between network devices. At this time, all protocols of DeviceNet I/O message are contained in the 11-bit CAN identifier, and other parts are data.
The 11-bit CAN identifier is used to define the connection ID. DeviceNet divides 11-bit CAN identifiers into 4 groups, and the connection ID of the first 3 groups includes 6-bit media access control identifier (MAC ID) and message identifier (Message ID). The definition of the information group is shown in Figure 2. Group 4 information is used for offline communication.
By design, the nodes in the DeviceNet system can manage their own identifiers. These identifiers are interleaved throughout the range. All nodes have a complete range of packet priorities that they can obtain, regardless of their MAC IDs. The repeating MAC ID algorithm guarantees the uniqueness of CAN identifiers without the need for network centralized tools or records.
(2) Message transmission of DeviceNet
DeviceNet replaces the traditional source/destination transport with a more efficient producer/consumer model. This mode requires the packet to be packaged so that it has a data identification bit field. Identifiers also provide a means to resolve multiple levels of priority (used in arbitration) for more efficient delivery of I/O data and use by multiple consumers.
DeviceNet defines two different types of messages, called I/O messages and explicit messages. I/O messages are suitable for data with high real-time requirements and control-oriented. The 8-bit data field in the I/O message data frame does not contain any protocol-related bits. Only when the I/O message is an I/O message fragment formed by dividing a large message, the data bit field One bit is used by the packet segmentation protocol. The connection identifier provides the relevant information of the I/O message. Before the I/O message is sent using the connection identifier, the sending and receiving devices of the message must be set first. The set content includes the properties of the source and destination objects, as well as the addresses of the data producers and consumers. Explicit message is suitable for multi-purpose point-to-point message transfer between two devices. It is a typical request-response communication method and is often used for node configuration and problem diagnosis. The Display message usually uses the connection identifier with low priority, and the relevant information of the message is contained in the data bit field of the data frame of the display message, including the service to be executed and the attributes and addresses of the related objects.
(3) Predefined master/slave connection groups
DeviceNet provides a powerful application layer protocol that allows dynamic configuration of connections between devices. But considering that some devices simply don’t need or have the resources to use this powerful feature, DeviceNet specifies a set of connection identifiers called predefined master/slave connection groups to simplify I/O and configuration in a master/slave structure type data transmission.
Many sensors and actuators are designed to perform functions that are predetermined (e.g. feel pressure, start motors, etc.), so the type and amount of data that these devices will produce and/or consume is known before power-up . These devices typically provide input data or request output data and configuration data. The predefined master/slave connection group can meet these requirements of the device, and all the configuration of the connection object provided by it is completed when the device is powered on. The only step the master device must perform when initiating a data stream is to broadcast ownership of the predefined connection group within the slave.
(4) DeviceNet object model and device description
① Object model. Provides a template for managing and implementing the properties (data), services (methods or steps) and behaviors of DeviceNet product components. The model provides an addressing scheme consisting of 4 numbers for each attribute, namely the node address (MAC ID), object class identifier, instance number, and attribute number. This level 4 address is combined with an explicit message connection to transfer data from one point to another on the DeviceNet network. Table 1 lists the ranges of the 4 address components:
Figure 3 is an object model of a generic DeviceNet device; Table 2 is a typical object class in DeviceNet products.
② Device Profiles. The DeviceNet specification is more than just a physical connection protocol specification. It facilitates interoperability between devices from different vendors by defining standard device models. All devices belonging to the same device model must support common identification and communication state data. Device descriptions are defined for various devices. The device description includes various device-specific data. Simple devices from multiple vendors (eg pushbuttons, motor starters, photocells, pneumatic valve actuators) that fit the device type description are logically interchangeable.
The DeviceNet specification defines an Electronic Data File (EDS). EDS is a simple file format that allows suppliers to provide product-specific information to other suppliers. This allows for user-friendly configuration tools that can be easily updated without constant revisions to the configuration software tools.
3 Communication adapter software system design
The following mainly introduces the design of the communication protocol. The realization of the software is guided by version 2.0 of the DeviceNet protocol specification, and different applications have different specific realizations. This article only gives the design principles and guiding ideology and principles.
3.1 Power-on state flow diagram of DeviceNet communication equipment
Before each device is powered on, there is a routine state flow process. This procedure describes the following things that must be done before a device can communicate on DeviceNet (such as duplicate MAC ID detection, etc.), and network events that affect device communication.
Figure 4 is the state flow diagram of the DeviceNet device after it is powered on, in which there are 4 states: sending duplicate MAC ID detection packets, waiting for duplicate MAC ID detection packets, online status, and communication error status.
3.2 Initialization of CAN chip
Before establishing the communication of the CAN bus, there are some initialization procedures in advance. Generally, the independent CAN chip SJA1000 needs to initialize the working register after power-on or when the software function is reset after power-on. When the system is powered on, the processor first runs its own special initialization process, and then enters the connection establishment process of the SJA1000 (pin 17 of the SJA1000 gets a Reset low-level pulse and enters the Reset mode). Before initializing the registers of SJA1000, the main microprocessor should check the mode/request flag of Reset. If SJA1000 is already in Reset mode, because all registers can only be written in Reset mode, all registers will get corresponding configuration information.
After finishing all the initialization work, SJA1000 enters the working mode, and makes the interrupt function of the CAN controller effective. Please refer to the supplementary edition of the website of this journal for the SJA1000 initialization and a program of simulating sending and receiving process written by C51.
3.3 Message Transceiver Procedures and Segmentation Services
The message sending and receiving protocols mentioned here have different definitions for different communication protocols. In addition, the data length of CAN cannot exceed 8 bytes, and how to support messages larger than 8 bytes involves segmentation services. The segment protocol information consists of 1 byte, in which the upper 2 bits represent the type of segment, and the lower 6 bits are used as segment counters to identify each data packet. It is calculated as:
fragmentCount=(fragmentcount+1) mod 64. Table 3 is the specific segment type.
Therefore, in the design of the program, support for the segmented service protocol should be added.
The process of sending and receiving packets is a reverse process. It should be noted that when writing a program, it is necessary to strictly follow the definition of the DeviceNet protocol specification, otherwise unpredictable errors will occur, which will bring a lot of trouble to future protocol conformance testing and bottom-level debugging.
3.4 Design of Main Program of DeviceNet Communication Adapter
The software consists of header files, initialization routines, functional subroutines and main routines.
The composition of the software provides the convenience of hardware and software upgrades. In the software, the part with the main processor, CAN controller and other hardware interfaces will be designed independently, while the main program and functional subprograms mainly focus on the completion of the protocol. This provides great convenience for future hardware modification and possible protocol modification.
The software is written in Franklin C51 language and debugged through Weifu E51L single chip microcomputer development device.
The software structure is shown in Figure 5.
After realizing all the functional modules, the most important thing is how to construct an organic main program module, organize these scattered modules, and carry out the initialization of the system. In addition, an optimized loop body should be designed and executed periodically to generate actions for messages on the DeviceNet network.