When setting up a drive, everyone knows an "object" is something you want to accelerate to a particular velocity in the shortest time possible. But what is an "object" when you're connecting a drive to an industrial network? Here's a clue: it doesn't accelerate.
There are many terms in the world of communication networks that are probably unfamiliar to motion engineers - terms like "class" and "attribute," and understanding them will make it easier to link drives to networks. This introduction to networking terminology looks specifically at installing DeviceNet into a motion system, as most drives now offer an interface to this popular bus.
Getting physical
In networking, the hardware is referred to as the "physical layer." In DeviceNet, it consists of an integrated- circuit transceiver device based on the Controller Area Network (CAN) bus and the transmission media of cables, connectors, and junction boxes.
The transceiver is a balanced differential- voltage driver and receiver package that employs twisted pair communications similar to the RS- 485 systems. Its outputs connect directly to the DeviceNet cable.
The physical layer can be configured as a "trunk and drop line" where the cable is laid as a backbone (trunk) with additional cables branching (drops) from it to the individual nodes, or connected devices. The physical layer addresses up to 64 nodes. It's structured so that you can remove any node without shutting down the network. The cable wire, a twisted pair signal conductor and braided shield with drain, houses both signal and 24 Vdc power conductors. The 24-V conductors can power some low-power devices directly.
The physical layer also offers selectable data rates of 125, 250, and 500 kbaud. Cable lengths are a function of data rates, so the higher the rate, the shorter the cable.
Proper protocol
DeviceNet's foundation is a network protocol that's also based on CAN. CAN was developed in Europe by Bosch to provide an internal communications network for automobiles. In this application, it requires a high level of error detection, low latency (response) times, and a high degree of determinism or confidence that messages are transmitted and received at specific times.
Its success has resulted in a readily available supply of low-cost integrated circuit products. Intel, Motorola, Philips, and Siemens all manufacture CAN bus interface chips as well as microprocessors with integral CAN controller modules.
The protocol controller accepts data from a device's main processor and formats it for transmission on the bus. It also receives information from the bus and converts it to data for use by the main processor.
The protocol and transceivers allow non-destructive message arbitration. In other words, if two devices send a message at the same time, the higher priority message remains intact and continues to its destination. This conflict-resolution scheme is different from many networks where both messages would be lost and the transmitting devices would need to re-issue them.
A node's main processor must format information sent to and received from the protocol controller in a manner that conforms with DeviceNet specifications. This is the job of the Application Layer.
Loose ends
There are several components that make up a typical DeviceNet system, including a PLC or PC, a scanner, cabling, and the various nodes on the network. The scanner serves as the interface between a PLC or PC and the network. It is located in the PLC as a separate module, and in the PC as an option board. We'll assume that a PLC is the system controller for the following discussions.
Each device connected to the network has its own address. The address is referred to as a media access control identifier or MAC ID, and goes from 0 to 63. These identifiers are usually set by a switch on the devices.
The scanner module acts as a buffer between the main PLC processor and network. It holds records of information moving through the network in the form of data tables. The information includes the status of discrete inputs and outputs, as well as large data blocks. These tables are continuously updated at a rate selected during initial network setup, typically about 10 msec. Tables for large blocks of data are only updated when a PLC initiates a request for data.
Continue on page 2
In and out
DeviceNet data are exchanged using two different message schemes referred to as I/O and explicit messaging. I/O messaging uses discrete input and output tables; and explicit messaging uses large block data transfer areas.
In I/O messaging, data exchanged are updated by the scanner once every scan cycle. You can think of it as high-speed I/O between a PLC and a product it's directly wired to.
To make it more flexible, it comes in four flavors; polled, strobed, cyclic, and change-of-state. Polled is a point-to-point transfer of data sent by the scanner when it solicits a response from a single device. Strobed is a multicast data transfer sent by the scanner when it solicits a response from each slave device.
Cyclic messaging transfers data with slave devices on a regular basis selectable by the user. Change-ofstate transfers data with slave devices when data change or at a user-configured rate.
I/O messaging is the easiest way to map DeviceNet I/O points directly into PLC program ladder logic.
Explicit messaging only occurs when the PLC processor initiates a transfer. The large blocks of data exchanged have a lower priority than I/O messaging. Therefore, the time it takes for them to reach their destination varies, depending on network traffic during message initiation.
You can think of explicit messaging as data transmitted using an RS- 232 serial connection. Serial data transmission is typically used for large amounts of data, such as setup parameters, that are not time critical.
While these messages allow access to large, complex data, the access mechanism, from a PLC programming standpoint, is considerably more complex. Data must be exchanged using transfer methods in the PLC program. For those familiar with this, these are the file copy (COP) and file move (MOV) commands. Additionally, the data must be painstakingly organized in a PLC integer file.
Information in explicit messages must also include the path to locate these data. The path consists of the class ID, the instance number, and the attribute ID parameters. Each parameter gives the receiving device an ever more detailed description of what type of data to expect. It must also include the action to get or set the data and the MAC ID.
Here is an example of the data required to issue an explicit message to change the index move distance in a brushless servo drive with indexing capability. The numbers are in hexadecimal notation.
MAC ID Number: 05
Get/Set Code (10 = set data/0E = get data): 01
Class ID Number - selects Drive Parameters: 0F
Instance Number - selects Index 1 Distance Parameter: 282
Attribute Number - set to 1: 1 Actual Parameter Value (Index 1 Position): 0001FECB (Here's the actual new position data).
This is a lot of work just to change the commanded position for an index motion. And, because this is an explicit message, there is no guarantee of how long it will take before the drive receives it. It may be 100 msec or several seconds. Despite its complexity and speed limitations, however, explicit messaging provides an excellent means to set and query many parameters in a single device.
Drive connection
Suppose you want to connect an integrated servo or positioning drive and motion controller to DeviceNet, and you want the equivalent functionality of discrete, hardwired I/O. No problem.
I/O messaging is a direct replacement for hard-wired I/O. And most positioning servo drives that support DeviceNet use a version of it.
Once you've made the physical connections, the next step is to transfer parameters and data in a manner similar to that used with serial interfaces. With DeviceNet, you should be able to easily transfer gain, configuration data, and motion parameters like index distance and speed.
Before a PLC can access a network node, however, engineers must map it into the scanner's scan list using some sort of DeviceNet manager software. Mapping determines which PLC bits transfer data between the controller and drive. You also set the I/O messaging method (polled, cyclic, and so on) at this time. This will allow the PLC's ladder logic program to access I/O data over DeviceNet.
As configured, the ladder logic program controls the positioning servo drive's input and output functions just as if they were hard-wired. If, as is often the case, the digital drive has more I/O functions than actual physical inputs and outputs, DeviceNet can get around this. Using the input functions previously described, we can construct a ladder logic program to control all the I/O any positioning servo drive might need.
Continue on page 3
For these drives, explicit messaging is more appropriate for transferring such non time-critical data as gain and mode settings and motion parameters like acceleration or maximum speed.
Considerably more thought is required, however, for the PLC program since it necessitates using PLC file-copying techniques to transfer data in addition to specifying the classes, instances, and attributes. Formats for explicit messaging vary slightly depending on the manufacturer of the scanner module.
Making the message explicit
Here's an example of what it takes to set up an explicit message. Let's assume we want to set the drive's position loop proportional gain to a value of 2.5.
Step 1: As mentioned earlier, an explicit message requires that you specify the class, instance, and attribute for the parameter you wish to change or query, so you must first determine these values.
Step 2: Next, assemble a complete explicit message. In addition to the class, instance, attribute, and parameter value, you must include a header that gives the message's destination and size.
Step 3: When the data are organized correctly, you can then enter the values into a PLC integer data file. This file is simply an area of the PLC memory where data are stored in integer format.
Step 4: Now, using ladder logic, the commands must be executed to send the integer file to the scanner module for transmission to the positioning drive. To do this, copy the integer file to a specific location in the PLC's M0 file. Here, an explicit message must start at the word location 224. When the file is copied to the PLC, it will be transferred to the scanner module's M0 file and sent to the positioning drive.
Step 5: The explicit message may take several seconds to transfer to the drive, depending on network traffic. The positioning drive will send an explicit message response back to the scanner module. To use the response data in the PLC program, they must be copied from the scanner into the PLC integer file using the same file copy technique mentioned above, except the source is the MI file instead of the M0 file.
Mike Woelfel is senior product engineer at Rockwell Automation in Eden Prairie, Minn.