Module: dn

DN is only available on devices that have been licensed to use DeviceNet and have CAN hardware support. DN is the object returned when the plugin is loaded. It is the starting point for configuring and using DN.

DN requires a memory map in order to start. A memory map is XML that describes how the memory is organized. When applied, the attributes described in the map become accessible to JavaScript. JavaScript can then write to the outputs and connect to changed events on the inputs. Memory maps can be created and edited using the memory map editor tool. See Memory Map for more detail. Settings up a DN memory map is very similar to FLNet, except that DN can also contain a CIP section. See FLNet Memory Map for an example of how to set up an FLNet memory map.

The name of the plugin for loading is 'dn'.

About

DeviceNet is a digital, multi-drop network that connects and serves as a communication network between industrial controllers and I/O devices. Each device and/or controller is a node on the network. DeviceNet is a producer-consumer network that supports multiple communication hierarchies and message prioritization. DeviceNet systems can be configured to operate in a master-slave or a distributed control architecture using peer-to-peer communication. DeviceNet systems offer a single point of connection for configuration and control by supporting both I/O and explicit messaging. DeviceNet also has the unique feature of having power on the network. This allows devices with limited power requirements to be powered directly from the network, reducing connection points and physical size.

DeviceNet uses a trunk-line/drop-line topology that provides separate wire pairs for both signal and power distribution. Thick or thin cable can be used for either trunklines or droplines. End-to-end network length varies with data rate and cable thickness.

DeviceNet uses the Common Industrial Protocol, called CIP, for its upper protocol layers. CIP is strictly object oriented. Each object has attributes (data) and services (commands) and behavior (reaction to events). Two different types of objects are defined in the CIP specification: communication objects and application-specific objects. Vendor-specific objects can also be defined by product vendors for situations where a product requires functionality that is not in the specification.

See:

Requires