IOL-Interface-Spec 10002 V113 Jun19
IOL-Interface-Spec 10002 V113 Jun19
IOL-Interface-Spec 10002 V113 Jun19
and
System
Specification
Version 1.1.3
June 2019
Any comments, proposals, requests on this document are appreciated through the IO-Link CR
database www.io-link-projects.com. Please provide name and email address.
Login: IO-Link-V113
Password: Report
Important notes:
NOTE 1 The IO-Link Community Rules shall be observed prior to the development and marketing of IO-Link products.
The document can be downloaded from the www.io-link.com portal.
NOTE 2 Any IO-Link Device shall provide an associated IODD file. Easy access to the file and potential updates shall
be possible. It is the responsibility of the IO-Link Device manufacturer to test the IODD file with the help of
the IODD-Checker tool available per download from www.io-link.com.
NOTE 3 Any IO-Link devices shall provide an associated manufacturer declaration on the conformity of the device. A
corresponding form with references to relevant documents is available per download from www.io-link.com.
Disclaimer:
The attention of adopters is directed to the possibility that compliance with or adoption of IO-Link Community
specifications may require use of an invention covered by patent rights. The IO-Link Community shall not be
responsible for identifying patents for which a license may be required by any IO-Link Community specification, or
for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. IO-
Link Community specifications are prospective and advisory only. Prospective users are responsible for protecting
themselves against liability for infringement of patents.
The information contained in this document is subject to change without notice. The material in this document details
an IO-Link Community specification in accordance with the license and notices set forth on this page. This
document does not represent a commitment to implement any portion of this specification in any company's
products.
WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE IO-LINK COMMUNITY
MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF
MERCHANTABILITY OR WARRANTY OF FITNESS FOR PARTICULAR PURPOSE OR USE.
In no event shall the IO-Link Community be liable for errors contained herein or for indirect, incidental, special,
consequential, reliance or cover damages, including loss of profits, revenue, data or use, incurred by any user or
any third party. Compliance with this specification does not absolve manufacturers of IO-Link equipment, from the
requirements of safety and regulatory agencies (TÜV, IFA, UL, CSA, etc.).
© No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
_____________________________________________________________________________________________________________________
CONTENTS
INTRODUCTION ................................................................................................................... 21
1 Scope ............................................................................................................................ 23
2 Normative references .................................................................................................... 23
3 Terms, definitions, symbols, abbreviated terms and conventions ................................... 24
3.1 Terms and definitions............................................................................................ 24
3.2 Symbols and abbreviated terms ............................................................................ 28
3.3 Conventions .......................................................................................................... 30
General ......................................................................................................... 30
Service parameters ....................................................................................... 30
Service procedures ........................................................................................ 30
Service attributes........................................................................................... 31
Figures .......................................................................................................... 31
Transmission octet order ............................................................................... 31
Behavioral descriptions.................................................................................. 31
4 Overview of SDCI (IO-Link TM ) ........................................................................................ 33
4.1 Purpose of technology .......................................................................................... 33
4.2 Positioning within the automation hierarchy .......................................................... 33
4.3 Wiring, connectors and power ............................................................................... 34
4.4 Communication features of SDCI .......................................................................... 34
4.5 Role of a Master ................................................................................................... 36
4.6 SDCI configuration ................................................................................................ 37
4.7 Mapping to fieldbuses and/or other upper level systems ....................................... 37
4.8 Standard structure ................................................................................................ 37
5 Physical Layer (PL) ....................................................................................................... 38
5.1 General ................................................................................................................. 38
Basics ........................................................................................................... 38
Topology ....................................................................................................... 38
5.2 Physical layer services ......................................................................................... 39
Overview ....................................................................................................... 39
PL services .................................................................................................... 40
5.3 Transmitter/Receiver ............................................................................................. 41
Description method ........................................................................................ 41
Electrical requirements .................................................................................. 41
Timing requirements ...................................................................................... 46
5.4 Power supply ........................................................................................................ 49
Power supply options ..................................................................................... 49
Port Class B .................................................................................................. 50
Power-on requirements .................................................................................. 51
5.5 Medium ................................................................................................................. 51
Connectors .................................................................................................... 51
Cable ............................................................................................................. 52
6 Standard Input and Output (SIO) ................................................................................... 53
7 Data link layer (DL)........................................................................................................ 53
7.1 General ................................................................................................................. 53
7.2 Data link layer services ......................................................................................... 55
Version 1.1.3 –4– IO-Link Interface and System © IO-Link
Figure 29 – Structure and services of the data link layer (Device) ......................................... 54
Figure 30 – State machines of the data link layer .................................................................. 68
Figure 31 – Example of an attempt to establish communication ............................................ 69
Figure 32 – Failed attempt to establish communication ......................................................... 70
Figure 33 – Retry strategy to establish communication ......................................................... 70
Figure 34 – Fallback procedure ............................................................................................. 71
Figure 35 – State machine of the Master DL-mode handler ................................................... 72
Figure 36 – Submachine 1 to establish communication ......................................................... 72
Figure 37 – State machine of the Device DL-mode handler ................................................... 75
Figure 38 – SDCI message sequences ................................................................................. 77
Figure 39 – Overview of M-sequence types ........................................................................... 77
Figure 40 – State machine of the Master message handler ................................................... 78
Figure 41 – Submachine "Response 3" of the message handler ............................................ 79
Figure 42 – Submachine "Response 8" of the message handler ............................................ 79
Figure 43 – Submachine "Response 15" of the message handler .......................................... 79
Figure 44 – State machine of the Device message handler ................................................... 82
Figure 45 – Interleave mode for the segmented transmission of Process Data ...................... 84
Figure 46 – State machine of the Master Process Data handler ............................................ 84
Figure 47 – State machine of the Device Process Data handler ............................................ 85
Figure 48 – State machine of the Master On-request Data handler ....................................... 87
Figure 49 – State machine of the Device On-request Data handler ....................................... 88
Figure 50 – Structure of the ISDU ......................................................................................... 89
Figure 51 – State machine of the Master ISDU handler ......................................................... 90
Figure 52 – State machine of the Device ISDU handler ......................................................... 92
Figure 53 – State machine of the Master command handler .................................................. 93
Figure 54 – State machine of the Device command handler .................................................. 94
Figure 55 – State machine of the Master Event handler ........................................................ 96
Figure 56 – State machine of the Device Event handler ........................................................ 97
Figure 57 – Structure and services of the application layer (Master) ..................................... 98
Figure 58 – Structure and services of the application layer (Device) ..................................... 99
Figure 59 – OD state machine of the Master AL .................................................................. 107
Figure 60 – OD state machine of the Device AL .................................................................. 109
Figure 61 – Sequence diagram for the transmission of On-request Data ............................. 110
Figure 62 – Sequence diagram for On-request Data in case of errors ................................. 111
Figure 63 – Sequence diagram for On-request Data in case of timeout ............................... 111
Figure 64 – Event state machine of the Master AL .............................................................. 112
Figure 65 – Event state machine of the Device AL .............................................................. 113
Figure 66 – Single Event scheduling ................................................................................... 114
Figure 67 – Sequence diagram for output Process Data...................................................... 115
Figure 68 – Sequence diagram for input Process Data ........................................................ 116
Figure 69 – Structure and services of the Master System Management ............................... 117
Figure 70 – Sequence chart of the use case "port x setup" ................................................. 118
Figure 71 – Main state machine of the Master System Management ................................... 124
IO-Link Interface and System © IO-Link – 13 – Version 1.1.3
1 INTRODUCTION
2 0.1 General
3 IEC 61131-9 is part of a series of standards on programmable controllers and the associated
4 peripherals and should be read in conjunction with the other parts of the series.
5 Where a conflict exists between this and other IEC standards (except basic safety standards),
6 the provisions of this standard should be considered to govern in the area of programmable
7 controllers and their associated peripherals.
8 The increased use of micro-controllers embedded in low-cost sensors and actuators has
9 provided opportunities for adding diagnosis and configuration data to support increasing
10 application requirements.
11 The driving force for the SDCI (IO-Link™ 1)) technology is the need of these low-cost sensors
12 and actuators to exchange this diagnosis and configuration data with a controller (PC or PLC)
13 using a low-cost, digital communication technology while maintaining backward compatibility
14 with the current DI/DO signals.
15 In fieldbus concepts, the SDCI technology defines a generic interface for connecting sensors
16 and actuators to a Master unit, which may be combined with gateway capabilities to become a
17 fieldbus remote I/O node.
18 Any SDCI compliant Device can be attached to any available interface port of the Master.
19 SDCI compliant Devices perform physical to digital conversion in the Device, and then
20 communicate the result directly in a standard format using "coded switching" of the 24 V I/O
21 signalling line, thus removing the need for different DI, DO, AI, AO modules and a variety of
22 cables.
23 Physical topology is point-to-point from each Device to the Master using 3 wires over
24 distances up to 20 m. The SDCI physical interface is backward compatible with the usual
25 24 V I/O signalling specified in IEC 61131-2. Transmission rates of 4,8 kbit/s, 38,4 kbit/s and
26 230,4 kbit/s are supported.
27 The Master of the SDCI interface detects, identifies and manages Devices plugged into its
28 ports.
29 Tools allow the association of Devices with their corresponding electronic I/O Device Des-
30 criptions (IODD) and their subsequent configuration to match the application requirements.
31 The SDCI technology specifies three different levels of diagnostic capabilities: for immediate
32 response by automated needs during the production phase, for medium term response by
33 operator intervention, or for longer term commissioning and maintenance via extended
34 diagnosis information.
36 Conformity with IEC 61131-9 cannot be claimed unless the requirements of Annex H are met.
37 Terms of general use are defined in IEC 61131-1 or in the IEC 60050 series. More specific
38 terms are defined in each part.
—————————
1 IO-Link TM is a trade name of the "IO-Link Community". This information is given for the convenience of users of
this international Standard and does not constitute an endorsement by IEC of the trade name holder or any of its
products. Compliance to this standard does not require use of the registered logos for IO-Link TM . Use of the
registered logos for IO-Link TM requires permission of the "IO-Link Community".
Version 1.1.3 – 22 – IO-Link Interface and System © IO-Link
44
45 IEC takes no position concerning the evidence, validity and scope of these patent rights.
46 The holders of these patents' rights have assured the IEC that they are willing to negotiate
47 licences either free of charge or under reasonable and non-discriminatory terms and condi-
48 tions with applicants throughout the world. In this respect, the statements of the holders of
49 these patent rights are registered with IEC.
[AB] ABB AG
Heidelberg
Germany
[FE] Festo AG
Esslingen
Germany
[SI] Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
[SK] Sick AG
Waldkirch
Germany
51
52 Attention is drawn to the possibility that some of the elements of this document may be the
53 subject of patent rights other than those identified above. IEC shall not be held responsible for
54 identifying any or all such patent rights.
58
IO-Link Interface and System © IO-Link – 23 – Version 1.1.3
59 PROGRAMMABLE CONTROLLERS —
60
61 Part 9: Single-drop digital communication interface
62 for small sensors and actuators (SDCI)
63
64
65 1 Scope
66 This part of IEC 61131 specifies a single-drop digital communication interface technology for
67 small sensors and actuators SDCI (commonly known as IO-Link™ 2), which extends the
68 traditional digital input and digital output interfaces as defined in IEC 61131-2 towards a point-
69 to-point communication link. This technology enables the transfer of parameters to Devices
70 and the delivery of diagnostic information from the Devices to the automation system.
71 This technology is mainly intended for use with simple sensors and actuators in factory
72 automation, which include small and cost-effective microcontrollers.
73 This part specifies the SDCI communication services and protocol (physical layer, data link
74 layer and application layer in accordance with the ISO/OSI reference model) for both SDCI
75 Masters and Devices.
77 This part does not cover communication interfaces or systems incorporating multiple point or
78 multiple drop linkages, or integration of SDCI into higher level systems such as fieldbuses.
79 2 Normative references
80 The following documents, in whole or in part, are normatively referenced in this document and
81 are indispensable for its application. For dated references, only the edition cited applies. For
82 undated references, the latest edition of the referenced document (including any
83 amendments) applies.
84 IEC 60947-5-2, Low-voltage switchgear and controlgear – Part 5-2: Control circuit devices
85 and switching elements – Proximity switches
86 IEC 61000-4-2, Electromagnetic compatibility (EMC) – Part 4-2: Testing and measurement
87 techniques – Electrostatic discharge immunity test
88 IEC 61000-4-3, Electromagnetic compatibility (EMC) – Part 4-3: Testing and measurement
89 techniques – Radiated, radiofrequency, electromagnetic field immunity test
90 IEC 61000-4-4, Electromagnetic compatibility (EMC) – Part 4-4: Testing and measurement
91 techniques – Electrical fast transient/burst immunity test
92 IEC 61000-4-5, Electromagnetic compatibility (EMC) – Part 4-5: Testing and measurement
93 techniques – Surge immunity test
94 IEC 61000-4-6, Electromagnetic compatibility (EMC) – Part 4-6: Testing and measurement
95 techniques – Immunity to conducted disturbances, induced by radio-frequency fields
96 IEC 61000-4-11, Electromagnetic compatibility (EMC) – Part 4-11: Testing and measurement
97 techniques – Voltage dips, short interruptions and voltage variations immunity tests
—————————
2 IO-Link TM is a trade name of the "IO-Link Community". This information is given for the convenience of users of
this international Standard and does not constitute an endorsement by IEC of the trade name holder or any of its
products. Compliance to this standard does not require use of the registered logos for IO-Link TM . Use of the
registered logos for IO-Link TM requires permission of the "IO-Link Community".
Version 1.1.3 – 24 – IO-Link Interface and System © IO-Link
100 IEC 61000-6-4, Electromagnetic compatibility (EMC) – Part 6-4: Generic standards –
101 Emission standard for industrial environments
102 IEC 61076-2-101, Connectors for electronic equipment – Product requirements – Part 2-101:
103 Circular connectors – Detail specification for M12 connectors with screw-locking
105 IEC 61131-2, Programmable controllers – Part 2: Equipment requirements and tests
107 ISO/IEC 646:1991, Information technology – ISO 7-bit coded character set for information
108 interchange
109 ISO/IEC 2022, Information technology – Character code structure and extension techniques
110 ISO/IEC 10646, Information technology – Universal Multiple-Octet Coded Character Set
111 (UCS)
112 ISO/IEC 10731, Information technology – Open Systems Interconnection – Basic Reference
113 Model – Conventions for the definition of OSI services
114 ISO/IEC 19505 (all parts), Information technology – Object Management Group Unified
115 Modeling Language (OMG UML)
116 ISO 1177, Information processing – Character structure for start/stop and synchronous
117 character-oriented transmission
119 Internet Engineering Task Force (IETF): RFC 1305 – Network Time Protocol Version 4:
120 Specification, Implementation and Analysis; available at < www.ietf.org >
121
126 3.1.1
127 address
128 part of the M-sequence control to reference data within data categories of a communication
129 channel
130 3.1.2
131 application layer
132 AL
133 <SDCI> part of the protocol responsible for the transmission of Process Data objects and On-
134 request Data objects
135 3.1.3
136 Block Parameter
137 consistent parameter access via multiple Indices or Subindices
138 3.1.4
139 checksum
140 <SDCI> complementary part of the overall data integrity measures in the data link layer in
141 addition to the UART parity bit
IO-Link Interface and System © IO-Link – 25 – Version 1.1.3
142 3.1.5
143 CHKPDU
144 integrity protection data within an ISDU communication channel generated through XOR
145 processing the octets of a request or response
146 3.1.6
147 coded switching
148 SDCI communication, based on the standard binary signal levels of IEC 61131-2
149 3.1.7
150 COM1
151 SDCI communication mode with transmission rate of 4,8 kbit/s
152 3.1.8
153 COM2
154 SDCI communication mode with transmission rate of 38,4 kbit/s
155 3.1.9
156 COM3
157 SDCI communication mode with transmission rate of 230,4 kbit/s
158 3.1.10
159 COMx
160 one out of three possible SDCI communication modes COM1, COM2, or COM3
161 3.1.11
162 communication channel
163 logical connection between Master and Device
164 Note 1 to entry: Four communication channels are defined: process channel, page and ISDU channel (for
165 parameters), and diagnosis channel.
166 3.1.12
167 communication error
168 unexpected disturbance of the SDCI transmission protocol
169 3.1.13
170 cycle time
171 time to transmit an M-sequence between a Master and its Device including the following idle
172 time
173 3.1.14
174 Device
175 single passive peer to a Master such as a sensor or actuator
176 Note 1 to entry: Uppercase "Device" is used for SDCI equipment, while lowercase "device" is used in a generic
177 manner.
178 3.1.15
179 Direct Parameters
180 directly (page) addressed parameters transferred acyclically via the page communication
181 channel without acknowledgment
182 3.1.16
183 dynamic parameter
184 part of a Device's parameter set defined by on-board user interfaces such as teach-in buttons
185 or control panels in addition to the static parameters
186 3.1.17
187 Event
188 instance of a change of conditions in a Device
189 Note 1 to entry: Uppercase "Event" is used for SDCI Events, while lowercase "event" is used in a generic manner.
190 Note 2 to entry: An Event is indicated via the Event flag within the Device's status cyclic information, then acyclic
191 transfer of Event data (typically diagnosis information) is conveyed through the diagnosis communication channel.
Version 1.1.3 – 26 – IO-Link Interface and System © IO-Link
192 3.1.18
193 fallback
194 transition of a port from coded switching to switching signal mode
195 3.1.19
196 inspection level
197 degree of verification for the Device identity
198 3.1.20
199 interleave
200 segmented cyclic data exchange for Process Data with more than 2 octets through
201 subsequent cycles
202 3.1.21
203 ISDU
204 indexed service data unit used for acyclic acknowledged transmission of parameters that can
205 be segmented in a number of M-sequences
206 3.1.22
207 legacy (Device or Master)
208 Device or Master designed in accordance with [8] 3
209 3.1.23
210 M-sequence
211 sequence of two messages comprising a Master message and its subsequent Device
212 message
213 3.1.24
214 M-sequence control
215 first octet in a Master message indicating the read/write operation, the type of the
216 communication channel, and the address, for example offset or flow control
217 3.1.25
218 M-sequence error
219 unexpected or wrong message content, or no response
220 3.1.26
221 M-sequence type
222 one particular M-sequence format out of a set of specified M-sequence formats
223 3.1.27
224 Master
225 active peer connected through ports to one up to n Devices and which provides an interface
226 to the gateway to the upper level communication systems or PLCs
227 Note 1 to entry: Uppercase "Master" is used for SDCI equipment, while lowercase "master" is used in a generic
228 manner.
229 3.1.28
230 message
231 <SDCI> sequence of UART frames transferred either from a Master to its Device or vice versa
232 following the rules of the SDCI protocol
233 3.1.29
234 On-request Data
235 OD
236 acyclically transmitted data upon request of the Master application consisting of parameters
237 or Event data
—————————
3 Numbers in square brackets refer to the Bibliography.
IO-Link Interface and System © IO-Link – 27 – Version 1.1.3
238 3.1.30
239 physical layer
240 first layer of the ISO-OSI reference model, which provides the mechanical, electrical,
241 functional and procedural means to activate, maintain, and de-activate physical connections
242 for bit transmission between data-link entities
243 Note 1 to entry: Physical layer also provides means for wake-up and fallback procedures.
244 [SOURCE: ISO/IEC 7498-1, 7.7.2, modified — text extracted from subclause, note added]
245 3.1.31
246 port
247 communication medium interface of the Master to one Device
248 3.1.32
249 Process Data
250 PD
251 input or output values from or to a discrete or continuous automation process cyclically
252 transferred with high priority and in a configured schedule automatically between Master and
253 Device
254 3.1.33
255 Process Data cycle
256 complete transfer of all Process Data from or to an individual Device that may comprise
257 several cycles in case of segmentation (interleave)
258 3.1.34
259 single parameter
260 independent parameter access via one single Index or Subindex
261 3.1.35
262 SIO
263 port operation mode in accordance with digital input and output defined in IEC 61131-2 that is
264 established after power-up or fallback or unsuccessful communication attempts
265 3.1.36
266 static parameter
267 part of a Device's parameter set to be saved in a Master for the case of replacement without
268 engineering tools
269 3.1.37
270 switching signal
271 binary signal from or to a Device when in SIO mode (as opposed to the "coded switching"
272 SDCI communication)
273 3.1.38
274 System Management
275 SM
276 <SDCI> means to control and coordinate the internal communication layers and the
277 exceptions within the Master and its ports, and within each Device
278 3.1.39
279 UART frame
280 <SDCI> bit sequence starting with a start bit, followed by eight bits carrying a data octet,
281 followed by an even parity bit and ending with one stop bit
282 3.1.40
283 wake-up
284 procedure for causing a Device to change its mode from SIO to SDCI
Version 1.1.3 – 28 – IO-Link Interface and System © IO-Link
285 3.1.41
286 wake-up request
287 WURQ
288 physical layer service used by the Master to initiate wake-up of a Device, and put it in a
289 receive ready state
AL application layer
BEP bit error probability
C/Q connection for communication (C) or switching (Q) signal (SIO)
DI digital input
DL data link layer
DO digital output
IQPKH maximum driver current on high-side driver in unsaturated operating status ON (measured in A)
IQPKL maximum driver current on low-side driver in unsaturated operating status ON (measured in A)
IQQ quiescent current at input C/Q to V0 with inactive output drivers (measured in A)
r time to reach a stable level with reference to the beginning of the start bit (measured in T BIT )
s time to exit a stable level with reference to the beginning of the start bit (measured in T BIT )
V0 voltage at L-
VD+ L voltage drop on the line between the L+ connections on Master and Device (measured in V)
VD0 L voltage drop on the line between the L- connections on Master and Device (measured in V)
VDQ L voltage drop on the line between the C/Q connections on Master and Device (measured in V)
VHYS hysteresis of receiver threshold voltage (measured in V)
VIH input voltage range at connection C/Q for high signal (measured in V)
VIL input voltage range at connection C/Q for low signal (measured in V)
VTHH threshold voltage of receiver for safe detection of a high signal (measured in V)
VTHL threshold voltage of receiver for safe detection of a low signal (measured in V)
291
302 The service specification in this standard uses a tabular format to describe the component
303 parameters of the service primitives. The parameters which apply to each group of service
304 primitives are set out in tables. Each table consists of up to five columns:
322 a) a parameter-specific constraint "(=)" indicates that the parameter is semantically equiva-
323 lent to the parameter in the service primitive to its immediate left in the table;
324 b) an indication that some note applies to the entry "(n)" indicates that the following note "n"
325 contains additional information related to the parameter and its use.
326 3.3.3 Service procedures
327 The procedures are defined in terms of:
328 • the interactions between application entities through the exchange of protocol data units;
329 and
330 • the interactions between a communication layer service provider and a communication
331 layer service consumer in the same system through the invocation of service primitives.
IO-Link Interface and System © IO-Link – 31 – Version 1.1.3
332 These procedures are applicable to instances of communication between systems which
333 support time-constrained communications services within the communication layers.
342 • an arrow with just a service name represents both a request and the corresponding
343 confirmation, with the request being in the direction of the arrow;
344 • a request without confirmation, as well as all indications and responses are labelled as
345 such (i.e. service.req, service.ind, service.rsp).
346 Figure 1 shows the example of a confirmed service.
Initiator Responder
Service.req
Service.ind
Service.rsp
Service.cnf
347
Key
MSO = Most significant octet 0 t
LSO = Least significant octet Transmission time
352
353 Figure 2 – Memory storage and transmission order for WORD based data types
357 State diagrams are the primary source for implementations whereas sequence charts
358 illustrate certain use cases.
360 • triggers/events coming from external requests ("calls") or internal changes such as
361 timeouts;
Version 1.1.3 – 32 – IO-Link Interface and System © IO-Link
366 In this document, the concept of "nested states" with superstates and substates is used as
367 shown in the example of Figure 3.
ConventionSample_0
Superstate
E_7
Default_entry/
Tn
A_1 X_4
Termination
B_2 Y_5
Substates
Event1[Guard1]/
Tn+1
C_3 Z_6
Event2[Guard2]/
Tn+2
368
370 UML 2 allows hierarchies of states with superstates and substates. The highest superstate
371 represents the entire state machine.
372 This concept allows for simplified modelling since the content of superstates can be moved to
373 a separate drawing. An eyeglasses icon usually represents this content.
374 Compared to "flat" state machines, a particular set of rules shall be observed for "nested
375 states":
376 a) A transition to the edge of a superstate (e.g. Default_entry) implies transition to the initial
377 substate (e.g. A_1).
378 b) Transition to a termination state inside a superstate implies a transition without event and
379 guard to a state outside (e.g.X_4). The superstate will become inactive.
380 c) A transition from any of the substates (e.g. A_1, B_2, or C_3) to a state outside (Y_5) can
381 take place whenever Event1 occurs and Guard1 is true. This is helpful in case of common
382 errors within the substates. The superstate will become inactive.
383 d) A transition from a particular substate (e.g. C_3) to a state outside (Z_6) can take place
384 whenever Event2 occurs and Guard2 is true. The superstate will become inactive.
385 Due to UML design tool restrictions the following exceptions apply.
386 For state diagrams, a service parameter (in capital letters) is attached to the service name via
387 an underscore character, such as for example in DL_SetMode_INACTIVE.
388 For sequence diagrams, the service primitive is attached via an underscore character instead
389 of a dot, and the service parameter is added in parenthesis, such as for example in
390 DL_Event_ind (OPERATE).
392 Asynchronously received service calls are not modelled in detail within state diagrams.
IO-Link Interface and System © IO-Link – 33 – Version 1.1.3
398 The single-drop digital communication interface technology for small sensors and actuators
399 SDCI (commonly known as IO-Link TM ) defines a migration path from the existing digital input
400 and digital output interfaces for switching 24 V Devices as defined in IEC 61131-2 towards a
401 point-to-point communication link. Thus, for example, digital I/O modules in existing fieldbus
402 peripherals can be replaced by SDCI Master modules providing both classic DI/DO interfaces
403 and SDCI. Analog transmission technology can be replaced by SDCI combining its robust-
404 ness, parameterization, and diagnostic features with the saving of digital/analog and
405 analog/digital conversion efforts.
PLC / Host
Parameter
Fieldbus controller server
Fieldbus
integration
409 Figure 5 – Domain of the SDCI technology within the automation hierarchy
—————————
4 IO-Link TM is a trade name of the "IO-Link Community". This information is given for the convenience of users of
this international Standard and does not constitute an endorsement by IEC of the trade name holder or any of its
products. Compliance to this standard does not require use of the registered logos for IO-Link TM . Use of the
registered logos for IO-Link TM requires permission of the "IO-Link Community".
Version 1.1.3 – 34 – IO-Link Interface and System © IO-Link
410 The SDCI technology defines a generic interface for connecting sensors and actuators to a
411 Master unit, which may be combined with gateway capabilities to become a fieldbus remote
412 I/O node.
413 Starting point for the design of SDCI is the classic 24 V digital input (DI) defined in
414 IEC 61131-2 and output interface (DO) specified in Table 6. Thus, SDCI offers connectivity of
415 classic 24 V sensors ("switching signals") as a default operational mode. Additional connec-
416 tivity is provided for actuators when a port has been configured into "single-drop
417 communication mode".
418 Many sensors and actuators nowadays are already equipped with microcontrollers offering a
419 UART interface that can be extended by addition of a few hardware components and protocol
420 software to support SDCI communication. This second operational mode uses "coded
421 switching" of the 24 V I/O signalling line. Once activated, the SDCI mode supports
422 parameterization, cyclic data exchange, diagnosis reporting, identification & maintenance
423 information, and external parameter storage for Device backup and fast reload of replacement
424 devices. Sensors and actuators with SDCI capability are referred to as "Devices" in this
425 standard. To improve start-up performance these Devices usually provide non-volatile storage
426 for parameters.
427 NOTE Configuration and parameterization of Devices is supported through an XML-based device description (see
428 [6]), which is not part of this standard.
434 Five pins connections (port class B) are specified for Devices requiring additional power from
435 an independant 24 V power supply.
436 NOTE A port class A Device using the fourth wire is not compatible with a port class B Master.
437 Maximum length of cables is 20 m, shielding is not required.
Process data
Parameter and
commands
0...32
octets
in 231 0
0xFFFF
Index 0...65535,
232 octets/index
Subindex 1...255
maximum
selective
51 10 5 Event memory
(diagnosis)
...
231 0
0...32 0...32
Subindex 0
octets octets
entire record
out
...
Direct Parameter
0x00 page 1+2
15 0
440
442 A Device may receive Process Data (out) to control a discrete or continuous automation
443 process or send Process Data (in) representing its current state or measurement values. The
444 Device usually provides parameters enabling the user to configure its functions to satisfy
445 particular needs. To support this case a large parameter space is defined with access via an
446 Index (0 to 65535; with a predefined organization) and a Subindex (0 to 255).
447 The first two index entries 0 and 1 are reserved for the Direct Parameter page 1 and 2 with a
448 maximum of 16 octets each. Parameter page 1 is mainly dedicated to Master commands such
449 as Device startup and fallback, retrieval of Device specific operational and identification
450 information. Parameter page 2 allows for a maximum of 16 octets of Device specific
451 parameters.
452 The other indices (2 to 65535) each allow access to one record having a maximum size of 232
453 octets. Subindex 0 specifies transmission of the complete record addressed by the Index,
454 other subindices specify transfer of selected data items within the record.
455 Within a record, individual data items may start on any bit offset, and their length may range
456 from 1 bit to 232 octets, but the total number of data items in the record cannot exceed 255.
457 The organization of data items within a record is specified in the IO Device Description
458 (IODD).
459 All changes of Device condition that require reporting or intervention are stored within an
460 Event memory before transmission. An Event flag is then set in the cyclic data exchange to
461 indicate the existence of an Event.
462 Communication between a Master and a Device is point-to-point and is based on the principle
463 of a Master first sending a request message and then a Device sending a response message
464 (see Figure 38). Both messages together are called an M-sequence. Several M-sequence
465 types are defined to support user requirements for data transmission (see Figure 39).
466 Data of various categories are transmitted through separate communication channels within
467 the data link layer, as shown in Figure 7.
Direct
DirectParameter
Parameter Page
Page
(Page
(Page11 or
or2)
2)
Configuration/
Configuration/
maintenance
maintenance
Parameter
Parameter ISDU
ISDU
(Index
(Index>1)
>1)
On-request
On-request (acyclic)
(acyclic)
Errors
Errors
Events
Events Warnings Diagnosis
Diagnosis
Warnings
Notifications
Notifications
468
470 • Operational data such as Device inputs and outputs is transmitted through a process
471 channel using cyclic transfer. Operational data may also be associated with qualifiers such
472 as valid/invalid.
473 • Configuration and maintenance parameters are transmitted using acyclic transfers. A page
474 channel is provided for direct access to parameter pages 1 and 2, and an ISDU channel is
475 used for accessing additional parameters and commands.
Version 1.1.3 – 36 – IO-Link Interface and System © IO-Link
476 • Device events are transmitted using acyclic transfers through a diagnostic channel. Device
477 events are reported using 3 severity levels, error, warning, and notification.
478 The first octet of a Master message controls the data transfer direction (read/write) and the
479 type of communication channel.
480 Figure 8 shows each port of a Master has its own data link layer which interfaces to a
481 common master application layer. Within the application layer, the services of the data link
482 layer are translated into actions on Process Data objects (input/output), On-request Data
483 objects (read/write), and events. Master applications include a Configuration Manager (CM),
484 Data Storage mechanism (DS), Diagnosis Unit (DU), On-request Data Exchange (ODE), and a
485 Process Data Exchange (PDE).
486 System Management checks identification of the connected Devices and adjusts ports and
487 Devices to match the chosen configuration and the properties of the connected Devices. It
488 controls the state machines in the application (AL) and data link layers (DL), for example at
489 start-up.
Master applications
management
System management
Data link
DL
DL DL
DL DL
DL layer (DL)
Port ... Port ... Port Physical
Port Port Port
layer (PL)
Acyclic Cyclic
communication communication
channels channel
(on-request) (process data)
management
DL
System management
DL
On-request data objects Process data objects
Output
Device
Device technology
technology
490
500 If there is a mismatch between the Device parameters and the stored parameter set within the
501 Master, the parameters in the Device are overwritten (see 11.4) or the stored parameters
502 within the master are updated depending on the configuration.
IO-Link Interface and System © IO-Link – 37 – Version 1.1.3
503 The Master is responsible for the assembling and disassembling of all data from or to the
504 Devices (see Clause 11).
505 The Master provides a Data Storage area of at least 2 048 octets per Device for backup of
506 Device data (see 11.4). The Master may combine this Device data together with all other
507 relevant data for its own operation, and make this data available for higher level applications
508 for Master backup purpose or recipe control (see 13.4.2).
Master Device
SMI Technology
AL AL
SM DL DL DL ... SIO SM DL SIO
PL PL PL ... PL
Medium
533
535 Clause 10 specifies Device applications and features. These include Process Data Exchange
536 (PDE), Parameter Management (PM), Data Storage (DS), and Event Dispatcher (ED).
537 Technology specific Device applications are not part of this standard. They may be specified
538 in profiles for particular Device families.
539 Clause 11 specifies Master applications and features. These include Process Data Exchange
540 (PDE), On-request Data Exchange (ODE), Configuration Management (CM), Data Storage
541 (DS) and Diagnosis Unit (DU). A Standardized Master Interface (SMI) ensures uniform
542 behavior via specified services and allows for usage of one PDCT (Master tool) for different
543 Master brands.
Version 1.1.3 – 38 – IO-Link Interface and System © IO-Link
544 Clause 12 provides a holistic best practice view on Data Storage behavior of both Master and
545 Device. Clause 13 outlines integration aspects of IO-Link into various automation and IT
546 realms.
547 Several normative and informative annexes are included. Annex A defines the available M-
548 sequence types. Annex B describes the parameters of the Direct Parameter page and the
549 fixed Device parameters. Annex C lists the error types in case of acyclic transmissions and
550 Annex D the EventCodes (diagnosis information of Devices). Annex E specifies the coding of
551 argument blocks for the SMI services. Annex F specifies the available basic and composite
552 data types. Annex G defines the structure of Data Storage objects. Annex H deals with
553 conformity and electromagnetic compatibility test requirements and Annex I provides graphs
554 of residual error probabilities, demonstrating the level of SDCI's data integrity. The
555 informative Annex J provides an example of the sequence of acyclic data transmissions. The
556 informative Annex K explains two recommended methods for detecting parameter changes in
557 the context of Data Storage.
L+
C/Q
Master Device
L-
564
570 Port class A uses a four-pin connector. The fourth wire may be used as an additional signal
571 line complying with IEC 61131-2. Its support is optional in both Masters and Devices.
572 Five wire connections (port class B) are specified for Devices requiring additional power from
573 an independant 24 V power supply (see 5.5.1).
574 NOTE A port class A Device using the fourth wire is not compatible with a port class B Master.
575 5.1.2 Topology
576 The SDCI system topology uses point-to-point links between a Master and its Devices as
577 shown in Figure 11. The Master may have multiple ports for the connection of Devices. Only
578 one Device shall be connected to each port.
Master
Ports 1 2 3 ... n
SDCI links
Devices 1 2 3 n
579
Master
Port x handler DL-mode handler Message handler SIO NC/
DI / DO DI / DO
Mode switch
Medium
584
586 The physical layer specifies the operation of the C/Q line in Figure 4 and the associated line
587 driver (transmitter) and receiver of a particular port. The Master operates this line in three
588 main modes (see Figure 12): inactive, "Switching signal" (DI/DO), or "Coded switching"
589 (COMx). The service PL-SetMode.req is responsible for switching into one of these modes.
590 If the port is in inactive mode, the C/Q line shall be high impedance (floating). In SIO mode,
591 the port can be used as a standard input or output interface according to the definitions of
592 IEC 61131-2 or in Table 6 respectively. The communication layers of SDCI are bypassed as
593 shown in Figure 12; the signals are directly processed within the Master application. In SDCI
594 mode, the service PL_WakeUp.req creates a special signal pattern (current pulse) that can be
595 detected by an SDCI enabled Device connected to this port (see 5.3.3.3).
596 Figure 13 shows an overview of the Device's physical layer and its service primitives.
597 The physical layer of a Device according to Figure 13 follows the same principle, except that
598 there is no inactive state. By default, at power on or cable reconnection, the Device shall
599 operate in the SIO mode, as a digital input (from a Master's point of view). The Device shall
600 always be able to detect a wake-up current pulse (wake-up request). The service
601 PL_WakeUp.ind reports successful detection of the wake-up request (usually a
602 microcontroller interrupt), which is required for the Device to switch to the SDCI mode.
603 A special MasterCommand (fallback) sent via SDCI causes the Device to switch back to SIO
604 mode.
Device
Line handler DL-mode handler Message handler SIO NC/
DI / DO DI / DO
Mode switch
Wake-up Coded switching Switching signal Option
Physical Layer
Medium
605
607 Subsequently, the services are specified that are provided by the PL to System Management
608 and to the Data Link Layer (see Figure 85 and Figure 96 for a complete overview of all the
609 services). Table 1 lists the assignments of Master and Device to their roles as initiator or
610 receiver for the individual PL services.
Version 1.1.3 – 40 – IO-Link Interface and System © IO-Link
612
Argument M
TargetMode M
618
619 Argument
620 The service-specific parameters of the service request are transmitted in the argument.
621 TargetMode
622 This parameter indicates the requested operation mode
623 Permitted values:
624 INACTIVE (C/Q line in high impedance),
625 DI (C/Q line in digital input mode),
626 DO (C/Q line in digital output mode),
627 COM1 (C/Q line in COM1 mode),
628 COM2 (C/Q line in COM2 mode),
629 COM3 (C/Q line in COM3 mode)
630
<none>
637
Argument
Data M M
Result (+) S
Result (-) S
Status M
642
643 Argument
644 The service-specific parameters of the service request are transmitted in the argument.
645 Data
646 This parameter contains the data value which is transferred over the SDCI interface.
647 Permitted values: 0…255
648 Result (+):
649 This selection parameter indicates that the service request has been executed successfully.
652 Status
653 This parameter contains supplementary information on the transfer status.
654 Permitted values:
655 PARITY_ERROR (UART detected a parity error),
656 FRAMING_ERROR (invalid UART stop bit detected),
657 OVERRUN (octet collision within the UART)
658
672 In operating status ON the descriptive variables are the residual voltage VRQ, the standard
673 driver current IQ, and the peak current IQPK. The source is controlled by the On/Off signal.
674 An overload current event is indicated at the “Overload” output (OVD). This feature can be
675 used for the current pulse detection (wake-up).
VRQ
On/ IQ
Off IQPK
676 Overload
678 The receiver is specified by a reference schematic according to Figure 15. It performs the
679 function of a comparator and is specified by its switching thresholds VTH and a hysteresis
680 VHYS between the switching thresholds. The output indicates the logic level (High or Low) at
681 the receiver input.
VI
H/L
VTH
VHYS
682 V0
684 Figure 16 shows the reference schematics for the interconnection of Master and Device for
685 the SDCI 3-wire connection system.
ISD ISM
On/
VRQHD On/
Off IQHD Off
IQPKHD
OVD VRQHM
IQHM
VDQL IQPKHM
H/L C/Q C/Q H/L
VSD VSM
OVD
689 The subsequent illustrations and parameter tables refer to the voltage level definitions in
690 Figure 17. The parameter indices refer to the Master (M), Device (D) or line (L). The voltage
691 drops on the line VD+ L , VDQ L and VD0 L are implicitely specified in 5.5 through cable
692 parameters.
IO-Link Interface and System © IO-Link – 43 – Version 1.1.3
VRQHD
VSD VDQL
VSM
VID
VIM
VRQLD
V0D
VD0L VRQLM
Output Input
V0M
Input Output
693
NOTE 1 Thresholds are compatible with the definitions of type 1 digital inputs in IEC 61131-2.
NOTE 2 Hysteresis voltage VHYS = VTHH – VTHL
NOTE 3 Due to 5.4.1 the Master receiver signals VI M are always within permitted supply ranges.
699
700 Figure 18 demonstrates the switching thresholds for the detection of Low and High signals.
Version 1.1.3 – 44 – IO-Link Interface and System © IO-Link
VID,M
V+
Voltage range
'H'
VTHHMAX
VTHLMAX
Threshold 'H' VTHHMIN
Threshold 'L' VTHLMIN
Voltage range
'L'
V0
701
NOTE 1 Currents are compatible with the definition of type 1 digital inputs in IEC 61131-2. However, for the
range 5 V < VI M < 15 V, the minimum current is 5 mA instead of 2 mA in order to achieve short enough slew
rates for pure p-switching Devices.
NOTE 2 Wake-up request current (5.3.3.3).
IO-Link Interface and System © IO-Link – 45 – Version 1.1.3
706 The Master shall provide a charge of 400 mA × 50 ms = 20 mAs within the first 50 ms after
707 power-on without any overload-shutdown. After 50 ms, the specific current limitation of the
708 Master or system applies.
ISM
ISIRM min
ISM min
Minimum current the Master shall provide
Unspecified
behavior
50 ms t
709
QIS D Power-up charge n/a n/a 70 mAs See equation (1) and
consumption Table 8
714
715 The Device shall be able to reach a stable operational state (ready for Wake-up) consuming
716 the maximum charge according to equation (1).
Version 1.1.3 – 46 – IO-Link Interface and System © IO-Link
717 Figure 20 shows how the power-on behavior of a Device is defined by the ramp-up time of the
718 Power 1 supply and by the Device internal time to get ready for the wake-up operation.
VS
VSD min
t
TRDL
719
721 Upon power-on it is mandatory for a Device to reach the wake-up ready state within the time
722 limits specified in Table 8.
724
725 The value of 1 nF for input capacitance CQ D is applicable for a transmission rate of 230,4
726 kbit/s. It can be relaxed to a maximum of 10 nF in case of push-pull stage design when
727 operating at lower transmission rates, provided that all dynamic parameter requirements in
728 5.3.3.2 are met.
734 The open-circuit level on the C/Q line is 0 V with reference to L-. A start bit has logic value
735 “0”, i.e. +24 V with reference to L-.
736 A UART frame is used for the "data octet"-by-"data octet" coding. The format of the SDCI
737 UART frame is a bit string structured as shown in Figure 21.
Transmitted
bit sequence 1st 2 3 4 5 6 7 8 9 10 11th
7
Significance of 20 2
information bits lsb msb
0 b0 b1 b2 b3 b4 b5 b6 b7 P 1
740 The definition of the UART frame format is based on ISO 1177 and ISO/IEC 2022.
745 Regardless of boundary conditions, the transmitter shall generate a voltage characteristic on
746 the receiver's C/Q connection that is within the permissible range of the eye diagram.
747 The receiver shall detect bits as a valid signal shape within the permissible range of the eye
748 diagram on the C/Q connection. Signal shapes in the “no detection” areas (below VTHL MAX or
749 above VTHH MIN and within t ND ) shall not lead to invalid bits.
tH tND tL tND
VIHD,M MAX
V+D,M
VRQHD,M MAX
VTHLMAX VTHLMIN
1) Detection 'L'
VRQLD,M MAX
V0D,M
VILD,M MIN
tDR tDF
TBIT TBIT
750
753 In order for a UART frame to be detected correctly, a signal characteristic as demonstrated in
754 Figure 23 is required on the receiver side. The signal delay time between the C/Q signal and
755 the UART input shall be considered. Time T BIT always indicates the receiver's bit rate.
Start Stop
Bit n=1 Bit n=2 Bit n=3 Bit n=9 Bit n=10 Bit n=11
TBIT TBIT
VTHH
VTHL
757 Figure 23 – Eye diagram for the correct detection of a UART frame
758 For every bit n in the bit sequence (n =1…11) of a UART frame, the time (n-r)T BIT (see Table
759 9 for values of r) designates the time at the end of which a correct level shall be reached in
760 the 'H' or 'L' ranges as demonstrated in the eye diagram in Figure 22. The time (n-s) T BIT (see
Version 1.1.3 – 48 – IO-Link Interface and System © IO-Link
761 Table 9 for values of s) describes the time, which shall elapse before the level changes.
762 Reference shall always be made to the eye diagram in Figure 22, where signal characteristics
763 within a bit time are concerned.
764 This representation permits a variable weighting of the influence parameters "transmission
765 rate accuracy", "bit-width distortion", and "slew rate" of the receiver.
768
769 The parameters ‘r’ and ‘s’ apply to the respective Master or Device receiver side. This
770 definition allows for a more flexible definition of oscillator accuracy, bit distortion and slewrate
771 on the Device side. The overall bit-width distortion on the last bit of the UART frame shall
772 provide a correct level in the range of Figure 23.
IO-Link Interface and System © IO-Link – 49 – Version 1.1.3
775 A service call (PL_WakeUp.req) from the DL initiates the wake-up process (see 5.2.2.2).
776 The wake-up request (WURQ) starts with a current pulse induced by the Master (port) for a
777 time TWU . The wake-up request comprises the following phases (see Figure 24):
778 a) Injection of a current IQ WU by the Master depending on the level of the C/Q connection.
779 For an input signal equivalent to logic “1” this is a current source; for an input signal
780 equivalent to logic “0” this is a current sink.
781 b) Delay time of the Device until it is ready to receive.
782 The wake-up request pulse can be detected by the Device through a voltage change on the
783 C/Q line or evaluation of the current of the respective driver element within the time TWU .
784 Figure 24 shows examples for Devices with low output power.
V
SIO Mode Wake-up request Ready to communicate
Device output a) b)
t
TWU
TREN
785
787 Table 10 specifies the current and timing properties associated with the wake-up request. See
788 Table 6 for values of IQPKL M and IQPKH M.
790
796 Manufacturers/vendors shall emphasize this requirement within the user manual of the
797 Master. Any additional measure for further increased robustness is within the responsibility of
798 the designer/manufacturer of the Master.
799 The minimum supply current available from a Master port is specified in Table 6.
800 The application section of the Device may be powered in one of three ways:
801 • via the power lines of the SDCI 3-wire connection system (class A ports), using Power 1
802 • via the extra power lines of the SDCI 5-wire connection system (class B ports), using an
803 extra power supply at the Master (Power 2) that shall be nonreactive, that means no
804 impact on voltages and currents of Power 1 and on SDCI communications
805 • via a local power supply at the Device (design specific) that shall be nonreactive to
806 Power 1, thus guaranteeing correct communication even in case of failing local power
807 supply
808 It is recommended for Devices not to consume more than the minimum current a Master shall
809 support (see Table 6). This ensures easiest handling of Master/Device systems without
810 inquiries, checking, and calculations. Whenever a Device requires more than the minimum
811 current the capabilities of the respective Master port and of its cabling shall be checked.
823 A Device designer shall ensure that Power 1 and Power 2 are always electrically isolated
824 even in particular deployments/applications at the customer's site. Violation of this rule at one
825 port can have impact on all other ports.
5 5
N24 (Act)
826
828 Table 11 shows the electrical characteristics of a Master port class B (M12).
IO-Link Interface and System © IO-Link – 51 – Version 1.1.3
a) A minimum voltage shall be guaranteed for testing at maximum recommended supply current. At the Device
side 18 V shall be available in this case.
b) Minimum current in order to guarantee a high degree of interoperability.
c) The recommended maximum current for a wire gauge of 0,34 mm 2 and standard M12 connector is 3,5 A.
Maximum current depends on the type of connector, the wire gauge, maximum temperature, and simultaneity
factor of the ports (check user manual of a Master).
830
831 In general, the requirements of Devices shall be checked whether they meet the available
832 capabilities of the Master. In case a simultaneity factor for Master ports exists, it shall be
833 documented in the user manual and be observed by the user of the Master.
840 Ports class A use M5, M8, and M12 connectors, with a maximum of four pins.
845 Female connectors are assigned to the Master. Table 12 lists the pin assignments and Figure
846 26 shows the layout and mechanical coding for M12, M8, and M5 connections.
848
Version 1.1.3 – 52 – IO-Link Interface and System © IO-Link
Male 1 1
(Device) 3 3
1 2 1 3 5
4 4 M12 connectors
M5 M8 M12-4 M12-5 are A-coded
according to IEC
2 2 61076-2-101
3 4 4 2
Female 1 1
3 3
(Master)
2 1 3 1 5 5
4 4
M5 M8 M12-5 M12-5
849
851 Figure 26 shows the layout of the two port classes A and B. Class B ports shall be marked to
852 distinguish them from Class A ports, because of risks deriving from incompatibilities.
853 Male connectors are assigned to the Device. Table 13 lists the pin assignments.
854 Table 13 – Device pin assignments
P24 b) P24 (port class B) Extra power supply for power Devices (port class B)
a) Device signals shall not impact I/Q input of a Master. Devices shall withstand permanent DC (see Table 6)
on the Master side.
b) Devices relying on Port class A shall use 3-wire connection in this case in order to avoid bypassing galvanic
isolation
c) A Master shall always be able to establish and maintain SDCI communication without interferences
855
Overall loop resistance RL eff a) n/a n/a 6,0 (for a current of 200 mA) Ω
1,2 (for a current of 1000 mA)
IO-Link Interface and System © IO-Link – 53 – Version 1.1.3
a) The overall loop resistence shall be rated such that minimum Device supply voltages are guaranteed at
maximum supply current (see Table 7).
862
863 The loop resistance RL eff and the effective line capacitance CL eff may be measured as
864 demonstrated in Figure 27.
L+
RLeff
C/Q
CLeff L-
865 L
866 Figure 27 – Reference schematic for effective line capacitance and loop resistance
867 Table 15 shows the cable conductors and their assigned color codes.
869
884 A set of DL-services is available to the application layer (AL) for the exchange of Process
885 Data (PD) and On-request Data (OD). Another set of DL-services is available to System
886 Management (SM) for the retrieval of Device identification parameters and the setting of state
887 machines within the DL. The DL uses PL-Services for controlling the physical layer (PL) and
888 for exchanging UART frames. The DL takes care of the error detection of messages (whether
889 internal or reported from the PL) and the appropriate remedial measures (e.g. retry).
Version 1.1.3 – 54 – IO-Link Interface and System © IO-Link
890 The data link layers are structured due to the nature of the data categories into Process Data
891 handlers and On-request Data handlers which are in turn using a message handler to deal
892 with the requested transmission of messages. The special modes of Master ports such as
893 wake-up, COMx, and SIO (disable communication) require a dedicated DL-mode handler
894 within the Master DL. The special wake-up signal modulation requires signal detection on the
895 Device side and thus a DL-mode handler within the Device DL. Each handler comprises its
896 own state machine.
897 The data link layer is subdivided in a DL-A section with its own internal services and a DL-B
898 section with the external services. The DL uses additional internal administrative calls
899 between the handlers which are defined in the "internal items" section of the associated state-
900 transition tables. Figure 28 shows an overview of the structure and the services of the
901 Master's data link layer.
Application Layer
DL_PDInput-
DL_PDCycle
DL_PDOut-
DL_Control
putUpdate
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Write-
DL_Event
System
DL_Event
Transport
Transport
Param
Param
Manage- Abort
Conf
ment
PD.req
PDTrig
PD.cnf
DL_Mode
Master
Port x
handler DL-mode MHInfo
handler Message
handler
SIO
DI / DO
Mode switch
904 Figure 28 – Structure and services of the data link layer (Master)
905 Figure 29 shows an overview of the structure and the services of the Device's data link layer.
Application Layer
System
DL_PDOutput-
DL_PDInput-
DL_PDCycle
Manage-
DL_Control
DL_Event-
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Write-
DL_Event
Transport
Transport
ment
Update
Trigger
Param
Param
Abort
DL-B
PDInStatus
DL_Read
EventFlag
DL-A
OD.rsp
OD.ind
PD.rsp
PD.ind
DL_Write
Device
Line
DL_Mode DL-mode
handler MHInfo
handler Message
handler
SIO
DI/DO
Mode switch
907 Figure 29 – Structure and services of the data link layer (Device)
IO-Link Interface and System © IO-Link – 55 – Version 1.1.3
DL_ReadParam R I
DL_WriteParam R I
DL_ISDUTransport R I
DL_ISDUAbort R I
DL_PDOutputUpdate R
DL_PDOutputTransport I
DL_PDInputUpdate R
DL_PDInputTransport I
DL_PDCycle I I
DL_SetMode R
DL_Mode I I
DL_Event I R
DL_EventConf R
DL_EventTrigger R
DL_Control I/R R/I
DL_Read R I
DL_Write R I
Key (see 3.3.4)
I Initiator of service
R Receiver (responder) of service
916
917 See 3.3 for conventions and how to read the service descriptions in 7.2, 8.2, 9.2.2, and 9.3.2.
Argument M M
Address M M
Result (+) S S
Value M M
Result (-) S
ErrorInfo M
923
924 Argument
925 The service-specific parameters are transmitted in the argument.
Version 1.1.3 – 56 – IO-Link Interface and System © IO-Link
926 Address
927 This parameter contains the address of the requested Device parameter, i.e. the Device
928 parameter addresses within the page communication channel (see Table B.1).
929 Permitted values: 0 to 31
930 Result (+):
931 This selection parameter indicates that the service has been executed successfully.
932 Value
933 This parameter contains read Device parameter values.
934 Result (-):
935 This selection parameter indicates that the service failed.
936 ErrorInfo
937 This parameter contains error information.
938 Permitted values:
939 NO_COMM (no communication available),
940 STATE_CONFLICT (service unavailable within current state)
941 7.2.1.3 DL_WriteParam
942 The DL_WriteParam service is used by the AL to write a parameter value to the Device via
943 the page communication channel. The parameters of the service primitives are listed in Table
944 18.
Argument M M
Address M M
Value M M
Result (+) S
Result (-) S
ErrorInfo M
946
947 Argument
948 The service-specific parameters are transmitted in the argument.
949 Address
950 This parameter contains the address of the requested Device parameter, i.e. the Device
951 parameter addresses within the page communication channel.
952 Permitted values: 16 to 31, in accordance with Device parameter access rights
953 Value
954 This parameter contains the Device parameter value to be written.
955 Result (+):
956 This selection parameter indicates that the service has been executed successfully.
959 ErrorInfo
960 This parameter contains error information.
961 Permitted values:
962 NO_COMM (no communication available),
963 STATE_CONFLICT (service unavailable within current state)
IO-Link Interface and System © IO-Link – 57 – Version 1.1.3
Argument M M
Address M M
Result (+) S S
Value M M
Result (-) S
ErrorInfo M
969
970 Argument
971 The service-specific parameters are transmitted in the argument.
972 Address
973 This parameter contains the address of the requested Device parameter, i.e. the Device
974 parameter addresses within the page communication channel (see Table B.1).
975 Permitted values: 0 to 15, in accordance with Device parameter access rights
976 Result (+):
977 This selection parameter indicates that the service has been executed successfully.
978 Value
979 This parameter contains read Device parameter values.
980 Result (-):
981 This selection parameter indicates that the service failed.
982 ErrorInfo
983 This parameter contains error information.
984 Permitted values:
985 NO_COMM (no communication available),
986 STATE_CONFLICT (service unavailable within current state)
987 7.2.1.5 DL_Write
988 The DL_Write service is used by System Management to write a Device parameter value to
989 the Device via the page communication channel. The parameters of the service primitives are
990 listed in Table 20.
Argument M M
Address M M
Value M M
Result (+) S
Result (-) S
ErrorInfo M
992
993 Argument
994 The service-specific parameters are transmitted in the argument.
995 Address
996 This parameter contains the address of the requested Device parameter, i.e. the Device
997 parameter addresses within the page communication channel.
Version 1.1.3 – 58 – IO-Link Interface and System © IO-Link
1005 ErrorInfo
1006 This parameter contains error information.
1007 Permitted values:
1008 NO_COMM (no communication available),
1009 STATE_CONFLICT (service unavailable within current state)
1010 7.2.1.6 DL_ISDUTransport
1011 The DL_ISDUTransport service is used to transport an ISDU. This service is used by the
1012 Master to send a service request from the Master application layer to the Device. It is used by
1013 the Device to send a service response to the Master from the Device application layer. The
1014 parameters of the service primitives are listed in Table 21.
Argument M M
ValueList M M
Result (+) S S
Data C C
Qualifier M M
Result (-) S S
ISDUTransportErrorInfo M M
1016
1017 Argument
1018 The service-specific parameters are transmitted in the argument.
1019 ValueList
1020 This parameter contains the relevant operating parameters
1021 Parameter type: Record
1022 Index
1023 Permitted values: 2 to 65535 (See B.2.1 for constraints)
1024 Subindex
1025 Permitted values: 0 to 255
1026 Data
1027 Parameter type: Octet string
1028 Direction
1029 Permitted values:
1030 READ (Read operation),
1031 WRITE (Write operation)
1032 Result (+):
1033 This selection parameter indicates that the service has been executed successfully.
1034 Data
1035 Parameter type: Octet string
1036 Qualifier
1037 Permitted values: an I-Service Device response according to Table A.12
IO-Link Interface and System © IO-Link – 59 – Version 1.1.3
1040 ISDUTransportErrorInfo
1041 This parameter contains error information.
1042 Permitted values:
1043 NO_COMM (no communication available),
1044 STATE_CONFLICT (service unavailable within current state),
1045 ISDU_TIMEOUT (ISDU acknowledgment time elapsed, see Table 102),
1046 ISDU_NOT_SUPPORTED (ISDU not implemented),
1047 VALUE_OUT_OF_RANGE (Service parameter value violates range definitions)
1048 7.2.1.7 DL_ISDUAbort
1049 The DL_ISDUAbort service aborts the current ISDU transmission. This service has no
1050 parameters. The service primitives are listed in Table 22.
<none>
1052
1053 The service returns with the confirmation after abortion of the ISDU transmission.
Argument M
OutputData M
Result (+) S
TransportStatus M
Result (-) S
ErrorInfo M
1059
1060 Argument
1061 The service-specific parameters are transmitted in the argument.
1062 OutputData
1063 This parameter contains the Process Data provided by the application layer.
1064 Parameter type: Octet string
1065 Result (+):
1066 This selection parameter indicates that the service has been executed successfully.
1067 TransportStatus
1068 This parameter indicates whether the data link layer is in a state permitting data to be
1069 transferred to the communication partner(s).
1070 Permitted values:
1071 YES (data transmission permitted),
1072 NO (data transmission not permitted),
1073 Result (-):
1074 This selection parameter indicates that the service failed.
1075 ErrorInfo
Version 1.1.3 – 60 – IO-Link Interface and System © IO-Link
Argument M
OutputData M
1085
1086 Argument
1087 The service-specific parameters are transmitted in the argument.
1088 OutputData
1089 This parameter contains the Process Data to be transmitted to the application layer.
1090 Parameter type: Octet string
1091 7.2.1.10 DL_PDInputUpdate
1092 The Device's application layer uses the DL_PDInputUpdate service to update the input data
1093 (Process Data from Device to Master) on the data link layer. The parameters of the service
1094 primitives are listed in Table 25.
Argument M
InputData M
Result (+) S
TransportStatus M
Result (-) S
ErrorInfo M
1096
1097 Argument
1098 The service-specific parameters are transmitted in the argument.
1099 InputData
1100 This parameter contains the Process Data provided by the application layer.
1101 Result (+):
1102 This selection parameter indicates that the service has been executed successfully.
1103 TransportStatus
1104 This parameter indicates whether the data link layer is in a state permitting data to be
1105 transferred to the communication partner(s).
1106 Permitted values:
1107 YES (data transmission permitted),
1108 NO (data transmission not permitted),
1109 Result (-):
1110 This selection parameter indicates that the service failed.
1111 ErrorInfo
1112 This parameter contains error information.
IO-Link Interface and System © IO-Link – 61 – Version 1.1.3
Argument M
InputData M
1121
1122 Argument
1123 The service-specific parameters are transmitted in the argument.
1124 InputData
1125 This parameter contains the Process Data to be transmitted to the application layer.
1126 Parameter type: Octet string
1127 7.2.1.12 DL_PDCycle
1128 The data link layer uses the DL_PDCycle service to indicate the end of a Process Data cycle
1129 to the application layer. This service has no parameters. The service primitives are listed in
1130 Table 27.
<none>
1132
Argument M
Mode M
ValueList U
Result (+) S
Result (-) S
ErrorInfo M
1138
1139 Argument
1140 The service-specific parameters are transmitted in the argument.
1141 Mode
1142 This parameter indicates the requested mode of the Master's DL on an individual port.
1143 Permitted values:
1144 INACTIVE (handler shall change to the INACTIVE state),
1145 STARTUP (handler shall change to STARTUP state),
1146 PREOPERATE (handler shall change to PREOPERATE state),
1147 OPERATE (handler shall change to OPERATE state)
Version 1.1.3 – 62 – IO-Link Interface and System © IO-Link
1148 ValueList
1149 This parameter contains the relevant operating parameters.
1150 Data structure: record
1151 M-sequenceTime: (to be propagated to message handler)
1152
1153 M-sequenceType: (to be propagated to message handler)
1154 Permitted values:
1155 TYPE_0,
1156 TYPE_1_1, TYPE_1_2, TYPE_1_V,
1157 TYPE_2_1, TYPE_2_2, TYPE_2_3, TYPE_2_4, TYPE_2_5, TYPE_2_V
1158 (TYPE_1_1 forces interleave mode of Process and On-request Data transmission,
1159 see 7.3.4.2)
1160 PDInputLength: (to be propagated to message handler)
1161
1162 PDOutputLength: (to be propagated to message handler)
1163
1164 OnReqDataLengthPerMessage: (to be propagated to message handler)
1165
1166 Result (+):
1167 This selection parameter indicates that the service has been executed successfully.
1170 ErrorInfo
1171 This parameter contains error information.
1172 Permitted values:
1173 STATE_CONFLICT (service unavailable within current state),
1174 PARAMETER_CONFLICT (consistency of parameter set violated)
1175 7.2.1.14 DL_Mode
1176 The DL uses the DL_Mode service to report to System Management that a certain operating
1177 status has been reached. The parameters of the service primitives are listed in Table 29.
Argument M
RealMode M
1179
1180 Argument
1181 The service-specific parameters are transmitted in the argument.
1182 RealMode
1183 This parameter indicates the status of the DL-mode handler.
1184 Permitted values:
1185 INACTIVE (Handler changed to the INACTIVE state)
1186 COM1 (COM1 mode established)
1187 COM2 (COM2 mode established)
1188 COM3 (COM3 mode established)
1189 COMLOST (Lost communication)
1190 ESTABCOM (Handler changed to the EstablishCom state)
1191 STARTUP (Handler changed to the STARTUP state)
1192 PREOPERATE (Handler changed to the PREOPERATE state)
1193 OPERATE (Handler changed to the OPERATE state)
IO-Link Interface and System © IO-Link – 63 – Version 1.1.3
Argument M M
Instance M M
Type M M
Mode M M
EventCode M M
EventsLeft M
1199
1200 Argument
1201 The service-specific parameters are transmitted in the argument.
1202 Instance
1203 This parameter indicates the Event source.
1204 Permitted values: Application (see Table A.17)
1205 Type
1206 This parameter indicates the Event category.
1207 Permitted values: ERROR, WARNING, NOTIFICATION (see Table A.19)
1208 Mode
1209 This parameter indicates the Event mode.
1210 Permitted values: SINGLESHOT, APPEARS, DISAPPEARS (see Table A.20)
1211 EventCode
1212 This parameter contains a code identifying a certain Event (see Table D.1).
1213 Parameter type: 16-bit unsigned integer
1214 EventsLeft
1215 This parameter indicates the number of unprocessed Events.
1216 7.2.1.16 DL_EventConf
1217 The DL_EventConf service confirms the transmitted Events via the Event handler. This
1218 service has no parameters. The service primitives are listed in Table 31.
<none>
1220
<none>
1228
Version 1.1.3 – 64 – IO-Link Interface and System © IO-Link
Argument M M
ControlCode M M(=)
1235
1236 Argument
1237 The service-specific parameters are transmitted in the argument.
1238 ControlCode
1239 This parameter indicates the qualifier status of the Process Data (PD)
1240 Permitted values:
1241 VALID (Input Process Data valid; see 7.2.2.5, 8.2.2.12)
1242 INVALID (Input Process Data invalid)
1243 PDOUTVALID (Output Process Data valid; see 7.3.7.1)
1244 PDOUTINVALID (Output Process Data invalid or missing)
1245 7.2.2 DL-A services
1246 7.2.2.1 Overview
1247 According to 7.1 the data link layer is split into the upper layer DL-B and the lower layer DL-A.
1248 The layer DL-A comprises the message handler as shown in Figure 28 and Figure 29.
1249 The Master message handler encodes commands and data into messages and sends these to
1250 the connected Device via the physical layer. It receives messages from the Device via the
1251 physical layer and forwards their content to the corresponding handlers in the form of a
1252 confirmation. When the "Event flag" is set in a Device message (see A.1.5), the Master
1253 message handler invokes an EventFlag service to prompt the Event handler.
1254 The Master message handler shall employ a retry strategy following a corrupted message, i.e.
1255 upon receiving an incorrect checksum from a Device, or no checksum at all. In these cases,
1256 the Master shall repeat the Master message two times (see Table 102). If the retries are not
1257 successful, a negative confirmation shall be provided, and the Master shall re-initiate the
1258 communication via the Port-x handler beginning with a wake-up.
1259 After a start-up phase the message handler performs cyclic operation with the M-sequence
1260 type and cycle time provided by the DL_SetMode service.
1261 Table 34 lists the assignment of Master and Device to their roles as initiator (I) or receiver (R)
1262 in the context of the execution of their individual DL-A services.
OD R I
PD R I
EventFlag I R
PDInStatus I R
MHInfo I I
ODTrig I
PDTrig I
1264
IO-Link Interface and System © IO-Link – 65 – Version 1.1.3
1265 7.2.2.2 OD
1266 The OD service is used to set up the On-request Data for the next message to be sent. In
1267 turn, the confirmation of the service contains the data from the receiver. The parameters of
1268 the service primitives are listed in Table 35.
1269 Table 35 – OD
Argument M M
RWDirection M M
ComChannel M M
AddressCtrl M M
Length M M
Data C C
Result (+) S S
Data C C(=)
Length M M
Result (-) S S
ErrorInfo M M(=)
1270
1271 Argument
1272 The service-specific parameters are transmitted in the argument.
1273 RWDirection
1274 This parameter indicates the read or writes direction.
1275 Permitted values:
1276 READ (Read operation),
1277 WRITE (Write operation)
1278 ComChannel
1279 This parameter indicates the selected communication channel for the transmission.
1280 Permitted values: DIAGNOSIS, PAGE, ISDU (see Table A.1)
1281 AddressCtrl
1282 This parameter contains the address or flow control value (see A.1.2).
1283 Permitted values: 0 to 31
1284 Length
1285 This parameter contains the length of data to transmit.
1286 Permitted values: 0 to 32
1287 Data
1288 This parameter contains the data to transmit.
1289 Data type: Octet string
1290 Result (+):
1291 This selection parameter indicates that the service has been executed successfully.
1292 Data
1293 This parameter contains the read data values.
1294 Length
1295 This parameter contains the length of the received data package.
1296 Permitted values: 0 to 32
1297 Result (-):
1298 This selection parameter indicates that the service failed.
1299 ErrorInfo
1300 This parameter contains error information.
Version 1.1.3 – 66 – IO-Link Interface and System © IO-Link
1308 Table 36 – PD
Argument M M
PDInAddress C C(=)
PDInLength C C(=)
PDOut C C(=)
PDOutAddress C C(=)
PDOutLength C C(=)
Result (+) S S
PDIn C C(=)
Result (-) S S
ErrorInfo M M(=)
1309
1310 Argument
1311 The service-specific parameters are transmitted in the argument.
1312 PDInAddress
1313 This parameter contains the address of the requested input Process Data (see 7.3.4.2).
1314 PDInLength
1315 This parameter contains the length of the requested input Process Data.
1316 Permitted values: 0 to 32
1317 PDOut
1318 This parameter contains the Process Data to be transferred from Master to Device.
1319 Data type: Octet string
1320 PDOutAddress
1321 This parameter contains the address of the transmitted output Process Data (see 7.3.4.2).
1322 PDOutLength
1323 This parameter contains the length of the transmitted output Process Data.
1324 Permitted values: 0 to 32
1325 Result (+)
1326 This selection parameter indicates that the service has been executed successfully.
1327 PDIn
1328 This parameter contains the Process Data to be transferred from Device to Master.
1329 Data type: Octet string
1330 Result (-)
1331 This selection parameter indicates that the service failed.
1332 ErrorInfo
1333 This parameter contains error information.
1334 Permitted values:
1335 NO_COMM (no communication available),
1336 STATE_CONFLICT (service unavailable within current state)
IO-Link Interface and System © IO-Link – 67 – Version 1.1.3
Argument
Flag M M
1341
1342 Argument
1343 The service-specific parameters are transmitted in the argument.
1344 Flag
1345 This parameter contains the value of the "Event flag".
1346 Permitted values:
1347 TRUE ("Event flag" = 1)
1348 FALSE ("Event flag" = 0)
1349 7.2.2.5 PDInStatus
1350 The service PDInStatus sets and signals the validity qualifier of the input Process Data. The
1351 parameters of the service primitives are listed in Table 38.
Argument
Status M M
1353
1354 Argument
1355 The service-specific parameters are transmitted in the argument.
1356 Status
1357 This parameter contains the validity indication of the transmitted input Process Data.
1358 Permitted values:
1359 VALID (Input Process Data valid based on PD status flag (see A.1.5); see 7.2.1.18)
1360 INVALID (Input Process Data invalid)
1361 7.2.2.6 MHInfo
1362 The service MHInfo signals an exceptional operation within the message handler. The
1363 parameters of the service are listed in Table 39.
Argument
MHInfo M
1365
1366 Argument
1367 The service-specific parameters are transmitted in the argument.
1368 MHInfo
1369 This parameter contains the exception indication of the message handler.
1370 Permitted values:
1371 COMLOST (lost communication),
1372 ILLEGAL_MESSAGETYPE (unexpected M-sequence type detected)
1373 CHECKSUM_MISMATCH (Checksum error detected)
Version 1.1.3 – 68 – IO-Link Interface and System © IO-Link
Argument
DataLength M
1380
1381 Argument
1382 The service-specific parameters are transmitted in the argument.
1383 DataLength
1384 This parameter contains the available space for On-request Data (OD) per message.
1385 7.2.2.8 PDTrig
1386 The service PDTrig is only available on the Master. The service triggers the Process Data
1387 handler to provide the Process Data (PD) for the next Master message.
Argument
DataLength M
1390
1391 Argument
1392 The service-specific parameters are transmitted in the argument.
1393 DataLength
1394 This parameter contains the available space for Process Data (PD) per message.
1395 7.3 Data link layer protocol
1396 7.3.1 Overview
1397 Figure 28 and Figure 29 are showing the structure of the data link layer and its components; a
1398 DL-mode handler, a message handler, a Process Data handler, and an On-request Data
1399 handler to provide the specified services. Subclauses 7.3.2 to 7.3.8 define the behaviour
1400 (dynamics) of these handlers by means of UML state machines and transition tables.
1401 The On-request Data handler supports three independent types of data: ISDU, command and
1402 Event. Therefore, three additional state machines are working together with the On-request
1403 Data handler state machine as shown in Figure 30.
State
State machine:
machine: State
State machine:
machine: State
State machine:
machine:
ISDU
ISDU handler
handler Command
Command handler
handler Event
Event handler
handler
State
State machine:
machine:
Process
Process Data
Data handler
handler
State
State machine:
machine:
On-request
On-request Data
Data handler
handler
State
State machine:
machine: State
State machine:
machine:
DL-mode
DL-mode handler
handler Message
Message handler
handler
1404
1406 Supplementary sequence or activity diagrams are demonstrating certain use cases. See
1407 IEC/TR 62390 and ISO/IEC 19505.
1408 The elements each handler is dealing with, such as messages, wake-up procedures,
1409 interleave mode, ISDU (Indexed Service Data Units), and Events are defined within the
1410 context of the respective handler.
1416 The Device DL-mode handler shown in Figure 29 is responsible to detect a wake-up request
1417 and to establish communication. It receives MasterCommands to synchronize with the Master
1418 DL-mode handler states STARTUP, PREOPERATE, and OPERATE and manages the
1419 activation and de-activation of handlers as appropriate.
1423 The Master DL-mode handler tries to establish communication via a wake-up request
1424 (PL_WakeUp.req) followed by a test message with M-sequence TYPE_0 (read
1425 "MinCycleTime") according to the sequence shown in Figure 31.
TREN
WURQ 1 2 3 Master
start-up
Master
1428 After the wake-up request (WURQ), specified in 5.3.3.3, the DL-mode handler requests the
1429 message handler to send the first test message after a time T REN (see Table 10) and T DMT
1430 (see Table 42). The specified transmission rates of COM1, COM2, and COM3 are used in
1431 descending order until a response is obtained, as shown in the example of Figure 31:
1432 Step : Master message with transmission rate of COM3 (see Table 9).
1433 Step : Master message with transmission rate of COM2 (see Table 9).
1434 Step : Master message with transmission rate of COM1 (see Table 9).
1435 Step : Device response message with transmission rate of COM1.
1436 Before initiating a (new) message, the DL-mode handler shall wait at least for a time of T DMT .
1437 T DMT is specified in Table 42.
1438 The following conformity rule applies for Devices regarding support of transmission rates:
1439 • a Device shall support only one of the transmission rates of COM1, COM2, or COM3.
1440 If an attempt to establish communication fails, the Master DL-mode handler shall not start a
1441 new retry wake-up procedure until after a time T DWU as shown in Figure 32 and specified in
1442 Table 42.
Version 1.1.3 – 70 – IO-Link Interface and System © IO-Link
WURQ WURQ
Master
SIO
No response
Device
TDWU
1443
1445 The Master shall make up to n WU +1 successive wake-up requests as shown in Figure 33. If
1446 this initial wake-up retry sequence fails, the Device shall reset its C/Q line to SIO mode after a
1447 time T DSIO (T DSIO is retrigged in the Device after each detected WURQ). The Master shall not
1448 trigger a new wake-up retry sequence until after a time T SD .
SIO
Master
TDSIO
TDSIO
TDSIO
TSD
1449
1451 The DL of the Master shall request the PL to go to SIO mode after a failed wake-up retry
1452 sequence.
1453 The values for the timings of the wake-up procedures and retries are specified in Table 10
1454 and Table 42. They are defined from a Master's point of view.
1456 The Master’s data link layer shall stop the establishing communication procedure once it finds
1457 a communicating Device and shall report the detected COMx-Mode to System Management
1458 using a DL_Mode indication. If the procedure fails, a corresponding error is reported using the
1459 same service.
1463 • A MasterCommand "Fallback" (see Table B.2) forces the Device to change to the SIO
1464 mode.
1465 • The Device shall accomplish the transition to the SIO mode after 3 MasterCycleTimes
1466 and/or within maximum T FBD after the MasterCommand "Fallback". This allows for
1467 possible retries if the MasterCommand failed indicated through a negative Device
1468 response.
1469 • The Master shall ensure waiting at least maximum T FBD before initiating the next start-up
1470 procedure.
1471 Figure 34 shows the fallback procedure and its retry and timing constraints.
MasterCommand "Fallback"
Possible retries
Master
SIO
Device
TFBD
MasterCycleTime
1472
1474 Table 43 specifies the fallback timing characteristics. See A.2.6 for details.
1483 The purpose of state "Startup_2" is to check a Device's identity via the data of the Direct
1484 Parameter page (see Figure 6). In state "PreOperate_3", the Master assigns parameters to
1485 the Device using ISDUs. Cyclic exchange of Process Data is performed in state "Operate".
1486 Within this state additional On-request Data such as ISDUs, commands, and Events can be
1487 transmitted using appropriate M-sequence types (see Figure 39).
1488 In state PreOperate_3 and Operate_4 different sets of handlers within the Master are
1489 activated.
Version 1.1.3 – 72 – IO-Link Interface and System © IO-Link
/Initialization
DL_SetMode_INACTIVE/
DL_SetMode_INACTIVE/
T13
T8 Idle_0
[Retry = 3]/
DL_SetMode_STARTUP/ T5
T1
EstablishCom_1
Submachine 1
"WakeUp" enex_4
MHInfo_COMLOST/
enex_1 enex_2 enex_3 T14
Startup_2
MHInfo_COMLOST/
DL_SetMode_
T9
STARTUP/
T12
DL_SetMode_PRE DL_SetMode
DL_SetMode
OPERATE/ _OPERATE/
_STARTUP/
T6 T11
T7
PreOperate_3 Operate_4
DL_SetMode_OPERATE/
T10
1490
EstablishCom_1
tm(Tdmt)/
T15
[Response COM3]/
T2
ComRequestCOM3_6
enex_1
tm(Tdmt)[No Response]/
T16
[Response COM2]/
ComRequestCOM2_7 T3
enex_2
tm(Tdmt)[No Response]/
T17
[Response COM1]/
ComRequestCOM1_8 T4
enex_3
tm(Tdmt)[No Response]/
T18
[Retry =3]/
T5
Retry_9
enex_4
1492
1494 Table 44 shows the state transition tables of the Master DL-mode handler.
Idle_0 Waiting on wakeup request from System Management (SM): DL_SetMode (STARTUP)
EstablishComm_1 Perform wakeup procedure (submachine 1)
Startup_2 System Management uses the STARTUP state for Device identification, check, and
communication configuration (see Figure 71)
Preoperate_3 On-request Data exchange (parameter, commands, Events) without Process Data
Operate_4 Process Data and On-request Data exchange (parameter, commands, Events)
SM: WURQ_5 Create wakeup current pulse: Invoke service PL-Wake-Up (see Figure 12 and 5.3.3.3)
and wait T DMT (see Table 42).
SM: ComRequestCOM3_6 Try test message with transmission rate of COM3 via the message handler: Call
MH_Conf_COMx (see Figure 40) and wait T DMT (see Table 42).
SM: ComRequestCOM2_7 Try test message with transmission rate of COM2 via the message handler: Call
MH_Conf_COMx (see Figure 40) and wait T DMT (see Table 42).
SM: ComRequestCOM1_8 Try test message with transmission rate of COM1 via the message handler: Call
MH_Conf_COMx (see Figure 40) and wait T DMT (see Table 42).
SM: Retry_9 Check number of Retries
1496
TRANSITION SOURCE TARGET ACTION
STATE STATE
T1 0 1 Set Retry = 0.
T2 1 2 Transmission rate of COM3 successful. Message handler activated and
configured to COM3 (see Figure 40, Transition T2). Activate command
handler (call CH_Conf_ACTIVE in Figure 53). Return DL_Mode.ind
(STARTUP) and DL_Mode.ind (COM3) to SM.
T3 1 2 Transmission rate of COM2 successful. Message handler activated and
configured to COM2 (see Figure 40, Transition T2). Activate command
handler (call CH_Conf_ACTIVE in Figure 53). Return DL_Mode.ind
(STARTUP) and DL_Mode.ind (COM2) to SM.
T4 1 2 Transmission rate of COM1 successful. Message handler activated and
configured to COM1 (see Figure 40, Transition T2). Activate command
handler (call CH_Conf_ACTIVE in Figure 53). Return DL_Mode.ind
(STARTUP) and DL_Mode.ind (COM1) to SM.
T5 1 0 Return DL_Mode.ind (INACTIVE) to SM.
T6 2 3 SM requested the PREOPERATE state. Activate On-request Data (call
OH_Conf_ACTIVE in Figure 48), ISDU (call IH_Conf_ACTIVE in Figure
51), and Event handler (call EH_Conf_ACTIVE in Figure 55). Change
message handler state to PREOPERATE (call MH_Conf_PREOPERATE in
Figure 40). Return DL_Mode.ind (PREOPERATE) to SM.
T7 3 2 SM requested the STARTUP state. Change message handler state to
STARTUP (call MH_Conf_STARTUP in Figure 40). Deactivate On-request
Data (call OH_Conf_INACTIVE in Figure 48), ISDU (call IH_Conf_IN-
ACTIVE in Figure 51), and Event handler (call EH_Conf_INACTIVE in
Figure 55). Return DL_Mode.ind (STARTUP) to SM.
T8 3 0 SM requested the SIO mode. Deactivate all handlers (call
xx_Conf_INACTIVE). Return DL_Mode.ind (INACTIVE) to SM. See 7.3.2.3.
T9 3 0 Message handler informs about lost communication via the DL-A service
MHInfo (COMLOST). Deactivate all handlers (call xx_Conf_INACTIVE).
Return DL_Mode.ind (COMLOST) to SM.
T10 3 4 SM requested the OPERATE state. Activate the Process Data handler (call
PD_Conf_SINGLE if M-sequence type = TYPE_2_x, or
PD_Conf_INTERLEAVE if M-sequence type = TYPE_1_1 in Figure 46).
Change message handler state to OPERATE (call MH_Conf_OPERATE in
Figure 40). Return DL_Mode.ind (OPERATE) to SM.
T11 2 4 SM requested the OPERATE state. Activate the Process Data handler (call
PD_Conf_SINGLE or PD_Conf_INTERLEAVE in Figure 46 according to the
Master port configuration). Activate On-request Data (call
Version 1.1.3 – 74 – IO-Link Interface and System © IO-Link
MH_Conf_COMx Call This call causes the message handler to send a message with the
requested transmission rate of COMx and with M-sequence TYPE_0 (see
Table 46).
MH_Conf_STARTUP Call This call causes the message handler to switch to the STARTUP state
(see Figure 40)
MH_Conf_PREOPERATE Call This call causes the message handler to switch to the PREOPERATE state
(see Figure 40)
MH_Conf_OPERATE Call This call causes the message handler to switch to the OPERATE state
(see Figure 40)
xx_Conf_ACTIVE Call These calls activate the respective handler. xx is substitute for MH
(message handler), OH (On-request Data handler), IH (ISDU handler), CH
(Command handler), and/or EH (Event handler)
xx_Conf_INACTIVE Call These calls deactivate the respective handler. xx is substitute for MH
(message handler), OH (On-request Data handler), IH (ISDU handler), CH
(Command handler), and/or EH (Eventhandler)
Retry Variable Number of retries to establish communication
1498
1499 7.3.2.5 State machine of the Device DL-mode handler
1500 Figure 37 shows the state machine of the Device DL-mode handler.
1501 In state PreOperate_3 and Operate_4 different sets of handlers within the Device are
1502 activated.
1503 The Master uses MasterCommands (see Table 44) to change the Device to SIO, STARTUP,
1504 PREOPERATE, and OPERATE states.
1505 Whenever the message handler detects illegal (unexpected) M-sequence types, it will cause
1506 the DL-mode handler to change to the STARTUP state and to indicate this state to its system
1507 mangement (see 9.3.3.2) for the purpose of synchronization of Master and Device.
1508
IO-Link Interface and System © IO-Link – 75 – Version 1.1.3
/Initialization
[MCmd_FALLBACK]/ [MCmd_FALLBACK]/
T8 T9
Idle_0
tm(Tdsio)/ PL_WakeUp/
T10 T1
EstablishCom_1
[Successful COMx]/
T2 MHInfo_ILLEGAL_MESSAGETYPE/
T11
Startup_2
MHInfo_ILLEGAL_MESSAGETYPE/ [MCmd_STARTUP]/
T12 T7
PreOperate_3 Operate_4
[MCmd_OPERATE]/
T4
1509
1511 Table 45 shows the state transition tables of the Device DL-mode handler.
MCmd_XXXXXXX Call Any MasterCommand received by the Device command handler (see Table
44 and Figure 54, state "CommandHandler_2")
V1.0-supp Flag Device supports V1.0 mode
1515
1524 All the multi-octet data types shall be transmitted as a big-endian sequence, i.e. the most
1525 significant octet (MSO) shall be sent first, followed by less significant octets in descending
1526 order, with the least significant octet (LSO) being sent last, as shown in Figure 2.
1527 The Master message starts with the "M-sequence Control" (MC) octet, followed by the
1528 "CHECK/TYPE" (CKT) octet, and optionally followed by either "Process Data" (PD) and/or
1529 "On-request Data" (OD) octets. The Device message in turn starts optionally with "Process
1530 Data" (PD) octets and/or "On-request Data" (OD) octets, followed by the "CHECK/STAT"
1531 (CKS) octet.
IO-Link Interface and System © IO-Link – 77 – Version 1.1.3
Master message
UART UART
M-sequence type ...
frame frame
1532
1534 Various M-sequence types can be selected to meet the particular needs of an actuator or
1535 sensor (scan rate, amount of Process Data). The length of Master and Device messages may
1536 vary depending on the type of messages and the data transmission direction, see Figure 38.
1537 Figure 39 presents an overview of the defined M-sequence types. Parts within dotted lines
1538 depend on the read or write direction within the M-sequence control octet.
TYPE_0 MC CKT WR
OD
RD CKS
TYPE_1_1 MC CKT
PD0 PD1
CKS
TYPE_1_2 MC CKT
OD0 OD1
CKS
TYPE_1_V MC CKT
OD0 ODn
CKS
TYPE_2_1 MC CKT
OD
PD CKS
TYPE_2_2 MC CKT
OD
PD0 PD1 CKS
TYPE_2_3 MC CKT PD
OD
CKS
TYPE_2_5 MC CKT PD
OD
PD CKS
1541 The fixed M-sequence types consist of TYPE_0, TYPE_1_1, TYPE_1_2, and TYPE_2_1
1542 through TYPE_2_5. Caution: The former TYPE_2_6 is no more supported. The variable M-
1543 sequence types consist of TYPE_1_V and TYPE_2_V.
1544 The different M-sequence types meet the various requirements of sensors and actuators
1545 regarding their Process Data width and respective conditions. See A.2 for details of M-
1546 sequence types. See A.3 for the timing constraints with M-sequences.
1553 After these phases, cyclic Process Data communication can be started by the Master via the
1554 DL_SetMode (OPERATE) service. M-sequence types for the cyclic data exchange shall be
1555 used in this communication phase to exchange Process Data (PD) and On-request Data with
1556 a Device (see Table A.9 and Table A.10).
1557 The Master shall use for time t CYC the value indicated in the Device parameter
1558 "MasterCycleTime" (see Table B.1) with a relative tolerance of -1 % to +10 % (including jitter).
1559 In cases, where a Device has to be switched back to SIO mode after parameterization, the
1560 Master shall send a command "Fallback" (see Table B.2), which is followed by a confirmation
1561 from the Device.
MH_Conf_INACTIVE/
MH_Conf_Startup/ T35
T38
MH_Conf_OPERATE/
T39 MH_Conf_INACTIVE/ /Initialization
MH_Conf_Startup/ T36
T37
MH_Conf_OPERATE/ MH_Conf_PREOPERATE/
Operate_12 T26 Preoperate_6 T12 Startup_2 Inactive_0
DL_Write/ DL_Read/
[Tcyc]/ DL_ReadParam/ GetOD_7 T6 T5
T27 T13 MH_Conf_COMx/
T1
DL_WriteParam/
T14
AwaitReply_1
GetPD_13 DL_ISDUTransport/ [Response OK]/
T15 T2
EventFlag/
tm(TM-sequence)/
T16
PD/ T4
T28 DL_Write_DEVICEMODE/
[Idle]/ T17 [Response not OK]/
T25 T3
CheckHandler_11 [Not idle]/
GetOD_14
T24 [No error]/ Response_3 [Retry = MaxRetry]/
T10 T11
OD[Tinitcyc]/
T18 enex_2 enex_1
enex_4 enex_3
Response_15 [Retry = MaxRetry]/
T33
enex_6 enex_5
1566
1568 The message handler takes care of the special communication requirements within the states
1569 "EstablishCom", "Startup", "PreOperate", and "Operate" of the DL-Mode handler. An internal
1570 administrative call MH_Conf_COMx in state "Inactive_0" causes the message handler to send
1571 "test" messages with M-sequence TYPE_0 and different transmission rates of COM3, COM2,
1572 or COM1 during the establish communication sequence.
1573 The state "Startup_2" provides all the communication means to support the identity checks of
1574 System Management with the help of DL_Read and DL_Write services. The message handler
1575 waits on the occurrence of these services to send and receive messages (acyclic
1576 communication). The state "Preoperate_6" is the checkpoint for all On-request Data activities
1577 such as ISDUs, commands, and Events for parameterization of the Device. The message
1578 handler waits on the occurrence of the services shown in Figure 40 to send and receive
1579 messages (acyclic communication). The state "Operate_12" is the checkpoint for cyclic
1580 Process Data exchange. Depending on the M-sequence type the message handler generates
1581 Master messages with Process Data acquired from the Process Data handler via the PD
1582 service and optionally On-request Data acquired from the On-request Data handler via the OD
1583 service.
Response_3
tm(TM-sequence)/
enex_1
enex_2 T7
AwaitReply_4 ErrorHandling_5
Response_8
tm(TM-sequence)/
T19
AwaitReply_9 ErrorHandling_10
Res ponse_15
tm(TM-sequenc e)
Aw aitReply_16 / ErrorHandling_17
T30
1593 Table 46 shows the state transition tables of the Master message handler.
Inactive_0 Waiting on demand for a "test" message via MH_Conf_COMx call (see Figure 36 and
Table 44) from DL-mode handler.
AwaitReply_1 Waiting on response from the Device to the "test" message. Return to Inactive_0 state
whenever the time T M-sequence elapsed without response from the Device or the
response to the "test" message could not be decoded. In case of a correct response
from the Device, the message handler changes to the Startup_2 state.
Startup_2 When entered via transition T2, this state is responsible to control acyclic On-request
Data exchange according to conditions specified in Table A.7. Any service DL_Write or
DL_Read from System Management causes a transition.
Response_3 The OD service caused the message handler to send a corresponding message. The
submachine in this pseudo state waits on the response and checks its correctness.
SM: AwaitReply_4 This state checks whether the time T M-sequence elapsed and the response is correct.
SM: ErrorHandling_5 In case of an incorrect response the message handler will re-send the message after a
waiting time T initcyc . After too many retries the message handler will change to the
Inactive_0 state.
Preoperate_6 Upon reception of a call MH_Conf_PREOPERATE the message handler changed to this
state. The message handler is now responsible to control acyclic On-request Data
exchange according to conditions specified in Table A.8. Any service DL_ReadParam,
DL_WriteParam, DL_ISDUTransport, DL_Write, or EventFlag causes a transition.
GetOD_7 The message handler used the ODTrig service to aquire OD from the On-request Data
handler. The message handler waits on the OD service to send a message after a time
T initcyc .
Response_8 The OD service caused the message handler to send a corresponding message. The
submachine in this pseudo state waits on the response and checks its correctness.
SM: AwaitReply_9 This state checks whether the time T M-sequence elapsed and the response is correct.
SM: ErrorHandling_10 In case of an incorrect response the message handler will re-send the message after a
waiting time T initcyc . After too many retries the message handler will change to the
Inactive_0 state.
CheckHandler_11 Some services require several OD acquisition cycles to exchange the OD. Whenever
the affected OD, ISDU, or Event handler returned to the idle state, the message
handler can leave the OD acquisition loop.
Operate_12 Upon reception of a call MH_Conf_OPERATE the message handler changed to this
state and after an initial time T initcyc , it is responsible to control cyclic Process Data
and On-request Data exchange according to conditions specified in Table A.9 and
Table A.10. The message handler restarts on its own a new message cycle after the
time t CYC elapsed.
GetPD_13 The message handler used the PDTrig service to aquire PD from the Process Data
handler. The message handler waits on the PD service and then changes to state
GetOD_14.
GetOD_14 The message handler used the ODTrig service to aquire OD from the On-request Data
handler. The message handler waits on the OD service to complement the already
acquired PD and to send a message with the acquired PD/OD.
Response_15 The message handler sent a message with the acquired PD/OD. The submachine in
this pseudo state waits on the response and checks its correctness.
SM: AwaitReply_16 This state checks whether the time T M-sequence elapsed and the response is correct.
SM: ErrorHandling_17 In case of an incorrect response the message handler will re-send the message after a
waiting time t CYC . After too many retries the message handler will change to the
Inactive_0 state.
1595
TRANSITION SOURCE TARGET ACTION
STATE STATE
T1 0 1 Send a message with the requested transmission rate of COMx and with
M-sequence TYPE_0: Read Direct Parameter page 1, address 0x02
("MinCycleTime"), compiling into an M-sequence control MC = 0xA2 (see
A.1.2). Start timer with T M-sequence .
IO-Link Interface and System © IO-Link – 81 – Version 1.1.3
t CYC Time The DL_SetMode service provides this value with its parameter "M-
sequenceTime". See equation (A.7)
1597
tm(MaxCycleTime)/
/Initialization
T10
[Ready]/
T6 (send) MH_Conf_ACTIVE/
CreateMessage_4 Idle_1 T1 Inactive_0
MH_Conf_INACTIVE/
PL_Transfer/ T11
[No error]/
T5 [ChecksumError]/ T2
tm(MaxUARTframeTime)/
T7 T9
[TypeError and not
CheckMessage_3 ChecksumError]/
T8 GetMessage_2
PL_Transfer/
[Completed]/
T3
T4
1600
1602 Table 47 shows the state transition tables of the Device message handler.
IO-Link Interface and System © IO-Link – 83 – Version 1.1.3
Inactive_0 Waiting for activation by the Device DL-mode handler through MH_Conf_ACTIVE (see
Table 45, Transition T1).
Idle_1 Waiting on first UART frame of the Master message through PL_Transfer service
indication. Check whether time "MaxCycleTime" elapsed.
GetMessage_2 Receive a Master message UART frame. Check number of received UART frames
(Device detects M-sequence type by means of the first two received octets depending
on the current communication state and thus knows the number of the UART frames).
Check whether the time "MaxUARTframeTime" elapsed.
CheckMessage_3 Check M-sequence type and checksum of received message.
CreateMessage_4 Compile message from OD.rsp, PD.rsp, EventFlag, and PDStatus services.
1604
TRANSITION SOURCE TARGET ACTION
STATE STATE
T1 0 1 –
T2 1 2 Start "MaxUARTframeTime" and "MaxCycleTime" when in OPERATE.
T3 2 2 Restart timer "MaxUARTframeTime".
T4 2 3 Reset timer "MaxUARTframeTime".
T5 3 4 Invoke OD.ind and PD.ind service indications
T6 4 1 Compile and invoke PL_Transfer.rsp service response (Device sends
response message)
T7 3 1 –
T8 3 1 Indicate error to DL-mode handler via MHInfo (ILLEGAL_MESSAGETYPE)
T9 2 1 Reset both timers "MaxUARTframeTime" and "MaxCycleTime".
T10 1 1 Indicate error to actuator technology that shall observe this information
and take corresponding actions (see 10.2 and 10.8.3).
T11 1 0 Device message handler changes state to Inactive_0.
1605
INTERNAL ITEMS TYPE DEFINITION
MaxUARTFrameTime Time Time for the transmission of a UART frame (11 T BIT ) plus maximum of t 1
(1 T BIT ) = 11 T BIT .
MaxCycleTime Time The purpose of the timer "MaxCycleTime" is to check, whether cyclic
Process Data exchange took too much time or has been interrupted.
MaxCycleTime shall be > MasterCycleTime (see A.3.7).
TypeError Guard One of the possible errors detected: ILLEGAL_MESSAGETYPE, or
COMLOST
ChecksumError Guard Checksum error of message detected
1606
1613 All Process Data are transmitted within one M-sequence when using M-sequences of
1614 TYPE_2_x (see Figure 39). In this case the execution time of a Process Data cycle is equal to
1615 the cycle time t CYC .
1619 45. It demonstrates the Master messages writing output Process Data to a Device. The
1620 service parameter PDOutAddress indicates the partition of the output PD to be transmitted
1621 (see 7.2.2.3). For input Process Data the service parameter PDInAddress correspondingly
1622 indicates the partition of the input PD. Within a Process Data cycle all input PD shall be read
1623 first followed by all output PD to be written. A Process Data cycle comprises all cycle times
1624 required to transmit the complete Process Data.
t (time)
1625
1626 Figure 45 – Interleave mode for the segmented transmission of Process Data
/initialization PDTrig/
T1
Inactive_0
PD_Conf_INACTIVE/ PD_Conf_INACTIVE/
T9 T11
PD_Conf_INACTIVE/
T10
PD_Conf_SINGLE/ PD_Conf_INTERLEAVE/
T2 T4
1630
1632 Table 48 shows the state transition tables of the Master Process Data handler.
IO-Link Interface and System © IO-Link – 85 – Version 1.1.3
1633 Table 48 – State transition tables of the Master Process Data handler
<None>
1636
/initialization
PD_ind/
T1
Inactive_0
PD_Conf_ACTIVE/ PD_Conf_INACTIVE/
T2 T8
PD_ind/
PDActive_1 T4
HandlePD_2
DL_PDInputUpdate/ [PD incomplete]/
T3 T5
[PD complete]/
T6
[Cycle complete]/
T7
1639
1642 Table 49 shows the state transition tables of the Device Process Data handler
1643 Table 49 – State transition tables of the Device Process Data handler
1646
1653 Whenever an EventFlag.ind is received, the state machine will change to the Event handler.
1654 After the complete readout of the Event information it will return to the ISDU handler state.
1655 Whenever a DL_Control.req or PDInStatus.ind service is received while in the ISDU handler
1656 or in the Event handler, the state machine will change to the command handler. Once the
1657 command has been served, the state machine will return to the previously active state (ISDU
1658 or Event).
1661 The On-request Data handler redirects the ODTrig.ind service primitive for the next message
1662 content to the currently active subsidiary handler (ISDU, command, or Event). This is
1663 performed through one of the ISDUTrig, CommandTrig, or EventTrig calls.
IO-Link Interface and System © IO-Link – 87 – Version 1.1.3
/initialization
Inactive_0
OH_Conf_INACTIVE/ OH_Conf_INACTIVE/
T11 T12
OH_Conf_ACTIVE/ OH_Conf_INACTIVE/
T1 T13
ODTrig/
T2
ISDU_1
DL_Control/
Command_2 T7 Event_3
1666 Table 50 shows the state transition tables of the Master On-request Data handler.
1667 Table 50 – State transition tables of the Master On-request Data handler
T1 0 1 -
T2 1 1 On-request Data handler propagates the ODTrig.ind service now named
ISDUTrig to the ISDU handler (see Figure 51). In case of DL_Read,
DL_Write, DL_ReadParam, or DL_WriteParam services, the ISDU handler
will use a separate transition (see Figure 51, T13).
T3 1 2 -
T4 2 1 -
T5 1 3 EventActive = TRUE
T6 3 1 EventActive = FALSE
T7 3 2 -
T8 2 3 -
T9 2 2 On-request Data handler propagates the ODTrig.ind service now named
CommandTrig to the command handler (see Figure 53)
T10 3 3 On-request Data handler propagates the ODTrig.ind service now named
EventTrig to the Event handler (see Figure 55)
T11 2 0 -
T12 3 0 -
T13 1 0 -
1669
INTERNAL ITEMS TYPE DEFINITION
EventActive Bool Flag to indicate return direction after interruption of Event processing by a
high priority command request
Version 1.1.3 – 88 – IO-Link Interface and System © IO-Link
1672 The Device On-request Data handler obtains information on the communication channel and
1673 the parameter or FlowCTRL address via the OD.ind service. The communication channels are
1674 totally independent. In case of a valid access, the corresponding ISDU, command or Event
1675 state machine is addressed via the associated communication channel.
1676 The Device shall respond to read requests to not implemented address ranges with the value
1677 "0". It shall ignore write requests to not implemented address ranges.
OD_ind_Command/ OD_ind_Param/
T3 T2 /initialization
OH_Conf_ACTIVE/
Idle_1 Inactive_0
T1
OH_Conf_INACTIVE/
T6
OD_ind_ISDU/ OD_ind_Event/
T4 T5
1678
1680 In case of an ISDU access in a Device without ISDU support, the Device shall respond with
1681 "No Service" (see Table A.12). An error message is not created.
1682 NOTE OD.ind (R, ISDU, FlowCTRL = IDLE) is the default message if there are no On-request Data pending for
1683 transmission.
1684 Table 51 shows the state transition tables of the Device On-request Data handler.
1685 Table 51 – State transition tables of the Device On-request Data handler
T1 0 1 -
T2 1 1 Provide data content of requested parameter or perform appropriate write
action
T3 1 1 Redirect to command handler
T4 1 1 Redirect to ISDU handler
T5 1 1 Redirect to Event handler
T6 1 0 -
1687
INTERNAL ITEMS TYPE DEFINITION
OD_ind_Param Service Alias for Service OD.ind (R/W, PAGE, 1 to 31, Data) in case of
DL_ReadParam or DL_WriteParam
OD_ind_Command Service Alias for Service OD.ind (W, PAGE, 0, MasterCommand)
OD_ind_ISDU Service Alias for Service OD.ind (R/W, ISDU, FlowCtrl, Data)
OD_ind_Event Service Alias for Service OD.ind (R/W, DIAGNOSIS, n, Data)
1688
IO-Link Interface and System © IO-Link – 89 – Version 1.1.3
I-Service Length
ExtLength
Index
Subindex
Data 1
...
Data n
CHKPDU = Checksum
1693
1695 The sequence of the elements corresponds to the transmission sequence. The elements of an
1696 ISDU can take various forms depending on the type of I-Service (see A.5.2 and Table A.12).
1697 The ISDU allows accessing data objects (parameters and commands) to be transmitted (see
1698 Figure 6). The data objects shall be addressed by the “Index” element.
1699 All multi-octet data types shall be transmitted as a big-endian sequence, i.e. the most
1700 significant octet (MSO) shall be sent first, followed by less significant octets in descending
1701 order, with the least significant octet (LSO) being sent last, as shown in Figure 2.
1707 In the ISDU communication channel, the "Address" element within the M-sequence control
1708 octet accommodates a counter (= FlowCTRL). FlowCTRL is controlling the segmented data
1709 flow (see A.1.2) by counting the M-sequences necessary to transmit an ISDU.
1710 The receiver of an ISDU expects a FlowCTRL + 1 in the next message in case of undisturbed
1711 communication. If FlowCTRL is unchanged, the previously transmitted message is repeated.
1712 In any other case the ISDU structure is violated.
1713 The Master uses the "Length" element of the ISDU and FlowCTRL to check the
1714 accomplishment of the complete transmission.
FlowCTRL Definition
FlowCTRL Definition
For a start request associated with a response, a Device shall send “No Service” until its
application returns response data (see Table A.12).
0x11 IDLE 1
No request for ISDU transmission.
0x12 IDLE 2: Reserved for future use
No request for ISDU transmission.
0x13 to 0x1E Reserved
0x1F ABORT
Abort entire service.
The Master responds by rejecting received response data.
The Device responds by rejecting received request data and may generate an abort.
1717
1718 In state Idle_1, values 0x12 to 0x1F shall not lead to a communication error.
/Initialization
Inactive_0
IH_Conf_ACTIVE/ IH_Conf_INACTIVE/
T1 T16
ISDUTrig[ ISDUTrig[
ParamRequest]/ DL_ISDUTransport]/
T13 T2 [Data written]/
Idle_1 ISDURequest_2
T4
ISDUTrig/ ISDUTrig/
T14 T3
DL_Mode_COMLOST/
T12 ISDUTrig/
DL_ISDUAbort/
T19 T5
ISDUTrig/ [Error]/
T11 T9
IH_Conf_INACTIVE/
ISDUError_4 ISDUWait_3
T15
DL_ISDUAbort/
T17
[ResponseStart]/
[Error]/ DL_ISDUAbort/ T6
T10 T18
ISDUTrig[ Transmission
completed]/ ISDUResponse_5
T8
ISDUTrig/
T7
1721
1723 Table 53 shows the state transition tables of the Master ISDU handler.
T1 0 1 -
T2 1 2 Invoke OD.req with ISDU write start condition: OD.req (W, ISDU, flowCtrl =
START, data)
T3 2 2 Invoke OD.req with ISDU data write and FlowCTRL under conditions of
Table 52
T4 2 3 Start timer (ISDUTime)
T5 3 3 Invoke OD.req with ISDU read start condition: OD.req (R, ISDU, flowCtrl =
START)
T6 3 5 Stop timer (ISDUTime)
T7 5 5 Invoke OD.req with ISDU data read and FlowCTRL under conditions of
Table 52
T8 5 1 OD.req (R, ISDU, flowCtrl = IDLE)
Invoke positive DL_ISDUTransport confirmation
T9 3 4 -
T10 5 4 -
T11 4 1 Invoke OD.req with ISDU abortion: OD.req (R, ISDU, flowCtrl = ABORT).
Invoke negative DL_ISDUTransport confirmation
T12 2 4 -
T13 1 1 Invoke OD.req with appropriate data.
Invoke positive DL_ReadParam/DL_WriteParam confirmation
T14 1 1 Invoke OD.req with idle message: OD.req (R, ISDU, flowCtrl = IDLE)
T15 4 1 In case of lost communication, the message handler informs the DL_Mode
handler which in turn uses the administrative call IH_Conf_INACTIVE. No
actions during this transition required.
T16 1 0 -
T17 3 4 -
T18 5 4 -
T19 2 4 -
1726
INTERNAL ITEMS TYPE DEFINITION
ISDUTime Time Measurement of Device response time (watchdog, see Table 102)
ResponseStart Service OD.cnf (data different from ISDU_BUSY)
ParamRequest Service DL_ReadParam or DL_WriteParam
Error Variable Any detectable error within the ISDU transmission or DL_ISDUAbort
requests, or any violation of the ISDU acknowledgment time (see Table
102)
1727
ISDURead/ ISDUWrite/
T14 T3
/Initialization
ISDUStart/
IH_Conf_ACTIVE/ Idle_1 T2
ISDURequest_2
Inactive_0 T1
[ISDUError]/T13
IH_Conf_INACTIVE/ ISDUAbort/
T12 T9
ISDUResponse_4 ISDUWait_3
ISDURespStart/
T6
ISDURead/ ISDURead/
T7 T5
1730
1732 Table 54 shows the state transition tables of the Device ISDU handler.
T1 0 1 -
T2 1 2 Start receiving of ISDU request data
T3 2 2 Receive ISDU request data
T4 2 3 Invoke DL_ISDUTransport.ind to AL (see 7.2.1.6)
T5 3 3 Invoke OD.rsp with "busy" indication (see Table A.14)
T6 3 4 -
T7 4 4 Invoke OD.rsp with ISDU response data
T8 4 1 -
T9 2 1 -
T10 3 1 Invoke DL_ISDUAbort
T11 4 1 Invoke DL_ISDUAbort
T12 1 0 -
T13 2 1 Invoke DL_ISDUAbort
T14 1 1 Invoke OD.rsp with "no service" indication (see Table A.12 and Table
A.14)
T15 3 1 Invoke DL_ISDUAbort
T16 4 1 Invoke DL_ISDUAbort
1735
INTERNAL ITEMS TYPE DEFINITION
1736
1743 The permissible control codes for output Process Data are listed in Table 55.
1745
1746 The command handler receives input Process Data status information via the PDInStatus
1747 service and propagates it within a DL_Control.ind service primitive.
1748 In addition, the command handler translates Device mode change requests from System
1749 Management into corresponding MasterCommands (see Table B.2).
/Initialization
Inactive_0
CH_Conf_ACTIVE/ CH_Conf_INACTIVE/
T1 T6
PDInStatus/ DL_Control_PDOUT/
T2 T3
Idle_1 MasterCommand_2
DL_Write_DEVICEMODE/
T4
CommandTrig/
T5
1752
1754 Table 56 shows the state transition tables of the Master command handler.
Version 1.1.3 – 94 – IO-Link Interface and System © IO-Link
T1 0 1 -
T2 1 1 If service PDInStatus.ind = VALID invoke DL_Control.ind (VALID) to signal
valid input Process Data to AL. If service PDInStatus.ind = INVALID invoke
DL_Control.ind (INVALID) to signal invalid input Process Data to AL.
T3 1 1 If service DL_Control.req = PDOUTVALID invoke OD.req (WRITE, PAGE,
0, 1, MasterCommand = 0x98).
If service DL_Control.req = PDOUTINVALID invoke OD.req (WRITE,
PAGE, 0, 1, MasterCommand = 0x99). See Table B.2.
T4 1 2 The services DL_Write_DEVICEMODE translate into:
INACTIVE: OD.req (WRITE, PAGE, 0, 1, MasterCommand = 0x5A)
STARTUP: OD.req (WRITE, PAGE, 0, 1, MasterCommand = 0x97)
PREOPERATE: OD.req (WRITE, PAGE, 0, 1, MasterCommand = 0x9A)
OPERATE: OD.req (WRITE, PAGE, 0, 1, MasterCommand = 0x99)
T5 2 1 A call CommandTrig from the OD handler causes the command handler to
invoke the OD.req service primitive and subsequently the message handler
to send the appropriate MasterCommand to the Device.
T6 1 0 -
1757
INTERNAL ITEMS TYPE DEFINITION
1758
CH_Conf_INACTIVE/ [Accomplished]/
T6 T5
DL_Control_PDIn/
T3
1764
1766 Table 57 shows the state transition tables of the Device command handler.
IO-Link Interface and System © IO-Link – 95 – Version 1.1.3
T1 0 1 -
T2 1 1 Invoke DL_Control.ind (PDOUTVALID) if received MasterCommand =
0x98. Invoke DL_Control.ind (PDOUTINVALID) if received
MasterCommand = 0x99.
T3 1 1 If service DL_Control.req (VALID) then invoke PDInStatus.req (VALID).
If service DL_Control.req (INVALID) then invoke PDInStatus.req
(INVALID). Message handler uses PDInStatus service to set/reset the PD
status flag (see A.1.5)
T4 1 2 -
T5 2 1 -
T6 1 0 -
1769
INTERNAL ITEMS TYPE DEFINITION
<none>
1770
1777 The general structure and coding of Events is specified in A.6. Event codes without details
1778 are specified in Table A.16. EventCodes with details are specified in Annex D. The structure
1779 of the Event memory for EventCodes with details within a Device is specified in Table 58.
1781
1785 Upon reception of a Device reply message with the "Event flag" bit = 1, the Master shall
1786 switch from the ISDU handler to the Event handler. The Event handler starts reading the
1787 StatusCode.
1788 If the "Event Details" bit is set (see Figure A.22), the Master shall read the Event details of
1789 the Events indicated in the StatusCode from the Event memory. Once it has read an Event
1790 detail, it shall invoke the service DL_Event.ind. After reception of the service DL_EventConf,
1791 the Master shall write any data to the StatusCode to reset the "Event flag" bit. The Event
1792 handling on the Master shall be completed regardless of the contents of the Event data
1793 received (EventQualifier, EventCode).
1794 If the "Event Details" bit is not set (see Figure A.21) the Master Event handler shall generate
1795 the standardized Events according to Table A.16 beginning with the most significant bit in the
1796 EventCode.
1797 Write access to the StatusCode indicates the end of Event processing to the Device. The
1798 Device shall ignore the data of this Master Write access. The Device then resets the "Event
1799 flag" bit and may now change the content of the fields in the Event memory.
/Initialization
Inactive_0
DL_Mode_COMLOST/ DL_Mode_COMLOST/
T9 T6
DL_EventConf/ EventTrig/
EventConfirmation_4 Idle_1 ReadEvent_2
T7 T2
EventTrig/
T8 [Events completed]/
T4
1802
1804 Table 59 shows the state transition tables of the Master Event handler.
ReadEvent_2 Read Event data set from Device message by message through Event memory
address. Check StatusCode for number of activated Events (see Table 58).
SignalEvent_3 Analyze Event data and invoke DL_Event indication to Master AL (see 7.2.1.15) for
each available Event.
EventConfirmation_4 Waiting on Event confirmation transmission via service OD.req to the Device
1806
TRANSITION SOURCE TARGET ACTION
STATE STATE
T1 0 1 -
T2 1 2 Read Event StatusCode octet via service OD.req (R, DIAGNOSIS, Event
memory address = 0, 1)
T3 2 2 Read octets from Event memory via service OD.req (R, DIAGNOSIS,
incremented Event memory address, 1)
T4 2 3 -
T5 3 1 -
T6 2 0 -
T7 1 4 -
T8 4 1 Invoke OD.req (W, DIAGNOSIS, 0, 1, any data) with Write access to
"StatusCode" (see Table 58) to confirm Event readout to Device
T9 4 0 -
T10 1 0 -
1807
INTERNAL ITEMS TYPE DEFINITION
<None>
1808
1811
1813 Table 60 shows the state transition tables of the Device Event handler.
T1 0 1 -
T2 1 1 Change Event memory entries with new Event data (see Table 58)
T3 1 2 Invoke service EventFlag.req (Flag = TRUE) to indicate Event activation to
the Master via the "Event flag" bit. Mark all Event slots in memory as not
changeable.
T4 2 2 Master requests Event memory data via EventRead (= OD.ind). Send
Event data by invoking OD.rsp with Event data of the requested Event
memory address.
T5 2 1 Invoke service EventFlag.req (Flag = FALSE) to indicate Event
deactivation to the Master via the "Event flag" bit. Mark all Event slots in
memory as invalid according to A.6.3.
T6 1 1 Send contents of Event memory by invoking OD.rsp with Event data
T7 1 0 -
T8 2 0 Discard Event memory data
1816
INTERNAL ITEMS TYPE DEFINITION
EventRead Service OD.ind (R, DIAGNOSIS, Event memory address, length, data)
EventConf Service OD.ind (W, DIAGNOSIS, address = 0, data = don't care)
1817
Master applications
Configuration Manager Data Storage On-request Data Exchange Diagnosis Unit Process Data Exchange
AL_SetOutput
AL_NewInput
AL_PDCycle
AL_GetInput
AL_Control
AL_Event
AL_Read
AL_Abort
AL_Write
SM_GetPortConfig
SM_SetPortConfig
SM_PortMode
SM_Operate
DL_PDCycle
DL_PDOut-
DL_Control
DL_Event-
putUpdate
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Write-
DL_Event
Transport
Transport
Port x AL_Read
Param
Param
Abort
Conf
Handler
DL_Read SIO
Coordination Process data handler
On-request data handler DI / DO
DL_Write
1824
1825 Figure 58 shows an overview of the structure and services of the Device application layer
1826 (AL).
IO-Link Interface and System © IO-Link – 99 – Version 1.1.3
Device applications
Parameter Manager (PM) Data Storage (DS) Event Dispatcher (ED) Process Data Exchange (PDE)
AL_NewOutput
AL_GetOutput
AL_PDCycle
AL_SetInput
AL_Control
AL_Event
AL_Read
AL_Abort
AL_Write
On-request Data Process Data
SM_GetDeviceComm
SM_SetDeviceComm
AL
SM_SetDeviceMode
SM_GetDeviceIdent
SM_SetDeviceIdent
DL_PDOutput-
DL_PDInput-
DL_PDCycle
DL_Control
DL_Event-
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Write-
DL_Event
Transport
Transport
Update
Trigger
Param
Param
Abort
SIO
On-request data handler Process data handler DI / DO
System Line
manage- handler
ment Data Link Layer
1827
AL_Read R I
AL_Write R I
AL_Abort R I
AL_GetInput R
AL_NewInput I
AL_SetInput R
AL_PDCycle I I
AL_GetOutput R
AL_NewOutput I
AL_SetOutput R
AL_Event I/R R
AL_Control I/R R/I
Key (see 3.3.4)
I Initiator of service
R Receiver (Responder) of service
1836
Argument M M
Port M
Index M M
Subindex M M
Result (+) S S(=)
Port M
Data M M(=)
Result (-) S S(=)
Port M
ErrorInfo M(=)
1842
1843 Argument
1844 The service-specific parameters are transmitted in the argument.
1845 Port
1846 This parameter contains the port number for the On-request Data to be read.
1847 Parameter type: Unsigned8
1848 Index
1849 This parameter indicates the address of On-request Data objects to be read from the
1850 Device. Index 0 in conjunction with Subindex 0 addresses the entire set of Direct
1851 Parameters from 0 to 15 (see Direct Parameter page 1 in Table B.1) or in conjunction with
1852 Subindices 1 to 16 the individual parameters from 0 to 15. Index 1 in conjunction with
1853 Subindex 0 addresses the entire set of Direct Parameters from addresses 16 to 31 (see
1854 Direct Parameter page 2 in Table B.1) or in conjunction with Subindices 1 to 16 the
1855 individual parameters from 16 to 31. It uses the page communication channel (see Figure
1856 7) for both and always returns a positive result. For all the other indices (see B.2) the ISDU
1857 communication channel is used.
1858 Permitted values: 0 to 65535 (See B.2.1 for constraints)
1859 Subindex
1860 This parameter indicates the element number within a structured On-request Data object. A
1861 value of 0 indicates the entire set of elements.
1862 Permitted values: 0 to 255
1863 Result (+):
1864 This selection parameter indicates that the service has been executed successfully.
1865 Port
1866 This parameter contains the port number of the requested On-request Data.
1867 Data
1868 This parameter contains the read values of the On-request Data.
1869 Parameter type: Octet string
1870 Result (-):
1871 This selection parameter indicates that the service failed.
1872 Port
1873 This parameter contains the port number for the requested On-request Data.
1874 ErrorInfo
1875 This parameter contains error information.
1876 Permitted values: see Annex C
1877 NOTE The AL maps DL ErrorInfos into its own AL ErrorInfos using Annex C.
1878
IO-Link Interface and System © IO-Link – 101 – Version 1.1.3
Argument M M
Port M
Index M M
Subindex M M
Data M M(=)
Result (+) S S(=)
Port M
Result (-) S S(=)
Port M
ErrorInfo M M(=)
1883
1884 Argument
1885 The service-specific parameters are transmitted in the argument.
1886 Port
1887 This parameter contains the port number for the On-request Data to be written.
1888 Parameter type: Unsigned8
1889 Index
1890 This parameter indicates the address of On-request Data objects to be written to the
1891 Device. Index 0 always returns a negative result except for use in conjunction with
1892 Subindex 16 at Devices without ISDU support. Index 1 in conjunction with Subindex 0
1893 addresses the entire set of Direct Parameters from addresses 16 to 31 (see Direct
1894 Parameter page 2 in Table B.1) or in conjunction with Subindices 1 to 16 the individual
1895 parameters from 16 to 31. It uses the page communication channel (see Figure 7) in case
1896 of Index 1 and always returns a positive result. For all other Indices (see B.2) the ISDU
1897 communication channel is used.
1898 Permitted values: 1 to 65535 (see Table 102)
1899 Subindex
1900 This parameter indicates the element number within a structured On-request Data object. A
1901 value of 0 indicates the entire set of elements.
1902 Permitted values: 0 to 255
1903 Data
1904 This parameter contains the values of the On-request Data.
1905 Parameter type: Octet string
1906 Result (+):
1907 This selection parameter indicates that the service has been executed successfully.
1908 Port
1909 This parameter contains the port number of the On-request Data.
1910 Result (-):
1911 This selection parameter indicates that the service failed.
1912 Port
1913 This parameter contains the port number of the On-request Data.
1914 ErrorInfo
1915 This parameter contains error information.
1916 Permitted values: see Annex C
1917
Version 1.1.3 – 102 – IO-Link Interface and System © IO-Link
Argument M M
Port M
1923
1924 Argument
1925 The service-specific parameter is transmitted in the argument.
1926 Port
1927 This parameter contains the port number of the service to be abandoned.
1928 8.2.2.4 AL_GetInput
1929 The AL_GetInput service reads the input data within the Process Data provided by the data
1930 link layer of a Device connected to a specific port. The parameters of the service primitives
1931 are listed in Table 65.
Argument M
Port M
Result (+) S
Port M
InputData M
Result (-) S
Port M
ErrorInfo M
1933
1934 Argument
1935 The service-specific parameters are transmitted in the argument.
1936 Port
1937 This parameter contains the port number for the Process Data to be read.
1938 Result (+):
1939 This selection parameter indicates that the service has been executed successfully.
1940 Port
1941 This parameter contains the port number for the Process Data.
1942 InputData
1943 This parameter contains the values of the requested process input data of the specified
1944 port.
1945 Parameter type: Octet string
1946 Result (-):
1947 This selection parameter indicates that the service failed.
1948 Port
1949 This parameter contains the port number for the Process Data.
1950 ErrorInfo
1951 This parameter contains error information.
1952 Permitted values:
1953 NO_DATA (DL did not provide Process Data)
IO-Link Interface and System © IO-Link – 103 – Version 1.1.3
Argument M
Port M
1959
1960 Argument
1961 The service-specific parameter is transmitted in the argument.
1962 Port
1963 This parameter specifies the port number of the received Process Data.
1964 8.2.2.6 AL_SetInput
1965 The AL_SetInput local service updates the input data within the Process Data of a Device.
1966 The parameters of the service primitives are listed in Table 67.
Argument M
InputData M
Result (+) S
Result (-) S
ErrorInfo M
1968
1969 Argument
1970 The service-specific parameters are transmitted in the argument.
1971 InputData
1972 This parameter contains the Process Data values of the input data to be transmitted.
1973 Parameter type: Octet string
1974 Result (+):
1975 This selection parameter indicates that the service has been executed successfully.
1978 ErrorInfo
1979 This parameter contains error information.
1980 Permitted values:
1981 STATE_CONFLICT (Service unavailable within current state)
1982 8.2.2.7 AL_PDCycle
1983 The AL_PDCycle local service indicates the end of a Process Data cycle. The Device
1984 application can use this service to transmit new input data to the application layer via
1985 AL_SetInput. The parameters of the service primitives are listed in Table 68.
Version 1.1.3 – 104 – IO-Link Interface and System © IO-Link
Argument
Port O
1987
1988 Argument
1989 The service-specific parameter is transmitted in the argument.
1990 Port
1991 This parameter contains the port number of the received new Process Data (Master only).
1992 8.2.2.8 AL_GetOutput
1993 The AL_GetOutput service reads the output data within the Process Data provided by the data
1994 link layer of the Device. The parameters of the service primitives are listed in Table 69.
Argument M
Result (+) S
OutputData M
Result (-) S
ErrorInfo M
1996
1997 Argument
1998 The service-specific parameters are transmitted in the argument.
2001 OutputData
2002 This parameter contains the Process Data values of the requested output data.
2003 Parameter type: Octet string
2004 Result (-):
2005 This selection parameter indicates that the service failed.
2006 ErrorInfo
2007 This parameter contains error information.
2008 Permitted values:
2009 NO_DATA (DL did not provide Process Data)
2010 8.2.2.9 AL_NewOutput
2011 The AL_NewOutput local service indicates the receipt of updated output data within the
2012 Process Data of a Device. This service has no parameters. The service primitives are shown
2013 in Table 70.
<None>
2015
Argument M
Port M
OutputData M
Result (+) S
Port M
Result (-) S
Port M
ErrorInfo M
2020
2021 Argument
2022 The service-specific parameters are transmitted in the argument.
2023 Port
2024 This parameter contains the port number of the Process Data to be written.
2025 OutputData
2026 This parameter contains the output data to be written at the specified port.
2027 Parameter type: Octet string
2028 Result (+):
2029 This selection parameter indicates that the service has been executed successfully.
2030 Port
2031 This parameter contains the port number for the Process Data.
2032 Result (-):
2033 This selection parameter indicates that the service failed.
2034 Port
2035 This parameter contains the port number for the Process Data.
2036 ErrorInfo
2037 This parameter contains error information.
2038 Permitted values:
2039 STATE_CONFLICT (Service unavailable within current state)
2040 8.2.2.11 AL_Event
2041 The AL_Event service indicates up to 6 pending status or error messages. The source of one
2042 Event can be local (Master) or remote (Device). The Event can be triggered by a
2043 communication layer or by an application. The parameters of the service primitives are listed
2044 in Table 72.
Argument M M M M
Port M M M
EventCount M M
Event(1) Instance M M
Mode M M
Type M M
Origin M
EventCode M M
…
Event(n) Instance M M
Mode M M
Type M M
Origin M
EventCode M M
2046
Version 1.1.3 – 106 – IO-Link Interface and System © IO-Link
2047 Argument
2048 The service-specific parameters are transmitted in the argument.
2049 Port
2050 This parameter contains the port number of the Event data.
2051 EventCount
2052 This parameter indicates the number n (1 to 6) of Events in the Event memory.
2053 Event(x)
2054 Depending on EventCount this parameter exists n times. Each instance contains the
2055 following elements.
2056 Instance
2057 This parameter indicates the Event source.
2058 Permitted values: Application (see Table A.17)
2059 Mode
2060 This parameter indicates the Event mode.
2061 Permitted values: SINGLESHOT, APPEARS, DISAPPEARS (see Table A.20)
2062 Type
2063 This parameter indicates the Event category.
2064 Permitted values: ERROR, WARNING, NOTIFICATION (see Table A.19)
2065 Origin
2066 This parameter indicates whether the Event was generated in the local communi-
2067 cation section or remotely (in the Device).
2068 Permitted values: LOCAL, REMOTE
2069 EventCode
2070 This parameter contains a code identifying a certain Event.
2071 Permitted values: see Annex D
2072 8.2.2.12 AL_Control
2073 The AL_Control service contains the Process Data qualifier status information transmitted to
2074 and from the Device application. This service shall be synchronized with AL_GetInput and
2075 AL_SetOutput respectively (see 11.7.2.1). The parameters of the service primitives are listed
2076 in Table 73.
Argument M M
Port C C
ControlCode M M
2078
2079 Argument
2080 The service-specific parameters are transmitted in the argument.
2081 Port
2082 This parameter contains the number of the related port.
2083 ControlCode
2084 This parameter contains the qualifier status of the Process Data (PD).
2085 Permitted values:
2086 VALID (Input Process Data valid)
2087 INVALID (Input Process Data invalid)
2088 PDOUTVALID (Output Process Data valid, see Table 55)
2089 PDOUTINVALID (Output Process Data invalid, see Table 55)
IO-Link Interface and System © IO-Link – 107 – Version 1.1.3
2094 The application layer manages the data transfer with all its assigned ports. That means, AL
2095 service calls need to identify the particular port they are related to.
2100 "AL_Service" represents any AL service in Table 61 related to OD. "Portx" indicates a
2101 particular port number.
/Initialization
[Service processed]/
AL_Abort_Portx/ OnReq_Idle_0
T16
T17
AL_Service_Portx/
T1
Build_DL_Service_1
[Argument_Error]/
T2
Await_DL_Param_cnf_2 Await_DL_ISDU_cnf_3
Build_AL_cnf_4
2102
2104 Table 74 shows the states and transitions for the OD state machine of the Master AL.
2105 Table 74 – States and transitions for the OD state machine of the Master AL
OnReq_Idle_0 AL service invocations from the Master applications or from the SM Portx handler (see
Figure 57) can be accepted within this state.
Build_DL_Service_1 Within this state AL service calls are checked, and corresponding DL services are
created within the subsequent states. In case of an error in the arguments of the AL
service a negative AL confirmation is created and returned.
Version 1.1.3 – 108 – IO-Link Interface and System © IO-Link
Await_DL_Param_cnf_2 Within this state the AL service call is transformed in a sequence of as many
DL_ReadParam or DL_WriteParam calls as needed (Direct Parameter page access;
see page communication channel in Figure 7). All asynchronously occurred AL service
invocations except AL_Abort are rejected (see 3.3.7).
Await_DL_ISDU_cnf_3 Within this state the AL service call is transformed in a DL_ISDUTransport service call
(see ISDU communication channel in Figure 7). All asynchronously occurred AL service
invocations except AL_Abort are rejected (see 3.3.7).
Build_AL_cnf_4 Within this state an AL service confirmation is created depending on an argument error,
the DL service confirmation, or an AL_Abort.
2106
TRANSITION SOURCE TARGET ACTION
STATE STATE
Argument_Error Bool Illegal values within the service body, for example "Port number or Index
out of range"
DL_RWParam Label "DL_RWParam": DL_WriteParam_cnf or DL_ReadParam_cnf
Completed Bool No more OD left for transfer
Octets_left Bool More OD for transfer
Portx Variable Service body variable indicating the port number
ISDU_Flag Bool Device supports ISDU
AL_Service Label "AL_Service" represents any AL service in Table 61 related to OD
2108
AL_Abort/T11 /Initialization
DL_ISDUAbort/
DL_WriteParam_ind/T1 T10
Await_AL_Write_rsp_1 Idle_0
AL_Write_rsp/T2
AL_Read_rsp/ AL_Write_rsp/
T7 T8
DL_ReadParam_ind/
T3
DL_ISDUTransport
AL_Read_rsp/ _ind[DirRead]/ AL_Abort/
T4 T5 T9
Await_AL_Read_rsp_2 Await_AL_RW_rsp_3
DL_ISDUTransport_ind[DirWrite]/
T6
2112
2114 Table 75 shows the states and transitions for the OD state machine of the Device AL.
2115 Table 75 – States and transitions for the OD state machine of the Device AL
T1 0 1 Invoke AL_Write.
T2 1 0 Invoke DL_WriteParam (16 to 31).
T3 0 2 Invoke AL_Read.
T4 2 0 Invoke DL_ReadParam (0 to 31).
T5 0 3 Invoke AL_Read.
T6 0 3 Invoke AL_Write.
T7 3 0 Invoke DL_ISDUTransport (read)
T8 3 0 Invoke DL_ISDUTransport (write)
T9 3 0 Current AL_Read or AL_Write abandoned upon this asynchronous
AL_Abort service call. Return negative DL_ISDUTransport (see 3.3.7).
T10 3 0 Current waiting on AL_Read or AL_Write abandoned.
T11 0 0 Current DL_ISDUTransport abandoned. All OD are set to "0".
2117
INTERNAL ITEMS TYPE DEFINITION
2118
2122 Figure 61 demonstrates two examples for the exchange of On-request Data. For Indices > 1
2123 this is performed with the help of ISDUs and corresponding DL services (ISDU communication
2124 channel according to Figure 7). Access to Direct Parameter pages 0 and 1 uses different DL
2125 services (page communication channel according to Figure 7)
AL_Read_req(Index > 1)
DL_ISDUTransport_req()
Read
Parameter via Message()
ISDU
DL_ISDUTransport_ind()
AL_Read_ind()
AL_Read_rsp()
DL_ISDUTranspot_rsp()
Message()
DL_ISDUTransport_cnf()
AL_Read_cnf()
AL_Read_req(Index <= 1)
DL_ReadParam_req()
Read Direct
Parameter Message()
page 0 or 1
DL_ReadParam_ind()
AL_Read_ind(Index <=1)
AL_Read_rsp()
DL_ReadParam_rsp()
Message()
DL_ReadParam_cnf()
AL_Read_cnf()
2126
2128 Figure 62 demonstrates the behaviour of On-request Data exchange in case of an error such
2129 as requested Index not available (see Table C.1).
2130 Another possible error occurs when the Master application (gateway) tries to read an Index >
2131 1 from a Device, which does not support ISDU. The Master AL would respond immediately
2132 with "NO_ISDU_SUPPORTED" as the features of the Device are acquired during start-up
2133 through reading the Direct Parameter page 1 via the parameter "M-sequence Capability" (see
2134 Table B.1).
IO-Link Interface and System © IO-Link – 111 – Version 1.1.3
AL_Read_req(Index > 1)
DL_ISDUTransport_req()
Message()
DL_ISDUTransport_ind() Device
AL_Read_ind() application
responds with
error information
"Index not
AL_Read_rsp() available"
DL_ISDUTransport_rsp() (0x8011,
Message() IDX_NOTAVAIL)
DL_ISDUTransport_cnf()
AL_Read_cnf()
ErrorInfo:
ErrorInfo: IDX_NOTAVAIL
IDX_NOTAVAIL
2135
2137 Figure 63 demonstrates the behaviour of On-request Data exchange in case of an ISDU
2138 timeout (5 000 ms). A Device shall respond within less than the "ISDU acknowledgment time"
2139 (see 10.8.5).
2140 NOTE See Table 102 for system constants such as "ISDU acknowledgment time".
AL_Read_req()
DL_ISDUTransport_req()
Message()
DL_ISDUTransport_ind()
AL_Read_ind()
<5000 ms>
DL_ISDUTransport_cnf()
AL_Read_cnf()
ErrorInfo =
ErrorInfo =
TIMEOUT
TIMEOUT Reaction of the Device
application missing or
too late (usually an
implementation error)
AL_Read_rsp()
Message()
FlowCTRL = DL_ISDUAbort_ind()
Abort AL_Abort_ind()
2141
/Initialization
Event_inactive_0
Activate/ Deactivate/
T1 T2
Event_idle_1
AL_Event_req/
T7
DL_Event_ind[Diag_Portx]/ AL_Event_rsp/
T3 T6
DL_Event_ind[Events_done]/
Read_Event_Set_2 T5 DU_Event_handling_3
DL_Event_ind[Events_left]/
T4
2146
2148 Table 76 specifies the states and transitions of the Event state machine of the Master
2149 application layer.
2150 Table 76 – State and transitions of the Event state machine of the Master AL
T1 0 1 -
T2 1 0 -
T3 1 2 -
T4 2 2 -
T5 2 3 AL_Event.ind
T6 3 1 DL_EventConf.req
T7 1 1 AL_Event.ind
2152
INTERNAL ITEMS TYPE DEFINITION
2153
IO-Link Interface and System © IO-Link – 113 – Version 1.1.3
/Initialization
Event_inactive_0
Activate/ Deactivate/
T1 T2
Event_idle_1
AL_Event_req/ DL_EventTrigger_cnf/
T3 T4
Await_Event_response_2
2156
2158 Table 77 specifies the states and transitions of the Event state machine of the Device appli-
2159 cation layer.
2160 Table 77 – State and transitions of the Event state machine of the Device AL
T1 0 1 -
T2 1 0 -
T3 1 2 An AL_Event request triggers a DL_Event and the corresponding
DL_EventTrigger service. The DL_Event carries the diagnosis information
from AL to DL. The DL_EventTrigger sets the Event flag within the cyclic
data exchange (see A.1.5).
T4 2 1 A DL_EventTrigger confirmation triggers an AL_Event confirmation.
2162
INTERNAL ITEMS TYPE DEFINITION
none
2163
2167 • The Device application creates an Event request (Step 1), which is passed from the AL to
2168 the DL and buffered within the Event memory (see Table 58).
2169 • The Device AL activates the EventTrigger service to raise the Event flag, which causes
2170 the Master to read the Event from the Event memory.
Version 1.1.3 – 114 – IO-Link Interface and System © IO-Link
2171 • The Master then propagates this Event to the gateway application (Step 2), and waits for
2172 an Event acknowledgment.
2173 • Once the Event acknowledgment is received (Step 3), it is indicated to the Device by
2174 writing to the StatusCode (Step 4).
2175 • The Device confirms the original Event request to its application (Step 5), which may now
2176 initiate a new Event request.
Master Master Master Device Device Device
Diagnosis AL DL DL AL App
Unit Portx
Event flag is
set AL_Event_req()
DL_Event_req()
OD_req()
Message()
Master reads
event via event
handler OD_ind()
Message()
Step 2: Event
DL_Event_ind()
propagated to the
AL_Event_ind()
gateway application
AL_Event_rsp()
DL_EventConf_req()
Step 3: Event Master writes to
acknowledged by the "StatusCode"
OD_req()
gateway application
Message()
Step 4: Event
acknowledged
OD_ind() to Device
application
DL_EventTrigger_cnf()
AL_Event_cnf()
AL_Event_req()
DL_Event_req()
Step 5: Event
DL_EventTrigger_req() x+1 occurs
2177
2185 Figure 66 also applies for the multi Event transport, except that this transport uses one
2186 DL_Event indication for each Event memory slot, and a single AL_Event indication for the
2187 entire Event set.
2188 One AL_Event.req carries up to 6 Events and one AL_Event.ind indicates up to 6 pending
2189 Events. AL_Event.rsp and AL_Event.cnf refer to the indicated entire Event set.
2190
IO-Link Interface and System © IO-Link – 115 – Version 1.1.3
2194 Figure 67 demonstrates how the AL and DL services of Master and Device are involved in the
2195 cyclic exchange of output Process Data. The Device application is able to acquire the current
2196 values of output PD via the AL_GetOutput service.
AL_Set Output_req(Portx )
DL_PDOutputUpdate_req()
Mess age()
DL_PDOutputTransport_ind()
AL_Set Output_req(Portx )
<Cy cle time> AL_NewOutput_ind()
... DL_PDOutputUpdate_req()
Mess age()
AL_Set Output_req(Portx )
...
DL_PDOutputTransport_ind()
DL_PDOutputUpdate_req()
... AL_NewOutput_ind()
Mess age()
...
DL_PDOutputTransport_ind()
...
AL_NewOutput_ind()
2197
2199 Figure 68 demonstrates how the AL and DL services of Master and Device are involved in the
2200 cyclic exchange of input Process Data. The Master application is able to acquire the current
2201 values of input PD via the AL_GetInput service.
Version 1.1.3 – 116 – IO-Link Interface and System © IO-Link
Message()
DL_PDCycle_ind()
AL_PDCycle_ind()
DL_PDInputTransport_req()
<Cycle time> AL_SetInput_req()
AL_NewInput_ind()
DL_PDInputUpdate_req()
Message()
DL_PDCycle_ind()
AL_PDCycle_ind()
DL_PDInputTransport_req()
AL_NewInput_ind()
... ... ...
Message()
... DL_PDCycle_ind()
AL_PDCycle_ind()
...
DL_PDInputTransport_req()
AL_NewInput_ind()
AL_GetInput_req() Asynchronous
access to input
Process Data
AL_GetInput_cnf()
2202
2204
2221 • SM_SetPortConfig transfers the necessary Device parameters (configuration data) from
2222 Configuration Management (CM) to System Mangement (SM). The port is then started
2223 implicitly.
2224 • SM_PortMode reports the positive result of the port setup back to CM in case of correct
2225 port setup and inspection. It reports the negative result back to CM via corresponding
2226 "errors" in case of mismatching revisions and incompatible Devices.
2227 • SM_GetPortConfig reads the actual and effective parameters.
2228 • SM_Operate switches a single port into the "OPERATE" mode.
2229 Figure 69 provides an overview of the structure and services of the Master System
2230 Management.
2231 The Master System Management needs one application layer service (AL_Read) to acquire
2232 data (identification parameter) from special Indices for inspection.
Master applications
Configuration Manager Data Storage On-request Data Exchange Diagnosis Unit Process Data Exchange
SM_Operate
PortConfig
PortConfig
SM_Port-
SM_Get-
SM_Set-
Application Layer
Mode
DL_PDInput-
DL_PDCycle
DL_PDOut-
DL_Control
DL_Event-
putUpdate
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Event
Transport
Transport
DL_Write
AL_Read
Param
Param
Port x
Abort
Conf
Handler
PD.req
PDTrig
DL-A
PD.cnf
Master
DL_Mode DL-mode MHInfo Message
System handler handler
Management SIO
DI / DO
Mode switch
2235 Figure 70 demonstrates the actions between the layers Master application (Master App),
2236 Configuration Management (CM), System Management (SM), Data Link (DL) and Application
2237 Layer (AL) for the startup use case of a particular port.
2239 • The Device for the available configuration is connected and inspection is successful
2240 • The Device uses the correct protocol version according to this specification
2241 • The configured InspectionLevel is "type compatible" (SerialNumber is read out of the
2242 Device and not checked).
2243 Dotted arrows in Figure 70 represent response services to an initial service.
Version 1.1.3 – 118 – IO-Link Interface and System © IO-Link
SMI_PortConfiguration(
Port x, PortConfigList) SM_SetPortConfig_req()
(Parameter list) Actions:
- Wake up
DL_SetMode_req() - Transmission rate
(Startup) detected
- --> State STARTUP
DL_Mode_ind(STARTUP)
Actions:
- Read Direct
Actions: DL_Read() Parameter 1
- Check protocol revision
Reply()
- Check device compatibility
(Direct Parameter 1)
- M-sequ. type (PREOPERATE)
- tinitcyc (PREOPERATE) ... Actions:
--> State
DL_SetMode_req(PREOPERATE)
PREOPERATE
(Value list)
DL_Mode_ind(PREOPERATE)
Actions: AL_Read()
- Check "Serial Number" Reply()
(Index: Serial number)
SM_PortMode_ind(COMREADY)
SMI_PortEvent(Port status
changed - 0xFF26)
SMI_PortStatus()
Reply()
(..., PREOPERATE, ...)
SM_GetPortConfig_req()
Reply()
(Parameter list)
Actions:
- M-sequence type (OPERATE)
SM_Operate() - Master Cycle Time (OPERATE)
Actions:
--> State OPERATE
DL_SetMode_req()
(OPERATE, Parameter list)
DL_Mode_ind(OPERATE)
SM_PortMode_ind(OPERATE)
SMI_PortEvent(Port status
changed - 0xFF26)
SMI_PortStatus()
Reply()
(..., OPERATE, ...)
2244
2246
SM_SetPortConfig R
SM_GetPortConfig R
SM_PortMode I
SM_Operate R
Key (see 3.3.4)
I Initiator of service
R Receiver (Responder) of service
2253
Argument M
ParameterList M
Result (+) S
Port Number M
Result (-) S
Port Number M
ErrorInfo M
2258
2259 Argument
2260 The service-specific parameters are transmitted in the argument.
2261 ParameterList
2262 This parameter contains the configured port and Device parameters of a Master port.
2263 Parameter type: Record
2264 Record Elements:
2265 Port Number
2266 This parameter contains the port number
2267 ConfiguredCycleTime
2268 This parameter contains the requested cycle time for the OPERATE mode
2269 Permitted values:
2270 0 (FreeRunning)
2271 Time (see Table B.3)
2272 TargetMode
2273 This parameter indicates the requested operational mode of the port
2274 Permitted values: INACTIVE, DI, DO, CFGCOM, AUTOCOM (see Table 81)
2275 ConfiguredRevisionID (CRID):
2276 Data length: 1 octet for the protocol version (see B.1.5)
2277 InspectionLevel:
2278 Permitted values: NO_CHECK, TYPE_COMP, IDENTICAL (see Table 80)
2279 ConfiguredVendorID (CVID)
2280 Data length: 2 octets
2281 NOTE VendorIDs are assigned by the IO-Link community
2282 ConfiguredDeviceID (CDID)
2283 Data length: 3 octets
Version 1.1.3 – 120 – IO-Link Interface and System © IO-Link
2303
2306
2307 CFGCOM is a Target Mode based on a user configuration (for example with the help of an
2308 IODD) and consistency checking of RID, VID, DID.
2309 AUTOCOM is a Target Mode without configuration. That means no checking of CVID and
2310 CDID. The CRID is set to the highest revision the Master is supporting. AUTOCOM should
2311 only be selectable together with Inspection Level "NO_CHECK" (see Table 80).
IO-Link Interface and System © IO-Link – 121 – Version 1.1.3
Argument M
Port Number M
Result (+) S(=)
Parameterlist M
Result (-) S(=)
Port Number M
ErrorInfo M
2316
2317 Argument
2318 The service-specific parameters are transmitted in the argument.
2323 ParameterList
2324 This parameter contains the configured port and Device parameter of a Master port.
2325 Parameter type: Record
2326 Record Elements:
2327 PortNumber
2328 This parameter contains the port number.
2329 TargetMode
2330 This parameter indicates the operational mode
2331 Permitted values: INACTIVE, DI, DO, CFGCOM, AUTOCOM (see Table 81)
2332 RealBaudrate
2333 This parameter indicates the actual transmission rate
2334 Permitted values:
2335 COM1 (transmission rate of COM1)
2336 COM2 (transmission rate of COM2)
2337 COM3 (transmission rate of COM3)
2338 RealCycleTime
2339 This parameter contains the real (actual) cycle time
2340 RealRevision (RRID)
2341 Data length: 1 octet for the protocol version (see B.1.5)
2342 RealVendorID (RVID)
2343 Data length: 2 octets
2344 NOTE VendorIDs are assigned by the IO-Link community
2345 RealDeviceID (RDID)
2346 Data length: 3 octets
2347 RealFunctionID (RFID)
2348 Data length: 2 octets
2349 RealSerialNumber (RSN)
2350 Data length: up to 16 octets
2351 Result (-):
2352 This selection parameter indicates that the service failed
Version 1.1.3 – 122 – IO-Link Interface and System © IO-Link
Argument M
Port Number M
Mode M
2365
2366 Argument
2367 The service-specific parameters are transmitted in the argument.
Argument M
Port number M
Result (+) S
Result (-) S
Port Number M
ErrorInfo M
2388
2389 Argument
2390 The service-specific parameters are transmitted in the argument.
2410 Comprehensive compatibility check methods are performed within the submachine states.
2411 These methods are indicated by "do method" fields within the state graphs, for example in
2412 Figure 72.
2413 The corresponding decision logic is demonstrated via activity diagrams (see Figure 73, Figure
2414 74, Figure 75, and Figure 78).
2417 Two submachines for the compatibility and serial number check are specified in subsequent
2418 sections.
2419 In case of communication disruption the System Management is informed via the service
2420 DL_Mode (COMLOST).
2422 The service SM_Operate causes no effect in any state except in state "wait_4".
2423
Version 1.1.3 – 124 – IO-Link Interface and System © IO-Link
/Inialization
PortInactive_0
DL_Mode_COMLOST/
SM_SetPortConfig[INACTIVE]/
T3
T14
DL_Mode_STARTUP/
T1 SM_SetPortConfig[CFGCOM or AUTOCOM]/
T15
JoinPseudoState_9
CheckCompatibility_1 enex_6
enex_1
wait_4
SM_Operate/
T12
SMOperate_5
DL_Mode_OPERATE/
T13
2424
2426 Table 85 shows the state transition tables of the Master System Management.
PortInactive_0 No communication
CheckCompatibility_1 Port is started and revision and Device compatibility is checked. See Figure 72.
waitonDLPreoperate_2 Wait until the PREOPERATE state is established and all the On-Request handlers are
started. Port is ready to communicate.
checkSerNum_3 SerialNumber is checked depending on the InspectionLevel (IL). See Figure 77.
wait_4 Port is ready to communicate and waits on service SM_Operate from CM.
SM Operate_5 Port is in state OPERATE and performs cyclic Process Data exchange.
InspectionFault_6 Port is ready to communicate. However, cyclic Process Data exchange cannot be
performed due to incompatibilities.
waitonDLOperate_7 Wait on the requested state OPERATE in case the Master is connected to a legacy
Device. The SerialNumber can be read thereafter.
DIDO_8 Port will be switched into the DI or DO mode (SIO, no communication).
IO-Link Interface and System © IO-Link – 125 – Version 1.1.3
JoinPseudoState_9 This pseudo state is used instead of a UML join bar. It allows execution of individual
SM_SetPortConfig services depending on the system status (INACTIVE, CFGCOM,
AUTOCOM, DI, or DO)
2428
TRANSITION SOURCE TARGET ACTION
STATE STATE
T1 0 1 CompRetry = 0
T2 1 2 DL_SetMode.req (PREOPERATE, ValueList)
T3 1,2,3,4,5, 0 DL_SetMode.req (INACTIVE) and SM_Mode.ind (COMLOST) due to
6,7 communication fault
T4 1 7 DL_SetMode.req (OPERATE, ValueList)
T5 1 6 SM_PortMode.ind (COMP_FAULT), DL_SetMode.req (OPERATE,
ValueList)
T6 1 6 SM_PortMode.ind (REVISION_FAULT), DL_SetMode.req (PREOPERATE,
ValueList)
T7 1 6 SM_PortMode.ind (COMP_FAULT), DL_SetMode.req (PREOPERATE,
ValueList)
T8 2 3 -
T9 7 3 -
T10 3 4 SM_PortMode.ind (COMREADY)
T11 3 6 SM_PortMode.ind (SERNUM_FAULT)
T12 4 5 DL_SetMode.req (OPERATE, ValueList)
T13 5 5 -
T14 0,4,5,6,8 0 SM_PortMode.ind (INACTIVE), DL_SetMode.req (INACTIVE)
T15 0,4,5,6,8 0 DL_SetMode.req (STARTUP, ValueList), PL_SetMode.req (SDCI)
T16 0,4,5,6,8 8 PL_SetMode.req (SIO), SM_Mode.ind (DI or DO), DL_SetMode.req
(INACTIVE)
T17 1 6 SM_PortMode.ind (CYCTIME_FAULT), DL_SetMode.req (PREOPERATE,
ValueList)
T18 1 6 SM_PortMode.ind (CYCTIME_FAULT), DL_SetMode.req (INACTIVE)
2429
INTERNAL ITEMS TYPE DEFINITION
2430
checkCompatibility_1
[WriteDone]/
T24 ReadComParameter_20
[<>V10]/ [V10]/
T21 T20
JoinPseudoState_25
enex_1
CheckVxy_22
DL_Mode_COMLOST/
T3 do check revision
RestartDevice_24
[RetryStartup]/ [RevisionFault]/
do write parameter T25 T6
2435 Table 86 shows the state transition tables of the Master submachine checkCompatibility_1.
ReadComParameter_20 Acquires communication parameters from Direct Parameter Page 1 (0x02 to 0x06) via
service DL_Read (see Table B.1).
CheckCompV10_21 Acquires identification parameters from Direct Parameter Page 1 (0x07 to 0x0D) via
service DL_Read (see Table B.1). The configured InspectionLevel (IL) defines the
decision logic of the subsequent compatibility check "CheckCompV10" with parameters
RVID, RDID, and RFID according to Figure 74.
CheckVxy_22 A check is performed whether the configured revision (CRID) matches the real (actual)
revision (RRID) according to Figure 73.
CheckComp_23 Acquires identification parameters from Direct Parameter Page 1 (0x07 to 0x0D) via
service DL_Read (see Table B.1). The configured InspectionLevel (IL) defines the deci-
sion logic of the subsequent compatibility check "CheckComp" according to Figure 75.
RestartDevice_24 Writes the compatibility parameters configured protocol revision (CRID) and configured
DeviceID (CDID) into the Device depending on the Target Mode of communication
CFGCOM or AUTOCOM (see Table 81) according to Figure 76.
JoinPseudoState_25 This pseudo state is used instead of a UML join bar. No guards involved.
2437
TRANSITION SOURCE TARGET ACTION
STATE STATE
T20 20 21 -
T21 20 22 DL_Write (0x00, MCmd_MASTERIDENT), see Table B.2
T22 22 23 -
T23 23 24 -
T24 24 20 -
T25 22 24 CompRetry = CompRetry +1
2438
INTERNAL ITEMS TYPE DEFINITION
2439
2440 Some states contain complex logic to deal with the compatibility and validity checks. Figure
2441 73 to Figure 76 are demonstrating the context.
2442 Figure 73 shows the decision logic for the protocol revision check in state "CheckVxy". In
2443 case of configured Devices the following rule applies: if the configured revision (CRID) and
2444 the real revision (RRID) do not match, the CRID will be transmitted to the Device. If the
2445 Device does not accept, the Master returns an indication via the SM_Mode service with
2446 REV_FAULT.
2447 In case of not configured Devices the operational mode AUTOCOM shall be used. See 9.2.2.2
2448 and 9.2.2.3 for the parameter name abbreviations.
[RRID = CRID]
D1 RevisionOK (T22)
[CompRetry = 0]
D2 RetryStartup (T25)
[CompRetry = 1]
RevisionFault (T6)
2449
2451 Figure 74 shows the decision logic for the legacy compatibility check in state
2452 "CheckCompV10".
Version 1.1.3 – 128 – IO-Link Interface and System © IO-Link
[Else]
[IL: NO_CHECK]
D4 V10CompOK (T4)
[Else]
2455
2456 Figure 75 shows the decision logic for the compatibility check in state "CheckComp".
[Else]
[IL: NO_CHECK]
D7 CompOK (T2) Device starts
[Else]
[CVID = RVID]
2459
WriteDone =FALSE
[AUTOCOM] [CFGCOM]
DL_Write (0x04, CRID) D10 DL_Write (0x04, CRID)
DL_Write (0x00,0x96, "DeviceIdent") DL_Write (0x09…0x0B, CDID)
DL_Read (0x02) (dummy cycle) DL_Write (0x00,0x96, "DeviceIdent")
DL_Read (0x02) (dummy cycle)
[CommError] [CommError]
[OK] [OK]
DL_Mode_COMLOST (T3) WriteDone = TRUE DL_Mode_COMLOST (T3)
(T24)
2461
2463
checkSerNum_3
ReadSerNum_30
enex_12
DL_Mode_COMLOST/
T3
[SRead-]/ [SReadOK]/
T30 T31
CheckSerNum_31
[SerNumOK]/ [SerNumFault]/
T10 T11
enex_11 enex_10
2467
2469 Table 87 shows the state transition tables of the Master submachine checkSerNum_3
ReadSerNum_30 Acquires the SerialNumber from the Device via AL_Read.req (Index: 0x0015). A
positive response (AL_Read(+)) leads to SReadOK = true. A negative response
(AL_Read(-)) leads to SRead- = true.
CheckSerNum_31 Optional: SerialNumber checking skipped or checked correctly.
2471
Version 1.1.3 – 130 – IO-Link Interface and System © IO-Link
T30 40 41 ‒
T31 40 41 ‒
2472
INTERNAL ITEMS TYPE DEFINITION
2473
2474 Figure 78 shows the decision logic (activity) for the state CheckSerNum_31.
[IL: IDENTICAL]
[SRead-]
D12 SerNumFault (T11)
[SReadOK]
[CSN = RSN]
SerNumOK (T10)
2475
2481 Different M-sequence types shall be used within the different operational states (see A.2.6).
2482 For example, when switching to the OPERATE state the M-sequence type relevant for cyclic
2483 operation shall be used. The M-sequence type to be used in operational state OPERATE is
2484 determined by the size of the input and output Process Data. The available M-sequence types
2485 in the three modes STARTUP, PREOPERATE, and OPERATE and the corresponding coding
2486 of the parameter M-sequenceCapability are specified in A.2.6. The input and output data
2487 formats shall be acquired from the connected Device in order to adjust the M-sequence type.
2488 It is mandatory for a Master to implement all the specified M-sequence types in A.2.6.
Device applications
Parameter Manager (PM) Data Storage (DS) Event Dispatcher (ED) Process Data Exchange (PDE)
Application Layer
SM_SetDevciceIdent
SM_SetDeviceMode
SM_GetDeviceIdent
SM_GetDeviceCom
SM_SetDeviceCom
SM_DeviceMode
DL_PDOutput-
DL_PDInput-
DL_PDCycle
DL_Control
DL_Event-
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Write-
DL_Event
Transport
Transport
Update
Trigger
Param
Param
Abort
On-request Data Process Data
Line handler handler
Handler
DL-B
PDInStatus
EventFlag
DL_Read
DL-A
OD.rsp
OD.ind
PD.rsp
PD.ind
DL_Write
Device
System DL_Mode DL-mode
Manage- handler
MHInfo Message
ment handler
SIO
DI / DO
Mode switch
Physical Layer
2493
2495 The System Management (SM) of the Device provides the central controlling instance via the
2496 Line Handler through all the phases of initialization, default state (SIO), communication
2497 startup, communication, and fallback to SIO mode.
2498 The Device SM interacts with the PL to establish the necessary line driver and receiver
2499 adjustments (see Figure 16), with the DL to get the necessary information from the Master
2500 (wake-up, transmission rates, a.o.) and with the Device applications to ensure the Device
2501 identity and compatibility (identification parameters).
2502 The transitions between the line handler states (see Figure 81) are initiated by the Master
2503 port activities (wake-up and communication) and triggered through the Device Data Link Layer
2504 via the DL_Mode indications and DL_Write requests (commands).
2505 The SM provides the Device identification parameters through the Device applications
2506 interface.
2507 The sequence chart in Figure 80 demonstrates a typical Device sequence from initialization to
2508 default SIO mode and via wake-up request from the Master to final communication. The
2509 sequence chart is complemented by the use case of a communication error such as T DSIO ex-
2510 pired, or communication fault, or a request from Master such as Fallback (caused by Event).
Version 1.1.3 – 132 – IO-Link Interface and System © IO-Link
PL DL SM Device
App
SM_SetDeviceMode(IDLE)
PL_SetMode(INACTIVE) Device default
communication
SM_DeviceMode(IDLE) and identification
parameter
SM_SetDeviceCom(Initial parameter)
SM_SetDeviceIdent(Initial parameter)
SM_SetDeviceMode(SIO)
PL_SetMode(DI | DO | INACTIVE)
SM_DeviceMode(SIO)
SIO mode
WakeUp
active
request from
master PL_WakeUp_ind()
DL_Mode(ESTABCOM)
PL_SetMode(COMx)
SM_DeviceMode(ESTABCOM)
PL_SetMode(INACTIVE)
SM_DeviceMode(IDLE)
SM_SetDeviceCOM(Initial parameter)
SM_SetDeviceIdent(Initial parameter)
SM_SetDeviceMode(SIO)
PL_SetMode(DI | DO | INACTIVE)
SM_DeviceMode(SIO)
SIO mode
active
2511
2512 Figure 80 – Sequence chart of the use case "INACTIVE – SIO – SDCI – SIO"
2518 Table 88 lists the assignment of the Device to its role as initiator or receiver for the individual
2519 System Management service.
SM_SetDeviceCom R
SM_GetDeviceCom R
SM_SetDeviceIdent R
SM_GetDeviceIdent R
SM_SetDeviceMode R
IO-Link Interface and System © IO-Link – 133 – Version 1.1.3
SM_DeviceMode I
Key (see 3.3.4)
I Initiator of service
R Receiver (Responder) of service
2521
Argument M
ParameterList M
Result (+) S
Result (-) S
ErrorInfo M
2527
2528 Argument
2529 The service-specific parameters are transmitted in the argument.
2530 ParameterList
2531 This parameter contains the configured communication parameters for a Device.
2532 Parameter type: Record
2533 Record Elements:
2534 SupportedSIOMode
2535 This parameter indicates the SIO mode supported by the Device.
2536 Permitted values:
2537 INACTIVE (C/Q line in high impedance)
2538 DI (C/Q line in digital input mode)
2539 DO (C/Q line in digital output mode)
2540 SupportedTransmissionrate
2541 This parameter indicates the transmission rate supported by the Device.
2542 Permitted values:
2543 COM1 (transmission rate of COM1)
2544 COM2 (transmission rate of COM2)
2545 COM3 (transmission rate of COM3)
2546 MinCycleTime
2547 This parameter contains the minimum cycle time supported by the Device (see
2548 B.1.3).
2549 M-sequence Capability
2550 This parameter indicates the capabilities supported by the Device (see B.1.4):
2551 - ISDU support
2552 - OPERATE M-sequence types
2553 - PREOPERATE M-sequence types
2554 RevisionID (RID)
2555 This parameter contains the protocol revision (see B.1.5) supported by the Device.
2556 ProcessDataIn
2557 This parameter contains the length of PD to be sent to the Master (see B.1.6).
2558 ProcessDataOut
2559 This parameter contains the length of PD to be sent by the Master (see B.1.7).
Version 1.1.3 – 134 – IO-Link Interface and System © IO-Link
2564 ErrorInfo
2565 This parameter contains error information.
2566 Permitted values:
2567 PARAMETER_CONFLICT (consistency of parameter set violated)
2568
Argument M
Result (+) S
ParameterList M
Result (-) S
ErrorInfo M
2573
2574 Argument
2575 The service-specific parameters are transmitted in the argument.
2578 ParameterList
2579 This parameter contains the configured communication parameter for a Device.
2580 Parameter type: Record
2581 Record Elements:
2582 CurrentMode
2583 This parameter indicates the current SIO or Communication Mode by the Device.
2584 Permitted values:
2585 INACTIVE (C/Q line in high impedance)
2586 DI (C/Q line in digital input mode)
2587 DO (C/Q line in digital output mode)
2588 COM1 (transmission rate of COM1)
2589 COM2 (transmission rate of COM2)
2590 COM3 (transmission rate of COM3)
2591 MasterCycleTime
2592 This parameter contains the MasterCycleTime to be set by the Master System
2593 Management (see B.1.3). This parameter is only valid in the state SM_Operate.
2594 M-sequence Capability
2595 This parameter indicates the current M-sequence capabilities configured in the
2596 System Management of the Device (see B.1.4):
2597 - ISDU support
2598 - OPERATE M-sequence types
2599 - PREOPERATE M-sequence types
2600 RevisionID (RID)
2601 This parameter contains the current protocol revision (see B.1.5) within the System
2602 Management of the Device.
2603 ProcessDataIn
IO-Link Interface and System © IO-Link – 135 – Version 1.1.3
2604 This parameter contains the current length of PD to be sent to the Master (see
2605 B.1.6).
2606 ProcessDataOut
2607 This parameter contains the current length of PD to be sent by the Master (see
2608 B.1.7).
2609 Result (-):
2610 This selection parameter indicates that the service failed.
2611 ErrorInfo
2612 This parameter contains error information.
2613 Permitted values:
2614 STATE_CONFLICT (service unavailable within current state)
2615 9.3.2.4 SM_SetDeviceIdent
2616 The SM_SetDeviceIdent service is used to configure the Device identification data in the
2617 System Management. The parameters of the service primitives are listed in Table 91.
Argument M
ParameterList M
Result (+) S
Result (-) S
ErrorInfo M
2619
2620 Argument
2621 The service-specific parameters are transmitted in the argument.
2622 ParameterList
2623 This parameter contains the configured identification parameter for a Device.
2624 Parameter type: Record
2625 Record Elements:
2626 VendorID (VID)
2627 This parameter contains the VendorID assigned to a Device (see B.1.8)
2628 Data length: 2 octets
2629 DeviceID (DID)
2630 This parameter contains one of the assigned DeviceIDs (see B.1.9)
2631 Data length: 3 octets
2632 FunctionID (FID)
2633 This parameter contains one of the assigned FunctionIDs (see B.1.10).
2634 Data length: 2 octets
2635 Result (+):
2636 This selection parameter indicates that the service has been executed successfully.
2639 ErrorInfo
2640 This parameter contains error information.
2641 Permitted values:
2642 STATE_CONFLICT (service unavailable within current state)
2643 PARAMETER_CONFLICT (consistency of parameter set violated)
Version 1.1.3 – 136 – IO-Link Interface and System © IO-Link
Argument M
Result (+) S
ParameterList M
Result (-) S
ErrorInfo M
2648
2649 Argument
2650 The service-specific parameters are transmitted in the argument.
2653 ParameterList
2654 This parameter contains the configured communication parameters of the Device.
2655 Parameter type: Record
2656 Record Elements:
2657 VendorID (VID)
2658 This parameter contains the actual VendorID of the Device (see B.1.8)
2659 Data length: 2 octets
2660 DeviceID (DID)
2661 This parameter contains the actual DeviceID of the Device (see B.1.9)
2662 Data length: 3 octets
2663 FunctionID (FID)
2664 This parameter contains the actual FunctionID of the Device (see B.1.10).
2665 Data length: 2 octets
2666 Result (-):
2667 This selection parameter indicates that the service failed.
2668 ErrorInfo
2669 This parameter contains error information.
2670 Permitted values:
2671 STATE_CONFLICT (service unavailable within current state)
2672 9.3.2.6 SM_SetDeviceMode
2673 The SM_SetDeviceMode service is used to set the Device into a defined operational state
2674 during initialization. The parameters of the service primitives are listed in Table 93.
Argument M
Mode M
Result (+) S
Result (-) S
ErrorInfo M
2676
IO-Link Interface and System © IO-Link – 137 – Version 1.1.3
2677 Argument
2678 The service-specific parameters are transmitted in the argument.
2679 Mode
2680 Permitted values:
2681 IDLE (Device changes to waiting for configuration)
2682 SIO (Device changes to the mode defined in service "SM_SetDeviceCom")
2683 Result (+):
2684 This selection parameter indicates that the service has been executed successfully.
2687 ErrorInfo
2688 This parameter contains error information.
2689 Permitted values:
2690 STATE_CONFLICT (service unavailable within current state)
2691 9.3.2.7 SM_DeviceMode
2692 The SM_DeviceMode service is used to indicate changes of communication states to the
2693 Device application. The parameters of the service primitives are listed in Table 94.
Argument M
Mode M
2695
2696 Argument
2697 The service-specific parameters are transmitted in the argument.
2698 Mode
2699 Permitted values:
2700 IDLE (Device changed to waiting for configuration)
2701 SIO (Device changed to the mode defined in service "SM_SetDeviceCom")
2702 ESTABCOM (Device changed to the SM mode "SM_ComEstablish")
2703 COM1 (Device changed to the COM1 mode)
2704 COM2 (Device changed to the COM2 mode)
2705 COM3 (Device changed to the COM3 mode)
2706 STARTUP (Device changed to the STARTUP mode)
2707 IDENT_STARTUP (Device changed to the SM mode "SM_IdentStartup")
2708 IDENT_CHANGE (Device changed to the SM mode "SM_IdentCheck")
2709 PREOPERATE (Device changed to the PREOPERATE mode)
2710 OPERATE (Device changed to the OPERATE mode)
2711 9.3.3 SM Device protocol
2712 9.3.3.1 Overview
2713 The behaviour of the Device is mainly driven by Master messages.
/Initialization
SM_Idle_0 SM_SIO_1
SM_DeviceMode_SIO/
T1
DL_Mode_ESTABCOM/
T2
SM_ComEstablish_2
DL_Mode_COMx/
T4 DL_Mode_STARTUP/
DL_Mode_INACTIVE/ T13
T3
DL_Mode_STARTUP/
T12
DL_Mode_OPERATE/
SM_ComStartup_3 T11
DL_Write_MCmd_MASTERIDENT/
T5
DL_Mode_PREOPERATE/
SM_IdentStartup_4 T10
DL_Write_MCmd_DEVICEIDENT/
T6
SM_IdentCheck_5
DL_Read_MinCycleTime/
T7
SM_CompStartup_6
DL_Mode_PREOPERATE/
T8
SM_Preoperate_7
DL_Mode_OPERATE/
T9
SM_Operate_8
2718
2720 Table 95 specifies the individual states and the actions within the transitions.
SM_Idle_0 In SM_Idle the SM is waiting for configuration by the Device application and to be set
to SIO mode. The state is left on receiving a SM_SetDeviceMode(SIO) request from the
Device application
The following sequence of services shall be executed between Device application and
SM.
Invoke SM_SetDeviceCom(initial parameter list)
Invoke SM_SetDeviceIdent(VID, initial DID, FID)
SM_SIO_1 In SM_SIO the SM Line Handler is remaining in the default SIO mode. The Physical
Layer is set to the SIO mode characteristics defined by the Device application via the
SetDeviceMode service. The state is left on receiving a DL_Mode(ESTABCOM)
indication.
SM_ComEstablish_2 In SM_ComEstablish the SM is waiting for the communication to be established in the
Data Link Layer. The state is left on receiving a DL_Mode(INACTIVE) or a
DL_Mode(COMx) indication, where COMx may be any of COM1, COM2 or COM3.
IO-Link Interface and System © IO-Link – 139 – Version 1.1.3
T1 0 1 The Device is switched to the configured SIO mode by receiving the trigger
SM_SetDeviceMode.req(SIO).
Invoke PL_SetMode(DI|DO|INACTIVE)
Invoke SM_DeviceMode(SIO)
T2 1 2 The Device is switched to the communication mode by receiving the trigger
DL_Mode.ind(ESTABCOM).
Invoke PL_SetMode(COMx)
Invoke SM_DeviceMode(ESTABCOM)
T3 2,3,4,5,6, 0 The Device is switched to SM_Idle mode by receiving the trigger
7,8 DL_Mode.ind(INACTIVE) .
Invoke PL_SetMode(INACTIVE)
Invoke SM_DeviceMode(IDLE)
T4 2 3 The Device application receives an indication on the baudrate with which
the communication has been established in the DL triggered by
DL_Mode.ind(COMx).
Invoke SM_DeviceMode(COMx)
T5 3 4 The Device identification phase is entered by receiving the trigger
DL_Write.ind(MCmd_MASTERIDENT).
Invoke SM_DeviceMode(IDENTSTARTUP)
T6 4 5 The Device identity check phase is entered by receiving the trigger
DL_Write.ind(MCmd_DEVICEIDENT).
Invoke SM_DeviceMode(IDENTCHANGE)
T7 5 6 The Device compatibility startup phase is entered by receiving the trigger
DL_Read.ind( Direct Parameter page 1, address 0x02 = "MinCycleTime").
T8 6 7 The Device's preoperate phase is entered by receiving the trigger
DL_Mode.ind(PREOPERATE).
Invoke SM_DeviceMode(PREOPERATE)
T9 7 8 The Device's operate phase is entered by receiving the trigger
DL_Mode.ind(OPERATE).
Version 1.1.3 – 140 – IO-Link Interface and System © IO-Link
2724
2725 Figure 82 shows a typical sequence chart for the SM communication startup of a Device
2726 matching the Master port configuration settings (regular startup).
DL AL SM Device
App
DL_Mode(COMx)
SM_DeviceMode(COMx)
DL_Read(Direct Parameter 1)
(MinCycleTime, MSeqCapability, RID,
PDin length, PDout length)
DL_Write(0x00, MCmd_MASTERIDENT)
Master actions SM_DeviceMode(IDENTSTARTUP)
(optional):
- Check RID, VID, DID,
FID DL_Read(Direct Parameter 1)
(Use case assumes: (VID,DID,FID)
check OK)
From now on:
PREOPERATE
DL_Write(0x00, MCmd_PREOPERATE) state
SM_DeviceMode(PREOPERATE)
...
DL_ISDUTransport()
AL_Read()
2727
2729 Figure 83 shows a typical sequence chart for the SM communication startup of a Device not
2730 matching the Master port configuration settings (compatibility mode). In this mode, the Master
2731 tries to overwrite the Device's identification parameters to achieve a compatible and a
2732 workable mode.
2733 The sequence chart in Figure 83 shows only the actions until the PREOPERATE state. The
2734 remaining actions until the OPERATE state can be taken from Figure 82.
DL SM Device
App
DL_Mode(COMx)
SM_DeviceMode(COMx)
DL_Read(Direct Parameter 1)
(MinCycleTime, MSeqCapability, RID,
PDin length, PDout length)
Master actions: DL_Write(0x00, MCmd_MASTERIDENT)
- Check RID, VID, DID, SM_DeviceMode(IDENTSTARTUP)
FID
(Use case assumes:
DL_Read(Direct Parameter 1)
check DID or RID fails)
(VID,DID,FID)
DL_Write(0x04, CRID)
DL_Write(0x09...0x0B, CDID)
DL_Write(0x00, MCmd_DEVICEIDENT)
SM_DeviceMode(IDENTCHANGE)
Device compa-
SM_GetDeviceCom(current parameter) tibility check:
- supported RID
SM_GetDeviceIdent(current parameter) - supported DID
Master action:
- Delay via one SM_SetDeviceCom(compatible parameter)
Read cycle
SM_SetDeviceIdent(compatible DID, FID)
DL_Read(Direct Parameter 1)
(MinCycleTime, MSeqCapability, RID,
PDin length, PDout length)
2735
2737 Figure 84 shows a typical sequence chart for the SM communication startup of a Device not
2738 matching the Master port configuration settings. The System Management of the Master tries
2739 to reconfigure the Device with alternative Device identification parameters (compatibility
2740 mode). In this use case, the alternative parameters are assumed to be incompatible.
Version 1.1.3 – 142 – IO-Link Interface and System © IO-Link
DL SM Device
App
DL_Mode(COMx)
SM_DeviceMode(COMx)
DL_Read(Direct Parameter page 1)
(MinCycleTime, MSeqCapability, RID,
PDin length, PDout length)
DL_Write(0x04, CRID)
DL_Write(0x09...0x0B, CDID)
DL_Write(0x00, MCmd_DEVICEIDENT)
SM_DeviceMode(IDENTCHANGE)
Device compa-
tibility check:
SM_GetDeviceCom(current parameter)
- not supported RID
SM_GetDeviceIdent(current parameter) - not supported DID
Master action:
- Delay via one SM_SetDeviceCom(supported parameter)
Read cycle SM_SetDeviceIdent(supported DID, FID)
DL_Read(Direct Parameter page 1)
(MinCycleTime, MSeqCapability, RID,
PDin length, PDout length)
Master actions:
- Check RID, VID, DID,
DL_Write(0x00, MCmd_MASTERIDENT)
FID
SM_DeviceMode(IDENTSTARTUP)
(Use case assumes:
check DID or RID fails) DL_Read(Direct Parameter page 1)
(VID,DID,FID)
... ...
2741
2743
2744
IO-Link Interface and System © IO-Link – 143 – Version 1.1.3
2745 10 Device
2746 10.1 Overview
2747 Figure 85 provides an overview of the complete structure and services of a Device.
Device applications
Parameter Manager (PM) Data Storage (DS) Event Dispatcher (ED) Process Data Exchange (PDE)
AL_NewOutput
AL_GetOutput
AL_PDCycle
AL_SetInput
AL_Control
AL_Event
AL_Abort
AL_Read
AL_Write
SIO:
DI / DO
AL
SM_SetDeviceMode
SM_GetDeviceIdent
SM_GetDeviceCom
SM_SetDeviceCom
DL_PDOutput-
DL_PDInput-
DL_PDCycle
DL_Control
DL_Event-
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Write-
DL_Event
Transport
Transport
Trigger
Update
Param
Param
Abort
DL-B
PDInStatus
EventFlag
DL_Read
OD.rsp
OD.ind
PD.rsp
PD.ind DL-A
DL_Write
Device
System DL_Mode DL-mode MHInfo Message
manage- handler
ment handler
SIO:
PL_SetMode.req PL_WakeUp.ind PL_Transfer.ind PL_Transfer.req DI / DO
Mode switch
Wake-up Coded switching Switching signal
Physical layer
2748
2750 The Device applications comprise first the technology specific application consisting of the
2751 transducer with its technology parameters, its diagnosis information, and its Process Data.
2752 The common Device applications comprise:
2753 • Parameter Manager (PM), dealing with compatibility and correctness checking of complete
2754 sets of technology (vendor) specific and common system parameters (see 10.3);
2755 • Data Storage (DS) mechanism, which optionally uploads or downloads parameters to the
2756 Master (see 10.4);
2757 • Event Dispatcher (ED), supervising states and conveying diagnosis information such as
2758 notifications, warnings, errors, and Device requests as peripheral initiatives (see 10.5);
2759 • Process Data Exchange (PDE) unit, conditioning the data structures for transmission in
2760 case of a sensor or preparing the received data structures for signal generation. It also
2761 controls the operational states to ensure the validity of Process Data (see 10.2).
2762 These Device applications provide standard methods/functions and parameters common to all
2763 Devices, and Device specific functions and parameters, all specified within Clause 10.
2767 An actuator (output Process Data) shall observe the cyclic transmission and enter a default
2768 appropriate state, for example keep last value, stop, or de-energize, whenever the data
2769 transmission is interrupted (see 7.3.3.5 and 10.8.3). The actuator shall wait on the
2770 MasterCommand "ProcessDataOutputOperate" (see Table B.2, output Process Data "valid")
2771 prior to regular operation after restart in case of an interruption.
2772 Within cyclic data exchange, an actuator (output Process Data) receives a Master-Command
2773 "DeviceOperate", whenever the output Process Data are invalid and a Master-Command
2774 "ProcessDataOutputOperate", whenever they become valid again (see Table B.2).
2775 There is no need for a sensor Device (input Process Data) to monitor the cyclic data
2776 exchange. However, if the Device is not able to guarantee valid Process Data, the PD status
2777 "Process Data invalid" (see A.1.5) shall be signaled to the Master application.
2782 Mandatory for all Devices are the so-called Direct Parameters in page 1. This page 1 contains
2783 common communication and identification parameters (see B.1).
2784 Direct Parameter page 2 optionally offers space for a maximum of 16 octets of technology
2785 (vendor) specific parameters for Devices requiring not more than this limited number and with
2786 small system footprint (ISDU communication not implemented, easier fieldbus handling
2787 possible but with less comfort). Access to the Direct Parameter page 2 is performed via
2788 AL_Read and AL_Write (see 10.8.5).
2789 The transmission of parameters to and from the spacious Index memory can be performed in
2790 two ways: single parameter by single parameter or as a block of parameters. Single
2791 parameter transmission as specified in 10.3.4 is secured via several checks and confirmation
2792 of the transmitted parameter. A negative acknowledgment contains an appropriate error
2793 description and the parameter is not activated. Block Parameter transmission as specified in
2794 10.3.5 defers parameter consistency checking and activation until after the complete
2795 transmission. The Device performs the checks upon reception of a special command and
2796 returns a confirmation or a negative acknowledgment with an appropriate error description. In
2797 this case the transmitted parameters shall be rejected and a roll back to the previous
2798 parameter set shall be performed to ensure proper functionality of the Device.
2804 The PM is driven by command messages of the Master (see Table B.9). For example, the
2805 guard [UploadStart] corresponds to the reception of the SystemCommand
2806 "ParamUploadStart" and [UploadEnd] to the reception of the SystemCommand
2807 "ParamUploadEnd".
2808 NOTE 1 Following a communication interruption, the Master System Management uses the service
2809 SM_DeviceMode with the variable "INACTIVE" to stop the upload process and to return to the "IDLE" state.
2810 Any new "ParamUploadStart" or "ParamDownloadStart" while another sequence is pending,
2811 for example due to an unexpected shut-down of a vendor parameterization tool, will abort the
2812 pending sequence. The corresponding parameter changes will be discarded.
2813 NOTE 2 A PLC user program and a parameterization tool can conflict (multiple access), for example if during
2814 commissioning, the user did not disable accesses from the PLC program while changing parameters via the tool.
2815 The parameter manager mechanism in a Device is always active and the DS_ParUpload.req
2816 in transition T4 is used to trigger the Data Storage (DS) mechanism in 10.4.2.
IO-Link Interface and System © IO-Link – 145 – Version 1.1.3
/Initialization
[UploadEnd or
[Single Parameter]/T1 Idle_0 [DownloadStart]/
DownloadBreak or
T16
[DownloadStore]/T2 DownloadEnd]/
T20
[Local Parameter]/T3
[DownloadStart]/T7
[UploadEnd or
SM_DeviceMode_IDLE/ DownloadBreak or
T12 [UploadStart]/
DownloadEnd]/
T10
T11
[UploadStart]/
[DownloadStore]/ Upload_3
T18
T17
[DownloadStart]/
T19
[DownloadEnd]/ [UploadStart]/T15
T13
[DownloadStore]/T14
2817
2819 Table 96 shows the state transition tables of the Device Parameter Manager (PM) state
2820 machine.
T1 0 1 -
T2 0 1 Set "StoreRequest" (= TRUE)
T3 0 1 Set "StoreRequest" (= TRUE)
T4 1 0 Mark parameter set as valid; invoke DS_ParUpload.req to DS; enable
positive acknowledge of transmission; reset "StoreRequest" (= FALSE)
T5 1 0 Mark parameter set as valid; enable positive acknowledge of transmission
T6 1 0 Mark parameter set as invalid; enable negative acknowledgment of
transmission; reset "StoreRequest" (= FALSE); discard parameter buffer
T7 0 2 Lock local parameter access
T8 2 0 Unlock local parameter access; discard parameter buffer
T9 2 0 Unlock local parameter access; discard parameter buffer
T10 0 3 Lock local parameter access
T11 3 0 Unlock local parameter access
T12 3 0 Unlock local parameter access
Version 1.1.3 – 146 – IO-Link Interface and System © IO-Link
2825 The Parameter Manager (PM) supports handling of "single parameter" (Index and Subindex)
2826 transfers as well as "Block Parameter" transmission (entire parameter set).
2836 It is recommended to avoid concurrent access to a parameter via local control elements and
2837 SDCI write services at the same point in time.
AL_Write_req(Parameter)
SDCI_Message()
AL_Write_ind(Parameter)
Parameter
check result
AL_Write_res(+)
= OK
SDCI_Message()
AL_Write_cnf(+)
Positive result
Negative result
AL_Write_req(Parameter)
SDCI_Message()
AL_Write_ind(Parameter) Parameter
check failed
AL_Write_res(-)
SDCI_Message()
AL_Write_cnf(-)
2841
2843 If single parameterization is performed via ISDU objects, the Device shall check the access,
2844 structure, validity and consistency (see Table 97) of the transmitted data within the context of
2845 the entire parameter set and return the result in the confirmation. Via positive conformation,
2846 the Device indicates that parameter contents
1 Access Check for valid access rights for this Index / See C.2.3 to C.2.8
Subindex, independent from data content (Index /
Subindex permanent or temporarily unavailable;
write/read access on read/write only Index)
2 Structure Check for valid data structure like data size, only See C.2.12 and
complete data structures can be written, for C.2.13
example 2 octets to an UInteger16 data type
3 Validity Check for valid data content of single parameters, See C.2.9 to C.2.11,
testing for data limits C.2.14, C.2.15
4 Consistency Check for valid data content of the entire See C.2.16 and
parameter set, testing for interference or C.2.17
correlations between parameters
NOTE These checks are valid for single and Block Parameters (see 10.3.5)
2852
Version 1.1.3 – 148 – IO-Link Interface and System © IO-Link
2860 A sample sequence chart for valid Block Parameter changes with an optional Data Storage
2861 request is demonstrated in Figure 88.
AL_Write_req(SysCommand)
(ParamDownloadStart) SDCI_Message()
AL_Write_ind(SysCommand)
(ParamDownloadStart)
AL_Write_res(+)
SDCI_Message()
AL_Write_cnf(+)
AL_Write_req(Parameter)
SDCI_Message()
AL_Write_ind(Parameter)
AL_Write_res(+)
SDCI_Message()
AL_Write_req(SysCommand)
(ParamDownloadStore) SDCI_Message()
AL_Write_ind(SysCommand) Parameter
(ParamDownloadStore) check result
= OK
AL_Write_res(+)
SDCI_Message()
DS_ParUpload_req()
Option:
AL_Write_cnf(+) Data storage
upload
request
2862
2863 Figure 88 – Positive Block Parameter download with Data Storage request
2864 A sample sequence chart for invalid Block Parameter changes is demonstrated in Figure 89.
2865 The "ParamDownloadStart" command (see Table B.9) indicates the beginning of the Block
2866 Parameter transmission in download direction (from user application to the Device). The
2867 SystemCommand "ParamDownloadEnd" or "ParamDownloadStore" terminates this sequence.
2868 Both functions are similar. However, in addition the SystemCommand "ParamDownloadStore"
2869 causes the Data Storage (DS) mechanism to upload the parameter set through the
2870 DS_UPLOAD_REQ Event (see 10.4.2).
IO-Link Interface and System © IO-Link – 149 – Version 1.1.3
AL_Write_req(SysCommand)
(ParamDownloadStart) SDCI_Message()
AL_Write_ind(SysCommand)
(ParamDownloadStart)
AL_Write_res(+)
SDCI_Message()
AL_Write_cnf(+)
AL_Write_req(Parameter)
SDCI_Message()
AL_Write_ind(Parameter)
AL_Write_res(+)
SDCI_Message()
AL_Write_req(SysCommand)
(ParamDownloadEnd or
SDCI_Message()
ParamDownloadStore)
AL_Write_ind(SysCommand) Parameter
(ParamDownloadEnd or check failed
ParamDownloadStore)
AL_Write_res(-)
SDCI_Message()
AL_Write_cnf(-)
2871
Rule Action
1 At first, access and structure checks shall always be performed for each parameter (see Table
97).
2 Then, optionally, validity checks can be performed for each parameter.
3 At this time, consistency checking for transferred parameters shall be disabled and the single
parameters shall not be activated.
4 Parameter manager shall not exit from block transfer mode in case of invalid accesses or
structure violations or validity faults. The parameter set shall be treated as invalid if one of these
checks failed.
5 With command "ParamDownloadEnd" or "ParamDownloadStore", the Device checks validity of
each parameter if not already performed and consistency of the entire parameter set. The
parameter set shall be treated as invalid if one of these checks failed. The result of the check is
indicated to the originator of the Block Parameter transmission within the ISDU acknowledgment
in return to the command.
Version 1.1.3 – 150 – IO-Link Interface and System © IO-Link
Rule Action
2875
2876 The "ParamUploadStart" command (see Table B.9) indicates the beginning of the Block
2877 Parameter transmission in upload direction (from the Device to the user application). The
2878 SystemCommand "ParamUploadEnd" terminates this sequence and indicates the end of
2879 transmission.
2883 In any case, the response to all "ParamXXX" commands (see Table B.9) shall be transmitted
2884 after execution of the requested action.
1 "Index not available", see Command parameter is not supported by the Device
C.2.3
2 "Function not available", see Command is not supported by the Device regardless of the
C.2.14 Device state
3 "Function temporarily not Command is supported but the actual state of the Device
available", see C.2.15 does not permit the requested command.
4 Write response (+) Command is supported and accepted in the current state of
the Device and action is finished. However, within the
context of certain commands, the action is just started. This
exception is defined at the certain command.
2893
2894 In any case the ISDU timeout shall be observed (see Table 102).
2905 During Data Storage the Device shall apply the same checking rules as specified for the Block
2906 Parameter transfer in 10.3.5.
2907 The implementation of the DS mechanism specified in this standard is highly recommended
2908 for Devices. If this mechanism is not supported, it is the responsibility of the Device vendor to
2909 describe how parameterization of a Device after replacement can be ensured in a system
2910 conform manner without tools.
2917 The Device shall generate an Event "DS_UPLOAD_REQ" (see Table D.1) only if the
2918 parameter set is valid and
2919 • parameters assigned for Data Storage have been changed locally on the Device (for
2920 example teach-in, human machine interface, etc.), or
2921 • the Device receives a SystemCommand "ParamDownloadStore"
2922 With this Event information the Data Storage mechanism of the Master is triggered and
2923 initiates a Data Storage upload or download sequence depending on port configuration. The
2924 state machine in Figure 90 specifies the Device Data Storage mechanism.
/Inialization
[Unlocked]/ [Locked]/
T6 T1
DSStateCheck_0
DS_ParUpload_ind/ DS_ParUpload_ind/
T7 T2
[Locked]/T5
[TransmissionStart]/T8
[TransmissionEnd]/
T11
[TransmissionEnd]/T9 DSActivity_3
[TranmissionBreak]/T10
2925
2927 Table 100 shows the state transition tables of the Device Data Storage (DS) state machine.
2928 See Table B.10 for details on DataStorageIndex assignments.
2929 Table 100 – State transition table of the Data Storage state machine
2932
2933 The truncated sequence chart in Figure 91 demonstrates the important communication
2934 sequences after the parameterization.
IO-Link Interface and System © IO-Link – 153 – Version 1.1.3
AL_Write_ind(SysCommand)
SDCI_Message()
AL_Event_ind(DS_UPLOAD_REQ)
AL_Write_res(+)
SDCI_Message()
AL_Write_cnf(+)
AL_Write_req(DS_Command)
(DS_UploadEnd or SDCI_Message()
DS_DownloadEnd)
AL_Write_ind(DS_Command)
(DS_UploadEnd or Data storage
DS_DownloadEnd) request
inactive
AL_Write_res(+)
SDCI_Message()
AL_Write_cnf(+)
2935
2959 "DS_DownloadEnd" (see Table B.10). If one of the Indices is rejected by the Device, the Data
2960 Storage Master will abort the up- or download with a SystemCommand "DS_Break". In this
2961 case no retries of the Data Storage sequence will be performed.
2980 Events are classified in "Errors", "Warnings", and "Notifications". See 10.10.2 for these
2981 classifications and see 11.6 for how the Master is controlling and processing these Events.
2982 All Events provided at one point in time are acknowledged with one single command.
2983 Therefore, the Event acknowledgment may be delayed by the slowest acknowledgment from
2984 upper system levels.
2996 As a Device can provide backward compatibility to previous DeviceIDs (DID), these
2997 compatible Devices shall support all parameters and communication capabilities of the
2998 previous DeviceID. Thus, the Device is permitted to change any communication (except
2999 transmission rate) or identification parameter in this case.
3008 Devices supporting both V1.0 and V1.1 mode are permitted
IO-Link Interface and System © IO-Link – 155 – Version 1.1.3
3009 • to use the same predefined parameters, Events, and ErrorTypes in both modes;
3010 • to support Block Parameterization with full functionality including the Event "DS_UP-
3011 LOAD_REQ". A legacy Master propagates such an Event without any further action.
3012
3041 • Data processing of a Device to be synchronized with the Master (port) cycle within certain
3042 limits;
3043 • Data processing of multiple Devices on different Master ports to be synchronized with one
3044 another;
3045 • Data processing of multiple Devices on different Master ports to run with a defined offset.
3046 Figure 92 demonstrates the timing of messages in respect to the data processing in Devices.
tCYC
Device specific
technology toffset Data processing toffset Data processing
Port
(Master) Message Message
Message Message
Device
tM-sequence tidle
3047
3049 The OffsetTime defines a trigger relative to the start of an M-sequence cycle. The support for
3050 this function is optional for a Device.
3072 Table B.9 defines which of these SystemCommands are mandatory, highly recommended or
3073 optional.
3074 Table 101 provides an overview on impacted items when performing one of these options.
3075 Table 101 – Overview on reset options and their impact on Devices
Keys
PowerCycle Device power on off on
Initial Set to initial values according to power up state
COM Communication
No Not affected
Clear Set to "0" in case of no COM restart. All active Events will be sent with "Disappear" to clear
DeviceStatus. After a performed "Restore factory settings", pending Events can be resent.
Default Reset to initial value of state of delivery to customer
Event Trigger upload via DS_UPLOAD_REQ flag
Discard Transferred parameters not activated
History recorder For example: Operation hour meter
3076
3081 This feature is triggered upon reception of SystemCommand "Device reset" (see Table B.9).
3082 In any case, the ISDU response to this SystemCommand shall be transmitted immediately to
3083 the Master, also allowing retries in case of communication faults.
3091 This feature is triggered upon reception of a SystemCommand "Application reset" (see Table
3092 B.9). In any case, the ISDU response to this SystemCommand shall be transmitted to the
3093 Master after successful execution of the requested action.
3115 terization. It is especially useful, whenever a Device is removed from an already parameteri-
3116 zed installation and reactivated for example as a spare part. If the Device remains in an auto-
3117 mation application beyond the next PowerCycle, all parametrization will be overwritten just as
3118 if it were a replacement.
3119 It is triggered upon reception of the SystemCommand "Back-to-box" (see Table B.9), i.e. the
3120 Device shall stop and disable communication until next PowerCycle. If the Device provides a
3121 user interface, the special state “Waiting for PowerCycle” shall be visible. In any case, the
3122 response to a SystemCommand shall be transmitted to the Master, also allowing retries in
3123 case of communication faults.
3136 The format of the transmitted data is Device specific and varies from no data octets up to 32
3137 octets in each communication direction.
3138 Recommendations:
3153 The parameters from the Direct Parameter page cannot be saved and restored via the Data
3154 Storage mechanism.
3158 The following rules shall be considered when using this channel (see Figure 7).
3159 • Index 0 is not accessible via the ISDU communication channel. The access is redirected
3160 by the Master to the Direct Parameter page 1 using the page communication channel.
IO-Link Interface and System © IO-Link – 159 – Version 1.1.3
3161 • Index 1 is not accessible via the ISDU communication channel. The access is redirected
3162 by the Master to the Direct Parameter page 2 using the page communication channel.
3163 • Index 3 cannot be accessed by a PLC application program. The access is limited to the
3164 Master application only (Data Storage).
3165 • After reception of an ISDU request from the Master the Device shall respond within
3166 5 000 ms (see Table 102). Any violation causes the Master to abandon the current task.
3167 10.8.6 DeviceID rules related to Device variants
3168 Devices with a certain DeviceID and VendorID shall not deviate in communication and
3169 functional behavior. This applies for sensors and actuators. Those Devices may vary for
3170 example in
ISDU acknowledgment time, B.2.2 5 000 ms Time from reception of an ISDU for
for example after a example SystemCommand and the
SystemCommand beginning of the response message of
the Device (see Figure 63)
Maximum number of entries B.2.3 70 Each entry comprises an Index and a
in Index List Subindex. 70 entries results in a total
of 210 octets.
Preset values for unused or Annex B 0 (if numbers) Engineering shall set all unused
reserved parameters, for 0x00 (if parameters to the preset values.
example FunctionID characters)
Wake-up procedure 7.3.2.2 See Table 42 Minimum and maximum timings and
and Table 43 number of retries
MaxRetry 7.3.3.3 2, Maximum number of retries after
see Table 46 communication errors
MinCycleTime A.3.7 and See Table Device defines its minimum cycle time
B.1.3 A.11 and to aquire input or process output data.
Table B.3
Usable Index range B.2 See Table This version of the standard reserves
B.8 some areas within the total range of
65535 Indices.
Errors and warnings 10.10.2 50 ms An Event with MODE "Event appears"
shall stay at least for the duration of
this time.
EventCount 8.2.2.11 1 Constraint for AL_Event.req
3178
3179 10.9 IO Device description (IODD)
3180 An IODD (I/O Device Description) is a file that provides all the necessary properties to
3181 establish communication and the necessary parameters and their boundaries to establish the
3182 desired function of a sensor or actuator.
3183 An IODD (I/O Device Description) is a file that formally describes a Device.
3184 An IODD file shall be provided for each Device and shall include all information necessary to
3185 support this standard.
Version 1.1.3 – 160 – IO-Link Interface and System © IO-Link
3186 The IODD can be used by engineering tools for PLCs and/or Masters for the purpose of
3187 identification, configuration, definition of data structures for Process Data exchange,
3188 parameterization, and diagnosis decoding of a particular Device.
3189 NOTE Details of the IODD language to describe a Device can be found in [6].
3190 10.10 Device diagnosis
3191 10.10.1 Concepts
3192 This standard provides only most common EventCodes in D.2. It is the purpose of these
3193 common diagnosis informations to enable an operator or maintenance person to take fast
3194 remedial measures without deep knowledge of the Device's technology. Thus, the text
3195 associated with a particular EventCode shall always contain a corrective instruction together
3196 with the diagnosis information.
3197 Fieldbus-Master-Gateways tend to only map few EventCodes to the upper system level.
3198 Usually, vendor specific EventCodes defined via the IODD can only be decoded into readable
3199 instructions via a Port and Device Configuration Tool (PDCT) or specific vendor tool using the
3200 IODD.
3201 Condensed information of the Device's "state of health" can be retrieved from the parameter
3202 "DeviceStatus" (see B.2.20). Table 103 provides an overview of the various possibilities for
3203 Devices and shows examples of consumers for this information.
3204 If implemented, it is also possible to read the number of faults since power-on or reset via the
3205 parameter "ErrorCount" (see B.2.19) and more information in case of profile Devices via the
3206 parameter "DetailedDeviceStatus" (see B.2.21).
3207 NOTE Profile specific values for the "DetailedDeviceStatus" are given in [7].
3208 If required, it is highly recommended to provide additional "deep" technology specific
3209 diagnosis information in the form of Device specific parameters (see Table B.8) that can be
3210 retrieved via port and Device configuration tools for Masters or via vendor specific tools.
3211 Usually, only experts or service personnel of the vendor are able to draw conclusions from
3212 this information.
3216 • Events of TYPE "Error" shall use the MODEs "Event appears / disappears"
3217 • Events of TYPE "Warning" shall use the MODEs "Event appears / disappears"
3218 • Events of TYPE "Notification" shall use the MODE "Event single shot"
3219 The following requirements apply:
3220 • All Events already placed in the Event queue are discarded by the Event Dispatcher when
3221 communication is interrupted or cancelled. Once communication resumed, the technology
3222 specific application is responsible for proper reporting of the current Event causes.
3223 • It is the responsibility of the Event Dispatcher to control the "Event appears" and "Event
3224 disappears" flow. Once the Event Dispatcher has sent an Event with MODE "Event
3225 appears" for a given EventCode, it shall not send it again for the same EventCode before
3226 it has sent an Event with MODE "Event disappears" for this same EventCode.
3227 • Each Event shall use static mode, type, and instance attributes.
3228 • Each vendor specific EventCode shall be uniquely assigned to one of the TYPEs (Error,
3229 Warning, or Notification).
3230 In order to prevent the diagnosis communication channel (see Figure 7) from being flooded,
3231 the following requirements apply:
3232 • The same diagnosis information shall not be reported at less than 1 s intervals. That
3233 means the Event Dispatcher shall not invoke the AL_Event service with the same
3234 EventCode more often than after 1 s.
3235 • The Event Dispatcher shall not issue an "Event disappears" less than 50 ms after the
3236 corresponding "Event appears".
3237 • Subsequent incidents of errors or warnings with the same root cause shall be disregarded,
3238 that means one root cause shall lead to a single error or warning.
3239 • The Event Dispatcher shall invoke the AL_Event service with an EventCount equal one.
3240 • Errors are prioritized over Warnings.
3241 Figure 93 shows how two successive errors are processed, and the corresponding flow of
3242 "Event appears" / "Event disappears" Events for each error.
Event flag SC SC SC SC
t
Toff
Trep
3248
3250 Table 104 defines the timing for the LED indicator of Devices.
3252
3253 NOTE Timings above are defined such that the general perception would be "power is on".
3254 A short periodical interruption indicates that the Device is in COMx communication state. In
3255 order to avoid flickering, the indication cycle shall start with a "LED off" state and shall always
3256 be completed (see Table 104).
3262 11 Master
3263 11.1 Overview
3264 11.1.1 Positioning of Master and Gateway Applications
3265 In 4.2 the domain of the SDCI technology within the automation hierarchy is already
3266 illustrated. Figure 95 shows the recommended relationship between the SDCI technology and
3267 a fieldbus technology. Even though this may be the major use case in practice, this does not
3268 automatically imply that the SDCI technology depends on the integration into fieldbus
3269 systems. It can also be directly integrated into PLC systems, industrial PC, or other
3270 automation systems without fieldbus communication in between.
3271 For the sake of preferably uniform behavior of Masters, Figure 95 shows a Standardized
3272 Master Interface (SMI) as layer in between the Master and the Gateway Applications or
3273 embedded systems on top. This Standardized Master Interface is intended to serve also the
3274 safety system extensions as well as the wireless system extensions. In case of FS-Masters,
3275 attention shall be payed to the fact, that this SMI in some aspects requires implementation
3276 according to safety standards.
3277 The Standardized Master Interface is specified in this clause via services and data objects
3278 similar to the other layers (PL, DL, and AL) in this document. It is designed using few uniform
3279 base structures that both upper layer fieldbus and upper layer IT systems can use in an
3280 efficient manner: push ("write"), pull ("read"), push/pull ("write/read"), and indication ("Event").
3281 The specification of Gateway Applications is not subject of this document. Designers shall
3282 observe the realtime requirements of control functions and safety functions in case of
3283 concurrent Gateway Applications (see 13.2).
IO-Link Interface and System © IO-Link – 163 – Version 1.1.3
Parameter Engineering:
Internet, IT, PLC/FS-PLC/OPC-UA
server - configuration,
Browser - parameterization,
Fieldbus Fieldbus controller
- process data
integration - diagnosis,
- identification &
Ethernet maintenance
e.g. XML, JSON
Key
CID ClientID
Device FS-Device Air interface
GA Gateway Application
Dedicated Pairing
W-Device JSON Javascript Object Notation
Tool button
Application Application OPC-UA Open Platform Communications
Application
Universal Architecture
Device Device Device UDP User Datagram Protocol
description description description XML Extensible Markup Language
3284
3285 NOTE Blue and orange shaded areas indicate features specified in this standard except those for functional
3286 safety (FS) and wireless (W)
3287 Figure 95 – Generic relationship of SDCI and automation technology
SMI services
Standardized Master Interface (SMI)
Configuration Manager Data Storage On-request Data Exchange Diagnosis Unit Process Data Exchange
AL_SetOutput
AL_NewInput
AL_PDCycle
SIO:
AL_GetInput
AL_Control
DI / DO
AL_Event
AL_Read
AL_Abort
AL_Write
SM_GetPortConfig
SM_SetPortConfig
SM_PortMode
SM_Operate
DL_PDCycle
NC
DL_PDOut-
DL_Control
DL_Event-
putUpdate
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Write-
DL_Event
Transport
Transport
AL_Read DI / DO
Port x
Param
Param
+
Abort
Conf
Handler Specific
EventFlag
ODTrig
PD.req
PDTrig
OD.req
DL-A
PD.cnf
OD.cnf
Master
DL_Mode DL-mode MHInfo Message
System
handler handler
management
SIO:
PL_SetMode.req PL_WakeUp.req PL_Transfer.req PL_Transfer.ind DI / DO
Mode switch
Inactive Wake-up Coded switching Switching
signal
Physical layer (port, C/Q) I/Q
3290
3292 The Master applications are located on top of the Master structure and consist of:
3293 • Configuration Manager (CM), which transforms the user configuration assignments into
3294 port set-ups;
3295 • On-request Data Exchange (ODE), which provides for example acyclic parameter access;
3296 • Data Storage (DS) mechanism, which can be used to save and restore the Device
3297 parameters;
3298 • Diagnosis Unit (DU), which routes Events from the AL to the Data Storage unit or the
3299 gateway application;
3300 • Process Data Exchange (PDE), building the bridge to upper level automation instruments.
3301
3302 They are accessible by the gateway applications (and others) via the Standardized Master
3303 Interface (SMI) and its services/methods.
3304 These services and corresponding functions are specified in an abstract manner within
3305 clauses 11.2.2 to 11.2.22 and Annex E.
3306 Master applications are described in detail in clauses 11.3 to 11.7. The Configuration Mana-
3307 ger (CM) and the Data Storage mechanism (DS) require special coordination with respect to
3308 On-request Data.
Master Port 1 2
Port
Port 3
MasterIdentification PortConfiguration Port 4
ReadBackConfiguration
PortStatus
DSToParServ
ParServToDS
PDIn
PDOut
PDInOut
PDInIQ
PDOutIQ
PDReadbackOutIQ
DeviceWrite
Key DeviceRead
Attribute/property ParamWriteBatch
ParamReadBatch
Method/function
PortPowerOffOn
Event DeviceEvent
PortEvent
3311
3313 Each object comes with attributes and methods that can be accessed by SMI services. Both,
3314 SMI services and attributes/methods/events are specified in the following clause 11.2.
SMI_ReadbackPortConfiguration
SMI_MasterIdentification
SMI_PDReadbackOutIQ
SMI_ParamReadBatch
SMI_ParamWriteBatch
SMI_PortConfiguration
SMI_PortPowerOffOn
SMI_DSToParServ
SMI_ParServToDS
SMI_DeviceEvent
SMI_DeviceRead
SMI_DeviceWrite
SMI_PortStatus
SMI_PortEvent
SMI_PDOutIQ
SMI_PDInOut
SMI_PDInIQ
SMI_PDOut
SMI_PDIn
Standardized Master Interface (SMI)
Configuration Manager Data Storage On-request Data Exchange Diagnosis Unit Process Data Exchange
SM_GetPortConfig
SM_SetPortConfig
AL_SetOutput
AL_NewInput
AL_PDCycle
SIO:
AL_GetInput
SM_PortMode
AL_Control
DI / DO
AL_Event
SM_Operate
AL_Read
AL_Abort
AL_Write
NC
DI / DO
+
Specific
On-request Data Process Data
AL_Read AL
Port x Handler objects objects
3319
3321 Communication interfaces such as Fieldbus, OPC UA, JSON, UDP or alike are responsible to
3322 provide access to the SMI services. It is mandatory for upper level communication systems to
3323 refer to the SMI definitions in their adaptations. Functionality behind SMI is mandatory unless
3324 it is specifically declared as optional.
3325 Table 105 lists the SMI services available to gateway applications or other clients.
Key
I Initiator of service R Receiver (Responder) of service
M Mandatory O Optional C Conditional
3327
3331 ClientID
3332 Gateway Applications may use the SMI services concurrently as clients of the SMI (see
3333 11.2.3). Thus, SMI services will assign a unique ClientID to each individual client. It is the
3334 responsibility of the Gateway Application(s) to coordinate these SMI service activities and to
3335 route responses to the calling client. The maximum number of concurrent clients is Master
3336 specific.
3366 Pairs of ExpArgBlock/RefArgBlock and ArgBlockID within one SMI structure shall be unique.
3367 Detailed coding of the ArgBlocks is specified in Annex E. ArgBlock types and their
3368 ArgBlockIDs are defined in Table E.1. Service errors are listed at each individual service and
3369 in C.4.
IO-Link Interface and System © IO-Link – 167 – Version 1.1.3
3372 • All SMI services with different PortNumber access different port objects (disjoint opera-
3373 tions);
3374 • Different SMI services using the same PortNumber access different attributes/methods of
3375 a port object (concurrent operations);
3376 • Identical SMI services using the same PortNumber and different ClientIDs access identical
3377 attributes concurrently (consistency).
3378 The following rules apply for SMI services when accessing methods:
3379 • SMI services for methods using different PortNumbers access different port objects
3380 (disjoint operations);
3381 • SMI services for methods using the same PortNumber and different ClientIDs create job
3382 instances and will be processed in the order of their arrival ( n Client concurrency);
3383 • SMI_ParamWriteBatch (ArgBlock "DeviceBatch") shall be treated as a job instance that
3384 shall not be interrupted by any SMI_DeviceWrite or SMI_DeviceRead service.
3385 Prioritization of SMI services within the Standardized Master Interface is not performed. All
3386 services accessing methods will be processed in the order of their arrival (first come, first
3387 serve).
Argument M
ClientID M
PortNumber (0x00) M
ExpArgBlockID (e.g. 0x0001) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
Result (+) S
ClientID M
PortNumber (0x00) M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber (0x00) M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3398
3399 Argument
3400 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3401 ClientID
3402 PortNumber
3403 This parameter contains a virtual Port addressing the entire Master unit (0x00)
Version 1.1.3 – 168 – IO-Link Interface and System © IO-Link
3404 ExpArgBlockID
3405 This parameter contains an ArgBlockID of the MasterIdent family, e.g. 0x0001 (see Table
3406 E.1)
3407 ArgBlockLength
3408 This parameter contains the length of the "VoidBlock" ArgBlock
3409 ArgBlock
3410 This parameter contains the ArgBlock "VoidBlock" (0xFFF0, see Annex E.17)
3411 Result (+):
3412 This selection parameter indicates that the service request has been executed successfully.
3413 ClientID
3414 PortNumber
3415 RefArgBlockID
3416 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3417 ArgBlockLength
3418 This parameter contains the length of the subsequent ArgBlock
3419 ArgBlock
3420 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Table E.2 )
3421 Result (-):
3422 This selection parameter indicates that the service request failed
3423 ClientID
3424 PortNumber
3425 RefArgBlockID
3426 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3427 ArgBlockLength
3428 This parameter contains the length of the "JobError" ArgBlock
3429 ArgBlock
3430 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18
3431 Permitted values in prioritized order (see Table C.3):
3432 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
3433 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
3434 11.2.5 SMI_PortConfiguration
3435 With the help of this service, an SMI client such as a gateway application launches the indi-
3436 cated Master port and the connected Device using the elements in parameter PortConfigList.
3437 The service shall be accepted immediately and performed without delay. Content of Data
3438 Storage for that port will be deleted at each new port configuration via "DS_Delete" (see
3439 Figure 99). Table 107 shows the structure of the service. The ArgBlock usually is different in
3440 SDCI Extensions such as safety and wireless and specified there (see [10] and [11]).
Argument M
ClientID M
PortNumber M
ExpArgBlockID (VoidBlock: 0xFFF0) M
ArgBlockLength M
ArgBlock (e.g. 0x8000) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x8000) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
IO-Link Interface and System © IO-Link – 169 – Version 1.1.3
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x8000) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3442
3443 Argument
3444 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3445 ClientID
3446 PortNumber
3447 ExpArgBlockID
3448 This parameter contains the ArgBlockID "VoidBlock" (0xFFF0, see Annex E.17)
3449 ArgBlockLength
3450 This parameter contains the length of the subsequent ArgBlock to be "pushed"
3451 ArgBlock
3452 This parameter contains an ArgBlock of the PortConfigList family, e.g. 0x8000 (see Table
3453 E.1)
3454 Result (+):
3455 This selection parameter indicates that the service request has been executed successfully.
3456 ClientID
3457 PortNumber
3458 RefArgBlockID
3459 This parameter contains as reference the ID of the ArgBlock sent by the request (0x8000)
3460 ArgBlockLength
3461 This parameter contains the length of the subsequent ArgBlock
3462 ArgBlock
3463 This parameter contains the ArgBlock associated to the ExpArgBlockID (0xFFF0)
3464 Result (-):
3465 This selection parameter indicates that the service request failed
3466 ClientID
3467 PortNumber
3468 RefArgBlockID
3469 This parameter contains as reference the ID of the ArgBlock sent by the request (0x8000)
3470 ArgBlockLength
3471 This parameter contains the length of the "JobError" ArgBlock
3472 ArgBlock
3473 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
3474 Permitted values in prioritized order:
3475 PORT_NUM_INVALID (incorrect Port number)
3476 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
3477 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
3478 ARGBLOCK_INCONSISTENT (incorrect ArgBlock content type)
3479 11.2.6 SMI_ReadbackPortConfiguration
3480 This service allows for retrieval of the effective configuration of the indicated Master port.
3481 Table 108 shows the structure of the service. This service usually is different in SDCI
3482 Extensions such as safety and wireless (see [10] and [11]).
Version 1.1.3 – 170 – IO-Link Interface and System © IO-Link
Argument
ClientID M
PortNumber M
ExpArgBlockID (e.g. 0x8000) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3484
3485 Argument
3486 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3487 ClientID
3488 PortNumber
3489 ExpArgBlockID
3490 This parameter contains an ArgBlockID of the PortConfigList family, e.g. 0x8000 (see
3491 Table E.1)
3492 ArgBlockLength
3493 This parameter contains the length of the "VoidBlock" ArgBlock
3494 ArgBlock
3495 This parameter contains the ArgBlock "VoidBlock" (0xFFF0, see Annex E.17)
3496 Result (+):
3497 This selection parameter indicates that the service request has been executed successfully.
3498 ClientID
3499 PortNumber
3500 RefArgBlockID
3501 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3502 ArgBlockLength
3503 This parameter contains the length of the subsequent ArgBlock
3504 ArgBlock
3505 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Annex E.3)
3506 Result (-):
3507 This selection parameter indicates that the service request failed
3508 ClientID
3509 PortNumber
3510 RefArgBlockID
3511 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3512 ArgBlockLength
3513 This parameter contains the length of the "JobError" ArgBlock
3514 ArgBlock
3515 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
IO-Link Interface and System © IO-Link – 171 – Version 1.1.3
Argument
ClientID M
PortNumber M
ExpArgBlockID (e.g. 0x9000) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3525
3526 Argument
3527 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3528 ClientID
3529 PortNumber
3530 ExpArgBlockID
3531 This parameter contains an ArgBlockID of the PortStatusList family, e.g. 0x9000 (see
3532 Table E.1)
3533 ArgBlockLength
3534 This parameter contains the length of the "VoidBlock" ArgBlock
3535 ArgBlock
3536 This parameter contains the ArgBlock "VoidBlock" (0xFFF0, see Annex E.17)
3537 Result (+):
3538 This selection parameter indicates that the service request has been executed successfully.
3539 ClientID
3540 PortNumber
3541 RefArgBlockID
3542 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3543 ArgBlockLength
3544 This parameter contains the length of the subsequent ArgBlock
3545 ArgBlock
3546 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Annex E.4)
3547 Result (-):
3548 This selection parameter indicates that the service request failed
Version 1.1.3 – 172 – IO-Link Interface and System © IO-Link
3549 ClientID
3550 PortNumber
3551 RefArgBlockID
3552 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3553 ArgBlockLength
3554 This parameter contains the length of the "JobError" ArgBlock
3555 ArgBlock
3556 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
3557 Permitted values in prioritized order:
3558 PORT_NUM_INVALID (incorrect Port number)
3559 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
3560 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
3561 11.2.8 SMI_DSToParServ
3562 With the help of this service, an SMI client such as a gateway application is able to retrieve
3563 the technology parameter set of a Device from Data Storage and back it up within an upper
3564 level parameter server (see Figure 95, clauses 11.4, and 13.4.2). Table 110 shows the
3565 structure of the service.
3566 In case of DI or DO on this Port, content of Data Storage is cleared. The same applies if Data
3567 Storage is not enabled for this Port.
Argument
ClientID M
PortNumber M
ExpArgBlockID (0x7000) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3569
3570 Argument
3571 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3572 ClientID
3573 PortNumber
3574 ExpArgBlockID
3575 This parameter contains the ArgBlockID 0x7000 (see Table E.1)
3576 ArgBlockLength
3577 This parameter contains the length of the "VoidBlock" ArgBlock
3578 ArgBlock
3579 This parameter contains the ArgBlock "VoidBlock" (0xFFF0, see Annex E.17)
3580 Result (+):
3581 This selection parameter indicates that the service request has been executed successfully.
IO-Link Interface and System © IO-Link – 173 – Version 1.1.3
3582 ClientID
3583 PortNumber
3584 RefArgBlockID
3585 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3586 ArgBlockLength
3587 This parameter contains the length of the subsequent ArgBlock
3588 ArgBlock
3589 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Annex E.6)
3590 Result (-):
3591 This selection parameter indicates that the service request failed
3592 ClientID
3593 PortNumber
3594 RefArgBlockID
3595 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3596 ArgBlockLength
3597 This parameter contains the length of the "JobError" ArgBlock
3598 ArgBlock
3599 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
3600 Permitted values in prioritized order:
3601 PORT_NUM_INVALID (incorrect Port number)
3602 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
3603 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
3604 11.2.9 SMI_ParServToDS
3605 With the help of this service, an SMI client such as a gateway application is able to restore
3606 the technology parameter set of a Device within Data Storage from an upper level parameter
3607 server (see Figure 95, clauses 11.4, and 13.4.2). Table 111 shows the structure of the ser-
3608 vice.
3609 In case of DI or DO on this Port, content of Data Storage is cleared. The same applies if Data
3610 Storage is not enabled for this Port.
Argument
ClientID M
PortNumber M
ExpArgBlockID (VoidBlock: 0xFFF0) M
ArgBlockLength M
ArgBlock (0x7000) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x7000) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x7000) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3612
3613 Argument
3614 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
Version 1.1.3 – 174 – IO-Link Interface and System © IO-Link
3615 ClientID
3616 PortNumber
3617 ExpArgBlockID
3618 This parameter contains the ArgBlockID "VoidBlock" (0xFFF0, see Annex E.17)
3619 ArgBlockLength
3620 This parameter contains the length of the subsequent ArgBlock to be "pushed"
3621 ArgBlock
3622 This parameter contains the ArgBlock DS_Data (0x7000, see Table E.1)
3623 Result (+):
3624 This selection parameter indicates that the service request has been executed successfully.
3625 ClientID
3626 PortNumber
3627 RefArgBlockID
3628 This parameter contains as reference the ID of the ArgBlock sent by the request (0x7000)
3629 ArgBlockLength
3630 This parameter contains the length of the subsequent ArgBlock
3631 ArgBlock
3632 This parameter contains the ArgBlock associated to the ExpArgBlockID
3633 Result (-):
3634 This selection parameter indicates that the service request failed
3635 ClientID
3636 PortNumber
3637 RefArgBlockID
3638 This parameter contains as reference the ID of the ArgBlock sent by the request (0x7000)
3639 ArgBlockLength
3640 This parameter contains the length of the "JobError" ArgBlock
3641 ArgBlock
3642 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18
3643
Argument
ClientID M
PortNumber M
ExpArgBlockID (VoidBlock: 0xFFF0) M
ArgBlockLength M
ArgBlock (0x3000) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x3000) M
ArgBlockLength M
ArgBlock (associated to the ExpArgBlockID) M
IO-Link Interface and System © IO-Link – 175 – Version 1.1.3
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x3000) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3653
3654 Argument
3655 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3656 ClientID
3657 PortNumber
3658 ExpArgBlockID
3659 This parameter contains the ArgBlockID "VoidBlock" (0xFFF0, see Annex E.17)
3660 ArgBlockLength
3661 This parameter contains the length of the subsequent ArgBlock to be "pushed
3662 ArgBlock
3663 This parameter contains the ArgBlock "On-requestData" (0x3000, see Table E.1)
3664 Result (+):
3665 This selection parameter indicates that the service request has been executed successfully.
3666 ClientID
3667 PortNumber
3668 RefArgBlockID
3669 This parameter contains as reference the ID of the ArgBlock sent by the request (0x3000)
3670 ArgBlockLength
3671 This parameter contains the length of the subsequent ArgBlock
3672 ArgBlock
3673 This parameter contains the ArgBlock associated to the ExpArgBlockID
3674 Result (-):
3675 This selection parameter indicates that the service request failed
3676 ClientID
3677 PortNumber
3678 RefArgBlockID
3679 This parameter contains as reference the ID of the ArgBlock sent by the request (0x3000)
3680 ArgBlockLength
3681 This parameter contains the length of the "JobError" ArgBlock
3682 ArgBlock
3683 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18
3684 Permitted values in prioritized order:
3685 PORT_NUM_INVALID (incorrect Port number)
3686 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
3687 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
3688 ARGBLOCK_INCONSISTENT (incorrect ArgBlock content type)
3689 SERVICE_TEMP_UNAVAILABLE (Master busy)
3690 DEVICE_NOT_ACCESSIBLE (Device not communicating)
3691 Device ErrorType (See Annex C.2 and C.3)
3692 11.2.11 SMI_DeviceRead
3693 This service allows for reading On-request Data (OD) from the Device via the Master. Table
3694 113 shows the structure of the service.
Version 1.1.3 – 176 – IO-Link Interface and System © IO-Link
Argument
ClientID M
PortNumber M
ExpArgBlockID (0x3000) M
ArgBlockLength M
ArgBlock ("On-request Data/Index": 0x3001) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x3001) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x3001) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3696
3697 Argument
3698 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3699 ClientID
3700 PortNumber
3701 ExpArgBlockID
3702 This parameter contains the ArgBlockID of "On-requestData" (0x3000, see Table E.1)
3703 ArgBlockLength
3704 This parameter contains the length of the subsequent ArgBlock
3705 ArgBlock
3706 This parameter contains the ArgBlock "On-requestData/Index" (0x3001, see Annex E.5)
3707 Result (+):
3708 This selection parameter indicates that the service request has been executed successfully.
3709 ClientID
3710 PortNumber
3711 RefArgBlockID
3712 This parameter contains as reference the ID of the ArgBlock sent by the request (0x3001)
3713 ArgBlockLength
3714 This parameter contains the length of the subsequent ArgBlock
3715 ArgBlock
3716 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Table E.5)
3717
3720 ClientID
3721 PortNumber
3722 RefArgBlockID
3723 This parameter contains as reference the ID of the ArgBlock sent by the request (0x3001)
3724 ArgBlockLength
3725 This parameter contains the length of the "JobError" ArgBlock
3726 ArgBlock
3727 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18
IO-Link Interface and System © IO-Link – 177 – Version 1.1.3
3739 • The service transfers the ArgBlock "DeviceParBatch" to the Master that conveys the
3740 content object by object to the Device via AL_Write (ISDU).
3741 • The same ArgBlock structure is returned as Result (+). However, a value "0x0000"
3742 indicates success of a particular AL_Write or an ISDU ErrorType of a failed AL_Write
3743 instead of a parameter record.
3744 • Result (-) is only returned in case of a failing service via "JobError".
3745 NOTE1 This service supposes use of Block Parameterization and sufficient buffer ressources
3746 NOTE2 This service may have unexpected duration
3747 This service is optional. Availability is indicated via Master identification (see Table E.2)
Argument
ClientID M
PortNumber M
ExpArgBlockID (VoidBlock: 0xFFF0) M
ArgBlockLength M
ArgBlock ("DeviceParBatch": 0x7001) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x7001) M
ArgBlockLength M
ArgBlock (associated to the ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x7001) M
ArgBlockLength M
ArgBlock (JobError: 0xFFF) M
3749
3750 Argument
3751 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3752 ClientID
3753 PortNumber
3754 ExpArgBlockID
3755 This parameter contains the ArgBlockID "VoidBlock" (0xFFF0, see Annex E.17)
3756 ArgBlockLength
3757 This parameter contains the length of the subsequent ArgBlock to be "pushed"
3758 ArgBlock
3759 This parameter contains the ArgBlock "DeviceParBatch" (0x7001, see Table E.1)
3760 Result (+):
3761 This selection parameter indicates that the service request has been executed successfully.
Version 1.1.3 – 178 – IO-Link Interface and System © IO-Link
3762 ClientID
3763 PortNumber
3764 RefArgBlockID
3765 This parameter contains as reference the ID of the ArgBlock sent by the request (0x7001)
3766 ArgBlockLength
3767 This parameter contains the length of the subsequent ArgBlock
3768 ArgBlock
3769 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Table E.7)
3770
3773 ClientID
3774 PortNumber
3775 RefArgBlockID
3776 This parameter contains as reference the ID of the ArgBlock sent by the request (0x7001)
3777 ArgBlockLength
3778 This parameter contains the length of the "JobError" ArgBlock
3779 ArgBlock
3780 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
3781 Permitted values in prioritized order:
3782 SERVICE_NOT_SUPPORTED (Service unknown)
3783 PORT_NUM_INVALID (incorrect Port number)
3784 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
3785 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
3786 ARGBLOCK_INCONSISTENT (incorrect ArgBlock content type)
3787 MEMORY_OVERRUN (insufficient memory)
3788 SERVICE_TEMP_UNAVAILABLE (Master busy)
3789 DEVICE_NOT_ACCESSIBLE (Device not communicating)
3790 11.2.13 SMI_ParamReadBatch
3791 This service allows for the "pull" transfer of a large number of consistent Device parameters
3792 via multiple ISDUs. Table 114 shows the structure of the service. The following rules apply:
3793 • The service transfers the ArgBlock "IndexList" to the Master that transforms the content
3794 entry by entry into AL_Read (ISDU) to the Device.
3795 • The corresponding ArgBlock "DeviceParBatch is returned as Result (+). In case of a
3796 successful AL_Read of an object, the corresponding parameter record or an ISDU
3797 ErrorType of a failed AL_Read instead of a parameter record is returned.
3798 • Result (-) is only returned in case of a failing service via "JobError".
3799 NOTE1 This service supposes use of Block Parameterization and sufficient buffer ressources
3800 NOTE2 This service may have unexpected duration
3801 This service is optional. Availability is indicated via Master identification (see Table E.2)
Argument
ClientID M
PortNumber M
ExpArgBlockID ("DeviceParBatch": 0x7001) M
ArgBlockLength M
ArgBlock ("IndexList": 0x7002) M
Result (+) S
ClientID M
PortNumber M
IO-Link Interface and System © IO-Link – 179 – Version 1.1.3
3803
3804 Argument
3805 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3806 ClientID
3807 PortNumber
3808 ExpArgBlockID
3809 This parameter contains the ArgBlockID of "DeviceParBatch" (0x7001, see Table E.1)
3810 ArgBlockLength
3811 This parameter contains the length of the ArgBlock "IndexList"
3812 ArgBlock
3813 This parameter contains the ArgBlock "IndexList" (0x7002, see Table E.1)
3814 Result (+):
3815 This selection parameter indicates that the service request has been executed successfully.
3816 ClientID
3817 PortNumber
3818 RefArgBlockID
3819 This parameter contains as reference the ID of the ArgBlock sent by the request (0x7002)
3820 ArgBlockLength
3821 This parameter contains the conditional length of the subsequent ArgBlock
3822 ArgBlock
3823 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Table E.7)
3824
3827 ClientID
3828 PortNumber
3829 RefArgBlockID
3830 This parameter contains as reference the ID of the ArgBlock sent by the request (0x7002)
3831 ArgBlockLength
3832 This parameter contains the length of the "JobError" ArgBlock
3833 ArgBlock
3834 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
3835 Permitted values in prioritized order:
3836 SERVICE_NOT_SUPPORTED (Service unknown)
3837 PORT_NUM_INVALID (incorrect Port number)
3838 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
3839 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
3840 ARGBLOCK_INCONSISTENT (incorrect ArgBlock content type)
3841 MEMORY_OVERRUN (insufficient memory)
3842 SERVICE_TEMP_UNAVAILABLE (Master busy)
3843 DEVICE_NOT_ACCESSIBLE (Device not communicating)
Version 1.1.3 – 180 – IO-Link Interface and System © IO-Link
Argument
ClientID M
PortNumber M
ExpArgBlockID (VoidBlock: 0xFFF0) M
ArgBlockLength M
ArgBlock ("PortPowerOffOn": 0x7003) M
Result (+) S
ClientID M
PortNumber M
ExpArgBlockID (ID of request ArgBlock 0x7003) M
ArgBlockLength M
ArgBlock (associated to the ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
ExpArgBlockID (ID of request ArgBlock 0x7003) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3848
3849 Argument
3850 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3851 ClientID
3852 PortNumber
3853 ExpArgBlockID
3854 This parameter contains the ArgBlockID "VoidBlock" (0xFFF0, see Annex E.17)
3855 ArgBlockLength
3856 This parameter contains the length of the subsequent ArgBlock to be "pushed"
3857 ArgBlock
3858 This parameter contains the ArgBlock "PortPowerOffOn" (0x7003, see Table E.1)
3859 Result (+):
3860 This selection parameter indicates that the service request has been executed successfully.
3861 ClientID
3862 PortNumber
3863 RefArgBlockID
3864 This parameter contains as reference the ID of the ArgBlock sent by the request (0x7003)
3865 ArgBlockLength
3866 This parameter contains the length of the subsequent ArgBlock
3867 ArgBlock
3868 This parameter contains the ArgBlock associated to the ExpArgBlockID (0xFFF0)
3869 Result (-):
3870 This selection parameter indicates that the service request failed
3871 ClientID
3872 PortNumber
3873 RefArgBlockID
3874 This parameter contains as reference the ID of the ArgBlock sent by the request (0x7003)
3875 ArgBlockLength
3876 This parameter contains the length of the "JobError" ArgBlock
IO-Link Interface and System © IO-Link – 181 – Version 1.1.3
3877 ArgBlock
3878 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
3879 Permitted values in prioritized order:
3880 PORT_NUM_INVALID (incorrect Port number)
3881 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
3882 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
3883 ARGBLOCK_INCONSISTENT (incorrect ArgBlock content type)
3884 SERVICE_TEMP_UNAVAILABLE (Master busy)
3885 11.2.15 SMI_DeviceEvent
3886 This service allows for signaling a Master Event created by the Device. Table 117 shows the
3887 structure of the service.
Argument
ClientID (= "0" Broadcast) M
PortNumber M
ExpArgBlockID (VoidBlock: 0xFFF0) M
ArgBlockLength M
ArgBlock ("DeviceEvent": 0xA000) M
Acknowledgment S
ClientID (= "0") M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xA000) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
3889
3890 Argument
3891 The specific parameters of this indication are transmitted in the argument (see 11.2.2).
3892 ClientID
3893 For this indication, the ClientID shall be "0" ("broadcast" to upper level system)
3894 PortNumber
3895 ExpArgBlockID
3896 This parameter contains the ArgBlockID "VoidBlock" (0xFFF0, see Annex E.17)
3897 ArgBlockLength
3898 This parameter contains the length of the reported ArgBlock 0xA000
3899 ArgBlock
3900 This parameter contains the ArgBlock "DeviceEvent" (0xA000, see Table E.1)
3901 Acknowlegment
3902 This selection parameter indicates that the service request has been executed successfully.
3903 ClientID
3904 The ClientID shall be "0"
3905 PortNumber
3906 RefArgBlockID
3907 This parameter contains as reference the ID of the ArgBlock sent by the request (0xA000)
3908 ArgBlockLength
3909 This parameter contains the length of the subsequent ArgBlock
3910 ArgBlock
3911 This parameter contains the ArgBlock associated to the ExpArgBlockID (0xFFF0)
3912 11.2.16 SMI_PortEvent
3913 This service allows for signaling a Master Event created by the Port. Table 118 shows the
3914 structure of the service.
Version 1.1.3 – 182 – IO-Link Interface and System © IO-Link
Argument
ClientID (= "0" Broadcast) M
PortNumber M
ExpArgBlockID (VoidBlock: 0xFFF0) M
ArgBlockLength M
ArgBlock (PortEvent: 0xA001) M
Acknowledgment S
ClientID (= "0") M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xA001) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
3916
3917 Argument
3918 The specific parameters of this indication are transmitted in the argument (see 11.2.2).
3919 ClientID
3920 For this indication, the ClientID shall be "0" ("broadcast" to upper level system)
3921 PortNumber
3922 ExpArgBlockID
3923 This parameter contains the ArgBlockID "VoidBlock" (0xFFF0, see Annex E.17)
3924 ArgBlockLength
3925 This parameter contains the length of the reported ArgBlock 0xA001
3926 ArgBlock
3927 This parameter contains the ArgBlock "PortEvent" (0xA001, see Table E.1)
3928 Acknowlegment
3929 This selection parameter indicates that the service request has been executed successfully.
3930 ClientID
3931 The ClientID shall be "0"
3932 PortNumber
3933 RefArgBlockID
3934 This parameter contains as reference the ID of the ArgBlock sent by the request (0xA001)
3935 ArgBlockLength
3936 This parameter contains the length of the subsequent ArgBlock
3937 ArgBlock
3938 This parameter contains the ArgBlock associated to the ExpArgBlockID (0xFFF0)
3939 11.2.17 SMI_PDIn
3940 This service allows for cyclically reading input Process Data from an InBuffer (see 11.7.2.1).
3941 Table 119 shows the structure of the service. This service usually has companion services in
3942 SDCI Extensions such as safety and wireless (see [10] and [11]).
Argument
ClientID M
PortNumber M
ExpArgBlockID (e.g. 0x1001) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
IO-Link Interface and System © IO-Link – 183 – Version 1.1.3
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3944
3945 Argument
3946 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3947 ClientID
3948 PortNumber
3949 ExpArgBlockID
3950 This parameter contains an ArgBlockID of the Process Data family, e.g. 0x1001 (see Table
3951 E.1)
3952 ArgBlockLength
3953 This parameter contains the length of the "VoidBlock" ArgBlock
3954 ArgBlock
3955 This parameter contains the ArgBlock "VoidBlock" (0xFFF0, see Annex E.17)
3956 Result (+):
3957 This selection parameter indicates that the service request has been executed successfully.
3958 ClientID
3959 PortNumber
3960 RefArgBlockID
3961 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3962 ArgBlockLength
3963 This parameter contains the length of the subsequent ArgBlock
3964 ArgBlock: PDIn
3965 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Annex E.10)
3966
3969 ClientID
3970 PortNumber
3971 RefArgBlockID
3972 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
3973 ArgBlockLength
3974 This parameter contains the length of the "JobError" ArgBlock
3975 ArgBlock
3976 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
3977 Permitted values in prioritized order:
3978 PORT_NUM_INVALID (incorrect Port number)
3979 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
3980 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
3981 DEVICE_NOT_IN_OPERATE (Process Data not accessible)
Version 1.1.3 – 184 – IO-Link Interface and System © IO-Link
Argument
ClientID M
PortNumber M
ExpArgBlockID (VoidBlock: 0xFFF0) M
ArgBlockLength M
ArgBlock (e.g. 0x1002) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x1002) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x1002) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
3987
3988 Argument
3989 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
3990 ClientID
3991 PortNumber
3992 ExpArgBlockID
3993 This parameter contains the ArgBlockID "VoidBlock" (0xFFF0, see Annex E.17)
3994 ArgBlockLength
3995 This parameter contains the length of the subsequent ArgBlock to be "pushed"
3996 ArgBlock
3997 This parameter contains ArgBlock of the Process Data family, e.g. 0x1002 (see Table E.1)
3998 Result (+):
3999 This selection parameter indicates that the service request has been executed successfully.
4000 ClientID
4001 PortNumber
4002 RefArgBlockID
4003 This parameter contains as reference the ID of the ArgBlock sent by the request (0x1002)
4004 ArgBlockLength
4005 This parameter contains the length of the subsequent ArgBlock
4006 ArgBlock
4007 This parameter contains the ArgBlock associated to the ExpArgBlockID (0xFFF0)
4008 Result (-):
4009 This selection parameter indicates that the service request failed
4010 ClientID
4011 PortNumber
4012 RefArgBlockID
4013 This parameter contains as reference the ID of the ArgBlock sent by the request (0x1002)
4014 ArgBlockLength
IO-Link Interface and System © IO-Link – 185 – Version 1.1.3
Argument
ClientID M
PortNumber M
ExpArgBlockID (e.g. 0x1003) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
4030
4031 Argument
4032 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
4033 ClientID
4034 PortNumber
4035 ExpArgBlockID
4036 This parameter contains an ArgBlockID of the "Process Data" family, e.g. 0x1003 (see
4037 Table E.1)
4038 ArgBlockLength
4039 This parameter contains the length of the subsequent ArgBlock
4040 ArgBlock
4041 This parameter contains the ArgBlock "VoidBlock" (0xFFF0, see Annex E.17)
4042 Result (+):
4043 This selection parameter indicates that the service request has been executed successfully.
4044 ClientID
4045 PortNumber
4046 RefArgBlockID
4047 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
4048 ArgBlockLength
Version 1.1.3 – 186 – IO-Link Interface and System © IO-Link
4055 ClientID
4056 PortNumber
4057 RefArgBlockID
4058 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
4059 ArgBlockLength
4060 This parameter contains the length of the "JobError" ArgBlock
4061 ArgBlock
4062 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
4063 Permitted values in prioritized order:
4064 PORT_NUM_INVALID (incorrect Port number)
4065 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
4066 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
4067 DEVICE_NOT_IN_OPERATE (Process Data not accessible)
4068 11.2.20 SMI_PDInIQ
4069 This service allows for cyclically reading input Process Data from an InBuffer (see 11.7.2.1)
4070 containing the value of the input "I" signal (Pin 2 at M12). Table 122 shows the structure of
4071 the service.
Argument
ClientID M
PortNumber M
ExpArgBlockID (e.g. 0x1FFE) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
4073
4074 Argument
4075 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
4076 ClientID
4077 PortNumber
4078 ExpArgBlockID
4079 This parameter contains an ArgBlockID of the "Process Data" family, e.g. 0x1FFE (see
4080 Table E.1)
4081 ArgBlockLength
4082 This parameter contains the length of the subsequent ArgBlock
IO-Link Interface and System © IO-Link – 187 – Version 1.1.3
4083 ArgBlock
4084 This parameter contains the ArgBlock "VoidBlock" (0xFFF0, see Annex E.17)
4085 Result (+):
4086 This selection parameter indicates that the service request has been executed successfully.
4087 ClientID
4088 PortNumber
4089 RefArgBlockID
4090 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
4091 ArgBlockLength
4092 This parameter contains the length of the subsequent ArgBlock
4093 ArgBlock
4094 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Annex E.13)
4095
4098 ClientID
4099 PortNumber
4100 RefArgBlockID
4101 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
4102 ArgBlockLength
4103 This parameter contains the length of the "JobError" ArgBlock
4104 ArgBlock
4105 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
4106 Permitted values in prioritized order:
4107 SERVICE_NOT_SUPPORTED (Service unknown)
4108 PORT_NUM_INVALID (incorrect Port number)
4109 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
4110 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
4111 11.2.21 SMI_PDOutIQ
4112 This service allows for cyclically writing output Process Data to an OutBuffer (see 11.7.3.1)
4113 containing the value of the output "Q" signal (Pin 2 at M12). Table 123 shows the structure of
4114 the service.
Argument
ClientID M
PortNumber M
ExpArgBlockID (VoidBlock: 0xFFF0) M
ArgBlockLength M
ArgBlock (e.g. 0x1FFF) M
Result (+) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x1FFF) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
RefArgBlockID (ID of request ArgBlock 0x1FFF) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
4116
Version 1.1.3 – 188 – IO-Link Interface and System © IO-Link
4117 Argument
4118 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
4119 ClientID
4120 PortNumber
4121 ExpArgBlockID
4122 This parameter contains the ArgBlockID "VoidBlock" (0xFFF0, see Annex E.17)
4123 ArgBlockLength
4124 This parameter contains the length of the subsequent ArgBlock to be "pushed"
4125 ArgBlock
4126 This parameter contains an ArgBlock of the "Process Data" family, e.g. 0x1FFF (see Table
4127 E.1)
4128 Result (+):
4129 This selection parameter indicates that the service request has been executed successfully.
4130 ClientID
4131 PortNumber
4132 RefArgBlockID
4133 This parameter contains as reference the ID of the ArgBlock sent by the request (0x1FFF)
4134 ArgBlockLength
4135 This parameter contains the length of the subsequent ArgBlock
4136 ArgBlock
4137 This parameter contains the ArgBlock associated to the ExpArgBlockID (0xFFF0)
4138 Result (-):
4139 This selection parameter indicates that the service request failed
4140 ClientID
4141 PortNumber
4142 RefArgBlockID
4143 This parameter contains as reference the ID of the ArgBlock sent by the request (0x1FFF
4144 ArgBlockLength
4145 This parameter contains the length of the "JobError" ArgBlock
4146 ArgBlock
4147 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
4148 Permitted values in prioritized order:
4149 SERVICE_NOT_SUPPORTED (Service unknown)
4150 PORT_NUM_INVALID (incorrect Port number)
4151 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
4152 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
4153 ARGBLOCK_INCONSISTENT (incorrect ArgBock content type)
4154 11.2.22 SMI_PDReadbackOutIQ
4155 This service allows for cyclically reading back input Process Data from an OutBuffer (see
4156 11.7.3.1) containing the value of the output "Q" signal (Pin 2 at M12). Table 124 shows the
4157 structure of the service.
Argument
ClientID M
PortNumber M
ExpArgBlockID (e.g. 0x1FFF) M
ArgBlockLength M
ArgBlock (VoidBlock: 0xFFF0) M
IO-Link Interface and System © IO-Link – 189 – Version 1.1.3
Result (+) S
ClientID M
PortNumber M
ExpArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (associated to ExpArgBlockID) M
Result (-) S
ClientID M
PortNumber M
ExpArgBlockID (ID of request ArgBlock 0xFFF0) M
ArgBlockLength M
ArgBlock (JobError: 0xFFFF) M
4159
4160 Argument
4161 The specific parameters of the service request are transmitted in the argument (see 11.2.2).
4162 ClientID
4163 PortNumber
4164 ExpArgBlockID
4165 This parameter contains an ArgBlockID of the "Process Data" family, e.g. 0x1FFF (see
4166 Table E.1)
4167 ArgBlockLength
4168 This parameter contains the length of the subsequent ArgBlock
4169 ArgBlock
4170 This parameter contains the ArgBlock "VoidBlock" (0xFFF0, see Annex E.17)
4171 Result (+):
4172 This selection parameter indicates that the service request has been executed successfully.
4173 ClientID
4174 PortNumber
4175 RefArgBlockID
4176 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
4177 ArgBlockLength
4178 This parameter contains the length of the subsequent ArgBlock
4179 ArgBlock: PDOutIQ
4180 This parameter contains the ArgBlock associated to the ExpArgBlockID (see Annex E.14)
4181
4184 ClientID
4185 PortNumber
4186 RefArgBlockID
4187 This parameter contains as reference the ID of the ArgBlock sent by the request (0xFFF0)
4188 ArgBlockLength
4189 This parameter contains the length of the "JobError" ArgBlock
4190 ArgBlock
4191 This parameter contains the ArgBlock "JobError" (0xFFFF, see Annex E.18)
4192 Permitted values in prioritized order:
4193 SERVICE_NOT_SUPPORTED (Service unknown)
4194 PORT_NUM_INVALID (incorrect Port number)
4195 ARGBLOCK_NOT_SUPPORTED (ArgBlock unknown)
4196 ARGBLOCK_LENGTH_INVALID (incorrect ArgBlock length)
Version 1.1.3 – 190 – IO-Link Interface and System © IO-Link
SMI_PDReadbackOutIQ
SMI_ParamWriteBatch
SMI_PortConfiguration
SMI_ParamReadBatch
SMI_PortPowerOffOn
SMI_DSToParServ
SMI_ParServToDS
SMI_DeviceEvent
SMI_DeviceRead
SMI_DeviceWrite
SMI_PortStatus
SMI_PortEvent
SMI_PDOutIQ
SMI_PDInOut
SMI_PDInIQ
SMI_PDOut
SMI_PDIn
Standardized Master Interface (SMI)
DS_Startup OD_Block
DS_Ready OD_Unblock DS_UPLOAD
DS_Fault On-request Process
Configuration Data Diagnosis
Data Data
Manager DS_Delete Storage Unit
Exchange Exchange
(CM) DS_Change (DS) ODE_Start/ (DU)
Stop (ODE) DU_Start/ (PDE)
Stop
PDE_Start/
Stop
AL_Control
SM-Services AL_Write AL_Read AL_Write AL_Read AL_Event AL_Event AL_PD-Services
(response) (Indication)
4202
4204 Internal variables and Events controlling Master applications are listed in Table 125.
4205 Table 125 – Internal variables and Events controlling Master applications
DS_Startup This variable triggers the Data Storage (DS) state machine causing an Upload
or Download of Device parameters if required (see 11.4).
DS_Ready This variable indicates the Data Storage has been accomplished successfully;
operating mode is CFGCOM or AUTOCOM (see 9.2.2.2)
DS_Fault This variable indicates the Data Storage has been aborted due to a fault.
DS_Delete Any verified change of Device configuration leads to a deletion of the stored
data set in the Data Storage.
DS_Change This variable indicates a content change of Data Storage triggered by service
SMI_ParServToDS.
DS_Upload This variable triggers the Data Storage state machine in the Master due to the
special Event "DS_UPLOAD_REQ" from the Device.
OD_Start This variable enables On-request Data access via AL_Read and AL_Write.
OD_Stop This variable indicates that On-request Data access via AL_Read and AL_Write
is acknowledged with a negative response to the gateway application.
OD_Block Data Storage upload and download actions disable the On-request Data access
through AL_Read or AL_Write. Access by the gateway application is denied.
OD_Unblock This variable enables On-request Data access via AL_Read or AL_Write.
DU_Start This variable enables the Diagnosis Unit to propagate remote (Device) Events
to the gateway application.
IO-Link Interface and System © IO-Link – 191 – Version 1.1.3
DU_Stop This variable indicates that the Device Events are not propagated to the
gateway application and not acknowledged. Available Events are blocked until
the DU is enabled again.
PD_Start This variable enables the Process Data exchange with the gateway application.
PD_Stop This variable disables the Process Data exchange with the gateway application.
4206
4208 • SMI_PortConfiguration service (Port parameter setting and start-up or changes and restart
4209 of a port)
4210 • SMI_ParServToDS service (Download of Data Storage data if Data Storage is activated)
4211
4216 CM uses the values of ArgBlock "PortConfigList", initializes the port start-up in case of value
4217 changes and empties the Data Storage via "DS_Delete" or checks emptiness (see Figure 99).
4218 A gateway application can poll the actual port state via "SMI_PortStatus" to check whether the
4219 expected port state is reached. In case of fault this service provides corresponding
4220 information.
4221 After successfully setting up the port, CM starts the Data Storage mechanism and returns via
4222 parameter element "PortStatusInfo" either "OPERATE" or "PORT_FAULT" to the gateway
4223 application.
4224 In case of "OPERATE", CM activates the state machines of the associated Master applica-
4225 tions Diagnosis Unit (DU), On-request Data Exchange (ODE), and Process Data Exchange
4226 (PDE).
4230 Figure 100 illustrates the start-up of a port via SMI_ PortConfiguration service in a sequence
4231 diagram.
Version 1.1.3 – 192 – IO-Link Interface and System © IO-Link
SMI_PortConfiguration(
Port, PortConfigList) SM_SetPortConfig(CFGCOM)
Start-up of port.
SM_PortMode(COMREADY)
Parameter in
"PortConfigList"
DS_Startup()
OD_Block()
Gateway access
Data Storage to On-request
active: Data disabled
Download,
upload, none
OD_Unblock()
DS_Ready()
SM_Operate()
DS_Upload()
4232
4234
4240 Configuration Manager can receive information COMLOST from Port x Handler through
4241 "SM_PortMode" at any time.
4242 On the other hand, it can receive a service "SMI_PortConfiguration" from the gateway
4243 application with changed values in "PortConfigList" also at any time (see 11.2.5).
4244 It can also receive a Data Storage object with a changed parameter set via service
4245 "SMI_ParServToDS" from the gateway application triggering action in the Configuration
4246 Manager if Data Storage is activated.
/Initialization
Port_Deactived_8 [DO_CQ]/T10
[DEACTIVATED]/T11 CheckPortMode_0 Port_DIDO_6
do ModeCheck [DI_CQ]/T9
[Unknown]/T16
ConfigManager_7
SM_PortMode_
COMLOST/ DS_Change[IOL_MANUAL
T8 and DS_Active]/T14
SM_Startup_1
Port x handler sent
SM_PortMode_xFAULT/T4
SM_PortMode with
COMLOST
PortFault_3 SM_PortMode_COMREADY/
T3
DS_Fault/T6 DS_ParamManager_2
DS_Ready/
T5
WaitingOnOperate_4
SM_PortMode_OPERATE/
T7
Port_Active_5
Key
xFAULT: REV_FAULT or COMP_FAULT or SERNUM_FAULT or CYCTIME_FAULT
4248
4250 Table 126 shows the state transition tables of the Configuration Manager.
4254
4255 State "CheckPortMode_0" contains an activity with complex logic for checking the Port mode
4256 within a received Port configuration (see Table E.3). Figure 102 shows this activity within the
4257 context of the state machine in Figure 101.
[DEACTIVATED]
D1 DEACTIVATED (T11)
[Else]
[DI_CQ]
D2 DI_CQ (T9)
[Else]
[DO_CQ]
D3 DO_CQ (T10)
[Else]
[IOL_AUTOCOM]
D4 IOL_AUTOCOM (T2)
[Else]
[IOL_MANUAL]
D5 IOL_MANUAL (T1)
[Else]
Unknown (T16)
4258
4269 The Master shall always hold the header information (Parameter Checksum, VendorID, and
4270 DeviceID) for the purpose of checking and control. The object information (objects 1… n ) will
4271 be stored within the non-volatile memory part of the Master (see Annex G). Prior to a down-
4272 load of the Data Storage data object (parameter block), the Master will check the consistency
4273 of the header information with the particular Device.
4274 The maximum permitted size of the Data Storage data object is 2 x 2 10 octets. It is mandatory
4275 for Masters to provide at least this memory space per port if the Data Storage mechanism is
4276 implemented.
4280 In return, gateways are also able to write a port's current Data Storage object into the Master
4281 using the service "SMI_ParServToDS" (see 11.2.9). This causes under certain conditions an
4282 implicit restart of the Device and activation of the parameters within the Device (see 11.3.2).
4287 Figure 103 shows the state machine of the Data Storage mechanism.
/Initialization
[DS_Enabled &
NoCOMx]/
T8 DS_Delete/
T10
[DS_Enabled]/T1
DS_Cleared/
T11
[DS_Ready]/T3
enex_1 enex_2
DS_Disabled/
[DS_Fault]/T5 T12
[DS_Delete]/
T9
DS_Startup/T2
4288
4289 Figure 103 – Main state machine of the Data Storage mechanism
IO-Link Interface and System © IO-Link – 197 – Version 1.1.3
4294 This submachine can be invoked by the Data Storage mechanism or during runtime triggered
4295 by a "DS_UPLOAD_REQ" Event.
UpDownload_2
[Not passed]/T15
CheckIdentity_4
[Passed]/
T16
[Not passed]/T17
CheckMemSize_5
[Passed]/
T18
[DS_UPLOAD_Flag & UploadEnable]/
[Data Storage locked]/T29 T19
CheckUpload_6
enex_3
[DS_Valid]/
T22
enex_4
CheckChecksum_9
[Upload done]/
T26
enex_5 enex_6
4296
4299 This state machine can be invoked by the Data Storage mechanism or during runtime
4300 triggered by a DS_UPLOAD_REQ Event.
Version 1.1.3 – 198 – IO-Link Interface and System © IO-Link
Upload_7
[Data read]/T31
4301
4303 Figure 106 demonstrates the Data Storage upload sequence using the DataStorageIndex
4304 (DSI) specified in B.2.3 and Table B.10. The structure of Index_List is specified in Table B.11.
4305 The DS_UPLOAD_FLAG shall be reset at the end of each sequence (see Table B.10).
Master Device
Data Data
Storage Storage
Header
Entry X1 AL_Read(DSI: Index_List, Entry X1)
Response(Content of Entry X1)
...
Entry Xn AL_Read(DSI: Index_List, Entry Xn)
Response(Content of Entry Xn)
Data Storage
memory
AL_Read(DSI: Index 3, Subindex 4)
...
Response(Parameter Checksum)
0x00
AL_Write(DSI: Index 3, Subindex 1, DS_UploadEnd) 15
Response(+)
Reset
DS_UPLOAD_FLAG
4306
4309 This state machine can be invoked by the Data Storage mechanism.
IO-Link Interface and System © IO-Link – 199 – Version 1.1.3
Download_10
[Remaining data]/T37
Write_Parameter_18 Decompose_Set_17
[Write done]/T38
[Data completed]/
[Device_Error]/ [COMx_ERROR]/ T41
T39 T40
Download_Fault_20 Download_Done_19
[COMx_ERROR]/
T42
4310
4312
4313 Figure 108 demonstrates the Data Storage download sequence using the DataStorageIndex
4314 (DSI) specified in B.2.3 and Table B.10. The structure of Index_List is specified in Table B.11.
4315 The DS_UPLOAD_FLAG shall be reset at the end of each sequence (see Table B.10).
Master Device
Data Data
Storage Storage
231
AL_Write(DSI: Index 3, Subindex 1, DS_DownloadStart)
Response(+) Index 0...65535,
232 octets/index
maximum
Header
Entry X1 AL_Write(DSI: Index_List, Entry X1)
Response(+)
...
Entry Xn
AL_Write(DSI: Index_List, Entry Xn)
Data Storage Response(+)
memory
0x00
AL_Read(DSI: Index 3, Subindex 4) 15
Response(Parameter Checksum)
4316
4318 Table 127 shows the states and transitions of the Data Storage state machines.
4319 Table 127 – States and transitions of the Data Storage state machines
CheckActivationState_0 Check current state of the DS configuration: Independently from communication status,
DS_Startup from configuration management or an Event DS_UPLOAD_REQ is
expected.
Version 1.1.3 – 200 – IO-Link Interface and System © IO-Link
WaitingOnDSActivity_1 Waiting for upload request, Device startup, all changes of activation state independent
of the Device communication state.
UpDownload_2 Submachine for up/download actions and checks
Off_3 Data Storage handling switched off or deactivated
SM: CheckIdentity_4 Check Device identification (DeviceID, VendorID) against parameter set within the Data
Storage (see Table G.2). Empty content does not lead to a fault.
SM: CheckMemSize_5 Check data set size (Index 3, Subindex 3) against available Master storage size
SM: CheckUpload_6 Check for DS_UPLOAD_FLAG within the DataStorageIndex (see Table B.10)
SM: Upload_7 Submachine for the upload actions
SM: CheckDSValidity_8 Check whether stored data within the Master is valid or invalid. A Master could be
replaced between upload and download activities. It is the responsibility of a Master
designer to implement a validity mechanism according to the chosen use cases
SM: CheckChecksum_9 Check for differences between the data set content and the Device parameter via the
"Parameter Checksum" within the DataStorageIndex (see Table B.10)
SM: Download_10 Submachine for the download actions
SM: DS_Ready_11 Prepare DS_Ready indication to the Configuration Management (CM)
SM: DS_Fault_12 Prepare DS_Fault indication from "Identification_Fault", "SizeCheck_Fault",
"Upload_Fault", and "Download_Fault" to the Configuration Management (CM)
SM: Decompose_IL_13 Read Index List within the DataStorageIndex (see Table B.10). Read content entry by
entry of the Index List from the Device (see Table B.11).
SM: ReadParameter_14 Wait until read content of one entry of the Index List from the Device is accomplished.
SM: StoreDataSet_15 Task of the gateway application: store entire data set according to Table G.1 and Table
G.2
SM: Upload_Fault_16 Prepare Upload_Fault indication from "Device_Error" and "COM_ERROR" as input for
the higher-level indication DS_Fault.
SM: Decompose_Set_17 Write parameter by parameter of the data set into the Device according to Table G.1.
SM: Write_Parameter_18 Wait until write of one parameter of the data set into the Device is accomplished.
SM: Download_Done_19 Download completed. Read back "Parameter Checksum" from the DataStorageIndex
according to Table B.10. Save this value in the stored data set according to Table G.2.
SM: Download_Fault_20 Prepare Download_Fault indication from "Device_Error" and "COM_ERROR" as input
for the higher-level indication DS_Fault.
4320
TRANSITION SOURCE TARGET ACTION
STATE STATE
T1 0 1 ‒
T2 1 2 ‒
T3 2 1 OD_Unblock; Indicate DS_Ready to CM
T4 1 2 Confirm Event "DS_Upload" (see INTERNAL ITEMS)
T5 2 1 DS_Break (AL_Write, Index 3, Subindex 1); clear intermediate data
(garbage collection); rollback to previous parameter state; DS_Fault (see
Figure 98); OD_Unblock.
T6 3 2 ‒
T7 0 3 ‒
T8 3 1 ‒
T9 1 1 Clear saved parameter set (see Table G.1 and Table G.2)
T10 3 3 Clear saved parameter set (see Table G.1 and Table G.2)
T11 1 3 Clear saved parameter set (see Table G.1 and Table G.2)
T12 1 3 ‒
T13 3 3 Confirm Event "DS_Upload" (see INTERNAL ITEMS); no further action
T14 3 3 DS_Ready to CM
IO-Link Interface and System © IO-Link – 201 – Version 1.1.3
4322
4325 The IODD marks all parameters not included in Data Storage with the attribute "exclu-
4326 dedFromDataStorage". However, the Data Storage mechanism shall not consider the infor-
4327 mation from the IODD but rather the Parameter List read out from the Device.
4331 The gateway application is able to read On-request Data (OD) from the Device via the service
4332 "SMI_DeviceRead". This service is directly mapped to service AL_Read with Port, Index, and
4333 Subindex (see 8.2.2.1).
4334 The gateway application is able to write On-request Data (OD) to the Device via the service
4335 "SMI_DeviceWrite". This service is directly mapped to service AL_Write with Port, Index, and
4336 Subindex (see 8.2.2.2).
4337 During an active data transmission of the Data Storage mechanism, all On-request Data re-
4338 quests are blocked.
/Initialization SMI_DeviceRW/T1
Inactive_0
OD_Start/ OD_Stop/
T2 T3
SMI_DeviceRW/T4 SMI_DeviceRW/T6
OD_Block/T5
ODactive_1 ODblocked_2
OD_Unblock/T7
4339
4341 Table 128 shows the state transition table of the On-request Data Exchange state machine.
4342 Table 128 – State transition table of the ODE state machine
SMI_DeviceRW Variable On-request Data read or write requested via SMI_DeviceRead, SMI_De-
viceWrite, SMI_ParamWriteBatch, or SMI_ParamReadBatch
4345
4352 Additionally, the DU generates a Device or port specific diagnosis status that can be retrieved
4353 by the SMI_PortStatus service in PortStatusList (see Table E.4 and 11.6.4).
4359 Device diagnosis information flooding is avoided by flow control as shown in Figure 110,
4360 which allows for only one Event per Device to be propagated via SMI_DeviceEvent to the
4361 gateway application at a time.
AL_Event_req()
AL_Event_ind()
SMI_DeviceEvent_ind()
SMI_DeviceEvent_rsp()
AL_Event_rsp()
AL_Event_cnf()
4362
PortEvent_ind()
SMI_PortEvent_ind()
4369
4372 • It is not required to send disappearing Port Events in case of Device communication
4373 interrupt (communication restart);
4374 • Once communication resumed, the gateway client is responsible for proper reporting of
4375 the current Event causes.
4376 Port specific Events are specified in Annex D.3.
4383 After COMLOST and during Device startup the buffer will be deleted.
Port 1 … Port n
IODD
Device Device file
IODD defined Events
Application Application
IODD IODD
4400
4401 NOTE Blue shaded areas indicate features specified in this standard
4402 Figure 112 – SDCI diagnosis information propagation via Events
4407 The Standard Master Interface (SMI) comes with the following three services for the gateway
4408 application:
4409 • SMI_PDIn allows for reading input Process Data from the InBuffer together with Quality
4410 Information (PQI), see 11.2.17
4411 • SMI_PDOut allows for writing output Process Data to the OutBuffer, see 11.2.18
4412 • SMI_PDInOut allows for reading output Process Data from the OutBuffer and reading input
4413 Process Data from the InBuffer within one cycle, see 11.2.19
4414 After an established communication and Data Storage, the port is ready for any On-request
4415 Data (ODE) transfers. Process Data exchange is enabled whenever the specific port or all
4416 ports are switched to the OPERATE mode.
4423 A gateway application can get access to these data via the service "SMI_PDIn" (see 11.2.17).
4424 Figure 113 illustrates the principles of Process Data Input mapping and the content of the
4425 ArgBlock of this service (see E.10) consisting of the ArgBlockID, the qualifier PQI, the
4426 parameter InputDataLength, and the input Process Data.
Version 1.1.3 – 206 – IO-Link Interface and System © IO-Link
InBuffer
n
Input data
InputDataLength
Process Data In
AL_GetInput
(input data)
ArgBlockLength
SMI_PDIn
(Process Data In) Get signal status
C/Q
DI_
0 (DI_C/Q)
InputDataLength
PQI AL_Control
PQ
7 PQI 0
(PDin valid, invalid)
Key ArgBlockID=0x1001
PQ Port Qualifier
PQI Port Qualifier Information Bit 7 Bit 0
4427
4429 At state OPERATE the input data are cyclicly copied into the InBuffer starting at offset "4".
4430 The InBuffer is expanded by an octet "PQI" at offset "2", whose content shall be updated
4431 anytime the input data are read. Figure 114 illustrates the structure of this octet.
Dev- Dev-
PQ Err Com Reserved
Bit 7 Bit 0
4432
4439 It will be set if a Device is detected and in PREOPERATE or OPERATE state. It will be reset if
4440 there is no Device available.
4442 Parameter "PortStatusInfo" and "DiagEntry x "of service "SMI_PortStatus" provide the neces-
4443 sary information for this bit.
4444 It will be set if an Error or Warning occurred assigned to either Device or port. It will be reset
4445 if there is no Error or Warning.
4447 A value VALID for Process Data in service "AL_CONTROL" will set this bit.
4448 A value INVALID or PortStatusInfo <> "4" (see E.4) will reset this bit.
4459 A gateway application can write data via the service "SMI_PDOut" into the OutBuffer (see
4460 11.2.18). Figure 115 illustrates the principles of Process Data Output mapping and the
4461 content of the ArgBlock of this service (see E.11) consisting of the ArgBlockID, the Output
4462 Enable bit, the parameter OutputDataLength, and the output Process Data.
4463 An ErrorType 0x4034 – Incorrect ArgBlock length will be returned if length does not add up to
4464 Process Data Out plus four octets (see C.4.9).
OutBuffer
Output data
OutputDataLength
SMI_PDOut
(Process Data Out) Set signal
DO_
C/Q
(DO_C/Q)
OutputDataLength
AL_Control
detect
OE
OE
(PDout valid, invalid)
Key ArgBlockID=0x1002
OE Output Enable
OE detect Output Enable detection Bit 7 Bit 0
4465
4467 At state OPERATE the Process Data Out are cyclicly copied to output data starting at offset
4468 "3".
4469 The OutBuffer is expanded by an octet "OE" (Output Enable) at offset "2". Bit 0 indicates the
4470 validity of the Process Data Out. "0" means invalid, "1" means valid data. A change of this Bit
4471 from "0" to "1" will launch an AL_Control with "PDout valid". A change of this Bit from "1" to
4472 "0" will launch an AL_Control with "PDout invalid". See "OE detect" in Figure 115.
AL_Control_req()
(PDOUTINVALID) DL_Control_req()
(PDOUTINVALID) Message()
(MasterCommand
DL_Control_ind()
"DeviceOperate")
(PDOUTINVALID) AL_Control_ind()
(PDOUTINVALID)
Output PD
Input PD
AL_Control_req()
DL_Control_req()
(INVALID)
Message(CKS) (INVALID)
Message(CKS)
... AL_Control_req()
DL_Control_req() (VALID)
Message(CKS) (VALID)
AL_Control_ind() (VALID)
(VALID)
4480
4481 Figure 116 – Propagation of PD qualifier status between Master and Device
4482 The Master informs the Device about the output Process Data qualifier status "valid/invalid"
4483 by sending MasterCommands (see Table B.2) to the Direct Parameter page 1 (see 7.3.7.1).
4484 For input Process Data the Device sends the Process Data qualifier status in every single
4485 message as "PD status" flag in the Checksum / Status (CKS) octet (see A.1.5) of the Device
4486 message. A sample transmission of the input PD qualifier status "valid" from Device AL to
4487 Master AL is shown in the lower section of Figure 116.
4488 Any perturbation while in interleave transmission mode leads to an input or output Process
4489 Data qualifier status "invalid" indication respectively.
4500 tion, or other tools. The scenarios and associated preconditions are described in the following
4501 clauses.
4502 12.2.2 Preconditions for the activation of the Data Storage mechanism
4503 The following preconditions shall be observed prior to the usage of Data Storage:
4504 a) Data Storage is only available for Devices and Masters implemented according to this
4505 document (≥ V1.1).
4506 b) The Inspection Level of that Master port, the Device is connected to shall be adjusted to
4507 "type compatible" (corresponds to "TYPE_COMP" within Table 80)
4508 c) The Backup Level of that Master port, the Device is connected to shall be either
4509 "Backup/Restore" or "Restore", which corresponds to DS_Enabled in 11.4.4. See 12.4
4510 within this document for details on Backup Level.
4511 12.2.3 Preconditions for the types of Devices to be replaced
4512 After activation of a Backup Level (Data Storage mechanism) a "faulty" Device can be
4513 replaced by a type equivalent or compatible other Device. In some exceptional cases, for
4514 example non-calibrated Devices, a user manipulation can be required such as teach-in, to
4515 guarantee the same functionality and performance.
4516 Thus, two classes of Devices exist in respect to exchangeability, which shall be described in
4517 the user manual of the particular Device:
4519 The configured Device supports Data Storage in such a manner that the replacement Device
4520 plays the role of its predecessor fully automatically and with the same performance.
4522 The configured Device supports Data Storage in such a manner that the replacement Device
4523 requires user manipulation such as teach-in prior to operation with the same performance.
4524 The Data Storage class shall be described in the user manual of the Device. Device designer
4525 is responsible in case of class 2 to prevent from dangerous system restart after Device
4526 replacement, at least via descriptions within the user manual.
Parameter
PLC / Host server
(Master backup
parameter)
Master
4533 A replacement of the Device in operation will result in overwriting the active parameter set
4534 with the backup parameters in the newly connected Device.
4547 The USB-Master tool will mark the parameter set after configuration, parameterization, and
4548 validation (to become "active") via DS_UPLOAD_FLAG (see Table 130 and Table B.10). After
4549 installation into the machine/facility these parameters are uploaded (copied) automatically into
4550 the Data Storage within the Master (backup).
"USB Master"
Tool software
IODD
Parameter Test
Device
4551
4563 These adjustment possibilities lead for example to drop-down menu entries for "Backup Le-
4564 vel".
Commissioning Master port: Activation state: "DS_Cleared" Any change of active parameters within the
("Disable") Device will not be copied/saved.
Device replacement without automatic/semi-
automatic Data Storage.
Production Master port: Activation state: "DS_Enabled" Changes of active parameters within the
("Backup/Restore") Master port: UploadEnable Device will be copied/saved.
Master port: DownloadEnable Device replacement with automatic/semi-
automatic Data Storage supported.
Production Master port: Activation state: "DS_Enabled" Any change of active parameters within the
("Restore") Master port: UploadDisable Device will not be copied/saved. If the
parameter set is marked to be saved, the
Master port: DownloadEnable "frozen" parameters will be restored by the
Master.
However, Device replacement with auto-
matic/semi-automatic Data Storage of
"frozen" parameters is supported.
4571 • For (legacy) Devices according to [8] or Devices according to this document where the
4572 Port is preset to Inspection Level "NO_CHECK", only the Backup Level "Commissioning"
4573 shall be supported. This should also be the default presetting in this case.
4574 • For Devices according to this document where the Port is preset to Inspection Level
4575 "TYPE_COMP" all three Backup Levels shall be supported. Default presetting in this case
4576 should be "Backup/Restore".
4577 The following clauses describe the phases in detail.
4589 Criteria for the particular copy activities are listed in Table 130. These criteria are the condi-
4590 tions to trigger a copy process of the active parameters to the backup parameters, thus
4591 ensuring the consistency of these two sets.
Commissioning session Parameterization of the Device via Master Master tool sends ParamDownloadStore;
(see 12.3.1) tool (on-line). Transfer of active Device sets "DS_UPLOAD_FLAG" and
parameter(s) to the Device will cause then triggers upload via "DS_UPLOAD_-
backup activity. REQ" Event. "DS_UPLOAD_FLAG" is
reset as soon as the upload is comple-
ted.
Switching from commis- Restart of Port and Device because Port During system startup, the "DS_UP-
sioning to production configuration has been changed LOAD_FLAG" triggers upload (copy).
"DS_UPLOAD_FLAG" is reset as soon
as the upload is completed
Local modifications Changes of the active parameters through Device technology application sets
teach-in or local parameterzation at the "DS_UPLOAD_FLAG" and then triggers
Version 1.1.3 – 212 – IO-Link Interface and System © IO-Link
4593
4598 Any changes of the active parameters through teach-in, tool based parameterization, or local
4599 parameterization will lead to a Data Storage Event, and State Property "DS_UPLOAD_FLAG"
4600 will be set in the Device.
4601 In back-up level Production ("Restore") the Master shall ignore this flag and shall issue a
4602 DS_Download to overwrite the changed parameters.
4603 Criteria for the particular copy activities are listed in Table 131. These criteria are the condi-
4604 tions to trigger a copy process of the active parameters to the backup parameters, thus
4605 ensuring the consistency of these two sets.
Change port configura- Change of port configuration via Master Change of port configuration triggers
tion tool (on-line): e.g. Configured VendorID "DS_Delete" followed by an upload
(CVID), Configured DeviceID (CDID), see (copy) to Data Storage (see 13.4.1,
11.4.4 11.3.1 and 11.4.4).
4607
4631 e) Set port configurations: amongst others the Backup Level to "Backup/Restore" or "Re-
4632 store"
4633 f) Master "reset to factory settings": clear backup parameters of all ports within the Data
4634 Storage in case it is not a new Master out of the box
4635 g) Active parameters of all Devices are automatically uploaded (copied) to Data Storage
4636 (backup)
4637 12.5.3.3 Fieldbus support (comfort level)
4638 Any kind of fieldbus specific mechanism to back up the Master parameter set including the
4639 Data Storage of all Devices is used. Even though these fieldbus mechanisms are similar to
4640 the IO-Link approach, they are following their certain paradigm which may conflict with the
4641 described paradigm of the IO-Link back up mechanism (see Figure 117).
4645 This top down concept may conflict with the active parameter setting within the Devices.
4651 Following the concept of 12.5.3.4, after supply of the Master by the PLC, the Master can
4652 supply the Devices.
4653 13 Integration
4654 13.1 Generic Master model for system integration
4655 Figure 119 shows the integration relevant excerpt of Figure 95. Basis is the Standardized
4656 Master Interface (SMI), which is specified in an abstract manner in 11.2. It transforms SDCI
4657 objects into services and objects appropriate for the upper level systems such as embedded
4658 controllers, IT systems (JSON), fieldbuses and PLCs, engineering systems, as well as
4659 universal Master Tools (PDCT) for Masters of different brands.
Version 1.1.3 – 214 – IO-Link Interface and System © IO-Link
4660 It is an objective of this SMI to achieve uniform behavior of Masters of different brands from a
4661 user's point of view. Another objective is to provide a stringent specification for organizations
4662 developing integration specifications into their systems without administrative overhead.
4663 In Figure 119, the green marked items are areas of responsibility of fieldbus organizations
4664 and their integration specifications. The blue marked items are areas of responsibility of IT
4665 organizations and their specifications. The red marked items are areas of responsibility of
4666 individual automation equipment manufacturers. The white marked item ("Gateway manage-
4667 ment") represents a coordination layer for the different gateway applications. A corresponding
4668 specification is elaborated by a joint working group [12].
Parameter Engineering:
Internet, IT, PLC/FS-PLC/OPC-UA
server - configuration,
Browser - parameterization,
Fieldbus Fieldbus controller
- process data
integration - diagnosis,
- identification &
Ethernet maintenance
e.g. XML, JSON
Master Tool:
Fieldbus interface UDP (PDCT/IODD):
Webserver OPC-UA
- identification
Gateway Client a: Client b: Gateway Client c: Gateway Client d: - configuration,
management Embedded Application (GA) Application (GA) GA - parameterization,
Standardized Master Interface (SMI) - process data
- diagnosis
4669
4676 Gateway applications such as shown in Figure 119 include but are not limited to:
4677 • Pure coding tasks of the abstract SMI services, for example for embedded controllers;
4678 • Comfortable webserver providing text and data for standard browsers using for example
4679 XML, JSON;
4680 • OPC-UA server used for parameterization and data exchange via IT applications; security
4681 solutions available;
4682 • Adapters with a fieldbus interface for programmable logic controllers (PLCs) and human
4683 machine interfaces based on OPC-UA;
4684 • Adapters for a User Datagram Protocol (UDP) to connect engineering tools.
4685 13.2.2 Coordination
4686 It is the responsibility of gateway applications to prevent from access conflicts such as
4687 • Different clients to one Device
4688 • Concurrent tasks for one Device, for example prevent from SystemCommand "Restore
4689 factory settings" while Block Parameterization is running.
4690
Gateway Master_SMI
PDCT Application
SMI_MasterIdentification(Port x)
SMI_DeviceWrite(Port x, ParamStart)
Transfer para- SMI_DeviceWrite(Port x, Index, Subindex, data)
meter to SMI_DeviceWrite(Port x, Index, Subindex, data)
Device
SMI_DeviceWrite(Port x, ParamEnd)
SMI_DeviceWrite(Port x, ParamDownloadStore)
SMI_DeviceRead(Port x, ParamStart)
Retrieve para-
SMI_DeviceRead(Port x, Index, Subindex, data)
meter from
Device SMI_DeviceRead(Port x, Index, Subindex, data)
SMI_DeviceRead(Port x, ParamEnd)
4719
4723
4725 The PDCT display should always provide a navigation window for a project or a network
4726 topology, a window for the particular view on a chosen Device that is defined by its IODD, and
4727 a window for the available Devices based on the installed IODD files.
4729
4732 Annex A
4733 (normative)
4734
4735 Codings, timing constraints, and errors
4736 A.1 General structure and encoding of M-sequences
4737 A.1.1 Overview
4738 The general concept of M-sequences is outlined in 7.3.3.2. Subclauses A.1.2 to A.1.6 provide
4739 a detailed description of the individual elements of M-sequences.
Communication
R/W channel Address
Bit 7 Bit 0
4745
Value Definition
0 Process
1 Page
2 Diagnosis
3 ISDU
4756 Bit 7: R/W
4757 This bit indicates the transmission direction of the user data on the selected communication
4758 channel, i.e. read access (transmission of user data from Device to Master) or write access
4759 (transmission of user data from Master to Device). The defined values for the R/W parameter
4760 are listed in Table A.2.
Value Definition
0 Write access
1 Read access
4762 A Device is not required to support each and every of the 256 values of the M-sequence
4763 control octet. For read access to not implemented addresses or communication channels the
4764 value "0" shall be returned. A write access to not implemented addresses or communication
4765 channels shall be ignored.
Version 1.1.3 – 218 – IO-Link Interface and System © IO-Link
M-sequence
type Checksum
Bit 7 Bit 0
4769
Value Definition
0 Type 0
1 Type 1
2 Type 2 (see NOTE)
3 reserved
4779
4786 The detailed coding of the data types can be found in Annex F.
Event PD
flag status Checksum
Bit 7 Bit 0
4791
4799 This PD status flag shall be used for Devices with input Process Data. Devices with output
4800 Process Data shall always indicate "Process Data valid".
4801 If the PD status flag is set to “Process Data invalid” within a message, all the input Process
4802 Data of the complete Process Data cycle are invalid.
Value Definition
Value Definition
0 No Event
1 Event
4811
4823 A seed value of 0x52 is used for the checksum calculation across the message. It is XORed
4824 with the first octet of the message (MC).
Version 1.1.3 – 220 – IO-Link Interface and System © IO-Link
MC +
CKT XOR Checksum 8
processing
...
Message + + + +
Checksum 6
Octet n
4825
4827 The set of equations in (A.1) define the compression procedure from 8 to 6 bit in detail.
4834 Within SDCI, M-sequences provide the access to the communication channels via the M-
4835 sequence Control octet. The number of different M-sequence types meets the various
4836 requirements of sensors and actuators regarding their Process Data width. See Figure 39 for
4837 an overview of the available M-sequence types that are specified in A.2.2 to A.2.5. See A.2.6
4838 for rules on how to use the M-sequence types.
TYPE_0
TYPE_1_1
4847
4849 Two octets of Process Data are read or written per cycle. Address (bit offset) belongs to the
4850 process communication channel (see A.2.1).
4851 In case of interleave mode (see 7.3.4.2) and odd-numbered PD length the remaining octets
4852 within the messages are padded with 0x00.
4853 M-sequence TYPE_1_2 is shown in Figure A.7. Two octets of On-request Data are read or
4854 written per cycle.
TYPE_1_2
4857 M-sequence TYPE_1_V providing variable (extendable) message length is shown in Figure
4858 A.8. A number of m octets of On-request Data are read or written per cycle.
4859 When accessing octets via page and diagnosis communication channels using an M-
4860 sequence TYPE with multi-octet ODs, the following rules apply:
4861 • At write access, only the first octet (OD 0 ) of On-request Data is relevant. The Master shall
4862 send all subsequent ODs filled with "0x00". Any Device shall evaluate only the first octet
4863 of ODs and ignore the remaining octets.
4864 • At read access, the Device shall return the first relevant data octet as OD 0 and all
4865 subsequent ODs filled with either "0x00" or with subsequent data octets if appropriate.
4866 Master shall evaluate only the octet in OD 0 .
4867
Version 1.1.3 – 222 – IO-Link Interface and System © IO-Link
TYPE_1_V
4868
4878 M-sequence TYPE_2_1 transmits one octet of read Process Data and one octet of read or
4879 write On-request Data per cycle. This M-sequence type is shown in Figure A.9.
TYPE_2_1
4882 M-sequence TYPE_2_2 transmits 2 octets of read Process Data and one octet of On-request
4883 Data per cycle. This M-sequence type is shown in Figure A.10.
TYPE_2_2
4886 M-sequence TYPE_2_3 transmits one octet of write Process Data and one octet of read or
4887 write On-request Data per cycle. This M-sequence type is shown in Figure A.11.
IO-Link Interface and System © IO-Link – 223 – Version 1.1.3
TYPE_2_3
4890 M-sequence TYPE_2_4 transmits 2 octets of write Process Data and one octet of read or
4891 write On-request Data per cycle. This M-sequence type is shown in Figure A.12
TYPE_2_4
4892
4894 M-sequence TYPE_2_5 transmits one octet of write and read Process Data and one octet of
4895 read or write On-request Data per cycle. This M-sequence type is shown in Figure A.13.
TYPE_2_5
4898 M-sequence TYPE_2_V transmits the entire write (read) ProcessDataIn n (k) octets per cycle.
4899 The range of n (k) is 0 to 32. Either PDin or PDout are not existing when n = 0 or k = 0.
4900 TYPE_2_V also transmits m octets of (segmented) read or write On-request Data per cycle
4901 using the address in Figure A.1. Permitted values for m are 1, 2, 8, and 32. This variable M-
4902 sequence type is shown in Figure A.14.
Version 1.1.3 – 224 – IO-Link Interface and System © IO-Link
TYPE_2_V
Master read
message MC CKT PD0 PDn-1
Master write
message MC CKT PD0 PDn-1 OD0 ODm-1
4905 When using M-sequence TYPE with multi-octet ODs, the rules of M-sequence TYPE_1_V
4906 apply (see Figure A.8).
4909 A.2.6 M-sequence type usage for STARTUP, PREOPERATE and OPERATE modes
4910 Table A.7 lists the M-sequence types for the STARTUP mode together with the minimum
4911 recovery time (T initcyc ) that shall be observed for Master implementations (see A.3.9). The M-
4912 sequence code refers to the coding in B.1.4.
4914
4915 Table A.8 lists the M-sequence types for the PREOPERATE mode together with the minimum
4916 recovery time (T initcyc ) that shall be observed for Master implementations.
0b 1 TYPE_0 100
1 2 TYPE_1_2 100
2 8 TYPE_1_V 210
3 32 TYPE_1_V 550
NOTE a The minimum recovery time in PREOPERATE mode is a requirement for the Master
NOTE b It is highly recommended for Devices not to use TYPE_0 thus improving error discovery
when Master restarts communication
4918
4919 Table A.9 lists the M-sequence types for the OPERATE mode for legacy Devices. The
4920 minimum cycle time for Master in OPERATE mode is specified by the parameter
4921 "MinCycleTime" of the Device (see B.1.3).
IO-Link Interface and System © IO-Link – 225 – Version 1.1.3
4922 Table A.9 – M-sequence types for the OPERATE mode (legacy protocol)
0 1 0 0 TYPE_0 NOTE
1 2 0 0 TYPE_1_2
don't care 2 3…32 octets 0…32 octets TYPE_1_1/1_2 (interleaved)
don't care 2 0…32 octets 3…32 octets TYPE_1_1/1_2 (interleaved)
don't care 1 1…8 bit 0 TYPE_2_1
don't care 1 9…16 bit 0 TYPE_2_2
don't care 1 0 1…8 bit TYPE_2_3
don't care 1 0 9…16 bit TYPE_2_4
don't care 1 1…8 bit 1…8 bit TYPE_2_5
NOTE It is highly recommended for Devices not to use TYPE_0 thus improving error discovery
when Master restarts communication
4923
4924 Table A.10 lists the M-sequence types for the OPERATE mode for Devices according to this
4925 specification. The minimum cycle time for Master in OPERATE mode is specified by the
4926 parameter MinCycleTime of the Device (see B.1.3).
0 1 0 0 TYPE_0 NOTE 1
1 2 0 0 TYPE_1_2
6 8 0 0 TYPE_1_V
7 32 0 0 TYPE_1_V
0 1 1…8 bit 0 TYPE_2_1
0 1 9…16 bit 0 TYPE_2_2
0 1 0 1…8 bit TYPE_2_3
0 1 0 9…16 bit TYPE_2_4
0 1 1…8 bit 1…8 bit TYPE_2_5
0 1 9…16 bit 1…16 bit TYPE_2_V NOTE 2
0 1 1…16 bit 9…16 bit TYPE_2_V NOTE 2
4 1 0…32 octets 3…32 octets TYPE_2_V
4 1 3…32 octets 0…32 octets TYPE_2_V
5 2 >0 bit, octets ≥0 bit, octets TYPE_2_V
5 2 ≥0 bit, octets >0 bit, octets TYPE_2_V
6 8 >0 bit, octets ≥0 bit, octets TYPE_2_V
6 8 ≥0 bit, octets >0 bit, octets TYPE_2_V
7 32 >0 bit, octets ≥0 bit, octets TYPE_2_V
7 32 ≥0 bit, octets >0 bit, octets TYPE_2_V
NOTE1 It is highly recommended for Devices not to use TYPE_0 thus improving error discovery
when Master restarts communication
NOTE2 Former TYPE_2_6 has been replaced in support of TYPE_2_V due to inefficiency.
Version 1.1.3 – 226 – IO-Link Interface and System © IO-Link
0 ≤ t 1 ≤ 1 T BIT (A.3)
0 ≤ t 2 ≤ 3 T BIT (A.4)
4953 In this formula, m is the number of UART frames sent by the port to the Device and n is the
4954 number of UART frames sent by the Device to the port. The formula can only be used for
4955 estimates as the times t 1 and t 2 may not be constant.
4956 Figure A.15 demonstrates the timings of an M-sequence consisting of a Master (port)
4957 message and a Device message.
IO-Link Interface and System © IO-Link – 227 – Version 1.1.3
t1 t1
Device UART UART UART
frame frame frame
t2 t2
tA
tM-sequence
4958
4963 The adjustable Device parameter “MasterCycleTime” can be used for the design of a Device
4964 specific technology such as an actuator to derive the timing conditions for a default
4965 appropriate action such as de-activate or de-energize the actuator (see 7.3.3.5
4966 "MaxCycleTime", 10.2, and 10.8.3).
4967 Table A.11 lists recommended minimum cycle time values for the specified transmission mode
4968 of a port. The values are calculated based on M-sequence Type_2_1.
COM1 18,0 ms
COM2 2,3 ms
COM3 0,4 ms
4974 The idle time shall be long enough for the Device to become ready to receive the next
4975 message.
4988 Remedy: The Master shall repeat the Master message 2 times (see 7.2.2.1). Devices shall
4989 reject all data with detected errors and create no reaction.
5015 Remedy: Abort of service with ErrorType information (see Annex C).
I-Service Length
Bit 7 Bit 0
5023
5029 All other elements of the structure specified in 7.3.6.1 are transmitted as independent octets.
5031
5032 Table A.13 specifies the syntax of the ISDUs. ErrorType can be found in Annex C.
5034
5041
5046 There is no requirement for the Device to support all Index and Subindex values. The Device
5047 shall send a negative response to Index or Subindex values not supported.
5048 The data element address of a structured parameter of the data object to be transmitted using
5049 the ISDU is specified in the “Subindex” element. “Subindex” has a range of values from
5050 0 to 255, whereby a value of "0" is used to reference the entire data object (see Figure 6).
5051 Table A.15 lists the Index formats used in the ISDU depending on the parameters transmitted.
5053
Sender Receiver
Index + Index +
Subindex + Subindex +
Data 1 + Data 1 +
... + ... +
Data n + Data n +
1. CHKPDU = "0"
2. CHKPDU = Checksum + CHKPDU = Checksum +
Prior to sending
Checksum
Checksum Result
Result == "0",
"0", otherwise
otherwise perturbed
perturbed bits
bits
5062
5064 The receiver checks whether XOR processing of all of the octets of the ISDU will lead to the
5065 result "0" (see Figure A.17). If the result is different from "0", error processing shall take
5066 place. See also A.1.6.
Request example 1 Request example 2 Request example 3 Request example 4 Request example 5
I-Service 0101 I-Service 0110 I-Service 0111 I-Service 0001 0000 0000
Index Index Index ExtLength (n) 1)
"Idle" request
Data 1 (MSO) Subindex Index Index
Data 2 (LSO) Data 1 Subindex Data 1
CHKPDU Data 2 Data 1 Data 2
CHKPDU Data 2 ...
8 Bit Index
CHKPDU ...
8 Bit Index and
Subindex Data (n-4)
16 Bit Index and
Subindex CHKPDU
5070
5073 The ISDU request in example 1 comprises one Index element allowing addressing from
5074 0 to 255 (see Table A.15 and Table B.8 for restrictions). In this example the Subindex is "0"
5075 and the whole content of Index is Data 1 with the most significant octet (MSO) and Data 2
5076 with the least significant octet (LSO). The total length is 5 ("0101").
5077 The ISDU request in example 2 comprises one Index element allowing addressing from 0 to
5078 255 and the Subindex element allowing addressing an element of a data structure. The total
5079 length is 6 ("0110").
5080 The ISDU request in example 3 comprises two Index elements allowing to address from 256
5081 to 65535 (see Table A.15) and the Subindex element allowing to address an element of a data
5082 structure. The total length is 7 ("0111").
Version 1.1.3 – 232 – IO-Link Interface and System © IO-Link
5083 The ISDU request in example 4 comprises one Index element and the ExtLength element
5084 indicating the number of ISDU elements (n), permitting numbers from 17 to 238. In this case
5085 the Length element has the value "1".
5086 The ISDU request "Idle" in example 5 is used to indicate that no service is pending.
5087 Figure A.19 demonstrates typical examples of response ISDUs, which are explained in the
5088 following paragraphs.
5094 The ISDU response in example 1 shows the minimum value 2 for the Length element ("0010").
5095 The ISDU response in example 2 shows two Data elements and a total number of 4 elements
5096 in the Length element ("0100"). Data 1 carries the most significant octet (MSO) and Data 2
5097 the least significant octet (LSO).
5098 The ISDU response in example 3 shows the ExtLength element indicating the number of ISDU
5099 elements (n), permitting numbers from 17 to 238. In this case the Length element has the
5100 value "1".
5101 The ISDU response "Busy" in example 4 is used when a Device is currently not able to
5102 respond to the read request of the Master due to the necessary preparation time for the
5103 response.
5104 Figure A.20 shows a typical example of both a read and a write request ISDU, which are
5105 explained in the following paragraphs.
5108 The code of the read request I-Service is "1001". According to Table A.13 this comprises an
5109 Index element. A successful read response (+) of the Device with code "1101" is shown next
5110 to the request with two Data elements. Total length is 4 ("0100"). An unsuccessful read
5111 response (-) of the Device with code "1100" is shown next in line. It carries the ErrorType with
5112 the two Data elements ErrorCode and AdditionalCode (see Annex C).
5113 The code of the write request I-Service is "0010". According to Table A.13 this comprises an
5114 Index and a Subindex element. A successful write response (+) of the Device with code
5115 "0101" is shown next to the request with no Data elements. Total length is 2 ("0010"). An
5116 unsuccessful read response (-) of the Device with code "0100" is shown next in line. It carries
5117 the ErrorType with the two Data elements ErrorCode and AdditionalCode (see Annex C).
0
Bit 7 Bit 0
5126
Event
Details Reserv. Activated events
1
Bit 7 Bit 0
5142
Event
Details Reserv. Activated events
StatusCode (type 2) 1
Bit 7 Bit 5 Bit 0
Bit 7 Bit 0
5159
Value Definition
0 Unknown
1 to 3 Reserved
4 Application
IO-Link Interface and System © IO-Link – 235 – Version 1.1.3
Value Definition
5 to 7 Reserved
5165
5166 Bit 3: SOURCE
5167 This bit indicates the source of the Event. Permissible values for SOURCE are listed in Table
5168 A.18.
Value Definition
0 Device (remote)
1 Master/Port
5170
5171 Bits 4 to 5: TYPE
5172 These bits indicate the Event category. Permissible values for TYPE are listed in Table A.19.
Value Definition
0 Reserved
1 Notification
2 Warning
3 Error
5174
5175 Bits 6 to 7: MODE
5176 These bits indicate the Event mode. Permissible values for MODE are listed in Table A.20.
Value Definition
0 reserved
1 Event single shot
2 Event disappears
3 Event appears
5178
5182 Annex B
5183 (normative)
5184
5185 Parameter and commands
5186 B.1 Direct Parameter page 1 and 2
5187 B.1.1 Overview
5188 In principle, the designer of a Device has a large amount of space for parameters and
5189 commands as shown in Figure 6. SDCI offers the so-called Direct Parameter pages 1 and 2
5190 with a simplified access method (page communication channel according to Table A.1).
5191 The range of Direct Parameters is structured as shown in Figure B.1. It is split into page 1
5192 and page 2.
Direct Parameter
Page 2:
Device Device specific
(individual or 0x10 … 0x1F
profile)
5193
5195 Page 1 ranges from 0x00 to 0x0F. It comprises the following categories of parameters:
5202 Page 2 ranges from 0x10 to 0x1F. This page comprises parameters optionally used by the
5203 individual Device technology. The Master application layer (AL) provides read/write access to
5204 Direct Parameter page 2 in form of data objects (see 8.2.1) via Index 1. Single octets can be
5205 written or read via Index 1 and the corresponding Subindex. Subindex 1 indicates address
5206 0x10 and Subindex 16 address 0x1F.
5207 A Device shall always return the value "0" upon a read access to Direct Parameter addresses,
5208 which are not implemented (for example in case of reserved parameter addresses or not
5209 supported optional parameters). The Device shall ignore a write access to not implemented
5210 parameters.
5211 The structure of the Direct Parameter pages 1 and 2 is specified in Table B.1.
IO-Link Interface and System © IO-Link – 237 – Version 1.1.3
5213
5217 Permissible values for these parameters are specified in Table B.2.
5219
5223 The MinCycleTime is a Device parameter to inform the Master about the shortest cycle time
5224 supported by this Device.
5225 See A.3.7 for the application of the MasterCycleTime and the MinCycleTime. The structure of
5226 these two parameters is shown in Figure B.2.
Bit 7 Bit 0
5227
5234 When all bits are zero, (binary code 0x00), the Device has no MinCycleTime. In this case the
5235 Master shall use the calculated worst case M-sequence timing, that is with the M-sequence
5236 type used by the Device, and the maximum times for t A and t 2 (see A.3.4 to A.3.6).
5237 The permissible combinations for time base and multiplier are listed in Table B.3 along with
5238 the resulting values for MasterCycleTime or MinCycleTime.
NOTE The value 0,4 results from the minimum possible transmission time according to A.3.7.
IO-Link Interface and System © IO-Link – 239 – Version 1.1.3
PREOPERATE
M-sequence OPERATE
Reserved type M-sequence type ISDU
Bit 7 Bit 0
5242
Value Definition
5248
5249 Bits 1 to 3: Coding of the OPERATE M-sequence type
5250 This parameter indicates the available M-sequence type during the OPERATE state.
5251 Permissible codes for the OPERATE M-sequence type are listed in Table A.9 for legacy
5252 Devices and in Table A.10 for Devices according to this standard.
MajorRev MinorRev
Bit 7 Bit 0
5265
Bit 7 Bit 0
5275
Value Definition
0 0 no Process Data
0 1 1 bit Process Data, structured in bits
0 n (2-15) n bit Process Data, structured in bits
0 16 16 bit Process Data, structured in bits
0 17 to 31 Reserved
1 0, 1 Reserved
1 2 3 octets Process Data, structured in octets
1 n (3-30) n +1 octets Process Data, structured in octets
1 31 32 octets Process Data, structured in octets
5292
5326 Figure B.6 shows the general mapping of data objects for the ISDU transmission.
Preferred Index
0x40 … 0xFE
Diagnosis
0x20 … 0x27
Identification
0x10 … 0x1F
System
0x02 … 0x0F
5327
5329 So-called ISDU "containers" are the transfer means to exchange application data objects or
5330 short data objects. The index of the ISDU is used to address the data objects.
5331 Subclause B.2 contains definitions and requirements for the implementation of technology
5332 specific Device applications. Implementation rules for parameters and commands are
5333 specified in Table B.7.
1 All parameters of an Index shall be readable and/or writeable as an entire data object via
Subindex 0
2 The technology specific Device application shall resolve inconsistencies of dependent
parameter sets during parameterization
3 The duration of an ISDU service request is limited (see Table 102). A master application
can abort ISDU services after this timeout
4 Application commands (for example teach-in, reset to factory settings, etc.) are treated
like parameters.
5335
5336 Table B.8 specifies the assignment of data objects (parameters and commands) to the Index
5337 range of ISDUs. All indices above 2 are ISDU related.
5339
5344 Implementation of the SystemCommand feature is optional for Devices. The coding of
5345 SystemCommands is specified in Table B.9.
0x00 0 Reserved
0x01 1 ParamUploadStart O Start parameter upload
0x02 2 ParamUploadEnd O Stop parameter upload
0x03 3 ParamDownloadStart O Start parameter download
0x04 4 ParamDownloadEnd O Stop parameter download
0x05 5 ParamDownloadStore O Finalize parameterization and start Data
Storage
0x06 6 ParamBreak O Cancel all Param commands
0x07 to 0x3F 7 to 63 Reserved
0x40 to 0x7F 64 to 127 Reserved for profiles
0x80 128 Device reset O See 10.7.2
0x81 129 Application reset H See 10.7.3
0x82 130 Restore factory settings O See 10.7.4
0x83 131 Back-to-box M See 10.7.5
0x84 to 0x9F 132 to 159 Reserved
0xA0 to 0xFF 160 to 255 Vendor specific
NOTE See 10.3
Key H = highly recommended; M = mandatory; O = optional;
5347
IO-Link Interface and System © IO-Link – 245 – Version 1.1.3
5351 The implementation of the SystemCommands 0x01 to 0x06 required for Block Parameteri-
5352 zation according to 10.3.5 is optional. However, all of these commands or none of them shall
5353 be implemented (for SystemCommand 0x05 the rule for Data Storage dominates).
5354 See B.1.11 for SystemCommand options on the Direct Parameter page 1.
5359
5360 The parameter DataStorageIndex 0x0003 contains all the information to be used for the Data
5361 Storage handling. This parameter is reserved for private exchanges between the Master and
5362 the Device; the Master shall block any write access request from a gateway application to this
5363 Index (see Figure 5). The parameters within this Index 0x0003 are specified as follows.
5364 DS_Command
5365 This octet carries the Data Storage commands for the Device.
5366 State_Property
5367 This octet indicates the current status of the Data Storage mechanism. Bit 7 shall be stored in
5368 non-volatile memory. The Master checks this bit at start-up and performs a parameter upload
5369 if requested.
5370 Data_Storage_Size
5371 These four octets provide the requested memory size as number of octets for storing all the
5372 information required for the replacement of a Device including the structural information
Version 1.1.3 – 246 – IO-Link Interface and System © IO-Link
5373 (Index, Subindex). Data type is UIntegerT32 (32 bit). The maximum size is 2 048 octets. See
5374 Table G.1 for the elements to be taken into account in the size calculation.
5375 Parameter_Checksum
5376 This checksum is used to detect changes in the parameter set without reading all parameters.
5377 The value of the checksum is calculated according to the procedure in 10.4.8. The Device
5378 shall change the checksum whenever a parameter out of the parameter set has been altered.
5379 Different parameter sets shall hold different checksums. It is recommended that the Device
5380 stores this parameter locally in non-volatile memory.
5381 Index_List
5382 Table B.11 specifies the structure of the Index_List. Each Index_List can carry up to 70
5383 entries (see Table 102).
5385
5386 Large sets of parameters can be handled via concatenated Index_Lists. The last two octets of
5387 the Index_List shall carry the Termination Marker. A value "0" indicates the end of the Index
5388 List. In case of concatenation the Termination Marker is set to the next Index containing an
5389 Index List. The structure of the following Index List is the same as specified in Table B.11.
5390 Thus, the concatenation of lists ends if a Termination Marker with the value "0" is found.
NOTE For compatibility reasons, the Master still reads the parameter State_Property
/State of Data Storage (see Table B.10).
5406
5407 Parameter (write) access:
5408 If this bit is set, write access to all Device parameters over the SDCI communication interface
5409 is inhibited for all read/write parameters of the Device except the parameter Device Access
5410 Locks. Read access is not affected. The Device shall respond with the negative service
5411 response – access denied – to a write access, if the parameter access is locked.
5412 The parameter (write) access lock mechanism shall not block downloads of the Data Storage
5413 mechanism (between DS_DownloadStart and DS_DownloadEnd or DS_Break).
5419 This setting is also indicated in the State Property within Data Storage Index.
5498 The following Device conditions in Table B.13 are specified. They shall be generated by the
5499 Device applications. The parameter DeviceStatus can be read by any PLC program or tools
5500 such as Asset Management (see Clause 11).
5501 Table B.13 lists the different DeviceStatus information. The criteria for these indications are
5502 specified in subclauses B.2.20.2 through B.2.20.5.
Value Definition
5504
4 Error_Warning_4 3 octets
…
n Error_Warning_n 3 octets
5533
5534 The designer may choose the implementation of a static list, i.e. one fix array position for
5535 each Event with a specific EventCode, or a dynamic list, i.e. each Event entry is stored into
5536 the next free array position. Subindex access is not supported.
Bit 7 Bit 0
5553
5560 The permissible combinations for Time Base and Multiplier are listed in Table B.15 along with
5561 the resulting values for OffsetTime. Setting both Multiplier and Time Base to zero deactivates
5562 synchronization with the help of an OffsetTime. The value of OffsetTime shall not exceed the
5563 MasterCycleTime (see B.1.3)
5565
5579 Annex C
5580 (normative)
5581
5582 ErrorTypes (ISDU errors)
5583 C.1 General
5584 An ErrorType is used within negative service confirmations of ISDUs (see A.5.2 and Table
5585 A.13). It indicates the cause of a negative confirmation of a Read or Write service. The origin
5586 of the error may be located in the Master (local) or in the Device (remote).
5587 The ErrorType consists of two octets, the main error cause and more specific information:
5597
Device Event – ISDU buffer 0x80 0x33 VAL_LENOVRRUN See C.3.8 and C.2.12
overflow Events from legacy
(DL, Error, single shot, 0x5200) Devices shall be
redirected in
compatibility mode to
this derived ErrorType
5665
5695
5720 Annex D
5721 (normative)
5722
5723 EventCodes (diagnosis information)
5724 D.1 General
5725 The concept of Events is described in 7.3.8.1 and the general structure and encoding of
5726 Events is specified in Clause A.6. Whenever the StatusCode indicates an Event in case of a
5727 Device or a Master incident, the associated EventCode shall be provided as diagnosis
5728 information. As specified in A.6, the Event entry contains an EventCode in addition to the
5729 EventQualifier. The EventCode identifies an actual incident. Permissible values for
5730 EventCode are listed in Table D.1; all other EventCode values are reserved and shall not be
5731 used.
5737
0x0000 to Reserved
0x17FF
0x1800 No Device (communication) Error
Trigger: SMI_PortEvent (0x1800) by SM_PortMode (COMLOST)
0x1801 Startup parametrization error – check parameter Error
0x1802 Incorrect VendorID – Inspection Level mismatch Error
Trigger: SM_PortMode (COMP_FAULT)
0x1803 Incorrect DeviceID – Inspection Level mismatch Error
Trigger: SM_PortMode (COMP_FAULT)
0x1804 Short circuit at C/Q – check wire connection Error
0x1805 PHY overtemperature – check Master temperature and load Error
0x1806 Short circuit at L+ – check wire connection Error
0x1807 Overcurrent at L+ – check power supply (e.g. L1+) Error
0x1808 Device Event overflow Error
0x1809 Backup inconsistency – memory out of range (2048 octets) Error
Trigger: SMI_PortEvent (0x1809) by DS_Fault (SizeCheck_Fault)
0x180A Backup inconsistency – identity fault Error
Trigger: SMI_PortEvent (0x180A) by DS_Fault (Identification_Fault)
0x180B Backup inconsistency – Data Storage unspecific error Error
Trigger: SMI_PortEvent (0x180B) by DS_Fault (All other incidents)
0x180C Backup inconsistency – upload fault Error
0x180D Parameter inconsistency – download fault Error
0x180E P24 (Class B) missing or undervoltage Error
0x180F Short circuit at P24 (Class B) – check wire connection (e.g. L2+) Error
0x1810 Short circuit at I/Q – check wiring Error
Version 1.1.3 – 260 – IO-Link Interface and System © IO-Link
0x1811 Short circuit at C/Q (if digital output) – check wiring Error
0x1812 Overcurrent at I/Q – check load Error
0x1813 Overcurrent at C/Q (if digital output) – check load Error
0x1814 to Reserved
0x1EFF
0x1F00 to Vendor specific
0x1FFF
0x2000 to Safety extensions See [10]
0x2FFF
0x3000 to Wireless extensions See [11]
0x3FFF
0x4000 to Reserved
0x5FFF
0x6000 Invalid cycle time Error
Trigger: SM_PortMode (CYCTIME_FAULT)
0x6001 Revision fault – incompatible protocol version Error
Trigger: SM_PortMode (REVISION_FAULT)
0x6002 ISDU batch failed – parameter inconsistency? Error
0x6003 to Reserved
0xFF20
0xFF27 Data Storage upload completed and new data object available Notification
Trigger: see Figure 104 (T26)
0xFF28 to Reserved
0xFF30
5744
5745
5746
IO-Link Interface and System © IO-Link – 261 – Version 1.1.3
5747 Annex E
5748 (normative)
5749
5750 Coding of ArgBlocks
5751 E.1 General
5752 The purpose of ArgBlocks is explained in 11.2.2. Each ArgBlock is uniquely defined by its
5753 ArgBlock identifier (ArgBlockID) and its ArgBlock length (ArgBlockLength). Extension of
5754 ArgBlocks by just using a larger ArgBlock length is not permitted. Manufacturer specific
5755 ArgBlocks are possible by using the service groups B to E (see Figure E.1).
5756 Transmission of ArgBlocks is following the convention in 3.3.6 as octet stream beginning with
5757 octet offset 0.
5758 The four-nibble structure of the ArgBlockID is shown in Figure E.1. The ArgBlockID "0x0000"
5759 is reserved. The fourth nibble (N4) is assigned to SMI service groups. The third nibble (N3) is
5760 assigned to domains and to SMI management. Nibble 1 (N1) and nibble 2 (N2) define
5761 ArgBlocks within the particular domain.
ArgBlockID
0 x N4 N3 N2 N1
5764 Table E.1 shows all defined ArgBlock types and their IDs including those for system
5765 extensions in order to avoid ambiguities. ArgBlockIDs are assigned by the IO-Link
5766 Community.
5768
12 PortTypes Array indicating for all n ports the type of port Array [1 to n ] 1 to 6
0: Class A of Unsigned8
1: Class A with PortPowerOffOn
2: Class B; see 5.4.2
3: FS_Port_A without OSSDe; see [10]
4: FS_Port_A with OSSDe; see [10]
5: FS_Port_B; see [10]
6: W_Master; see [11]
7 to
255: Reserved
5773
5779
5784 Content of "PortStatusInfo" is derived from "PortMode" in 9.2.2.4. Values not available shall
5785 be set to "0".
5787
5 to n On-request Data This element contains the On-request Data Octet string ‒
for ArgBlock 0x3000 if available.
5793
2 to n DataStorageObject This element contains the Device parameter Record (octet 1 to 2×2 10
set coded according to 11.4.2 (Table G.2 string) +12
followed by Table G.1)
5798
5805
5811
5817
5822 Mapping principles of input Process Data (PD) are specified in 11.7.2. The following rules
5823 apply for the ArgBlock PDIn:
5830
5835 Mapping principles of output Process Data (PD) are specified in 11.7.3. The following rules
5836 apply for the ArgBlock PDOut:
5841 • Subsequent octets are occupied by the output Process Data, which are propagated to the
5842 Device.
5843 Table E.11 – PDOut
5844
5851
5856 Mapping principles of input Process Data (PD) are specified in 11.7.2. The following rules
5857 apply for the ArgBlock PDInIQ:
5862
5868 Mapping principles of output Process Data (PD) are specified in 11.7.3. The following rules
5869 apply for the ArgBlock PDOutIQ:
5876
5881
5886
5891
5897
Version 1.1.3 – 272 – IO-Link Interface and System © IO-Link
5898 Annex F
5899 (normative)
5900
5901 Data types
5902 F.1 General
5903 This annex specifies basic and composite data types. Examples demonstrate the structures
5904 and the transmission aspects of data types for singular use or in a packed manner.
5905 NOTE More examples are available in [6].
5920
Bit 7 6 5 4 3 2 1 0 Values
TRUE 1 1 1 1 1 1 1 1 0xFF
FALSE 0 0 0 0 0 0 0 0 0x00
5922
Value = 13 1 1 0 1
4 bit 1 octet
0 0 0 0 1 1 0 1
Padding bits = 0
5928
5930
IO-Link Interface and System © IO-Link – 273 – Version 1.1.3
Value = 93786 1 0 1 1 0 1 1 1 0 0 1 0 1 1 0 1 0
17 bit 4 octets
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 1 1 0 1 0
Padding bits = 0
5931
5933 The data type UIntegerT is specified in Table F.3 for singular use.
5935
5943
5944 The 4 coding possibilities in containers are listed in Table F.5 through Table F.8.
Bit 7 6 5 4 3 2 1 0 Container
Octet 1 SN 2 62 2 61 2 60 2 59 2 58 2 57 2 56 8 octets
Octet 2 2 55 2 54 2 53 2 52 2 51 2 50 2 49 2 48
Octet 3 2 47 2 46 2 45 2 44 2 43 2 42 2 41 2 40
Octet 4 2 39 2 38 2 37 2 36 2 35 2 34 2 33 2 32
Octet 5 2 31 2 30 2 29 2 28 2 27 2 26 2 25 2 24
Octet 6 2 23 2 22 2 21 2 20 2 19 2 18 2 17 2 16
Octet 7 2 15 2 14 2 13 2 12 2 11 2 10 29 28
Octet 8 27 26 25 24 23 22 21 20
5946
Version 1.1.3 – 274 – IO-Link Interface and System © IO-Link
Bit 7 6 5 4 3 2 1 0 Container
Octet 1 SN 2 30 2 29 2 28 2 27 2 26 2 25 2 24 4 octets
Octet 2 2 23 2 22 2 21 2 20 2 19 2 18 2 17 2 16
Octet 3 2 15 2 14 2 13 2 12 2 11 2 10 29 28
Octet 4 27 26 25 24 23 22 21 20
5948
Bit 7 6 5 4 3 2 1 0 Container
Octet 1 SN 2 14 2 13 2 12 2 11 2 10 29 28 2 octets
Octet 2 27 26 25 24 23 22 21 20
5950
Bit 7 6 5 4 3 2 1 0 Container
Octet 1 SN 26 25 24 23 22 21 20 1 octet
5952
SN SN
Value = -4 11 11 00 00 SN = 0: positive numbers and zero Value = +4 00 11 00 00
SN = 1: negative numbers
(Two's complement)
11 11 11 11 11 11 00 00 00 00 00 00 00 11 00 00
SN
Value = -28250 17 bit 4 octets 11 11 00 00 11 00 00 00 11 11 00 11 00 00 11 11 00
SN
11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 00 00 11 00 00 00 11 11 00 11 00 00 11 11 00
Float32T See IEEE Std 754-1985 See IEEE Std 754-1985 4 octets
5961
IO-Link Interface and System © IO-Link – 275 – Version 1.1.3
Bits 7 6 5 4 3 2 1 0
20 27 26 25 24 23 22 21
Octet 2 (E) Fraction (F)
20 2 -1 2 -2 2 -3 2 -4 2 -5 2 -6 2 -7
Octet 3 Fraction (F)
5963
5964 In order to realize negative exponent values a special exponent encoding mechanism is set in
5965 place as follows:
5966 The Float32T exponent (E) is encoded using an offset binary representation, with the zero
5967 offset being 127; also known as exponent bias in IEEE Std 754-1985.
StringT US-ASCII see ISO/IEC 646 Any length of character string with a maximum of
232 octets
NOTE a Length can be obtained from a Device's IODD via the attribute 'fixedLength'.
NOTE b In order to ensure proper handling of client applications it is recommended not to use US-
ASCII or UTF-8 codes from 0x00 to 0x1F and 0xFF.
5979
5980 An instance of StringT can be shorter than defined by the IODD attribute 'fixedLength'. 0x00
5981 shall be used for the padding of unused octets.
5982 A condensed form can be used for optimization, where the character string is transmitted in
5983 its actual length and the padding octets are omitted. The receiver can deduce the original
5984 length from the length of the ISDU or by searching the first NULL (0x00) character (see A.5.2
5985 and A.5.3). This condensed form can be used in case of singular access (see Figure F.4).
Version 1.1.3 – 276 – IO-Link Interface and System © IO-Link
Sender: 'fixedLength' =7
0x48
0x48 0x45
0x45 0x4C
0x4C 0x4C
0x4C 0x4F
0x4F 0x00
0x00 0x00
0x00
Padding of unused octets = 0x00
H E L L O
Transmission options:
0x48
0x48 0x45
0x45 0x4C
0x4C 0x4C
0x4C 0x4F
0x4F StringT can be transmitted in condensed form or
unmodified.
Receiver: 'fixedLength' =7
0x48
0x48 0x45
0x45 0x4C
0x4C 0x4C
0x4C 0x4F
0x4F 0x00
0x00 0x00
0x00 Padding of unused octets = 0x00
5986
OctetStringT 0x00 … 0xFF per octet - Fixed length with a maximum of 232 octets
NOTE The length may be obtained from a Device's IODD via the attribute 'fixedLength'.
5993
0 1 2 3 4 5 6 Octet number
0x1F
0x1F 0x0A
0x0A 0x23
0x23 0xAA
0xAA 0xBB
0xBB 0xA1
0xA1 0xD0
0xD0
5994
6001 The first element is a 32-bit unsigned integer data type that provides the network time in
6002 seconds since 1900-01-01 0.00,00(UTC) or since 2036-02-07 6.28,16(UTC) for time values
6003 less than 0x9DFF4400, which represents the 1984-01-01 0:00,00(UTC). The second element
6004 is a 32-bit unsigned integer data type that provides the fractional portion of seconds in
6005 1/2 32 s. Rollovers after 136 years are not automatically detectable and shall be maintained by
6006 the application.
TimeT
Time
1900-01-01 1984-01-01 2036-02-07
0x00000000 s 0x9DFF4400 s 0xFFFFFFFF s
6007
6010
Bit 7 6 5 4 3 2 1 0 Definitions
Octet 7 2 15 2 14 2 13 2 12 2 11 2 10 29 28
Octet 8 27 26 25 24 23 22 21 20
MSB LSB MSB = Most significant bit
LSB = Least significant bit
6012
6018
Bit 7 6 5 4 3 2 1 0 Definitions
Octet 4 2 39 2 38 2 37 2 36 2 35 2 34 2 33 2 32
Octet 5 2 31 2 30 2 29 2 28 2 27 2 26 2 25 2 24
Octet 6 2 23 2 22 2 21 2 20 2 19 2 18 2 17 2 16
Version 1.1.3 – 278 – IO-Link Interface and System © IO-Link
Bit 7 6 5 4 3 2 1 0 Definitions
Octet 7 2 15 2 14 2 13 2 12 2 11 2 10 29 28
Octet 8 27 26 25 24 23 22 21 20
MSB LSB MSB = Most significant bit
LSB = Least significant bit
6020
1 The Subindex data items are packed in a row without gaps describing an octet sequence
2 The highest Subindex data item n starts right aligned within the octet sequence
3 UIntegerT and IntegerT with a length of ≥ 58 bit and < 64 bit are not permitted
6031
6032 Table F.18 and Figure F.7 give an example for the access of an array. Its content is a set of
6033 parameters of the same basic data type.
6035
00 11 00 11 11 00 11 00 00 11 11 11 11 00 11
Bit offset: 12 9 6 3 0
"Subindex1" "Subindex3" "Subindex5"
"Subindex2" "Subindex4"
6036
1 The Subindices within the IODD shall be listed in ascending order from 1 to n describing an
octet sequence. Gaps within the list of Subindices are allowed
2 Bit offsets shall always be indicated within this octet sequence (may show no strict order in
the IODD)
3 The bit offset starts with the last octet within the sequence; this octet starts with offset 0 for
the least significant bit and offset 7 for the most significant bit
4 The following data types shall always be aligned on octet boundaries: Float32T, StringT,
OctetStringT, TimeT, and TimeSpanT
5 UIntegerT and IntegerT with a length of ≥ 58 bit shall always be aligned on one side of an
octet boundary
6 It is highly recommended for UIntegerT and IntegerT with a length of ≥ 8 bit to align always
on one side of an octet boundary
7 It is highly recommended for UIntegerT and IntegerT with a length of < 8 bit not to cross
octet boundaries
8 A bit position shall not be used by more than one record item
6044
6045 Table F.20 gives an example 1 for the access of a RecordT. It consists of varied parameters
6046 named "Status", "Text", and "Value".
NOTE 'bitLength' and 'fixedLength' are defined in the IODD of the particular Device.
6048
6049 Table F.21 gives an example 2 for the access of a RecordT. It consists of varied parameters
6050 named "Level", "Min", and "Max". Figure F.8 shows the corresponding data structure.
11 11 00 00 11 00 11 11 11 11 00 00 00 11 00 11
Bit offset: 2 1 0
"Level" "Min"
6052 "Max"
6054 Table F.22 gives an example 3 for the access of a RecordT. It consists of varied parameters
6055 named "Control" through "Enable". Figure F.9 demonstrates the corresponding RecordT
6056 structure of example 3 with the bit offsets.
6058
0xF8
0xF8 0x23
0x23 0x41
0x41 0xC3
0xC3
Bit offset: 38 35 32 16 8
"Setpoint" "Unit" "Enable"
6059
6061 Figure F.10 shows a selective write request of a variable within the RecordT of example 3 and
6062 a write request of the complete RecordT (see A.5.7).
Write of a record
6065 Annex G
6066 (normative)
6067
6068 Structure of the Data Storage data object
6069 Table G.1 gives the structure of a Data Storage (DS) data object within the Master (see
6070 11.4.2).
6072
6073 The Device shall calculate the required memory size by summarizing the objects 1 to n (see
6074 Table B.10, Subindex 3).
6075 The Master shall store locally in non-volatile memory the header information specified in
6076 Table G.2. See Table B.10.
6077 Table G.2 – Associated header information for stored DS data objects
Header Parameter Checksum 32-bit CRC signature or revision counter (see Unsigned32
10.4.8)
VendorID See B.1.8 Unsigned16
DeviceID See B.1.9 Unsigned32
FunctionID See B.1.10 Unsigned16
6078
Version 1.1.3 – 282 – IO-Link Interface and System © IO-Link
6079 Annex H
6080 (normative)
6081
6082 Master and Device conformity
6083 H.1 Electromagnetic compatibility requirements (EMC)
6084 H.1.1 General
6085 The EMC requirements of this specification are only relevant for the SDCI interface part of a
6086 particular Master or Device. The technology functions of a Device and its relevant EMC
6087 requirements are not in the scope of this specification. For this purpose, the Device specific
6088 product standards shall apply. For Master usually the EMC requirements for peripherals are
6089 specified in IEC 61131-2 or IEC 61000-6-2.
6090 To ensure proper operating conditions of the SDCI interface, the test configurations specified
6091 in section H.1.6 (Master) or H.1.7 (Device) shall be maintained during all the EMC tests. The
6092 tests required in the product standard of equipment under test (EUT) can alternatively be
6093 performed in SIO mode.
6100 In case a test requires longer M-sequences than an M-sequence group specified in Table H.1,
6101 the error criteria shall be applied to every M-sequence group.
6104 The SDCI operating at an average cycle time as specified in Table H.1 shall not show more
6105 than six detected M-sequence errors within the number of M-sequences given in Table H.1.
6106 Multiple kinds of errors within one M-sequence shall be counted as one error. No interruption
6107 of communication is permitted.
NOTE1 The numbers of M-sequences are calculated according to the algorithm in I.2 and rounded up. The
larger number of M-sequences (in brackets) are required if a certain test (for example fast
transients/burst) applies interferences only with a burst/cycle ratio (see Table H.2)
NOTE2 "Number of M-sequences" is defined as a group for the performance criteria for which the maximum
number of detected errors is valid.
6109
6111 The error rate of criterion A shall also be satisfied after but not during the test. No change of
6112 actual operating state (e.g. permanent loss of communication) or stored data is allowed.
6116
6118 a) As this phenomenon influences the entire device under test, an existing device specific
6119 product standard shall take precedence over the test levels specified here.
6120 b) The test shall be performed with a step size of 1 % and a dwell of 1 s. If a single M-
6121 sequence error occurs at a certain frequency, that frequency shall be tested until the
6122 number of M-sequences according to Table H.1 has been transmitted or until 6 M-
6123 sequence errors occurred.
6124 c) Depending on the transmission rate the test time varies. The test time shall be at least
6125 one minute (with the transmitted M-sequences and the permitted errors increased
6126 accordingly).
6127 d) This phenomenon is expected to influence most probably the EUTs internal analog signal
6128 processing and only with a very small probability the functionality of the SDCI
6129 communication. Therefore, an existing device specific product standard shall take
6130 precedence over the test levels specified here.
6131 e) Measurement shall be performed at least for three orthogonal orientations of the Device
6132 with respect to the direction of the electromagnetic wave propagation.
6133
6138 All emission tests shall be performed at the fastest possible communication rate with the
6139 fastest cycle time.
6143 • In the following test setup diagrams only the SDCI and the power supply cables are
6144 shown. All other cables shall be treated as required by the relevant product standard.
6145 • Grounding of power supply, Master, and Devices shall be according to the relevant
6146 product standard or manual.
6147 • Where not otherwise stated, the SDCI cable shall have an overall length of 20 m. Excess
6148 length laid as an inductive coil with a diameter of 0,3 m, where applicable mounted 0,1 m
6149 above reference ground.
6150 • Where applicable, the auxiliary Devices shall be placed 10 cm above RefGND.
6151 • A typical test configuration consists of the Master and two Devices, except for the RF
6152 common mode test, where only one Device shall be used.
6153 • Each port shall fulfill the EMC requirements.
6154 H.1.6.2 Electrostatic discharges
6155 Figure H.1 shows the test setup for electrostatic discharge according to IEC 61000-4-2.
AUX 1
Power (Device)
EUT
Supply
(Master)
AUX 2
(Device)
D =0,3 m
d ≥ 1,0 m d ≥ 1,0 m
6156
AUX 1
Power (Device)
EUT
Supply
(Master)
AUX 2
Uniform area (Device)
AUX 1
CCC
Power (Device)
CDN EUT
Supply
(Master)
AUX 2
(Device)
D = 0,3 m
l = 0,5 m l = 0,5 m l = 0,5 m
Key
CDN: Coupling/Decoupling Network
CCC: Capacitive coupling clamp
6166
AUX 1
EM-Clamp
Power (Device)
CDN EUT
Supply
(Master)
Key x1 x2
0,1 m ≤ x1 ≤ 0,3 m L
0,1 m ≤ x2 ≤ 0,3 m
L = as short as possible
6171
6176 • In the following test setup diagrams only the SDCI and the power supply cables are
6177 shown. All other cables shall be treated as required by the relevant product standard.
6178 • Grounding of the Master and the Devices according to the relevant product standard or
6179 user manual.
6180 • Where not otherwise stated, the SDCI cable shall have an overall length of 20 m. Excess
6181 length laid as an inductive coil with a diameter of 0,3 m, where applicable mounted 0,1 m
6182 above RefGND.
6183 • Where applicable, the auxiliary Devices shall be placed 10 cm above RefGND.
6184 • Test with Device AUX 2 is optional
6185 H.1.7.2 Electrostatic discharges
6186 Figure H.5 shows the test setup for electrostatic discharge according to IEC 61000-4-2.
Power
AUX 1 EUT
Supply
(Master) (Device)
AUX 2 D = 0,3 m
(Device)
d ≥ 1,0 m
6187
Power
AUX 1 EUT
Supply
(Master) (Device)
AUX 2 D = 0,3 m
(Device)
Ferrite clamp or
other decoupling l = 1,0 m Uniform area
6192
Power
CDN AUX 1 EUT
Supply CCC
(Master) (Device)
AUX 2 D = 0,3 m
(Device)
l = 0,5 m l = 0,5 m
Key
CDN: Coupling/Decoupling Network, here only used for decoupling
CCC: Capacitive coupling clamp
6196
DUT
EM-Clamp
Power (Device)
CDN AUX 1
Supply
(Master)
Key
0,1 m ≤ x1 ≤ 0,3 m x1 x2
L
0,1 m ≤ x2 ≤ 0,3 m
L = as short as possible
6201
6213 shall copy the input Process Data of any received Device message to the output Process Data
6214 of the next Master message to be sent. The cycle time should be according to Table H.1. If
6215 not possible, the number of M-sequences for the test shall be calculated according to the
6216 algorithm in I.2 and rounded up. Used cycle time and number of M-sequences shall be
6217 documented in test records. The Device AUX 1 shall compare the output Process Data with
6218 the previously sent input Process Data and count the number of deviations. The Device shall
6219 also count the number of missing (not received within the expected cycle time) or received
6220 perturbed Master messages. All numbers shall be added and indicated.
6221 NOTE 1 A deviation of sent and received Process Data indicates to the AUX1 that the EUT (Master) did not
6222 receive the Device message.
6223 NOTE 2 Detailed instructions for the Master tests are specified in [9].
6224
Version 1.1.3 – 288 – IO-Link Interface and System © IO-Link
6225 Annex I
6226 (informative)
6227
6228 Residual error probabilities
6229 I.1 Residual error probability of the SDCI data integrity mechanism
6230 Figure I.1 shows the residual error probability ( REP ) of the SDCI data integrity mechanism
6231 consisting of the checksum data integrity procedure ("XOR6") as specified in A.1.6 and the
6232 UART parity. The diagram refers to IEC 60870-5-1 with its data integrity class I2 for a
6233 minimum Hamming distance of 4 (red dotted line).
1
0,1
Integrity class I2
0,01
1* 10-3
Residual error probability (REP)
1* 10-4
1* 10-5
Hamming distance 4
1* 10-6
1* 10-7
1* 10-8
1* 10-9
Key
1* 10-10
SDCI with 2 octets
1* 10-11 SDCI with 3 octets
SDCI with 4 octets
1* 10-12
1* 10-13
1* 10-4 1* 10-3 0,01 0,1 1
6235 Figure I.1 – Residual error probability for the SDCI data integrity mechanism
6236 The blue line shows the residual error curve for a data length of 2 octets. The black curve
6237 shows the residual error curve for a data length of 3 octets. The purple curve shows the
6238 residual error curve for a data length of 4 octets.
F 20 × R( BEP ) ≤ 1 (I.1)
IO-Link Interface and System © IO-Link – 289 – Version 1.1.3
1 1
NoTF ≥ × × NopErr (I.2)
BEP BitPerF
6265 Annex J
6266 (informative)
6267
6268 Example sequence of an ISDU transmission
6269 Figure J.1 demonstrates an example for the transmission of ISDUs using an AL_Read service
6270 with a 16-bit Index and Subindex for 19 octets of user data with mapping to an M-sequence
6271 TYPE_2_5 for sensors and with interruption in case of an Event transmission.
6272
Master Device
FC CKT PD OD OD PD CKS
comment cycle R Com Flow Frame CHK Process OnReq Data Process CHK comment
(state, action) nr W Chan. CTRL Typ Data Master Device Data E PD (state, action)
(see in Table 46) 1bit 2bit 5bit 2bit 6bit 8bit 8bit 8bit
Idle_1 0 1111 0001 10 xxxxxx xxxxxxxx 0000 0000 xxxxxxxx 0 0 xxxxxx OnReq idle
ISDURequest_2, transmission, 1 0111 0000 10 xxxxxx xxxxxxxx 1011 0101 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 2 0110 0001 10 xxxxxx xxxxxxxx Index(hi) xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 3 0110 0010 10 xxxxxx xxxxxxxx Index(lo) xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 4 0110 0011 10 xxxxxx xxxxxxxx Subindex xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 5 0110 0100 10 xxxxxx xxxxxxxx CHKPDU xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDUWait_3, start ISDU Timer 6 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUWait_3, inc. ISDU timer 7 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUWait_3, inc. ISDU timer 8 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUWait_3, inc. ISDU timer 9 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUWait_3, inc. ISDU timer 10 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUResponse_4, reception
Stop ISDU Timer 11 1111 0000 10 xxxxxx xxxxxxxx 1101 0001 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 12 1110 0001 10 xxxxxx xxxxxxxx 0001 0011 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 13 1110 0010 10 xxxxxx xxxxxxxx Data 1 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 14 1110 0011 10 xxxxxx xxxxxxxx Data 2 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 15 1110 0100 10 xxxxxx xxxxxxxx Data 3 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 16 1110 0101 10 xxxxxx xxxxxxxx Data 4 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 17 1110 0110 10 xxxxxx xxxxxxxx Data 5 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 18 1110 0111 10 xxxxxx xxxxxxxx Data 6 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 19 1110 1000 10 xxxxxx xxxxxxxx Data 7 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, no response, ISDUResponse_4,
retry in next cycle 20 1110 1001 10 Err xxxxxxxx xxxxxx korrupted CHK, don' t send resp.
ISDUResponse_4, no response, ISDUResponse_4,
retry in next cycle 21 1110 1001 10 Err xxxxxxxx xxxxxx corrupted CHK, don' t send resp.
ISDUResponse_4, reception 22 1110 1001 10 xxxxxx xxxxxxxx Data 8 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 34 1110 1010 10 xxxxxx xxxxxxxx Data 9 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception, ISDUResponse_4, transmission,
start eventhandler 35 1110 1011 10 xxxxxx xxxxxxxx Data 10 xxxxxxxx 1 0 xxxxxx freeze event
Diag State
Read_Event_2, reception 36 1100 0000 10 xxxxxx xxxxxxxx with detail xxxxxxxx 1 0 xxxxxx Read_Event_2, transmission
Event
Read_Event_2, reception 37 110x xxxx 10 xxxxxx xxxxxxxx qualifier xxxxxxxx 1 0 xxxxxx Read_Event_2, transmission
6273 Idle_1 57 1111 0001 10 xxxxxx xxxxxxxx 0000 0000 xxxxxxxx 0 0 xxxxxx Idle_1
ISDURequest_2, transmission 58 0111 0000 10 xxxxxx xxxxxxxx 0001 1011 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 59 0110 0001 10 xxxxxx xxxxxxxx Index xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 60 0110 0010 10 xxxxxx xxxxxxxx Data 1 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 61 0110 0011 10 xxxxxx xxxxxxxx Data 2 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 62 0110 0100 10 xxxxxx xxxxxxxx Data 3 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 63 0110 0101 10 xxxxxx xxxxxxxx Data 4 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 64 0110 0110 10 xxxxxx xxxxxxxx Data 5 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 65 0110 0111 10 xxxxxx xxxxxxxx Data 6 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 66 0110 1000 10 xxxxxx xxxxxxxx Data 7 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 67 0110 1001 10 xxxxxx xxxxxxxx Data 8 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 68 0110 1010 10 xxxxxx xxxxxxxx CHKPDU xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDUWait_3, start ISDU Timer 69 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUResponse_4, reception
Stop ISDU Timer 70 1111 0000 10 xxxxxx xxxxxxxx 0101 0010 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 71 1110 0001 10 xxxxxx xxxxxxxx CHKPDU xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
Idle_1 72 1111 0001 10 xxxxxx xxxxxxxx 0000 0000 xxxxxxxx 0 0 xxxxxx Idle_1
Idle_1 73 1111 0001 10 xxxxxx xxxxxxxx 0000 0000 xxxxxxxx 0 0 xxxxxx Idle_1
ISDURequest_2, transmission, 74 0111 0000 10 xxxxxx xxxxxxxx 1011 0101 xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 75 0110 0001 10 xxxxxx xxxxxxxx Index(hi) xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 76 0110 0010 10 xxxxxx xxxxxxxx Index(lo) xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 77 0110 0011 10 xxxxxx xxxxxxxx Subindex xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDURequest_2, transmission 78 0110 0100 10 xxxxxx xxxxxxxx CHKPDU xxxxxxxx 0 0 xxxxxx ISDURequest_2, reception
ISDUWait_3, start ISDU Timer 79 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUWait_3, inc. ISDU timer 80 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUWait_3, inc. ISDU timer 81 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUWait_3, inc. ISDU timer 82 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUWait_3, inc. ISDU timer 83 1111 0000 10 xxxxxx xxxxxxxx 0000 0001 xxxxxxxx 0 0 xxxxxx ISDUWait_3, application busy
ISDUResponse_4, reception
Stop ISDU Timer 84 1111 0000 10 xxxxxx xxxxxxxx 1101 0001 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 85 1110 0001 10 xxxxxx xxxxxxxx 0001 1110 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, reception 86 1110 0010 10 xxxxxx xxxxxxxx Data 1 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, transmission
ISDUResponse_4, ABORT 87 1111 1111 10 xxxxxx xxxxxxxx 0000 0000 xxxxxxxx 0 0 xxxxxx ISDUResponse_4, ABORT
Idle_1 88 1111 0001 10 xxxxxx xxxxxxxx 0000 0000 xxxxxxxx 0 0 xxxxxx Idle_1
Idle_1 89 1111 0001 10 xxxxxx xxxxxxxx 0000 0000 xxxxxxxx 0 0 xxxxxx Idle_1
6275
6277 Annex K
6278 (informative)
6279
6280 Recommended methods for detecting parameter changes
6281 K.1 CRC signature
6282 Cyclic Redundancy Checking belongs to the HASH function family. A CRC signature across
6283 all changeable parameters can be calculated by the Device with the help of a so-called proper
6284 generator polynomial. The calculation results in a different signature whenever the parameter
6285 set has been changed. It should be noted that the signature secures also the octet order
6286 within the parameter set. Any change in the order when calculating the signature will lead to a
6287 different value. The quality of securing (undetected changes) depends heavily on both the
6288 CRC generator polynomial and the length (number of octets) of the parameter set. The seed
6289 value should be > 0. One calculation method uses directly the formula, another one uses octet
6290 shifting and lookup tables. The first one requests less program memory and is a bit slower,
6291 the other one requires memory for a lookup table (1 x 2 10 octets for a 32-bit signature) and is
6292 fast. The parameter data set comparison is performed in state "Checksum_9" of the Data
6293 Storage (DS) state machine in Figure 104. Table K.1 lists several possible generator
6294 polynomials and their detection level.
6296
6304
IO-Link Interface and System © IO-Link – 293 – Version 1.1.3
6305 Bibliography
6306 [1] IEC 60050 (all parts), International Electrotechnical Vocabulary, (available at
6307 <http://www.electropedia.org>)
6308 [2] IEC 60870-5-1:1990, Telecontrol equipment and systems – Part 5: Transmission
6309 protocols – Section One: Transmission frame formats
6310 [3] IEC 61158-2, Industrial communication networks – Fieldbus specifications – Part 2:
6311 Physical layer specification and service definition
6312 [4] IEC/TR 62453-61, Field device tool interface specification – Part 61: Device Type
6313 Manager (DTM) Styleguide for common object model
6314 [5] ISO/IEC 7498-1, Information technology – Open Systems Interconnection – Basic
6315 Reference Model: The Basic Model
6316 [6] IO-Link Community, IO Device Description (IODD), Order No. 10.012 (available at
6317 <http://www.io-link.com>)
6318 [7] IO-Link Community, IO-Link Common Profile, Order No. 10.072 (available at
6319 <http://www.io-link.com>)
6320 [8] IO-Link Community, IO-Link Communication, V1.0, January 2009, Order No. 10.002
6321 (available at <http://www.io-link.com>)
6322 [9] IO-Link Community, IO-Link Test Specification, Order No. 10.032 (available at
6323 <http://www.io-link.com>)
6324 [10] IO-Link Community, IO-Link Safety System Extensions, Order No. 10.092 (available at
6325 <http://www.io-link.com>)
6326 [11] IO-Link Community, IO-Link Wireless System Extensions, Order No. 10.112 (available
6327 at <http://www.io-link.com>)
6328 [12] IO-Link Community, IO-Link Common Gateway Profile, work in progress
6329 _____________
6330
Copyright by:
IO-Link Community
c/o PROFIBUS Nutzerorganisation e.V.
Haid-und-Neu-Str. 7
76131 Karlsruhe
Germany
Phone: +49 (0) 721 / 96 58 590
Fax: +49 (0) 721 / 96 58 589
e-mail: [email protected]
http://www.io-link.com/