User Tech

SOFTWARE
KR C...
UserTech 2.1
Programming Handbook
SystemTech (KRS) V5.2, V5.3, V5.4
Issued: 02 Mai 2005 Version: 01
ProgHBUserTechfKRS2.1 11.04.01 en 1 von 61

e Copyright 2005
KUKA Roboter GmbH

This documentation or excerpts therefrom may not be reproduced or disclosed to third parties without the express permission of the publishers.
Other functions not described in this documentation may be operable in the controller. The user has no claim to these functions, however, in
the case of a replacement or service work.
We have checked the content of this documentation for conformity with the hardware and software described. Nevertheless, discrepancies
cannot be precluded, for which reason we are not able to guarantee total conformity. The information in this documentation is checked on a
regular basis, however, and necessary corrections will be incorporated in subsequent editions.
Subject to technical alterations without an effect on the function.
KUKA Interleaf
2 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

Contents
1 Installation / uninstallation / update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 UserTech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 User technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Reference section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Overview of language elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Reinitializing UserTech and BOF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Defining technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Areas of validity of the objects and variables in a technology . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Inline forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1 FOCUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.2 FOLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.3 PARAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4 STYLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4.1 WYSIWYG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4.2 SUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4.3 DSUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4.4 FCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4.5 DFCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4.6 ASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4.7 ASSAGG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.5 ONACCEPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.6 ONTOUCHUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.7 ONOPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Input, display and list boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.1 SHORTNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.2 SHORTCUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.3 UNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.4 ENABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.5 USERMODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.6 VALUE FieldDescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.6.1 The type {static: } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.6.2 The type {free: } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.6.3 The type {name: } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.6.4 The type {number: } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.6.5 The type {real: } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.6.6 The type {list: } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Parameter lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.1 Assigning a parameter list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.2 Parameter list properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.3 Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.4 Shortname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.5 Min/Max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

UserTech 2.1
3.6.6 Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.7 Shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.8 Autolimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.9 Default value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.10 Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.11 Filling the parameter list with parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.12 Adaptation of $config.dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 FOLDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 Status keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8.1 Creating new status keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8.1.1 TOPTEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8.1.2 CENTERTEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8.1.3 BOTTOMTEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8.1.4 PICTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8.1.5 KEYDOWN_PICTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8.1.6 KEYDOWNMINUS_PICTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8.1.7 ENABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8.1.8 NEED_SAFETYSWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8.1.9 NEED_DRIVESOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8.1.10 NEED_MODEOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8.1.11 NEED_PROSTATE0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8.1.12 NEED_PROSTATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.1.13 USERMODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.1.14 STYLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.1.15 ONKEYDOWN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.1.16 ONKEYUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.1.17 ONKEYSHOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.1.18 ONKEYDOWNMINUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.1.19 ONKEYUPMINUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.1.20 ONKEYREPEAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.1.21 ONKEYREPEATMINUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.1.22 NEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.2 Reassigning status keys that have already been declared . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.3 Creating a status key bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8.4 Reassigning status key bars that have already been declared . . . . . . . . . . . . . . . . . . . . . . . . 35
3.9 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9.1 SETVAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9.2 SHOWVAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9.3 REDECL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.9.4 DO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9.5 SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9.6 MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9.7 SWITCH...CASE(ELSE)...ENDSWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9.8 SWITCH DIALOG...CASE...ENDSWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.9.9 Predefined scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9.9.1 ACCEPTINLINEFORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9.9.2 CANCELINLINEFORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9.9.3 END . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9.9.4 NOTHING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Integrating technologies in the graphical user interface (GUI) . . . . . . . 43

4.1 Creating a submenu in the menu bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Examples of integration of a technology in a menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Simple submenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2 Submenu with pop--up menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.3 Example of integration of a technology via a status key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 File storage in a structured directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Programming status keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Programming inline forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Starting scripts by means of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.1 Case 1: Execute script when an inline form is opened or closed . . . . . . . . . . . . . . . . . . . . . . 55
5.3.2 Case 2: Execute script when an inline form is created or modified . . . . . . . . . . . . . . . . . . . . 56
5.3.3 Case 3: Execute script on toggling between inline forms within a technology . . . . . . . . . . . 57
6 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1 Typographical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2 Parameters and parameter reference placeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.1 Predefined parameter reference placeholders in KRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.1.1 %TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.1.2 %INLINEFORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.1.3 %MODULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.5 String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.6 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.6.1 “;” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.6.2 “_” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.6.3 “/” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.6.4 “%” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

UserTech 2.1

1 Installation / uninstallation / update
1 Installation / uninstallation / update
From system software version 5.x onwards, technology packages are offered exclusively as
add--on software modules. These are available on CD--ROM. Should you be interested in
purchasing further modules, please contact KUKA Support.
The installation procedure is the same for all technology packages and is described in a
separate documentation module.
The installation, uninstallation, reinstallation and update of technology packages

are described in detail in the documentation “Installation/Uninstallation/Update of
Tech Packages”.

UserTech 2.1
2 UserTech
2.1 Introduction
KUKA technology packages contain the most important functions for normal robot
applications. Special functions are programmed directly by the user in “KRL”, “KUKA Robot
Language”.
In order to offer the advantages of a graphically oriented user interface here also, the
“USERTech” package has been integrated. Using language elements from the “KUKA Form
Description Language”, or “KFDL“ for short, it is easy to add graphic elements to your
customized technology packages.
Menu
entry
USERTech
Status
key bar Inline KRL program
Status form section
key
Technology
Event Event
Scripts Kernel system
Softkey Message
window
Menu entries are used to call status key bars or inline forms. Data entered in the inline form
input boxes are later used in the generated KRL program section. You can use the status
keys to select options which define the further execution of the program. The execution of
program sections created by the user, which can exchange data with the kernel system, is
dependent on subsequent operator actions, i.e. it is “event--controlled”.

2 UserTech (Fortsetzung)
2.2 User technologies

User technologies are defined in files with the extension KFD. Any text editor can be used
to create them. The name of the file can be freely selected within the confines of the operating
system conventions and does not, itself, appear in the technology package.
KFD files are saved by default in the directory C:\KRC\TP\USERTECH\TEMPLATE. Further
options are available for advanced users; these are described in the chapter “Integrating
technologies in the graphical user interface (GUI)”.
Each KFD file can contain one or more technologies. The name of a technology may only,
however, appear once.
T1
file_1.kfd
T3 file_2.kfd
T4
T2 T5
T6

UserTech 2.1
3 Reference section
3.1 Overview of language elements
Relating to the technology:

DEFTP
... Designates the beginning and end of a technology
ENDTP
Relating to inline forms:

DECL INLINEFORM Definition of an inline form
DECL PARAM Defines the input boxes in an inline form
DECL FOLD Definition of a KRL Fold
DECL PLIST Description of a parameter list
--> Assignment of the parameter list to a parameter
Relating to status keys:

DECL STATKEYBAR Declaration of a status key bar
DECL STATKEY Declaration of a status key
SET The new assignment of an existing status key bar or status key
Relating to scripts:
DEFSCRIPT
... Designates the beginning and end of a script
ENDSCRIPT
CASE,
Designates a branch in the control structure SWITCH...ENDSWITCH
CASE ELSE
DO Command for executing a script
MESSAGE Generation of text in the message window
REDECL Creates a KRL variable in the kernel system or overwrites it
SETVAR Writes a value in a KRL variable in the kernel system
SHOWVAR Reads the value of a KRL variable in the kernel system
SWITCH
... Designates the beginning and end of a control structure
ENDSWITCH
SWITCH DIALOG
Designates the beginning and end of a control structure which
...
communicates with the user via the message window and softkey bar.
ENDSWITCH

3 Reference section (Fortsetzung)
3.2 Reinitializing UserTech and BOF
In order for changes to take effect in KFD files with the controller running, the function
“USERTech reinitialize” must be executed.
Modifications to INI files only take effect when “BOF Reinitialization” is executed.
These functions are available in the user group “Expert” or higher.

UserTech 2.1
3.3 Defining technologies

A *.KFD file is created for every user technology and saved in the directory
“C:\KRC\TP\USERTECH\TEMPLATE”. Any editor can be used to edit KFD files. The file
must be saved in ASCII format.
The definition of a user technology must be initiated within the KFD file using the statement:
DEFTP Name 〈 = {〈SOC Bool,〉 〈SOT Bool〉} 〉
and terminated using the statement:
ENDTP
If no additional parameters are entered, the basic settings in bold type are valid.
TRUE Command selection possible via list box

SOC
FALSE Command selection not possible via list box
TRUE Technology selection possible via list box

SOT
FALSE Technology selection not possible via list box
The statements:
DEFTP MyTech
ENDTP
DEFTP OtherTech
ENDTP
generate the following inline form:
It is possible to switch between the technologies using the +/-- status key (at the bottom right
of the display):
The statements:
DEFTP MyTech={SOT FALSE}
ENDTP
DEFTP OtherTech
ENDTP
generate this inline form:

It is not possible to switch between the technologies in this example. They must be integrated
individually by means of menu entries in the file MenueKeyUser.INI in the directory
C:\KRC\ROBOTER\INIT. (See also Chapter 4)
3.3.1 Areas of validity of the objects and variables in a technology

Objects and variables inserted between DEFTP and ENDTP are valid locally, i.e. only within
the technology. If objects and variables need to be valid globally, i.e. in every technology
contained in the KFD file, they must be inserted outside the statements (DEFTP, ENDTP).
Globally defined inline forms appear as separate entries in the list box.
3.4 Inline forms

The inline form (ILF) is a screen form for entering parameters that are required by USERTech
for generating KRL program code.
Syntax
DECL INLINEFORM Name =
{〈FOCUS Int,〉
〈FOLD[1] Name,〉 〈...,〉 〈FOLD[n] Name,〉
〈PARAM[1] Name,〉 〈...,〉 〈PARAM[n] Name,〉
〈STYLE WYSIWYG|SUB|DSUB|FCT|DFCT|ASS|ASSAGG,〉
〈ONACCEPT Name,〉
〈ONTOUCHUP Name,〉
〈ONOPEN Name〉 }
3.4.1 FOCUS
Number of the input box (see 3.5) that should be activated (when the inline form first
appears).
3.4.2 FOLD
Assigned KRL Fold(s). Folds must be defined before they can be used. For
information on the definition of Folds see 3.7.
If no Fold is assigned to the inline form, the form contents will be inserted into the KRL
program with the format defined by the setting in STYLE.

UserTech 2.1
3.4.3 PARAM
Input boxes in the inline form. Input boxes must be defined before they can be used.
For information on the definition of input boxes see 3.5.
3.4.4 STYLE
The options specified here influence the appearance of the inserted KRL program
section as follows:
3.4.4.1 WYSIWYG
The default setting. The KRL program line to be inserted is formatted in such a way
that it exactly matches the text in the inline form.
Resulting KRL program text:

LASER.ON WeldingDataSet=DataSet1, Distance=200mm,
WeavePattern=PULSE
3.4.4.2 SUB
Formatting is carried out in the form of a KRL subprogram call. The parameters are
reduced to the contents of the input boxes, separated by commas and contained
within brackets. The dot separating the name of the technology and the name of
the inline form is suppressed.

LASERON(DataSet1,200,PULSE)
3.4.4.3 DSUB
Formatting is carried out in the form of a KRL subprogram call. The parameters are
reduced to the contents of the input boxes, separated by commas and contained
within brackets. The dot separating the name of the technology and the name of
the inline form is suppressed.
Additionally, a parameter description is tagged on as a comment.

LASERON(DataSet1,200,PULSE) ;WeldingDataSet,Dis
WeavePattern

3.4.4.4 FCT
Formatting is carried out in the form of a KRL function call. Irrespective of its format,
the value of the first box (PARAM[1]) is presented as a fixed text and used as the
name of the function. The other parameters are reduced to the contents of the input
boxes, separated by commas and contained within brackets. The dot separating
the name of the technology and the name of the inline form is suppressed. An
equals sign is inserted between the form name and the function name.

LASERON=DataSet1(200,PULSE)
3.4.4.5 DFCT
Formatting is carried out in the form of a KRL function call. Irrespective of its format,
the value of the first box (PARAM[1]) is presented as a fixed text and used as the
name of the function. The other parameters are reduced to the contents of the input
boxes, separated by commas and contained within brackets. The dot separating
the name of the technology and the name of the inline form is suppressed. An
equals sign is inserted between the form name and the function name.
Additionally, a parameter description is tagged on as a comment.

LASERON=DataSet1(200,PULSE);Distance[mm],WeavePattern
3.4.4.6 ASS
Formatting is carried out in the form of an assignment. The parameters are reduced
to the contents of the input boxes and separated by commas. An equals sign is
inserted between the form name and the parameter list. The point of separation
between the name of the technology and the name of the inline form is suppressed.

LASERON=DataSet1,200,PULSE
3.4.4.7 ASSAGG
Formatting is carried out in the form of an aggregate assignment. The parameters
are reduced to the contents of the input boxes, preceded by the text entered under
SHORTNAME[], separated by commas and contained within braces. An equals
sign is inserted between the name of the inline form and the parameter block.

UserTech 2.1
Example
DEFTP SEARCH
DECL PARAM XDir={Shortname[] “X=”, Value {Number: },Unit[] “mm”}

DECL PARAM YDir={Shortname[] “Y=”, Value {Number: },Unit[] “mm”}
DECL PARAM ZDir={Shortname[] “Z=”, Value {Number: },Unit[] “mm”}
DECL InlineForm Direction={PARAM[1] XDir ,PARAM[2] YDir,PARAM[3] ZDir,STYLE _

ASSAGG}
ENDTP
The above inline form corresponds to command line 5:
3.4.5 ONACCEPT
An inline form event. The name of the script that is to be executed after pressing the
“Enter” key or the softkey “Cmd Ok” can be entered here.
3.4.6 ONTOUCHUP
An inline form event. The name of the script that is to be executed after pressing the
softkey “TouchUp” can be entered here.
3.4.7 ONOPEN
An inline form event. The name of the script that is to be executed after the inline form
is opened can be entered here.

3.5 Input, display and list boxes

Input, display and list boxes in inline forms are defined as follows:
Syntax
DECL PARAM Name={ 〈SHORTNAME[] “String”,〉
〈SHORTCUT[] “String”,〉
〈UNIT[] “String”,〉
〈ENABLE Bool,〉
〈USERMODE Int,〉
VALUE FieldDescription }
3.5.1 SHORTNAME
Text entered here appears in front of the input box.
In the example: “Distance=”.
3.5.2 SHORTCUT
Text entered here appears on the +/-- status key (at the bottom right of the display).
In the example: “DIST”.
If no text is entered here, the text entered under SHORTNAME appears on the status
key.
3.5.3 UNIT
Text entered here appears behind the input box.
In the example: “mm”.
3.5.4 ENABLE
This property activates or deactivates the box.
3.5.5 USERMODE
Not implemented.

UserTech 2.1
3.5.6 VALUE FieldDescription

Description of the input box to be displayed in terms of type and other characteristics.
The following options are available:
3.5.6.1 The type {static: }
Static text which cannot be edited by the user.
The correct syntax is:
{STATIC: DEFAULT[] “String”}
“String” contains the text that is displayed.
Example
decl param field_sta ={value _

{static: default[] “This can’t be changed”}}
generates this output box in the inline form:
The text that is displayed cannot be altered.
3.5.6.2 The type {free: }

Input box for text that can be entered freely and edited using the ASCII keypad.
{FREE: 〈DEFAULT[] “String”〉 }
By default, the input box contains the entry “String”.
Example
decl param field_fre ={shortname[] “Programmer: ”, _

{free: default[] “ Alfred E. Neumann ”}}
generates this input box in the inline form:
The default text can be altered. Entering a text is optional.
3.5.6.3 The type {name: }

Text representing a valid KRL variable name. It can be edited using the ASCII keypad. If the
last character entered is a digit (0 to 9), this can be incremented and decremented using the
plus/minus key.

{NAME: DEFAULT[] “Name”}

By default, the input box contains the entry “Name”.
Example
decl param field_nam ={
shortname[] “Welding point no.: ”, _
shortcut[] “WPT”, value _
{name: default[] “WPT1”}}
The preset KRL variable name can be altered.

The +/-- status key here bears the label “WPT” specified in “shortcut[]”.
Pressing this status key, the first digit from the right can be incremented or
decremented. This is useful when designating points.
Parameters of type {name:} ending in a digit are automatically incremented by 1 if a new inline
form is created.
No check is carried out to see whether parameter names already exist.
3.5.6.4 The type {number: }
Integer value with optional upper and lower limits and increment. It can be edited using either
the numeric keypad or the plus/minus key.
{NUMBER: 〈MIN Int,〉 〈MAX Int,〉 〈STEP Int,〉 〈DEFAULT Int,〉

〈AUTOLIMIT Bool〉 }
MIN Minimum value

MAX Maximum value
STEP Amount by which the value is incremented and decremented using the
plus/minus key. The default value is 1.
DEFAULT Default entry in the input box. The default value is 0.
AUTOLIMIT This automatically sets an incorrectly entered value to the minimum or
maximum value. The default value is TRUE.

UserTech 2.1
Example
decl param field_num ={
shortname[] “Distance: ”, _
shortcut[] “DIST”, _
unit[] “mm”, _
value _
{number: min 0, max 100, step 2, default 50,}}
generates this numeric box in the inline form:
The +/-- status key here bears the label “NUM” specified in “shortcut[]”. A value
between 0 and 100 can be entered in this numeric box (50 appears as the default
value). Pressing the +/-- status key increases or decreases this value in increments
of 2.
3.5.6.5 The type {real: }
Floating point value with optional upper and lower limits and increment. It can be edited using
either the numeric keypad or the plus/minus key.
{REAL: 〈MIN Real,〉 〈MAX Real,〉 〈STEP Real,〉 〈DEFAULT Real,〉
〈AUTOLIMIT Bool〉 }
MIN Minimum value

MAX Maximum value
STEP Amount by which the value is incremented and decremented using the
plus/minus key. The default value is 0.1.
DEFAULT Default entry in the input box. The default value is 0.
AUTOLIMIT This automatically sets an incorrectly entered value to the minimum or
maximum value. The default value is TRUE.
Example
decl param field_rea ={
shortname[] “Delay: ”, _
shortcut[] “DELAY”, _
unit[] “secs”, _
value _
{real: min 0.5, max 5,step 0.5, default 2}}
The +/-- status key here bears the label “DELAY” specified in “shortcut[]”. A value
between 0.5 and 5 can be entered in this box (5 appears as the default value). Pressing
the +/-- status key increases or decreases this value in increments of 0.5.

3.5.6.6 The type {list: }

List of static texts which cannot be edited. List entries can be selected using the plus/minus
key.
{LIST: 〈DEFAULT[] “String”,〉
〈POS Int,〉
ITEM[1] ItemDescription,
〈ITEM[2] ItemDescription,〉
〈...,〉
〈ITEM[n] ItemDescription〉 }
DEFAULT Specification of the string that is to appear by default in the list window.
The string must correspond to a defined ItemDescription string.
DEFAULT is an alternative to POS.
POS Number of the list entry that is to appear by default in the list window.
ITEM[n] Description of list entry n.
ItemDescription (list entry)

The complete syntax is:
{ITEM: VALUE[] “String” 〈, DISP[] “String”〉 }
You can use the parameter “disp” to distinguish between displayed text and text that
is actually processed in the program. This enables you to process a text other than
the one displayed. The actual value is entered after value[ ] while the displayed value
is entered after disp[ ]. By default: disp[ ] = value[ ].
Example 1:
decl param field_lis ={
shortname[] “Weave pattern: ”, _
shortcut[] “PATT”,value _
{list: pos 1, _
item[1] _
{item: value[] “Triangle”}, _
item[2] _
{item: value[] “Trapezoid”}, _
item[3] _
{item: value[] “Sinus”}}}
generates this list box in the inline form:

UserTech 2.1
The +/-- status key here bears the label “PATT” specified in “shortcut[]”. This
list box can be used to select one of the preset options (the first item in the list,
“Triangle”, appears as the default value). Pressing the “+/--” status key switches
between the preset items in the list box.
Example 2:
Using the disp[ ] option: a distinction is made between the values displayed in the list
box and the actual processed values.
deftp MyTech={ SOC true}

decl param field_lis ={ shortname[] “Weave pattern: ”, shortcut[] “PATT”, _
value {LIST: _
item[1] {item: value[] “3”,disp[] “Triangle”}, _
item[2] {item: value[] “Trapezoid”}, _
item[3] {item: value[] “Sinus”}}}
decl fold MyFold[1]
MyFold[1]= “Hugo=%field_lis”
decl InlineForm MyCmd={ FOLD[1] MyFold , param[1] field_lis}
endtp
The following inline form is obtained:
The text “Triangle” appears in the resulting KRL command line while the value 3 is assigned
to the Fold of the global variable Hugo:

3.6 Parameter lists

Inline forms use parameter lists for the entry of parameters. UserTech makes it possible to
create customized parameter lists.
The parameter list is defined in a KFD file which must be saved in the directory
“C:\KRC\TP\USERTECH\TEMPLATE”.
The following conditions must be met:
G No units may be entered for parameter names.
G Only one parameter list may be configured per inline form.
G The parameter list and its parameters must be part of a technology package (global
parameter lists are not possible).
The file MyTech.kfd (on which the following explanations are based) is located in the target
directory “C:\KRC\TP\USERTECH\TEMPLATE” and is an example with eight parameters.
The example illustrates the required structure of the file.
Fig. 1 illustrates the elements from the parameter list that are displayed when UserTech
inserts the example file MyTech.kfd.
We strongly recommend retaining the existing structure of the example file MyTech.kfd.
Parameters and other contents that are not described here are for internal purposes
only and should be left unchanged in order to ensure the correct functioning of the file.
KRL variable name

Title
Designation
Shortname
Unit
Default value
Fig. 1 Parameter list

UserTech 2.1
3.6.1 Assigning a parameter list

The first line of the KFD file specifies a parameter list “ParamList=” for the KRL variable name
and its designation in the inline form.
In the following example, the designation = “Val” and the KRL variable name = “val1”:
Decl PARAM ParamList={SHORTNAME[] “Val: ”,VALUE
{Name: DEFAULT[] “val1”}}
3.6.2 Parameter list properties

The parameter “LsrTool” describes the properties of the parameter list and must begin with
“PL_”.
The parameter is defined as “PL_LsrTool” in the following example:
Decl PARAM PL_LsrTool = {SHORTNAME[] “PLTOOL”, VAR[]

“LSC_TOOL_TYP”, SHORTCUT[] “LT”, UNIT[] “TOOL” ,Value {FREE:
DEFAULT[] “_”}}
3.6.3 Title
Title of the parameter list -- appears at the top left--hand side of the parameter list (see Fig. 1).
In the following example, the parameter list is given the title “PLTOOL”:
Decl PARAM PL_LsrTool = {SHORTNAME[] “PLTOOL”, VAR[]

“LSC_TOOL_TYP”, SHORTCUT[] “LT”, UNIT[] “TOOL” ,Value
{FREE: DEFAULT[] “_”}}
3.6.4 Shortname
A descriptive parameter name appears top left as the label of an individual section (see
Fig. 1).
The name “Minimum Power” is assigned in the following example:
Decl PARAM LSR_MIN_PWR = {SHORTNAME[] “Minimum Power”,

VALUE {NUMBER:MIN 0, MAX 20000, STEP 100 , AUTOLIMIT TRUE,
DEFAULT 2000}, UNIT[] “W”, SHORTCUT[] “MINP” }
3.6.5 Min/Max
Min and Max define the permissible range of values for the parameter.
In the following example, the values Min 0 and Max 2000 are defined for “Minimum
Power”:

3.6.6 Step
For each parameter, Step defines the increment for the entry of values using the status keys.
Fig. 2 Status keys

“STEP 100” in the following example means that the value is increased or decreased by
increments of 100 units:
3.6.7 Shortcut
The abbreviation used to label the status keys is defined under Shortcut.
In the following example, “MINP” is used for “Minimum Power” (see Fig. 2):
3.6.8 Autolimit
If a value is entered that exceeds the maximum permissible value, Autolimit causes the value
defined under Max to be entered.
The parameter can be defined as FALSE or TRUE.
In the following example for “Minimum Power”, “AUTOLIMIT TRUE” has been set:
3.6.9 Default value

The default value specifies the entry that must initially be present in the parameter list (see
Fig. 1).
In the following example, the value “DEFAULT 2000” is set for LSR_MIN_PWR:

UserTech 2.1
3.6.10 Unit
“Unit” defines the unit of the value entered for the specific parameter (see Fig. 1).
In the example, “W” signifies the laser power in watts:
3.6.11 Filling the parameter list with parameters

The parameter list “LsrTool[]” is declared in the following example.
The number of enabled parameters must be specified in the square brackets, followed by
the assignment to the parameter list declared at the start of the KFD file (see 3.6.1) as “-->
ParamList”:
DECL PLIST LsrTool[8] -> ParamList

LsrTool[1] = LSR_MAX_PWR
LsrTool[2] = LSR_MIN_PWR
LsrTool[3] = LSR_PRG
LsrTool[4] = SNSR_PRG
LsrTool[5] = GAS_PRESSURE
LsrTool[6] = GAS_PRE_FLOW
LsrTool[7] = GAS_POST_FLOW
LsrTool[8] = LSR_DELAY
The parameters are then listed in the desired order. This is the order in which they are
displayed in the parameter list.
The eight parameters are listed in the following example, and the sequence is defined by
means of the number in the square brackets.
A valid parameter name must be entered after the equals sign. This parameter must be a
component of an installed technology package. Each parameter must first be configured for
the parameter list (see 3.6.5 to 3.6.10).
In the following example, the parameter “LSR_MAX_PWR” is entered; this parameter will
be displayed as the first parameter in the parameter list, with the designation “Maximum
Power”:

3.6.12 Adaptation of $config.dat

The extensions from the example must be inserted in the user section “Userdefined Types”
of the $config.dat file.
;The next two lines must be inserted in $Config.dat to use this
example!
;
;STRUC LSC_TOOL_TYP INT LSR_MAX_PWR,INT LSR_MIN_PWR,INT
LSR_Prg,REAL SNSR_Prg,INT SNSR_State,REAL GAS_Pressure,INT
LSR_Dly,INT GAS_Pre_Flow,INT GAS_Post_Flow
;DECL LSC_TOOL_TYP LTDEFAULT={LSR_MAX_PWR 500,LSR_MIN_PWR
50,LSR_Prg 1,SNSR_Prg 1.0,SNSR_State 0,GAS_Pressure 1.0,LSR_Dly
100,GAS_Pre_Flow 0,GAS_Post_Flow 0}
The extensions must be inserted in the user section of the $config.dat file to prevent them
from being lost in the event of a controller update.
The following example contains an extract from $config.dat with the extensions inserted:
...
;ENDFOLD (INTERNAL SYSTEM CONTROL)
;ENDFOLD (LASERWELD GLOBALS)
;FOLD USER GLOBALS
;*******************************************
;Make your modifications --ONLY-- here
;*******************************************
;==================================
; Userdefined Types
;==================================
STRUC LSC_TOOL_TYP INT LSR_MAX_PWR,INT LSR_MIN_PWR,INT LSR_Prg,REAL
SNSR_Prg,INT SNSR_State,REAL GAS_Pressure,INT LSR_Dly,INT GAS_Pre_Flow,INT
GAS_Post_Flow
DECL LSC_TOOL_TYP LTDEFAULT={LSR_MAX_PWR 500,LSR_MIN_PWR
50,LSR_Prg 1,SNSR_Prg 1.0,SNSR_State 0,GAS_Pressure 1.0,LSR_Dly
100,GAS_Pre_Flow 0,GAS_Post_Flow 0}
;==================================
; Userdefined Externals
;==================================
;==================================
; Userdefined Variables
;==================================
;ENDFOLD (USER GLOBALS)

ENDDAT

UserTech 2.1
3.7 FOLDS
The KUKA user interface uses a special technique to display a KRL program clearly.
Instructions in the form of KRL comments make it possible to suppress parts of the program.
In this way the program is subdivided into meaningful sections, called “FOLDS” due to their
folder--like nature.
USERTech is able to generate such “FOLDS”, according to your specifications,
independently. To do this, the framework of the FOLD in which your data are to be entered
must be defined as follows:
Syntax
DECL FOLD NAME[n]

NAME[1]=“String”
...
〈 NAME[n]=“String” 〉
n Number of KRL lines
Each element of this array represents one line in the contents of the future FOLD. All
parameter reference placeholders (%Name) in the character sequence “String” are replaced
by the current values, or the values you have entered, in the inline form. The predefined
parameters “application program name” (%MODULE), “technology name” (%TP) and “inline
form name” (%INLINEFORM) can be used for the generation of KRL Folds.
Example
DECL FOLD MyFold[2]

MyFold[1]=“Laser(#%INLINEFORM , %DataSet ,%Pattern )”
MyFold[2]=“TRIGGER WHEN DISTANCE=%DistanceWay DELAY=0 DO _
LASER_ON=TRUE”
Result:
(if DataSet=“DataSet6”; DistanceWay=210; Pattern=“STEP”; Inlineform=“ON”)
Laser(#ON,DatSet6,STEP)
TRIGGER WHEN DISTANCE=210 DELAY=0 DO LASER_ON=TRUE

3.8 Status keys

UserTech allows the free assignment of four status keys on the KCP.
1
2
3
4
This is done in several steps:

G Labeling of the individual status key(s)
G Labeling of the entire status key bar
G Programming of the scripts which are combined with operator actions in the status
keys
3.8.1 Creating new status keys
DECL STATKEY Name= {〈TOPTEXT[] String,〉
〈CENTERTEXT[] String,〉
〈BOTTOMTEXT[] String,〉
〈PICTURE[] String,〉
〈KEYDOWN_PICTURE[] String,〉
〈KEYDOWNMINUS_PICTURE[] String,〉
〈ENABLE Bool,〉
〈NEED_SAFETYSWITCH Bool,〉
〈NEED_DRIVESOK Bool,〉
〈NEED_PROSTATE0 Int,〉
〈NEED_PROSTATE Int,〉
〈NEED_MODEOP Int,〉

UserTech 2.1
〈USERMODE Int,〉
〈STYLE #SWITCH|#TOGGLE,〉
〈ONKEYDOWN Name,〉
〈ONKEYUP Name,〉
〈ONKEYSHOW Name,〉
〈ONKEYDOWNMINUS Name,〉
〈ONKEYUPMINUS Name,〉
〈ONKEYREPEAT Name, 〉
〈ONKEYREPEATMINUS Name, 〉
〈NEXT Name〉 }
3.8.1.1 TOPTEXT
Text entered here appears horizontally centered in the upper part of the status key.
3.8.1.2 CENTERTEXT
Text entered here appears horizontally centered in the middle part of the status key.
3.8.1.3 BOTTOMTEXT
Text entered here appears horizontally centered in the lower part of the status key.
3.8.1.4 PICTURE
Specification of the path for the bit--mapped picture1) to be displayed on the status key.
A 34 × 48 pixel bit map is required for a single softkey, and a 34 × 128 pixel bit map
for a double softkey.
To create the pictures, you can use MS Paint which comes as part of the Windows 95
operating system.
1) It is better to use icons ( *.ico ) in order to avoid undesired effects when fading out a status
key.

3.8.1.5 KEYDOWN_PICTURE
Specification of the path for the bit--mapped picture1) to be displayed on the pressed
“Plus” status key.
operating system.
If no bit map is entered for KEYDOWN_PICTURE, the bit map entered under
PICTURE is displayed.
key.
3.8.1.6 KEYDOWNMINUS_PICTURE
Specification of the path for the bit--mapped picture1) to be displayed on the pressed
“Minus” status key.
operating system.
If no bit map is entered for KEYDOWNMINUS_PICTURE, the bit map entered under
PICTURE is displayed.
key.
3.8.1.7 ENABLE
This property activates or deactivates the status key. This is also dependent on the
values of the parameters NEED_SAFETYSWITCH, NEED_MODEOP, NEED_
DRIVESOK, NEED_PROSTATE0 and NEED_PROSTATE.
3.8.1.8 NEED_SAFETYSWITCH
This parameter makes operator control of the status key dependent on the enabling
switch (on the rear of the KCP) being pressed.
The default setting is the value FALSE.
3.8.1.9 NEED_DRIVESOK
This parameter makes operator control of the status key dependent on the drives
being switched on.
The default setting is the value FALSE.

UserTech 2.1
3.8.1.10 NEED_MODEOP
This parameter makes operator control of the status key dependent on the selected
operating mode.
The integer value represents a bit sequence:
UNKNOWN
Automatic
T2 mode
T1 mode
External
Operating mode
Bit number 4 3 2 1 0
Binary value (default) 0 0 I I I
Decimal value 7
For bit number “n” and corresponding binary value “1”, the decimal value is 2n.
In the example:
The value 7 means that the status key can be used in operating modes T1 and
T2.
The default value 15 means that the status key is available in operating modes T1,
T2 and Automatic.
The value 31 has the effect that the status keys are available in Automatic Exernal
mode.
3.8.1.11 NEED_PROSTATE0
This parameter makes operator control of the status key dependent on the operating
state of the “Submit Interpreter”.
UNKNOWN
ACTIVE
RESET
STOP
FREE
END
Operating mode
Bit number 5 4 3 2 1 0
Binary value (default) I 0 0 0 0 0
Decimal value 32
In the example:
The value 32 makes the status key available only when the “Submit Interpreter”
is running.
The default setting is the value 32.

3.8.1.12 NEED_PROSTATE
This parameter makes operator control of the status key dependent on the operating
state of the “Robot Interpreter”.
UNKNOWN
ACTIVE
RESET
STOP
FREE
END
Operating mode
Bit number 5 4 3 2 1 0
Binary value (default) 0 I I I I 0
Decimal value 30
In the example:
The value 30 means that the status key is available only when the Start key is
released.
The default setting is the value 30.
3.8.1.13 USERMODE
Identification number of the lowest user level at which this status key can be used.
More detailed information about user levels can be found in the documentation
[Configuring the system].
The default value is 0. This means that the status key can be used at every user level.
3.8.1.14 STYLE
The options specified here influence the appearance of the status key.
#SWITCH
The default setting. The KCP key on the left--hand side is assigned to the status
key.
#TOGGLE
The status key is represented as a double key. The upper KCP key is considered
as the “Plus” key, and the lower KCP key as the “Minus” key.
3.8.1.15 ONKEYDOWN
A status key event. The name of the script that is to be executed after pressing the
“Plus” key can be entered here.
3.8.1.16 ONKEYUP
A status key event. The name of the script that is to be executed after releasing the
“Plus” key can be entered here.

UserTech 2.1
3.8.1.17 ONKEYSHOW
A status key event. The name of the script that is to be executed after the appearance
of the status key can be entered here.
3.8.1.18 ONKEYDOWNMINUS
A status key event. The name of the script that is to be executed after pressing the
“Minus” key can be entered here.
3.8.1.19 ONKEYUPMINUS
A status key event. The name of the script that is to be executed after releasing the
“Minus” key can be entered here.
3.8.1.20 ONKEYREPEAT
A status key event. The name of the script that is to be executed after holding down
the “Plus” key can be entered here. This event is repeatedly triggered until the key is
released. The interval between repetitions becomes shorter and shorter.
3.8.1.21 ONKEYREPEATMINUS
A status key event. The name of the script that is to be executed after holding down
the “Minus” key can be entered here. This event is repeatedly triggered until the key
is released. The interval between repetitions becomes shorter and shorter.
3.8.1.22 NEXT
Name of the following status key or status key bar.
3.8.2 Reassigning status keys that have already been declared
SET Name = {〈TOPTEXT[] String,〉
〈CENTERTEXT[] String,〉
〈BOTTOMTEXT[] String,〉
〈PICTURE[] String,〉
〈KEYDOWN_PICTURE[] String,〉
〈KEYDOWNMINUS_PICTURE[] String,〉
〈ENABLE Bool,〉
〈NEED_SAFETYSWITCH Bool,〉
〈NEED_DRIVESOK Bool,〉
〈NEED_PROSTATE0 Int,〉

〈NEED_PROSTATE Int,〉
〈NEED_MODEOP Int,〉
〈USERMODE Int,〉
〈STYLE #SWITCH|#TOGGLE,〉
〈ONKEYDOWN Name,〉
〈ONKEYUP Name,〉
〈ONKEYSHOW Name,〉
〈ONKEYDOWNMINUS Name,〉
〈ONKEYUPMINUS Name,〉
〈ONKEYREPEAT Name, 〉
〈ONKEYREPEATMINUS Name, 〉
〈NEXT Name〉 }
This instruction can be used within or outside scripts. When used within scripts, placeholders
which received their value assignment before execution of the script (e.g. %INLINEFORM)
can also be used.
3.8.3 Creating a status key bar
DECL STATKEYBAR Name = {〈STATKEY[1] Name,〉
〈STATKEY[2] Name,〉
〈STATKEY[4] Name 〉 }
STATKEY [n]
Name of the status key to be displayed at position [n] of the status key bar.
3.8.4 Reassigning status key bars that have already been declared
SET Name = {〈STATKEY[1] Name,〉

〈STATKEY[4] Name 〉 }

UserTech 2.1
3.9 Scripts
Scripts are programs with special functions for communicating with the kernel system.
The definition of a script must be initiated within the KFD file using the statement:
DEFSCRIPT Name
and terminated using the statement:
ENDSCRIPT
Scripts cannot be nested. Only the keywords listed below can be used.
3.9.1 SETVAR
Sets or writes a value to a KRL variable in the kernel system.
Syntax
SETVAR (FULLPATH[] “String”, VALUE[] “String”)
FULLPATH
Variable name of the variable to be written or set.
All parameter reference placeholders (e.g. %Placeholder) in the
character string are replaced by their current values. The resulting
character string is interpreted as a variable name with path specification.
VALUE
Value to be assigned to the variable.
All parameter reference placeholders (e.g. %PLACEHOLDER) in the
character string is interpreted as a target value.
If the specified variable or reference does not exist, or if the target value is incompatible
with the variable type, the script is canceled and an error message is generated in the
message window.
Example
DEFTP MyTech
DEFSCRIPT Example
SETVAR( FULLPATH[] “$OUT[20]” , VALUE[] “TRUE”)
ENDSCRIPT
ENDTP
Once the script “Example” has been executed, the following applies:
$OUT[20]==TRUE.

3.9.2 SHOWVAR
Reads a KRL variable from the kernel system.
Syntax
SHOWVAR (FULLPATH[] “String”, PARAM Name)
FULLPATH
Variable name of the variable to be read.
PARAM
Name of the parameter into which the value found under FULLPATH[]
is written.
If the specified variable or reference does not exist, or if the target value is incompatible
with the variable type, the script is canceled and an error message is generated in the
message window.
Example
DEFTP MyTech
DECL PARAM MyParam ={VALUE {FREE: DEFAULT[] “”}}
DEFSCRIPT Example
SHOWVAR( FULLPATH[] “$MODE_OP” , PARAM MyParam)
MESSAGE “$MODE_OP=%MyParam”
ENDSCRIPT
ENDTP
If the script “Example” is executed when the program “Test.src” is open or selected in T1
mode, the following display appears in the message window:

UserTech 2.1
3.9.3 REDECL
Creates or overwrites a KRL variable in the kernel system.
Syntax:
REDECL (PATH[] “String”, DECLARATION[] “String”)
PATH
Path name of the new variable.
DECLARATION
Declaration of the new variable.
character string is interpreted as a target value.
If the specified variable already exists, but is of a different type, or the declaration section
is incorrectly programmed or is incompatible with the variable type of the parameter, the
script is canceled and an error message is generated in the message window.
Example
DEFTP MyTech
DEFSCRIPT Example
REDECL( PATH[] “%MODULE” , _

DECLARATION[] “DECL AXIS HOME={A1 0, A2 --90, A3 90, A4 0, A5 0, A6 0 }”)
ENDSCRIPT
ENDTP
Once the script “Example” has been executed with the program “Test.src” open or selected,
the variable “HOME” is created in the .dat file if the file “Test.dat” exists.

3.9.4 DO
Calls a script.
Syntax:
DO Name
Name Name of the script to be executed
If an error occurs while this script is being executed, the calling script is also
canceled.
3.9.5 SET
Redefining status keys and status key bars already declared. The syntax is described
in the chapter “Status keys”.
3.9.6 MESSAGE
Generates a one--line text in the message window.
Syntax:
MESSAGE “String”
character string are replaced by their current values. The character string
is then used as a key for the language database. In order to be able to
access this database successfully, it must contain a module with the
name of the technology package in which the script was defined. In the
case of global scripts, the module KUKATPUSERGlobal is accessed. If
access to the language database fails, the key itself is displayed in the
message window. The name of the technology which contains the script
currently being executed is displayed in the column “Source”.
In the case of parameterized outputs, the parameters must be tagged on
to the key, separated by the “|” character.
3.9.7 SWITCH...CASE(ELSE)...ENDSWITCH
Control structure for the conditional calling of scripts. After the keyword SWITCH, the
name of a variable is specified which is interrogated on entering the control structure.
Depending on the result of this interrogation, one of the prepared branches is
automatically selected. If no prepared branch is found, the CASE ELSE branch is
automatically selected. Nesting of SWITCH...CASE(ELSE)..ENDSWITCH blocks is
not possible.
Syntax:
SWITCH InterrogationString
CASE “ResultString” DO Name
...
CASE ELSE DO Name
ENDSWITCH

UserTech 2.1
InterrogationString
Two predefined keywords can also be used for InterrogationString:
ISCHANGE is TRUE if an inline form has been changed.
DOALWAYS is TRUE if toggling between 2 inline forms has occurred.
Application examples can be found in the chapter “Programming
examples”.
ResultString
Name
Name of the script to be executed.
If an error occurs during execution, the calling script is also canceled.
3.9.8 SWITCH DIALOG...CASE...ENDSWITCH

Generates a user dialog in the message window and calls a script according to the
response to the dialog.
Between two and seven branches must be programmed within this structure,
corresponding to the softkeys in the lower bar from right to left.
Syntax:
SWITCH DIALOG “QuestionString”
CASE “AnswerString1” DO Name1
CASE 〈“AnswerString2” DO Name2〉
CASE “AnswerString7” DO Name
ENDSWITCH
QuestionString
character string is displayed as a dialog text in the message window.
If a language database key with the same name exists, QuestionString
is translated into the active language before being displayed.

AnswerString
The label for the corresponding softkey. The character string is then
used as a key for the language database. If access to the language
database fails, the key itself is displayed in the message window. To
generate a blank softkey, simply leave this specification out.
Name
Name of the script to be executed.
If specified, the script “Name” is executed when the corresponding
softkey is pressed by the user. Script execution is then resumed after
ENDSWITCH.
If “Name” is not specified, script execution is again resumed after
ENDSWITCH.
If an error occurs during execution, the calling script is also canceled.
Only CASE and DO statements are permissible within the SWITCH DIALOG ENDSWITCH
block. The SWITCH DIALOG ENDSWITCH block cannot be nested.
QuestionString and AnswerString are both translated into the currently active language by
means of language database keys. In order to do this, a module with the name of the
technology package in which the script was defined must be created in the language
database. If the script is defined globally, an attempt is made to access the language
database module “KUKATPUSERGlobal”.
The answer softkeys are translated individually. This means that the corresponding key must
be created in the database for each individual softkey.
If access to the language database fails, the dialog or softkey is not translated and is
displayed unchanged.
In the case of parameterized translations, all parameters must be tagged on to the actual key,
separated by the “|” character. The translated text and the parameters are then combined
in the language database.
3.9.9 Predefined scripts
3.9.9.1 ACCEPTINLINEFORM
This script closes the open inline form, accepts the modified parameters and inserts
or replaces the KRL program section.
3.9.9.2 CANCELINLINEFORM
This script closes the open inline form, but does not accept the modified parameters
and does not insert any KRL program section.
3.9.9.3 END
This script serves to abort or terminate a script that is running.
3.9.9.4 NOTHING

UserTech 2.1
This script is blank and cancels the original assignment of a script.

4 Integrating technologies in the graphical user interface (GUI)
4 Integrating technologies in the graphical user interface (GUI)

The integration of user technologies is carried out by means of entries in the file
MenueKeyUser.INI in the directory C:\Krc\Roboter\Init.
New softkeys and menus can be defined in the section [SOFTKEYS].
Syntax:
skName = dbKey, ProcId, ProcName, ProcParam, NextLineType, NextLineId, UserLevel
skName: Softkey identifier, programmer’s name for the technology

dbKey: Language database key for the softkey label
ProcId: Function number
ProcName: Name of the function module using the following syntax:
KUKATPUSER; TP; Command
TP: Name of the technology package
Command: Technology package command displayed by default
ProcParam: Parameter string without quotation marks
NextLineType: Type of the next softkey bar:
NOLINE: There is no following softkey line. This is the default setting
POPUP: A pop--up menu is next
NextLineId: Name of the pop--up menu
UserLevel: Identification number of the lowest user level at which this softkey is available
4.1 Creating a submenu in the menu bar

To generate a submenu in the menu bar, carry out the following steps in the order given:
G Add your entry to the file section [SOFTKEYS] using the following format:
Submenu_name = Label,,,,POPUP,List_of_entries
G Define the entry list in the file section [MENU]:
List_of_entries=First_Option, Second_Option, Third_Option
G Enter the menu options in the file section [SOFTKEYS]:
a) Call inline form

To call an inline form using this submenu entry
First_Option = Label,11,TECHPACK,KUKATPUSER;_
Technology_Name;Inline_Form_Name
b) Call status key bar

To call a status key bar using this submenu entry
First_Option = Label,11,USERSTATKEYBAROCX;_
KUKATPUSER;Technology_Name.Status_Key_Bar_Name
c) Call status key

UserTech 2.1
To call a status key using this submenu entry

First_Option = Label,11,USERSTATKEYBAROCX;_
KUKATPUSER;Technology_Name.Status_Key_Name;Position
G The main menu in which the new menu item is to appear is specified in the section
[MOVE]:
a) Insert in Technology menu:
Submenu_Name = ,MENU#mTechnology,x
x represents the position of the new menu item in the main menu, 0 being the
uppermost position.
a) Insert in Status keys menu:
Submenu_Name = ,MENU#mTechstatuskeys,x
x represents the position of the new menu item in the main menu, 0 being the
uppermost position.
The new submenu item is available once the altered file has been saved and the GUI has
been reinitialized.
4.2 Examples of integration of a technology in a menu

4.2.1 Simple submenu
The technology “TWINKLE” is to be inserted into the Technology menu using the menu
item “BLINKTech”. By default, the technology package “TWINKLE” is to offer the function
“TWICE”.
For this, the following entries must be made in the file C:\Krc\Roboter\Init\MenueKey
User.ini:
[SOFTKEYS]
Flash_light=BLINKTech,,TECHPACK,KUKATPUSER;TWINKLE;TWICE,,,20
[MOVE]
Flash_light=,MENU#mTechnology,1
Explanations:
Flash_light:Programmer’s name for the technology
BLINKTech:The technology package is identified by this name in the pull--down menu
TWINKLE: Name of the technology package in the KFD file
TWICE: Technology package command that is to appear by default in the inline form
20: Lowest user level at which the technology package command is available
MENU#mTechnology: The new menu entry is to be tagged onto the Technology menu
1: Position of the entry in the pull--down menu (0 = uppermost position)

4 Integrating technologies in the graphical user interface (GUI) (Fortsetzung)
The menu selection above generates the following inline form:
The technology TWINKLE is defined as follows and must be stored in a KFD file in the
template directory:
DEFTP Twinkle
decl fold once[5]

once[1]=“/;flash once”
once[2]=“$out[5]=true”
once[3]=“wait sec 1.5”
once[4]=“$out[5]=false”
once[5]=“wait sec 1.5”
decl fold twice[9]

twice[1]=“/;flash twice”
twice[2]=“$out[5]=true”
twice[3]=“wait sec 1.5”
twice[4]=“$out[5]=false”
twice[6]=“$out[5]=true”
twice[8]=“$out[5]=false”
decl inlineform once = {fold[1] once}

decl inlineform twice = {fold[1] twice}
decl inlineform triple = {fold[1] once, fold[2] twice}
ENDTP

UserTech 2.1
4.2.2 Submenu with pop--up menu
A new submenu item with the designation “Submenu” is required in the “Technology” menu.
When this is selected, a pop--up menu should appear with the options “One”, “Two” and
“Three” available for selection. This menu will then be used for calling the 3 “TWINKLE”
technology inline forms.
When the file C:\Krc\Roboter\Init\MenueKeyUser.ini is opened, the system looks for the end
of the section [SOFTKEYS]. The following entries are made here:
[SOFTKEYS]
first_entry = One,2010,TECHPACK,KUKATPUSER;TWINKLE;ONCE
second_entry = Two,2010,TECHPACK,KUKATPUSER;TWINKLE;TWICE
third_entry = Three,2010,TECHPACK,KUKATPUSER;TWINKLE;TRIPLE
new_submenu = Submenu, , , ,POPUP,list_of_entries
The following entry is made at the beginning of the section [MENU]:

[MENU]
list_of_entries = first_entry, second_entry, third_entry
The following entry is then added to the section [MOVE]:

[MOVE]
new_submenu = ,MENU#mTechnology,6
This entry inserts the menu “Submenu” into the Technology menu in the seventh position.
The new submenu item is available once the altered INI file has been saved and the GUI has
been reinitialized:
The menu selection above generates the following inline form:

4 Integrating technologies in the graphical user interface (GUI) (Fortsetzung)
4.2.3 Example of integration of a technology via a status key

The technology “Purge” is to be integrated. It is to be possible to call this technology via a
status key. The KFD file has the following appearance:
Deftp PURGE_ADHESIVE
Decl statkey key4={TopText[] “Purge”,BottomText[] “ON”, _

picture[] “c:\krc\tp\usertech\template\bitmaps\Purge1.bmp”, _
need_prostate0 63 }
DefScript sc_KeyUp
SetVar(fullpath[] “$OUT[2]”, Value[] “FALSE”)
SetKey4={Picture[]“c:\krc\tp\usertech\template\bitmaps\Purge1.bmp”,
BottomText[] “ON” }
EndScript
DefScript sc_KeyDown
SetVar(fullpath[] “$OUT[2]”, Value[] “TRUE”)
SetKey4={Picture[]“c:\krc\tp\usertech\template\bitmaps\Purge2.bmp”,
BottomText[] “OFF” }
EndScript
Set key4={OnKeyDown sc_KeyDown, OnKeyUp sc_KeyUp}
Decl statkeybar bar4

Set bar4 ={statkey[4] key4}
Endtp
The file MenueKeyUser.ini must contain the following entries:

[SOFTKEYS]
userstat4=PURGE,11,USERSTATKEYBAROCX,KUKATPUSER;PURGE_ADHESIVE.bar
4
[MOVE]
userstat4=,MENU#mTechstatuskeys,0
Explanations:
userstat4: Programmer’s name for the technology
PURGE: The technology package is identified by this name in the pull--down menu
11: Function number of the status bar (always 11)
PURGE_ADHESIVE: Name of the technology package in the KFD file
bar4: Name of the status key bar for this technology
MENU#mTechstatuskeys: The new menu entry is to be tagged onto the Statuskeys
menu
0: Position of the entry in the pull--down menu (0 = uppermost position)
Once the INI file has been saved and the GUI has been reinitialized, the status key “Purge”
can be activated via the menu “Status keys”. It then appears in the bottom left--hand corner
of the GUI. Output 2 is set to TRUE while this status key is pressed.

UserTech 2.1
Purge
ON
4.3 File storage in a structured directory

By default, all KFD files are saved in the directory C:\KRC\TP\USERTECH\TEMPLATE. With
more complex applications, this can result in a loss of structure and clarity. For this reason,
it is optionally possible to store all the files belonging to a single technology in the directory
C:\KRC\TP\(TPName)\TEMPLATE\.
If you wish to do this, the following entry is required in the Windows registry.
Open the registry editor. In the section:
\HKEY_Local_Machine\Software\KUKARoboterGmbH\Options\KFD
the additional key: %InstallationDir%\TP\(TPName)\Template
must be added.
Example:
File path C:\KRC\TP\TestTech\Template\Test.KFD
Entry required in the registry:
Name TestTech
Value %InstallationDir%\TP\TestTech\Template

5 Programming examples
5 Programming examples
5.1 Programming status keys
The purpose of this program is to be able to set the brightness and contrast of the KCP
display using status keys. In order to do this, the system variables $PHGBRIGHT and
$PHGCONT must be altered.
A technology file must first be created and then saved in the directory
c:\krc\tp\usertech\template. It is given the file name DISP_SET.KFD.
The technology itself should also be named DISP_SET.
DEFTP disp_set
ENDTP
Next it is necessary to define which status keys are to make up the status key bar:
DEFTP disp_set
DECL STATKEYBAR bar = { STATKEY[1] brightness,
STATKEY[3] contrast }
ENDTP
The status keys themselves must be defined before the status key bar:
DEFTP disp_set
DECL STATKEY brightness = { PICTURE[] “c:\krc\tp\usertech\ _
template\bitmaps\phgbright.bmp”,_
ENABLE TRUE, _
USERMODE 10, _
STYLE #TOGGLE, _
ONKEYDOWN bright_hi, _
ONKEYDOWNMINUS bright_lo}
DECL STATKEY contrast = { PICTURE[] “c:\krc\tp\usertech\ _
template\bitmaps\phgcont.bmp”, _
ENABLE TRUE, _
USERMODE 10, _
STYLE #TOGGLE, _
ONKEYDOWN cont_hi, _
ONKEYDOWNMINUS cont_lo}
ENDTP
Before the status keys and status key bar are defined, the scripts which are called by the
events ONKEYDOWN and ONKEYDOWNMINUS must be defined:
DEFTP disp_set
DEFSCRIPT bright_hi
SHOWVAR(FULLPATH[] “$PHGBRIGHT”, PARAM bright)
SETVAR(FULLPATH[] “$PHGBRIGHT”, VALUE[] “%bright +1”)

UserTech 2.1
SHOWVAR(FULLPATH[] “$PHGCONT”, PARAM cont)

SHOWVAR(FULLPATH[] “$PHGTEMP”, PARAM temp)
MESSAGE “Brightness level: %bright contrast level: _
%cont display temperature: %temp °C”
ENDSCRIPT
DEFSCRIPT bright_lo
SETVAR(FULLPATH[] “$PHGBRIGHT”, VALUE[] “%bright -1”)
ENDSCRIPT
DEFSCRIPT cont_hi
SETVAR(FULLPATH[] “$PHGCONT”, VALUE[] “%cont +1”)
ENDSCRIPT
DEFSCRIPT cont_lo
SETVAR(FULLPATH[] “$PHGCONT”, VALUE[] “%cont -1”)
ENDSCRIPT
template\bitmaps\ _
phgbright.bmp”, _
ENABLE TRUE, _
USERMODE 10, _
STYLE #TOGGLE, _
ENABLE TRUE, _
USERMODE 10, _
STYLE #TOGGLE, _

5 Programming examples (Fortsetzung)
ENDTP
Finally, the parameters used in the scripts must be defined before the scripts:
DEFTP disp_set
DECL PARAM bright = {VALUE {NUMBER:}}
DECL PARAM cont = {VALUE {NUMBER:}}
DECL PARAM temp = {VALUE {NUMBER:}}
DEFSCRIPT bright_hi
SETVAR(FULLPATH[] “$PHGBRIGHT”, VALUE[] “%bright +1”)
ENDSCRIPT
DEFSCRIPT bright_lo
SETVAR(FULLPATH[] “$PHGBRIGHT”, VALUE[] “%bright -1”)
ENDSCRIPT
DEFSCRIPT cont_hi
SETVAR(FULLPATH[] “$PHGCONT”, VALUE[] “%cont +1”)
ENDSCRIPT
DEFSCRIPT cont_lo
SETVAR(FULLPATH[] “$PHGCONT”, VALUE[] “%cont -1”)

UserTech 2.1

ENDSCRIPT
template\bitmaps\phgbright.bmp”,_
ENABLE TRUE, _
USERMODE 10, _
STYLE #TOGGLE, _
ENABLE TRUE, _
USERMODE 10, _
STYLE #TOGGLE, _
DECL STATKEYBAR bar = { STATKEY[1] brightness, _
ENDTP
The following additions must be made in the file MenuKeyUser.ini in the directory
C:\Krc\Roboter\Init:
[SOFTKEYS]
DISPSET = DisplaySettings, 11, USERSTATKEYBAROCX, KUKATPUSER
;disp_set.bar; 1
[MOVE]
DISPSET=,MENU#mTechstatuskeys,0
This menu is available once the GUI has been reinitialized:

5.2 Programming inline forms

Program text
DEFTP LASER
DECL PARAM DataSet={SHORTNAME[] “WeldingDataSet=”, _
VALUE {NAME: DEFAULT[] “DataSet1”}, _
SHORTCUT[] “DATA”}
DECL PARAM DistanceWay={ SHORTNAME[] “Distance=”, _

VALUE {NUMBER: DEFAULT 200, MIN 0, MAX 500, _
STEP 10}, _
SHORTCUT[] “DIST”, UNIT[] “mm”}
DECL PARAM DelayTime={ SHORTNAME[] “Delay=”, _
VALUE {REAL:DEFAULT 0.8, MIN 0, MAX 20.3, _
STEP 0.3}, _
UNIT[] “ms”,SHORTCUT[] “DLY”}
DECL PARAM Pattern={ SHORTNAME[] “WeavePattern=”, _
VALUE {LIST: _ _
ITEM[1] {ITEM: VALUE[] “PULSE”}, _
ITEM[2] {ITEM: VALUE[] “STEP”}, _
ITEM[3] {ITEM: VALUE[] “CONT”} _
}, SHORTCUT[] “WPTN”}
DECL FOLD LasOn[2]
LasOn[1]=“Laser(#ON,%DataSet ,%Pattern )”
LasOn[2]=“TRIGGER WHEN DISTANCE=%DistanceWay _
DELAY=0 DO LASER_ON=TRUE”
DECL FOLD LasOff[2]
LasOff[1]=“Laser(#OFF)”
LasOff[2]=“TRIGGER WHEN DISTANCE=0 _
DELAY=%DelayTime _
DO LASER_ON=FALSE”
DECL InlineForm On={PARAM[1] DataSet ,PARAM[2] _
DistanceWay, PARAM[3] Pattern, FOLD[1] LasOn}
DECL InlineForm Off={PARAM[1] DelayTime, FOLD[1] LasOff}
ENDTP

UserTech 2.1
This produces the following inline forms:

5.3 Starting scripts by means of events

When defining an inline form, it is possible to specify the name of a script that is to be
executed if certain events occur, e.g. the opening or closing of an inline form.
Three examples are given below:
5.3.1 Case 1: Execute script when an inline form is opened or closed

The text “Fired when ILF is opened!” is to be displayed in the message window when an inline
form is opened and the text “Fired when ILF is closed!” is to be displayed following
confirmation by means of the Enter key or OK key:
Entries in MenueKeyUser.ini:
[SOFTKEYS]
Flash_lig=Tech,,TECHPACK,KUKATPUSER;test;TestILF,,,10
[MOVE]
Flash_lig=,MENU#mTechnology,1
Entries in the KFD file:
DEFTP test
;------------------------------------------
;------------ Scripts ----------
;------------------------------------------
DEFSCRIPT op_test
MESSAGE “Fired when ILF is opened !”
ENDSCRIPT
DEFSCRIPT cl_test
MESSAGE “Fired when ILF is closed !”
DO ACCEPTINLINEFORM
ENDSCRIPT
;------------------------------------------
;------------ FOLDs ------------
;------------------------------------------
DECL FOLD TestFold[1]

TestFold[1]=“/;only for testing ONOPEN--event”
;------------------------------------------------------
;------------ INLINEFORMs ------------
;------------------------------------------------------
DECL INLINEFORM TestILF={FOLD[1] TestFold, ONOPEN op_test, ONACCEPT

cl_test}
ENDTP

UserTech 2.1
The result:
5.3.2 Case 2: Execute script when an inline form is created or modified

The ONOPEN event is always triggered by default when an inline form is opened by means
of the CHANGE command.
If the user wants a certain script to be started only if a new inline form is inserted or if an
existing inline form is modified, he can use the SWITCH CASE statement with the keyword
ISCHANGE:
DEFTP test
;------------------------------------------
;------------ Scripts ----------
;------------------------------------------
DEFSCRIPT ch_test
MESSAGE “Fired only when ILF is changed !”
ENDSCRIPT
DEFSCRIPT new_test
MESSAGE “Fired only when ILF is created !”
ENDSCRIPT
DEFSCRIPT op_test
SWITCH “ISCHANGE”

CASE “TRUE” DO ch_test

CASE “FALSE” DO new_test
ENDSWITCH
ENDSCRIPT
DEFSCRIPT cl_test
MESSAGE “Fired when ILF is closed !”
DO ACCEPTINLINEFORM
ENDSCRIPT
;------------------------------------------
;------------ FOLDs ------------
;------------------------------------------

;------------------------------------------------------
;------------ INLINEFORMs ------------
;------------------------------------------------------
DECL INLINEFORM TestILF={FOLD[1] TestFold, ONOPEN op_test, ONACCEPT

cl_test}
ENDTP
5.3.3 Case 3: Execute script on toggling between inline forms within a technology
The ONOPEN event is triggered once by default on toggling between the different inline
forms within a technology.
If a script is to be started every time the user toggles between inline forms, this can be
achieved by means of the keyword DOALWAYS in a SWITCH CASE statement:
DEFTP test
;------------------------------------------
;------------ Scripts ----------
;------------------------------------------
DEFSCRIPT test_1
MESSAGE “Fired only once !”
ENDSCRIPT
DEFSCRIPT al_test
MESSAGE “Fired always !”
ENDSCRIPT
DEFSCRIPT test_2
SWITCH “DOALWAYS”
CASE “TRUE” DO al_test
ENDSWITCH
ENDSCRIPT
;------------------------------------------
;------------ FOLDs ------------
;------------------------------------------

UserTech 2.1

;------------------------------------------------------
;------------ INLINEFORMs ------------
;------------------------------------------------------
DECL INLINEFORM TestILF_1={FOLD[1] TestFold, ONOPEN test_1}

DECL INLINEFORM TestILF_2={FOLD[1] TestFold, ONOPEN test_2}
ENDTP

6 Appendix
6 Appendix
6.1 Typographical conventions
Example Explanation
Static syntax elements and keywords are printed as
DEFTP upper--case characters in bold type. They must be
used without modification.
Terms printed in italics must be replaced by user--
Name
specific information.
〈〉 Elements in angle brackets are optional.
The OR sign is used to separate mutually exclusive
|
options.
6.2 Parameters and parameter reference placeholders

The instruction “DECL PARAM Name = ...” is used to declare a parameter. If the user wants
the value of such a parameter to be displayed in a string, a special character is required
indicating that it is the value of the parameter that is to be displayed and not the text name
of the parameter. The percent sign “%” is used for this. An expression consisting of a percent
sign and a parameter name is referred to as a parameter reference placeholder.
6.2.1 Predefined parameter reference placeholders in KRL
6.2.1.1 %TP
The currently selected technology package, first parameter in every inline form.
6.2.1.2 %INLINEFORM
Name of the currently selected inline form, second parameter in every inline form.
6.2.1.3 %MODULE
Name of the application program currently loaded in the editor.
6.3 Data types
Data type Keyword Meaning Range of values

Integer INT Integer --231--1 ... 231--1
Real REAL Floating--point ±1.1E--38...±3.4E+38
number
Boolean BOOL Logic state TRUE, FALSE
Character CHAR Character ASCII character

UserTech 2.1
6.4 Names
The following restrictions apply when selecting a name:
G It may have a maximum length of 24 characters, including all characters added as
prefixes or suffixes by the system.
G It can consist of letters (A--Z), numbers (0--9) and the characters “_” and “$”
G It must not begin with a number.
G It must not be a keyword.
The first digit from the right can be altered while the program is running using the status key
+/--. This is useful when designating points.
The use of reserved KRL keywords is not permitted and prompts an error message.
A list of reserved KRL keywords can be found in [KRL Reference Guide].
Examples of syntactically correct expressions:

“A”
“Hallo”
“D47g11”
6.5 String
This term is used to describe a string of alphanumeric characters.
Commas and line breaks are not permitted and prompt an error message or malfunction.
Examples of syntactically correct expressions:

“A”
“Hallo”
“D47g11”
“1aBc”
“”
6.6 Special characters

6.6.1 “;”
“;” identifies the rest of the program line as a comment.

e.g.

6 Appendix (Fortsetzung)
;This is a comment
6.6.2 “_”
“ _” continues the program line with a new line despite the break. There must be a space
between the preceding program line and the “_” character.
e.g.
decl _
int _
number
corresponds to:
decl int number
6.6.3 “/”
“/” cancels the special function of a subsequent character.

The character “/” itself is suppressed in the resultant character string.
Application examples:
Comment line in a technology package
End of a parameter reference placeholder
Path specifications for SETVAR, SHOWVAR or REDECL
e.g.
/%
in order to be able to enter the character “%”, which has a special function.
6.6.4 “%”
“%” designates a parameter reference placeholder. The parameter reference placeholder

must be terminated by means of a “/” or a space. If a space is used, this must be followed
by a second space to separate the parameter from the following character or expression.
A space used to terminate a reference is suppressed in the resultant character string.
e.g.
%INLINEFORM
or
%INLINEFORM/

UserTech 2.1
Zeichen
;, 59
#SWITCH, 33
#TOGGLE, 33
%, 60
/, 60
_, 60
A
ACCEPTINLINEFORM, 41
Appendix, 58
Areas of validity, 13
ASS, 15
ASSAGG, 15
AUTOLIMIT, 19, 20
B
BOF Reinitialization, 11
BOOL, 58
Boolean, 58
BOTTOMTEXT, 30
C
CANCELINLINEFORM, 41
CASE, 10
CASE ELSE, 10
CENTERTEXT, 30
CHAR, 58
Character, 58
D
Data types, 58
DEFSCRIPT, 10, 36
DEFTP, 10, 12
DFCT, 15
DO, 10, 39
DOALWAYS, 56
DSUB, 14
E
ENABLE, 17, 31
END, 41
ENDSCRIPT, 10, 36
ENDSWITCH, 10, 39

ENDTP, 10, 12
F
FCT, 15
FOCUS, 13
FOLD, 10, 13, 28
G
Global, 13
I
Icons, 30, 31
Inline form, 52
INLINEFORM, 10, 13
INT, 58
Integer, 58
ISCHANGE, 55
K
KEYDOWN_PICTURE, 31
KEYDOWNMINUS_PICTURE, 31
KFDL, 8
KRL, 8
L
Local, 13
M
MESSAGE, 10, 39
N
Names, 59
NEED_DRIVESOK, 31
NEED_MODEOP, 32
NEED_PROSTATE, 33
NEED_PROSTATE0, 32
NEED_SAFETYSWITCH, 31
NEXT, 34
NOTHING, 41
O
ONACCEPT, 16
ONKEYDOWN, 33

UserTech 2.1
ONKEYDOWNMINUS, 34
ONKEYREPEAT, 34
ONKEYREPEATMINUS, 34
ONKEYSHOW, 34
ONKEYUP, 33
ONKEYUPMINUS, 34
ONOPEN, 16
ONTOUCHUP, 16
Overview, 10
P
PARAM, 10, 14, 17
Parameter lists, 23
PICTURE, 30
PLIST, 10
R
REAL, 58
Real, 58
REDECL, 10, 38
S
Scripts, 36
SET, 10, 39
SETVAR, 10, 36
SHORTCUT, 17
SHORTNAME, 17
SHOWVAR, 10, 37
SOC, 12
SOT, 12
Special characters, 59
STATKEY, 10
STATKEY [n], 35
STATKEYBAR, 10, 35
Status keys, 29
String, 59
STYLE, 14, 33
SUB, 14
SWITCH, 10
SWITCH DIALOG, 10
SWITCH DIALOG...CASE, 40
SWITCH...CASE, 39
T
Technologies, 42

TOPTEXT, 30
Type {free: }, 18
Type {list: }, 20
Type {name: }, 18
Type {number: }, 19
Type {real: }, 20
Type {static: }, 18
U
UNIT, 17
USERMODE, 17, 33
USERTech reinitialize, 11
V
VALUE, 18
W
WYSIWYG, 14

User Tech

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

User Tech

Загружено:

Авторское право:

Доступные форматы

SOFTWARE

Issued: 02 Mai 2005 Version: 01

ProgHBUserTechfKRS2.1 11.04.01 en 1 von 61

KUKA Roboter GmbH

2 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

1 Installation / uninstallation / update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

ProgHBUserTechfKRS2.1 11.04.01 en 3 von 61

4 Integrating technologies in the graphical user interface (GUI) . . . . . . . 43

4 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

ProgHBUserTechfKRS2.1 11.04.01 en 5 von 61

6 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

1 Installation / uninstallation / update

The installation, uninstallation, reinstallation and update of technology packages

ProgHBUserTechfKRS2.1 11.04.01 en 7 von 61

Scripts Kernel system

8 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

2.2 User technologies

ProgHBUserTechfKRS2.1 11.04.01 en 9 von 61

Relating to the technology:

Relating to inline forms:

Relating to status keys:

10 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

3.2 Reinitializing UserTech and BOF

These functions are available in the user group “Expert” or higher.

ProgHBUserTechfKRS2.1 11.04.01 en 11 von 61

3.3 Defining technologies

DEFTP Name 〈 = {〈SOC Bool,〉 〈SOT Bool〉} 〉

and terminated using the statement:

TRUE Command selection possible via list box

TRUE Technology selection possible via list box

12 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

3.3.1 Areas of validity of the objects and variables in a technology

3.4 Inline forms

DECL INLINEFORM Name =

〈FOLD[1] Name,〉 〈...,〉 〈FOLD[n] Name,〉

〈PARAM[1] Name,〉 〈...,〉 〈PARAM[n] Name,〉

ProgHBUserTechfKRS2.1 11.04.01 en 13 von 61

Resulting KRL program text:

Resulting KRL program text:

Resulting KRL program text:

14 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

Resulting KRL program text:

Resulting KRL program text:

Resulting KRL program text:

ProgHBUserTechfKRS2.1 11.04.01 en 15 von 61

DECL PARAM XDir={Shortname[] “X=”, Value {Number: },Unit[] “mm”}

DECL InlineForm Direction={PARAM[1] XDir ,PARAM[2] YDir,PARAM[3] ZDir,STYLE _

The above inline form corresponds to command line 5:

16 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

3.5 Input, display and list boxes

ProgHBUserTechfKRS2.1 11.04.01 en 17 von 61

3.5.6 VALUE FieldDescription

decl param field_sta ={value _

The text that is displayed cannot be altered.

3.5.6.2 The type {free: }

decl param field_fre ={shortname[] “Programmer: ”, _

The default text can be altered. Entering a text is optional.

3.5.6.3 The type {name: }

18 von 61 ProgHBUserTechfKRS2.1 11.04.01 en

{NAME: DEFAULT[] “Name”}

The preset KRL variable name can be altered.

No check is carried out to see whether parameter names already exist.

3.5.6.4 The type {number: }