Depending on the configuration of an IO-Link Port and whether a physical IO-Link Device is connected to the IO-Link Port, either an Object representing the IO-Link Device is connected to the IO-Link Port or not. The following state machine describes, whether such an Object is there, and what ObjectType is used.
The top-level state machine defines the states “Port not configured as IO-Link” and “Select Device Instance Type”. In the first state the IO-Link Port is configured that no IO-Link Device is used (PortMode is either DEACTIVATED, DI_C/Q or DO_C/Q) and the optional Device Object is not available. In the second state the IO-Link-Port is configured to be an IO-Link Device (PortMode is either IOL_AUTOSTART or IOL_MANUAL) and the substates indicate whether a Device Object exists as well as the used ObjectType. Changes of the PortMode trigger transitions between the states. For the second state, additional transitions are defined that trigger the re-entrance of the state and thus the re-evaluation whether a Device Object exists as well as the used ObjectType. Those transitions include plugging in or off devices, changing the UseIODD Property or changes of IO-Link Port configuration Parameters.
Figure 6 – State machine describing if an Object is connected to an IO-Link Port
The sub-state-machine of the “Select Device Instance Type” describes three states indicating, whether the Device Object exists and what ObjectType is used.
- “Device not instantiated” indicates that the optional Device Object does not exist.
- “IODD Device” indicates that the Device Object exists and the IODD is used and therefore the concrete ObjectType related to the IODD is used.
- “IO-Link Device” indicates that the Device Object exists and the IOLinkDeviceType is used.
The sub-state-machine defines different choices to find the correct state.
When the PortMode is IOL_AUTOSTART but no device is connected, the “Device not instantiated” state is used.
When the PortMode is IOL_AUTOSTART and a device is connected, or the PortMode is IOL_MANUAL it is further decided if the “IODD Device” or the “IO-Link Device” state is used.
When the IODD representing the IO-Link Device is available in the server and the UseIODD Parameter is “True”, the “IODD Device” state is used, otherwise the “IO-Link Device” state is used.
Note that if an IO-Link Device is connected, the information of the connected IO-Link Device is used to identify the IODD, even if the IO-Link Port has a different device configured (Status = INCORRECT_DEVICE). Only when the PortMode is IOL_MANUAL and no device is connected (Status == NO_DEVICE || NOT_AVAILABLE) the configured device information is used to identify the IODD.
When the IO-Link Port is in the “IODD Device” state and the IODD is deleted (e.g. by the Method RemoveIODD using the force option) it changes to the “IO-Link Device” state.
When the IO-Link Port is in the “IO-Link Device” state and the IODD representing the IO-Link Device is added to the server (e.g. by the Method TransferIODD) and the UseIODD Parameter is “True” it changes to the “IODD Device” state.
Note that there can be limitations on what Variables can be accessed and what Methods can be executed from the Device Object (states “IO-Link Device” or “IODD Device”).
- When the PortMode is IOL_MANUAL and no device is connected (Status == NO_DEVICE || NOT_AVAILABLE) the Device Object is available so OPC UA Clients can already be configured to use the configured IO-Link Device, but since no physical IO-Link Device is connected, all access to Variables or Methods requiring device access will fail (bad code). Providing the structure of the configured IO-Link Device is especially helpful if an IODD is used, since the structure defined by the IODD is already available to the OPC UA Client (specific Parameters etc.).
- When the PortMode is IOL_MANUAL but the incorrect IO-Link Device is connected (Status == INCORRECT_DEVICE) accessing the Variables representing the process data (e.g. ProcessDataInput, ProcessDataOutput) will fail (bad code).