A General Purpose Discrete I/O Device according to Volume 1 Chapter 6 Device Profiles of the CIP NETWORKS LIBRARY interfaces to multiple discrete I/O device types that do not have network capabilities. Examples include sensors and actuators.
As such the General Purpose Discrete I/O Device supports a variety of objects described in Chapter 5A Object Library, Part A of the CIP NETWORKS LIBRARY.
Currently the example shipped with the SDK supports basic functionality of the following objects:
Discrete Input Point Object (Class Code: 0x08)
The Discrete Input Point (DIP) Object models discrete inputs in a product. Note that the term "input" is defined from the network's point of view. An input will produce data on the network.
The Discrete Input Point interface is to real input points such as a switch or screw terminal. The input is sampled and the data is stored in this object's Value attribute.
Discrete Output Point Object (Class Code: 0x09)
A Discrete Output Point (DOP) models discrete outputs in a product. Note that the term "output" is defined from the network's point of view. An output will consume data from the network.
The Discrete Output Point interface is to real output points such as a relay or LED. The output is read from this object's Values attribute and applied to the output terminal, such as a LED.
Discrete Output Group Object (Class Code: 0x1E)
The Discrete Output Group (DOG) Object binds a group of discrete output points in a module. All points bound to the group share all attributes contained in the group. If an attribute is shared across more than one Discrete Output Point (DOP), then it can be contained in a Discrete Output Group. A Discrete Output Point can also be bound to more than one Discrete Output Group.
The ODVA specifications model each individual input and output as separate instances of the Discrete Input Point and the Discrete Output Point Objects. The only required attribute is Attribute 3 Value of BOOL data type. BOOL types are encoded as octets, in compliance with the ODVA specifications. See C-5.2.1 BOOL Encoding in Volume 1.
The profile specific elements of this example are implemented in device_profiles\discrete_io_device\app_discrete_io_device.c, device_profiles\discrete_io_device\app_discrete_io_device_dip.c, device_profiles\discrete_io_device\app_discrete_io_device_dop.c, device_profiles\discrete_io_device\app_discrete_io_device_dog.c, and state machine related functionality in device_profiles\discrete_io_device\app_discrete_io_device_sm.c. Board specific functionality is located in appNV.c and below board\am64x-evm\freertos.
Create General Purpose Discrete I/O Device specific Content
The initialization of the General Purpose Discrete I/O Device specific object model is peformed in EI_APP_DIO_DEVICE_init. It sequentially calls more specialized functions that cover the setup of the object structure of the Discrete Output Group Object (Class Code: 0x1E), Discrete Output Point Object (Class Code: 0x09), Discrete Input Point Object (Class Code: 0x08), and assemblies for cyclic I/O communication and configuration.
Note
The statemachines for Digital Input Points and Digital Output Points as described in 5A-9.6 and 5A-10.5 Behavior in Volume 1 are only partially implemented for the Discrete Output Point Object and for Instance 1 only.
Initialization of the Discrete Output Group Object
The Discrete Output Group Object example code shipped with th EtherNet/IP stack currently implement Instance Attributes 6 to 10 only. In particular Instance Attributes 3 Number of Bound Instances and 4 Binding which would contain an array with the Instance IDs of the Discrete Output Point Object bound to the Output Group need to be added by the end user.
Initialization of the Discrete Output Point Object
The behavior of the Discrete Output Point Object is governed by a state machine specified in Figure 5A-10.3 State Transition Diagram for Discrete Output Point Object of Volume 1 of the CIP Network Library. This state machine models effects as Behaviors on transitions which is not supported by the state machine design pattern applied in the implementation. Thus those effects are typically realized as entry actions of the individual states resulting in minor deviations to the state machine specification in Volume 1 which is partially inconsistent with respect to the LED behavior in the Recoverable Fault state.
EI_APP_DOP_init (called as entry action in state Non-Existent) in file app_discrete_io_device_dop.c first creates an instance of the Discrete Output Point Object. It then adds the Get_Attribute_Single as Class Service and adds Attribute 1, Revision to the Class Instance. According to Volume 1 Chapter 5A-10.3 Common Services, the Get_Attribute_Single service is required if any Class Attribute is implemented.
Class attributes of the Discrete Output Point Object
Attribute ID
Name
Data Type
Value
1
Revision
UINT
1
After the Class is set up, Instances are created for each Digital Output Point. For each Instance Get_Attribute_Single and Set_Attribute_Single services are registered. Finally, the required Attribute 3, Value of type BOOL is added to each Instance and callback functions for the get and set services are registered. The default value for each Digital Output Point is set to 0. Additinally Instance Attributes 5 to 9 are created for Fault Action and Value, as well as Idle Action and value. They enable a system integrator to define the behavior of a device when it enters Fault or Idle states in the Discrete Output Points state machine.
::
for (int i = 1; ((EI_API_CIP_eERR_OK == errCode) && (i <= EI_APP_DIO_DEVICE_DOP_NUM_OF_INST)); i++)
{
// Default value of Value attribute in each instance.
ei_api_cip_edt_bool instanceValue = 0;
// Create an instance for each Digital Output Point.
EI_APP_DIP_init in app_discrete_io_device_dip.c first creates an instance of the Discrete Input Point Object. It adds the Get_Attribute_Single as Class Service and Attribute 1, Revision to the Class Instance. The value of the Revision Attribute is 2.
Class attributes of the Discrete Input Point Object
Attribute ID
Name
Data Type
Value
1
Revision
UINT
2
Within the Class, Instances are created for each Digital Input Point. For all instances the Get_Attribute_Single and service is registered. Finally the required Attribute 3, Value of type BOOL is added to each Instance and a callback function for the get service is registered.
::
for (int i = 1; ((EI_API_CIP_eERR_OK == errCode) && (i <= EI_APP_DISCRETE_IO_DIP_NUM_OF_INST)); i++)
{
// Default value for each instance.
ei_api_cip_edt_bool instanceValue = 0;
// Create an instance for each Digital Input Point.
Instance attributes of the Discrete Input Point (Instances 1 to EI_APP_DISCRETE_IO_DIP_NUM_OF_INST)
Attribute ID
Name
Data Type
Value
3
Value
BOOL
The EI_APP_DIP_getValueCb callback function itself simply retrieves the value from the attribute as there is no specific hardware input functionality available on the supported evaluation boards. This code requires modification to user hardware if corresponding functionality is available on the hardware.
The Discrete I/O Point example currently differs from the specifications in Chapter 6-10 of Volume 1 in that it uses vendor-spefic implementations of Consuming and Producing Assemblies, as well as a vendor-specific example of a Configuration Assembly that is based on the specifications in that section. The corresponding code is implemented in the function EI_APP_DIO_DEVICE_cipSetup in device_profiles\discrete_io_device\app_discrete_io_device.c.
Note
In the diagrams above not all parameters required by the API functions are indicated. Please review the example source code and the API documentation for full details.
Assembly Instances implemented in the General Purpose Discrete I/O Device Example
Instance ID
Description
0x64
Producing Assembly (Input Data)
0x65
Consuming Assembly (Output Data)
0x28
Configuration Assembly
0xFE
Input Only
0xFF
Listen-only
Finally add Attributes to the assemblies created earlier. Digital Input Points are added to the Producing Assembly and Digital Output Points are added to the Consuming Assembly. Attributes of Digital Output Group Instance are added to the Configuation Assembly.
::
// Add Digital Input Point Instance Attributes 3, Value to the Producing Assembly.
Please note that the data structure of the Configuration Assembly differs from the format specified in Volume 1 Section 6-10.9 Output Configuration Assembly Data Attribute Format.
::
// Add Digital Output Group Instances to the Configuration Assembly.
In the EDS files this is reflected by the following Connection Manager section (example for the exclusive owner connection):
::
[Connection Manager]
Object_Name = "Connection Manager Object";
Object_Class_Code = 0x06;
Connection1 =
0x04010002, $ trigger & transport
$ 0-15 = supported transport classes (class 1)
$ 16 = cyclic (1 = supported)
$ 17 = change of state (0 = not supported)
$ 18 = on demand (0 = not supported)
$ 19-23 = reserved (must be zero)
$ 24-27 = exclusive owner
$ 28-30 = reserved (must be zero)
$ 31 = client 0 (don't care for classes 0 and 1)
0x44640005, $ point/multicast & priority & realtime format
$ 0 = O=>T fixed (1 = supported)
$ 1 = O=>T variable (0 = not supported)
$ 2 = T=>O fixed (1 = supported)
$ 3 = T=>O variable (0 = not supported)
$ 4-7 = reserved (must be zero)
$ 8-10 = O=>T header (4 byte run/idle)
$ 11 = reserved (must be zero)
$ 12-14 = T=>O header
$ 15 = reserved (must be zero)
$ 16-19 = O=>T point-to-point
$ 20-23 = T=>O multicast
$ 24-27 = O=>T scheduled
$ 28-31 = T=>O scheduled
,2,Assem2, $ O=>T RPI,Size,Format
,2,Assem1, $ T=>O RPI,Size,Format
,, $ config part 1 (dynamic assemblies)
2,Assem3, $ config part 2 (module configuration)
"Exclusive Owner", $ connection name
"", $ Help string
"20 04 24 28 2C 65 2C 64"; $ exclusive owner path
::
The corresponding Create/Decode Path dialog in EZ-EDS:
The registration of a callback function for the Confguration Assembly that is triggered by the Forward_Open service request is as follows:
::
// Register Configuration Assembly callback.
errCode = EI_API_CIP_createCfgAssemblySimple(
pCipNode,
EI_APP_DIO_DEVICE_ASSEMBLY_CONFIGURATION,
EI_APP_DIO_DEVICE_configurationAssemblyCb);
::
Cyclic Run Function
The cyclic operation of the General Purpose Discrete I/O functionality is executed within EI_APP_DIO_DEVICE_run. Within this function EI_APP_DOG_run, EI_APP_DIP_run, and finally EI_APP_DOP_SM_run are called. In paticular the doAction of the state machine implementation (EI_APP_DOP_SM_RUN_doAction) controls the industrial LED array on the supported evaluation boards, by internally calling EI_APP_DOP_run.