IO-Link (IEC 61131-9) is a point-to-point connection between a master port and a single sensor or actuator. Besides the cyclic process data it carries parameters (read/write on demand) and events (diagnosis reported by the device). This page explains how to connect IO-Link devices to an Indel system, how to configure them and how they show up in INOS.

Quick start

Plug a COP-IOL module (product code 612564000) into a COP-PAS (GinLink) or a COP-MAS2 (COPBus).
Connect the device to one of the 8 IO-Link ports of the COP-IOL.
Add the device's IODD (the XML device description provided by the device vendor) to the project configuration.
Add an <IOLink> section with one <Port> per used port to the COP-IOL's user configuration (see Configuration).
Download. The port is enabled as soon as the fieldbus is operational, its process data appears in the process image and its parameters in INCO.

Minimal example, the device is detected automatically:

<IOLink>
    <Port Name="Distance" Number="0" />
</IOLink>

Hardware

COP-IOL module

The COP-IOL (612564000) is the IO-Link master module of the COP family:

8 ports (Number 0..7), each port connects exactly one IO-Link device.
Transmission rates COM1 (4.8 kBaud), COM2 (38.4 kBaud) and COM3 (230.4 kBaud), selected automatically by the device's wake-up response.
Every configured port runs its own task, so a slow or failing device never blocks the other ports.

Topologies

The COP-IOL is connected like any other COP module, either

Bus master	Bus	User configuration file	Port name
COP-PAS	GinLink	the COP-PAS's `cop0.xml` (COP-IOL as nested `<Card>`)	`COP0.IOL0.Distance`
COP-MAS2	COPBus	one `xcfg` file per COP module, e.g. `xcfg-iol.xml`	`IOL0.Distance`

The port name (last column, for a COP-IOL named IOL0 and a port named Distance) identifies the port everywhere: in INCO, in the process image channel names and in the API (see Parameter access from the application).

Configuration

Example: COP-IOL on a COP-PAS (GinLink)

The COP-IOL is a nested <Card> of the COP-PAS's user configuration (config/ginlink/cop0.xml). Address is the COP slot of the COP-IOL.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!--
    trans-table-type="xcfg-mod-gin-GIN-COP-MOD"
    trans-table-name="COP0"
-->
<Card Name="COP0" ProductName="COP-PAS" ProductCode="611143600" VendorId="0" Options="0x40000000">
 
    <Card Name="IOL0" ProductCode="612564000" VendorId="0" Address="0" PortCache="0">
        <IOLink>
            <!-- fixed device, 2ms cycle, events acknowledged automatically -->
            <Port Name="Sensor2" Number="2" CycleTime="2000000" EventAcknowledge="auto">
                <Device vendorId="350" vendorName="Baumer Electric AG" deviceId="101023" />
            </Port>
            <!-- fixed device, 4ms cycle, own channel name, manual event acknowledge -->
            <Port Name="Sensor6" Number="6" CycleTime="4000000" EventAcknowledge="manual">
                <Device vendorId="350" vendorName="Baumer Electric AG" deviceId="101005">
                    <Channel TextId="TN_Measuredvalue" name="Distance" />
                </Device>
            </Port>
            <!-- whatever device is connected -->
            <Port Name="Sensor7" Number="7" />
        </IOLink>
    </Card>
 
    <!-- further COP modules of this COP-PAS -->
    <Card Name="IO1" ProductCode="611042400" VendorId="0" Address="1">
        ...
    </Card>
 
</Card>

Example: COP-IOL on a COP-MAS2 (COPBus)

On the COPBus every COP module has its own user configuration file. The trans-table-name is the module name.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!--
    trans-table-type="xcfg-mod-cop"
    trans-table-name="IOL0"
-->
<Card Name="IOL0" ProductCode="612564000" Address="0" PortCache="0">
    <IOLink>
        <Port Name="Sensor2" Number="2" CycleTime="2000000" EventAcknowledge="auto">
            <Device vendorId="350" vendorName="Baumer Electric AG" deviceId="101023" />
        </Port>
        <Port Name="Sensor6" Number="6" CycleTime="4000000" EventAcknowledge="manual">
            <Device vendorId="350" vendorName="Baumer Electric AG" deviceId="101005">
                <Channel TextId="TN_Measuredvalue" name="Distance" />
            </Device>
        </Port>
    </IOLink>
</Card>

Complete, working examples are found in config_mcrobot_iolink/ginlink and config_mcrobot_iolink/copbus.

The <IOLink> section

The <IOLink> section inside the COP-IOL's <Card> lists the ports to use. Ports that are not listed stay disabled. Changes take effect at the next bus start (GinLink: also after a rescan).

<IOLink>
    <Port ...>                        <!-- 0..8 ports -->
        <Device ...>                  <!-- optional: expected device -->
            <Channel ... />           <!-- optional: 0..n channel names -->
        </Device>
    </Port>
</IOLink>

<Port> attributes

Attribute	Required	Default	Description
`Number`	yes	-	Port number on the COP-IOL, `0`..7.
`Name`	yes	-	Port name, last part of the port name (e.g. `COP0.IOL0`.Sensor6). Must be unique per COP-IOL.
`CycleTime`	no	10000000	Master cycle time in ns (default 10 ms). `0` uses the device's MinCycleTime, the fastest cycle the device supports. Allowed: not faster than the device's MinCycleTime and 2 x the bus cycle time, not slower than 132.8 ms. The value is rounded up to a multiple of the bus cycle time.
`EventAcknowledge`	no	`auto`	`auto` or `manual`, see Acknowledge: EventAcknowledge="auto" \| "manual".

<Device> element and automatic detection

The optional <Device> element tells which device is expected at the port.

Attribute	Required	Description
`deviceId`	no	IO-Link DeviceID (decimal) of the expected device. Missing or `"auto"`: the device is detected automatically.
`vendorId`	no	Informative only (VendorID of the device).
`vendorName`	no	Informative only.

At startup the port always reads the VendorID/DeviceID reported by the connected device. With that

no <Device> element (or deviceId missing/"auto"): the connected device is identified by its DeviceID and set up with the matching IODD. Use this for "any device" ports or exchangeable devices.
deviceId given: the connected device has to report exactly this DeviceID, otherwise the port stops with INOS_MCTARGET_IOLINK_DEVICEID_WRONG. Use this to detect wrongly plugged devices.

In both cases the IODD for the DeviceID has to be part of the configuration (see Device description (IODD)), otherwise the port stops with INOS_MCTARGET_IOLINK_DEVICEID_UNKNOWN.

Note: A <Device> element is also where the process data channel names are configured. To combine own channel names with automatic detection, just omit deviceId.

Device description (IODD)

Everything INOS knows about a device - its parameters, process data layout, texts and event codes - comes from the device's IODD. Therefore:

The IODD xml of every device type used has to be part of the configuration (any configuration directory, e.g. config/iolink).
The file name has to contain IODD (or iodd) and end with .xml, e.g. Baumer-OG0xxUR_ID101005-20210121-IODD1.1.xml. This is how IODDs are recognized among the downloaded files.
IODD version 1.1 is supported.
One IODD per DeviceID. A second IODD with the same DeviceID is rejected (INOS_MCTARGET_IOLINK_DEVICEID_DUPLICATE).
Images, language files etc. that come with an IODD package are not needed.

All loaded device types are listed in INCO under Target.resource.fieldbus.iolink.pool.

What you get in INOS

Process data

The process data of a device is mapped to process image channels, named <port name>.<item name>:

IODD process data item	Process image channel
`BooleanT`	digital input/output bit
`IntegerT`	analog input (adc) / output (dac) channel
`UIntegerT`	analog input (adc) / output (dac) channel, enum combo if the IODD defines SingleValues
`Float32T`	analog input (adc) / output (dac) channel

The item name is the IODD text of the item, or the name configured with a <Channel> element (see Texts and names). Example: the item "Measurement value" of the device at port COP0.IOL0.Sensor6 becomes the adc channel COP0.IOL0.Sensor6.Measurement value, or COP0.IOL0.Sensor6.Distance with the <Channel> example above.

Note: IODD texts often contain spaces and change between IODD versions. Configure own channel names for every channel the application uses.

Name check. Every item name is checked against the INCO naming guidelines: only letters, digits, spaces, _ and - are allowed. Periods are replaced by _ beforehand, in every channel name (from the IODD, a text data file or a <Channel> entry), because the process image would split the name at a period, even at an escaped one (\.). A name that still violates the guidelines (e.g. Temperature (°C) or On/Off) is used anyway, but reported with a trace:

IOL: device 'COP0.IOL0.Sensor6': channel name 'Temperature (°C)' (TextId 'TI_PD_Temp', from IODD) violates the INCO naming guidelines

By default this is a warning. With the iDev feature IO-Link > Strict channel names (ch.indel.inos.iolink.strictnames) it is an error, e.g. to enforce clean names in a release build.

On a warning or error, replace the default name by a valid one. The trace shows the text id and where the name comes from:

from IODD: add a <Channel> entry for this text id to the port's <Device> element (see Process data channel names in the COP-IOL configuration), or rename it for all devices of this type in a text data file (see Text data files).
from config: fix the name attribute of the <Channel> entry (see Process data channel names in the COP-IOL configuration).

If the IODD defines different process data layouts depending on a parameter (<ProcessData> with <Condition>), the parameter is read at startup and the matching layout is used.

The channels are updated every master cycle while the port is in state operate. They keep their names when a port is restarted or the bus is rescanned.

INCO tree

Target.resource.fieldbus.iolink
    pool                                  <- all device types (loaded IODDs)
    ports
        COP0                              <- bus module (here the COP-PAS)
            IOL0                          <- COP-IOL
                Sensor6                   <- port
                    prop                  <- port state, baudrate, cycle times, ...
                    actual                <- frame statistics, ISDU state
                    param                 <- all device parameters (from the IODD)

param contains one entry per IODD variable, records as folders with one entry per subindex, with the IODD's names, units, value ranges and value texts. Reading an entry reads it from the device, writing it writes it to the device.
Parameters the IODD marks as dynamic (values that change on the device itself, e.g. a temperature) are shown in red and are refreshed every 500 ms while they are watched in INCO.
The device also appears below its COP-IOL in the COP module tree.

Parameter access from the application

Parameters are addressed by port name, ISDU index and subindex (see the device's IODD or manual). Subindex 0 addresses the whole parameter/record.

INCO procedures of Target.resource.fieldbus.iolink:

Procedure	Description
`paramget`	Read a parameter (result as number or string).
`paramset`	Write a parameter, number and string overload.
`portenable`	Start a port again (e.g. after a device exchange).
`portdisable`	Stop a port.

Every port offers the same procedures without the port argument, below its INCO path in command:

Procedure	Description
`paramget(index:l, subindex:l, "")`	Read a parameter, returns its value (number or string).
`paramset(index:l, subindex:l, value:d, "")`	Write a numeric parameter.
`paramset(index:l, subindex:l, "value", "")`	Write a string parameter.

From a PC via INCO (inco_32.dll / libinco_32.so)

Any INCO client can call these procedures. Example in Python, reading the temperature (index 86, V_DeviceTemperature) of the device on port COP0.IOL0.Sensor6 of target Net227:

>>> temperature = inco_32.CallProcedureExSync("Net227", "Target.resource.fieldbus.iolink.ports.COP0.IOL0.Sensor6.command.paramget(86:l,0:l,\"\")")
>>> print(temperature)
34.0

Writing works the same way (:l marks integer, :d floating point arguments, strings are quoted):

>>> port = "Target.resource.fieldbus.iolink.ports.COP0.IOL0.Sensor6.command"
>>> # numeric parameter: set point 1 (index 60, subindex 1)
>>> inco_32.CallProcedureExSync("Net227", port + ".paramset(60:l,1:l,50.0:d,\"\")")
>>> # string parameter: application tag (index 0x18 = 24)
>>> inco_32.CallProcedureExSync("Net227", port + ".paramset(24:l,0:l,\"Gripper left\",\"\")")
>>> tag = inco_32.CallProcedureExSync("Net227", port + ".paramget(24:l,0:l,\"\")")

From the target application (C++)

IOLINK is the CINOSMcTargetIOLinkMaster singleton:

// read a numeric parameter (index 60 = V_SSC1_Setpoints, subindex 1)
double dValue;
uint32 uResult = IOLINK.ParamGet("COP0.IOL0.Sensor6", 60, 1, dValue, "");
 
// write it (IODD value range 4..86, otherwise INOS_MCTARGET_IOLINK_PARAM_NBR_MAX)
uResult = IOLINK.ParamSet("COP0.IOL0.Sensor6", 60, 1, 50.0, "");
 
// read a string parameter (index 0x18 = ApplicationTag)
char cValue[64];
uResult = IOLINK.ParamGet("COP0.IOL0.Sensor6", 0x18, 0, cValue, sizeof(cValue), "");

Note: Parameter changes are written to the device only. IO-Link Data Storage (automatic parameter backup/restore by the master) is not supported. If parameters have to survive a device exchange, the application has to write them, e.g. after the port reached operate.

Texts and names

The names shown in INCO and used for the process image channels, as well as the event texts, are taken from the IODD's text collection (primary language). They can be replaced without touching the IODD. For each text the first match wins:

a <Channel> entry in the COP-IOL configuration (process data channel names only),
a text data file ch.indel.iolink.device.<deviceId>.text.xml,
the IODD text,
the text id itself (if the IODD has no such text).

Texts are referenced by their IODD text id. Look them up in the IODD:

<RecordItem subindex="1" bitOffset="4">
    <SimpleDatatype xsi:type="UIntegerT" bitLength="12" />
    <Name textId="TN_Measuredvalue" />                    <!-- the text id -->
</RecordItem>
...
<Text id="TN_Measuredvalue" value="Measurement value" /> <!-- the text -->

Process data channel names in the COP-IOL configuration

A <Channel> element inside the port's <Device> element renames one process data channel. TextId is the text id of the process data item, name the new name.

<Port Name="Sensor6" Number="6">
    <Device deviceId="101005">
        <Channel TextId="TN_Measuredvalue" name="Distance" />
        <Channel TextId="TN_SwitchstateSSC1" name="Present" />
    </Device>
</Port>

Result: COP0.IOL0.Sensor6.Distance and COP0.IOL0.Sensor6.Present instead of COP0.IOL0.Sensor6.Measurement value and COP0.IOL0.Sensor6.Switch state SSC1.

Use this to give channels application specific names, which can differ for two equal devices on different ports.

Text data files

A text data file replaces IODD texts for all devices with a given DeviceID: parameter names and descriptions in INCO, value texts of enum parameters, process data channel names and event texts. It's a standard INOS xml data file, the object id has to be ch.indel.iolink.device.<deviceId>.text and every <property> replaces the text with the given text id. Name the file like the object, e.g. ch.indel.iolink.device.101005.text.xml.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<object id="ch.indel.iolink.device.101005.text">
    <!-- parameter name -->
    <property id="TN_Stability" type="string">Signal quality</property>
    <!-- value texts of an enum parameter -->
    <property id="TN_Stability_False" type="string">poor</property>
    <property id="TN_Stability_True" type="string">good</property>
    <!-- parameter description -->
    <property id="TD_DeviceTemperatureCurrent" type="string">Current housing temperature</property>
    <!-- event name and description (event code 36000) -->
    <property id="TN_Event_36000" type="string">Set point too close to the object</property>
    <property id="TD_Event_36000" type="string">Teach the set point again</property>
</object>

Typical uses: translations (the IODD's primary language is usually English), shorter or company specific names, or clearer event texts for the operator.

Note: Names used in INCO paths can't contain a dot. Dots in texts are replaced automatically.

Events and messages

Devices report diagnosis as IO-Link events, e.g. "Temperature overrun" or "Maintenance required". Each event has a 16 bit EventCode (standard codes per IO-Link Annex D, or device specific ones defined in the IODD), a type and a mode.

Event -> message

Every event is logged and posted as INOS message with the message code 0x4044<EventCode> (INOS_IOLINK_EVENT_BASE + EventCode):

Event type	Message type
Error	`INOS_MCMSG_TYPE_ERROR`
Warning	`INOS_MCMSG_TYPE_WARNING`
Notification	`INOS_MCMSG_TYPE_INFO`

The message text is the event's text (IODD, text data file or standard EventCode text). The message carries an Info data object with the properties Text (event name) and Description (IODD event description, if any), which the application can display.

Getting the messages to the application

IO-Link messages are posted by the port tasks. To have them show up in the application's Machine message handling (folder Machine, message history, HMI), the machine module has to receive target messages. Set TgtMsg=Client in the machine's Param (e.g. applicat/lua/machine.dt2):

Param ; text_256 ; "Flags=Msg,Mode,Stat,NvR,UnR,MsgHistory,Emg,Module,Data,Script,Job TgtMsg=Client Lua=All ...";

Without TgtMsg=Client the events are still logged, but the application doesn't see them as messages.

Acknowledge: EventAcknowledge="auto" | "manual"

Events with mode appears / disappears describe a condition that comes and goes (e.g. over temperature). Events with mode single shot are a one-time notification.

Event mode	EventAcknowledge="auto" (default)	EventAcknowledge="manual"
appears	message posted	message posted
disappears	the message posted on appears is acknowledged automatically	nothing, the message stays until the operator acknowledges it
single shot	message posted, operator acknowledges	message posted, operator acknowledges

auto: the message list always shows the conditions that are present right now. Use it for conditions that just need to be visible.
manual: the operator sees every condition that occurred, even if it was gone a moment later. Use it for conditions that need attention (e.g. short circuit, temperature fault).

Limitations

Max. 32 bits of process data in and 32 bits out per device (INOS_MCTARGET_IOLINK_DEVICE_MAX_32BIT_SUPPORTED otherwise).
Operate M-sequence types TYPE_2_1 .. TYPE_2_5 and TYPE_2_V only, i.e. devices with process data. Devices without process data (TYPE_0, TYPE_1_2, TYPE_1_V) and legacy V1.0 devices with more than 2 octets of process data (TYPE_1_1/1_2 interleaved) are rejected with INOS_MCTARGET_IOLINK_OPERATE_MSEQUENCE_NOT_SUPPORTED.
IO-Link mode only, no SIO/DI/DO mode.
Cycle time between 2 ms (or 2 x bus cycle) and 132.8 ms.
No Data Storage (parameter backup/restore).
IODD data types OctetStringT, TimeT and TimeSpanT are not supported as parameters.

Troubleshooting

Symptom	Check
Port stays `inactive`, `INOS_MCTARGET_IOLINK_NO_SENSOR_DETECTED`	No sensor connected to this port number, or the cable/supply is broken (the port draws no current).
Port stays `inactive`, `INOS_MCTARGET_IOLINK_ESTABLISH_COMM_TO_DEVICE_FAILED`	Device connected to the right port number? Cable? Device supplied?
`INOS_MCTARGET_IOLINK_DEVICEID_UNKNOWN`	IODD of this DeviceID missing in the configuration, or its file name doesn't contain `IODD`. The DeviceID read from the device is shown in the port's `param` folder (`page1.deviceid`).
`INOS_MCTARGET_IOLINK_DEVICEID_WRONG`	Another device than configured is connected. Fix the config or use automatic detection.
Device works, but no IO-Link messages in the application	`TgtMsg=Client` missing in the machine config.
Channel named ...TN_xxx	The IODD has no text for this text id. Add it to a text data file or a `<Channel>` entry.
Trace `channel name '...' violates the INCO naming guidelines`	The default name contains invalid characters. Replace it, see name check.
Port runs, but no process data channels	The device has no process data, or more than 32 bits. Check the port's `prop` (`processdatainoctets` / `processdataoutoctets`).
`INOS_IOLINK_ISDU_*` on parameter access	The device rejected the access, see Parameter access errors (0x4043xxxx).

Error codes

Master errors (0x403F60xx)

Reported by port enable (shown in the port's prop, logged and returned by portenable) or by parameter access.

Code	Name (`INOS_MCTARGET_IOLINK_`...)	When
0x403F6000	GENERAL	Reserved, not raised currently.
0x403F6001	NOT_IMPLEMENTED	Reserved, not raised currently.
0x403F6002	PORT_UNKNOWN	API/INCO call with a port name that isn't configured.
0x403F6003	INDEX_INVALID	Parameter access to an index the IODD doesn't define; IODD defines an index twice (logged, second one ignored).
0x403F6004	SUBINDEX_INVALID	Parameter access to a subindex the IODD doesn't define; IODD defines a subindex twice (logged, second one ignored).
0x403F6005	DEVICEID_DUPLICATE	Two IODDs with the same DeviceID in the configuration, the second one is ignored.
0x403F6006	DEVICEID_MISSING	Reserved, not raised currently (a missing deviceId means automatic detection).
0x403F6007	DEVICEID_WRONG	Port enable: the connected device reports another DeviceID than configured.
0x403F6008	DEVICEID_UNKNOWN	Port enable: no IODD for the DeviceID of the connected device.
0x403F6009	DEVICE_NOT_CONNECTED	Parameter access to a port that isn't in operation (no device).
0x403F600A	DEVICE_CYCLETIME_TOO_FAST	Port enable: `CycleTime` shorter than the device's MinCycleTime.
0x403F600B	DEVICE_CYCLETIME_MIN_2MS	Port enable: `CycleTime` shorter than 2 x the bus cycle time.
0x403F600C	DEVICE_CYCLETIME_SET_FAILED	Port enable: the device didn't accept the master cycle time.
0x403F600D	DEVICE_MAX_32BIT_SUPPORTED	Port enable: device has more than 32 bits process data in or out.
0x403F600E	PARAM_IS_NUMBER	String access (get/set) to a numeric parameter.
0x403F600F	PARAM_IS_STRING	Numeric access (get/set) to a string parameter.
0x403F6010	PARAM_WRITE_ONLY	Read of a write-only parameter.
0x403F6011	PARAM_READ_ONLY	Write of a read-only parameter.
0x403F6012	PARAM_STR_MIN_LENGTH	String write shorter than the IODD's minimum length.
0x403F6013	PARAM_STR_MAX_LENGTH	String write longer than the IODD's maximum length.
0x403F6014	PARAM_NBR_MIN	Numeric write below the IODD's value range.
0x403F6015	PARAM_NBR_MAX	Numeric write above the IODD's value range.
0x403F6016	PARAM_WRITE_SIZE	Write of more than 1 byte to the direct parameter page.
0x403F6017	PARAM_INDEX_NOT_SUPPORTED	Access to a record that can only be accessed as a whole, but is too large (> 64 bits).
0x403F6018	PARAM_ISDU_NOT_SUPPORTED	Access to an ISDU index of a device without ISDU support.
0x403F6019	COMM_CHECKSUM_ERROR	Frame with checksum error during startup.
0x403F601A	COMM_SEND_TIMEOUT	Frame couldn't be sent during startup (hardware).
0x403F601B	COMM_RECEIVE_TIMEOUT	No answer from the device during startup.
0x403F601C	COMM_CMD_UNKNOWN	Internal error.
0x403F601D	OPERATE_MSEQUENCE_NOT_SUPPORTED	Port enable: the device's operate M-sequence type isn't supported (see Limitations).
0x403F601E	ESTABLISH_COMM_TO_DEVICE_FAILED	Port enable: wake-up failed, no device answered within 2 s.
0x403F601F	ESTABLISH_COMM_INVALID_BAUDRATE	Port enable: device answered with an unknown transmission rate.
0x403F6020	IODD_PARSE_ERROR	Configuration: an IODD file isn't valid xml (logged with line/column).
0x403F6021	IODD_INVALID	Configuration: an IODD file has no valid device identity.
0x403F6022	PARAM_PAGE_WRITE_NOT_IN_OPERATE	Write to the direct parameter page while the port is in operate.
0x403F6023	PROCESSDATA_VARIANT_UNRESOLVED	Port enable: the IODD's process data layout depends on a parameter that couldn't be read.
0x403F6024	DEVICE_MINCYCLETIME_INVALID	Port enable: the device reports a MinCycleTime with a reserved time base.
0x403F6025	DEVICE_CYCLETIME_TOO_SLOW	Port enable: `CycleTime` longer than 132.8 ms (the longest cycle time IO-Link can encode).
0x403F6026	NO_SENSOR_DETECTED	Port enable: no current drawn on the port within 1000 ms after power-on, i.e. no sensor connected (or cable/supply problem).

Parameter access errors (0x4043xxxx)

Parameter access (ISDU) errors. The master detected ones are:

Code	Name (`INOS_IOLINK_ISDU_`...)	When
0x40431000	COMM_ERROR	No valid answer from the device (device gone, GinLink down).
0x40431100	TIMEOUT	The device kept answering "busy" for too long.
0x40435600	CHECKUM_ERROR	ISDU answer with checksum error (after retries).
0x40435700	ILLEGAL_SERVICE	Reserved, not raised currently.

If the device rejects an access, its IO-Link ErrorType (Annex C) is returned as 0x4043<ErrorCode><AdditionalCode>, e.g.:

Code	Name (`INOS_IOLINK_ISDU_`...)	Meaning
0x40438000	DEVICE_APPLICATION_ERROR	Device application error, no details.
0x40438011	INDEX_NOT_AVAILABLE	Index not available in the device.
0x40438012	SUBINDEX_NOT_AVAILABLE	Subindex not available in the device.
0x40438020	SERVICE_TEMP_NOT_AVAILABLE	Service temporarily not available.
0x40438021	SERVICE_TEMP_NOT_AVAILABLE_LOCAL	Temporarily not available, local operation at the device.
0x40438022	SERVICE_TEMP_NOT_AVAILABLE_DEVICE	Temporarily not available, device control (e.g. teach-in running).
0x40438023	ACCESS_DENIED	Write to a read-only index.
0x40438030	PARAMETER_VALUE_OUT_OF_RANGE	Value out of range.
0x40438031	PARAMETER_VALUE_ABOVE_LIMIT	Value above limit.
0x40438032	PARAMETER_VALUE_BELOW_LIMIT	Value below limit.
0x40438033	PARAMETER_LENGTH_OVERRUN	Data too long.
0x40438034	PARAMETER_LENGTH_UNDERRUN	Data too short.
0x40438035	FUNCTION_NOT_AVAILABLE	Command not supported by the device.
0x40438036	FUNCTION_TEMP_UNAVAILABLE	Command temporarily unavailable.
0x40438040	INVALID_PARAM_SET	Conflicting parameter (single parameter).
0x40438041	INCONSISTENT_PARAM_SET	Parameter set inconsistent (block parameterization).
0x40438082	APPLICATION_NOT_READY	Device application not ready.
0x40438100	UNSPECIFIC	Vendor specific, codes 0x8101.. are defined by the device manual.

Event messages (0x4044xxxx)

Event messages carry 0x4044<EventCode>. Device specific EventCodes get their text from the IODD (or a text data file), the standard EventCodes (IO-Link Annex D) are predefined:

Code	Name (`INOS_IOLINK_EVENT_`...)	Meaning
0x40440000	BASE	No malfunction.
0x40441000	GENERAL_MALFUNCTION	General malfunction, unknown error.
0x40444000	TEMPERATURE_FAULT	Temperature fault, overload.
0x40444210	TEMPERATURE_OVERRUN	Device temperature overrun.
0x40444220	TEMPERATURE_UNDERRUN	Device temperature underrun.
0x40445000	HARDWARE_FAULT	Device hardware fault.
0x40445010	COMPONENT_MALFUNCTION	Component malfunction.
0x40445011	NVM_LOSS	Non volatile memory loss.
0x40445012	BATTERIES_LOW	Batteries low.
0x40445100	POWER_SUPPLY_FAULT	General power supply fault.
0x40445101	FUSE_BLOWN	Fuse blown/open.
0x40445110	PRIMARY_VOLTAGE_OVERRUN	Primary supply voltage overrun.
0x40445111	PRIMARY_VOLTAGE_UNDERRUN	Primary supply voltage underrun.
0x40445112	SECONDARY_VOLTAGE_FAULT	Secondary supply voltage fault.
0x40446000	SOFTWARE_FAULT	Device software fault.
0x40446320	PARAMETER_ERROR	Parameter error.
0x40446321	PARAMETER_MISSING	Parameter missing.
0x40447700	WIRE_BREAK	Wire break of a subordinate device (0x7701..0x770F: device 1..15).
0x40447710	SHORT_CIRCUIT	Short circuit.
0x40447711	GROUND_FAULT	Ground fault.
0x40448C00	APPLICATION_FAULT	Technology specific application fault.
0x40448C01	SIMULATION_ACTIVE	Simulation active.
0x40448C10	PROCESS_VAR_OVERRUN	Process variable range overrun.
0x40448C20	MEASUREMENT_RANGE_EXCEEDED	Measurement range exceeded.
0x40448C30	PROCESS_VAR_UNDERRUN	Process variable range underrun.
0x40448C40	MAINTENANCE_CLEANING	Maintenance required, cleaning.
0x40448C41	MAINTENANCE_REFILL	Maintenance required, refill.
0x40448C42	MAINTENANCE_EXCHANGE_PARTS	Maintenance required, exchange wear and tear parts.

Table of Contents