RoboticsCustomizedUIManual (031 060)
RoboticsCustomizedUIManual (031 060)
</Case>
<Case>
<Default>
</Default>
</Case>
</Switch>
</Line>
Example_2:
<Case Value="fine">
<Item Type="const">G60</Item>
</Case>
<Case Value="nodecel">
<Item Type="const">G64</Item>
</Case>
</Switch>
Example_3:
<Case Value=""/>
<Case>
<Default>
<Item Type="const">\PartLoad:=</Item>
</Default>
</Case>
</Switch>
<Switch ParamName="Location">
<Case Value="via1">
<Line>
<Item Type="parameter">Location</Item>
</Line>
<Line>
<Item Type="parameter">Speed</Item>
</Line>
</Case>
<Case>
<Default>
<Line>
</Line>
</Default>
</Case>
</Switch>
Since there are some characters which are not valid in XML format, it is advised to wrap the condition
inside a CDATA section: [CDATA[<condition>]]
Each parameter and dynamic parameter should also be wrapped by apostrophes, e.g., 'Speed1' (see
example below).
• OR (Or, or, |)
• ==
• <> (!=).
• +, -, * , /
• TRUE/FALSE
Example:
<If>
<Line>
</Line>
</If>
<ElseIf>
<Line>
</Line>
</ElseIf>
<Else>
<Line>
</Line>
</Else>
<Line>
<If>
</If>
<ElseIf>
</ElseIf>
<Else>
</Else>
</Line>
Definition:
Inside the Simulation Layer of a customized OLP Command, users should define how the customized
OLP command will be simulated.During simulation, when the controller encounters a customized OLP
Command, replaces it with its simulation layer and interprets this simulation layer instead.Inside the
simulation layer, users can write any elementary command (one per <line> ... </line> section) that is
understood by the controller:
• native controller syntax supported by the controller simulation (ex : IF var1 = 3 THEN, call to macros,
call to robot module procedure,....)
For the list of controller syntax supported by each controller simulation, refer to the specific controller
(short) user manual.Inside the simulation layer, it is fully permissible to mix "default controller"
commands with commands in native controller syntax.
Inside the simulation layer, it is fully permissible to mix "default controller" commands with commands
in native controller syntax.
Example:
For an Olp command that opens or closes a paint gun:This command takes the following as its
parameters:
• the desired status of the gun (<Status> a boolean, "true" for On / "false" for Off)
In the study, follow these naming rules for the gun fan components. They are called by the name of the
robot, followed by "gun", followed by a number. For instance, if the robot is called "r1" :
• r1_gun1
• r1_gun2
At the simulation layer, display or hide the correct gun fan component:
<SimulationLayer>
<Line>
<Item Type="const">IF</Item>
<Item Type="parameter">Status</Item>
<Item Type="const">THEN</Item>
</Line>
<Line>
<Item Type="parameter">GunNum</Item>
</Line>
<Line>
<Item Type="const">ELSE</Item>
</Line>
<Line>
<Item Type="parameter">GunNum</Item>
</Line>
<Line>
<Item Type="const">ENDIF</Item>
</Line>
</SimulationLayer>
2.37 Dialog
<OlpDialogs>
<OlpCommandRef>
<OlpCommand>ChooseLocation</OlpCommand>
</OlpCommandRef>
</Dialog>
</OlpDialogs>
[@, 1]Title: the title of the dialog in the Teach Pendant. Each | is a new subdirectory.
[@,0-1] Description: a short Description inside the dialog for the user.
User can create a folder CustomizedIcons" under \Robotics\Olp\ and put there its icons.
This folder is served all the controllers for OLP & motion customized dialogs.
Icon is optional attribute, and its value is the relative path from CustomizedIcons" folder (in order to
prevent writing of the headers).
Under this folder, the user can manage his icons with nested subfolders freely as he want.
It is legal to create several OLP commands using one dialog, as long as no parameter appears more than
once. Then when users click (in Teach Pendant) one of the OLP commands, the common dialog opens
again and allows users to edit both of them.
Note:
You may not change the names of a dialog (or the names of commands) in the XML after creating
commands using the dialog. Changing the name of a dialog would remove the connection
between it and the commands it was used to customize. Afterwards, it would no longer be
possible to further edit the existing commands.
Changing command names would also cause the download and simulation layers to become
irretrievable.
The value of the Representation attribute can be set to UI, simulation or download.
The less-than character (<) starts element markup (the first character of a start-tag or an end-tag).
&
The ampersand character (&) starts entity markup (the first character of a character entity reference).
>
"
The double-quote character (") can be symbolized with this character entity reference when you need to
embed a double-quote inside a string which is already double-quoted.
'
The apostrophe or single-quote character (') can be symbolized with this character entity reference
when you need to embed a single-quote or apostrophe inside a string which is already single-quoted.
Note:
(") and (') are supported in several editors, so before you use " and ' try the simple
one.
And in <ElmDef>:
<ComboDef>
<ElmDef>0<=10</ElmDef>
<ElmDef>10<=20</ElmDef>
<ElmDef>30<=40</ElmDef>
<ElmDef>40<50</ElmDef>
</ComboDef>
This attribute can be used to create seam operations during upload based on Olp Commands (instead of
based on customized locations). The system creates a seam from the location after the "Seam Start" Olp
Command, until the location after the "Seam End" Olp Command.
Additional explanation:
When upload encounters a customized OLP Command with UploadLocationType = Seam Start, the
system understands that the next location in the program defines the start of a seam. For cases where
there is no subsequent location (OLP Command after the last motion), upload then ignores the earlier
customized OLP command. As implemented for Seam Start customized motion commands, a location
which is understood as Seam Start via OLP, also closes the previous seam if necessary (for example,
when the Seam End marker is missing).
When upload encounters a customized OLP Command with UploadLocationType = Seam End, the system
understands that the next uploaded location defines the end of a seam. When there is no subsequent
location (OLP Command after the last motion), upload then ignores the earlier customized OLP
command. As implemented for Seam End customized motion commands, a location which is
understood as Seam End via OLP also creates a single location seam if the previous locations were not
defined as being inside seam (for example when the Seam Start marker is missing).
When upload encounters a customized OLP Command with UploadLocationType = Seam Middle the
system understands that the next uploaded location is a Seam Middle location. When there is no
subsequent location (OLP Command after the last motion), upload then ignores the earlier customized
OLP command. As implemented for Seam Middle customized motion commands, a location which is
understood as Seam Middle via OLP also starts a seam if necessary (for example, when the Seam Start
marker is missing).
Example:
LIN P1
LIN P2
OLP_COMMAND_DEFINED_AS_SEAM_START
LIN P3
LIN P4
OLP_COMMAND_DEFINED_AS_SEAM_END
LIN P5
LIN P6
CONTINUOUS OP
- P1 (via)
- P2 (via)
• OLP_COMMAND_DEFINED_AS_SEAM_START
• Seam 1
• P3 (seam)
• P4 (seam)
■ OLP_COMMAND_DEFINED_AS_SEAM_END
• P5 (seam)
- P6 (via)
The MfgType attribute is used to create dedicated subclasses of WeldPoint and ContinousMfg
manufacturing features.
NutWeldPoint
StudWeldPoint
Or any user defined Planner subclass of WeldPoint
Write:
In the following example, a template OLP command called SET_SEGMENT uses SegmentNumber as an
argument. In the dialog section, the same template command is used but with different argument
values:
<RobotController Name="Kuka-Krc">
<RoboticParams>
</RoboticParams>
<TemplateOlpCommands>
<TemplateCommand Name="SET_SEGMENT">
<RoboticParamRef>
<Param>ProgNr1</Param>
</RoboticParamRef>
<CommandName>
<Item Type="const">SET_SEGMENT_</Item>
</CommandName>
<Layers>
<UILayer>
<Line>
<Item Type="const">);</Item>
</Line>
</UILayer>
<SimulationLayer></SimulationLayer>
<DownloadLayer>
<Line>
<Item Type="const">(</Item>
<Item Type="parameter">ProgNr1</Item>
<Item Type="const">);</Item>
</Line>
</DownloadLayer>
</Layers>
</TemplateCommand>
</TemplateOlpCommands>
<OlpDialogs>
<Dialog Title="SET_SEGMENT|SET_SEGMENT1">
<OlpCommandRef>
<OlpCommand SegmentNumber="1">SET_SEGMENT</OlpCommand>
</OlpCommandRef>
</Dialog>
<Dialog Title="SET_SEGMENT|SET_SEGMENT2">
<OlpCommandRef>
<OlpCommand SegmentNumber="2">SET_SEGMENT</OlpCommand>
</OlpCommandRef>
</Dialog>
<Dialog Title="SET_SEGMENT|SET_SEGMENT3">
<OlpCommandRef>
<OlpCommand SegmentNumber="3">SET_SEGMENT</OlpCommand>
</OlpCommandRef>
</Dialog>
</OlpDialogs>
</RobotController>
2.44 Aliases
You can use Aliases to define reusable blocks or aliases of XML instructions that can be referenced in the
relevant layers of the commands,.
This dramatically reduces the size of the XML by removing redundant syntaxes. Using Aliases also
facilitates the maintenance of the XML since any fix would need to be implemented at a single place.
<RoboticParams>
...
</RoboticParams>
<Aliases>
<Alias Name="BitOrder">
<Switch ParamName="ordre1">
<Case Value="0">
</Case>
<Case Value="1">
<Item Type="const">\O1</Item>
</Case>
</Switch>
<Switch ParamName="ordre2">
<Case Value="0">
</Case>
<Case Value="1">
<Item Type="const">\O2</Item>
</Case>
</Switch>
<Switch ParamName="ordre3">
<Case Value="0">
</Case>
<Case Value="1">
<Item Type="const">\O3</Item>
</Case>
</Switch>
<Switch ParamName="ordre4">
<Case Value="0">
</Case>
<Case Value="1">
<Item Type="const">\O4</Item>
</Case>
</Switch>
<Switch ParamName="ordre5">
<Case Value="0">
</Case>
<Case Value="1">
<Item Type="const">\O5</Item>
</Case>
</Switch>
<Switch ParamName="ordre6">
<Case Value="0">
</Case>
<Case Value="1">
<Item Type="const">\O6</Item>
</Case>
</Switch>
</Alias>
</Aliases>
<OlpCommands>
<Command Name="PLC_Release">
<RoboticParamRef>
...
</RoboticParamRef>
<Layers>
<UILayer>
<Line>
<Alias>BitOrder</Alias>
</Line>
</UILayer>
<DownloadLayer>
<Line>
<Item Type="const">ORDER</Item>
<Alias>BitOrder</Alias>
<Item Type="const">;</Item>
</Line>
</DownloadLayer>
</Layers>
</Command>
</OlpCommands>
<ComboDef>
</ComboDef>
</Param>
The picture in the dialog changes dynamically according to the combobox selection. This aids you in
selecting the correct gun.
Picture is an optional attribute. Its value is the relative path from the "CustomizedPictures" folder (to
prevent writing of headers).
Under this folder, you can manage pictures with nested subfolders as desired. For example:
• Just a few people write manycustomized dialogs for OLP and motion for a controller (per version), and
then need to teach the global meaning of the dialogs to everyone else, including each of the values in
the combo, the meaning of each parameter, etc.
• Employees may forget something, or just want to be sure they understood correctly
A simple solution:
This service automatically generates a Help button at the lowerleft corner of the dialog, and when users
wish to learn about it some functionality, they simply click this button to open the file online.
This new online help mechanism supports all types of existing technologies including all kinds of
documents, audio, videoand other media.
The syntax:
If you wish to launch a URL, add the shortcut to the folder and the XML and then use the shortcut name
+ ".url".
• You can now launch the desired item over the net (internet, intranet).
• You can store all items on a single server and use shortcuts to access them.
2.47 Centralize all XML files under single shared folder which can
serve all users
By default, the xmls are read from the installation folder: \Robotics\Olp\<controller name>
\OlpConfiguration\*.xml \Robotics\Olp\<controller name>\MotionConfiguration\*.xml etc.
<InstalledVersions>
<ModuleName>C:\rrs_bin\rcs_krc1\krc5.3_r01\bin\rcskrc1_tune.exe</
ModuleName>
</Version>
</InstalledVersions>
</Controller>
In this example, the robot with Kuka-Krc controller and Version krc5.3_r01 reads its xml files from here:
Show Layers:
A new dialog opens with the simulation layer and download layer of each selected customized OLP
command:
Upload Checker:
A new dialog opens with the current values and uploaded values of each robotic parameter and dynamic
parameter of the selected customized OLP command.
Upload Debugger:
For cases when a customized OLP command failed to be recognized at upload, users can now debug the
reason for the failure. The workflow is as follow:
• Move the problematic customized OLP to that location, with appropriate customized parameters.
• The Debugger dialog displays showing any internal download/upload issues (unlikely to happen in
most cases).
• Paste the problematic line(s) from the original robot program into the dialog and click the Re-Upload
button.
• The dialog displays in red the lines that caused the XML upload to fail, notifies about the reason for
the failure.
Users can edit the Upload Debugger content dialog containing lines from their program and click the Re-
Upload button.
Upload and Download button is a debug tool which uploads and re-downloads the Upload Content
displayed in the Upload Debugger, and then compares the Upload Content to the Upload and download
result (displayed at the bottom of the Upload Debugger dialog).
For example, if the user defines the following customized OLP command:
XML:
<ComboDef>
<ElmDef>1.2.1</ElmDef>
<ElmDef>2.3.2</ElmDef>
</ComboDef>
</Param>
...
<DownloadLayer>
<Line>
<Item Type="const">;FOLD</Item>
<Item Type="parameter">GlueTechVersion</Item>
<If>
<![CDATA['GlueTechVersion'==1.2.1]]>
<Item Type="const">Yes</Item>
</If>
<Else>
<Item Type="const">No</Item>
</Else>
</Line>
<Line>
<Item Type="const">;ENDFOLD</Item>
</Line>
</DownloadLayer>
Or:
If the users program wrongly has the following line (mismatches with the possible lines stated above):
Then upload will be successful, but the OLP content will be different than the programs content. The
user can test this using the "Upload and Download" button.
Open the "Upload and Download" dialog and paste the wrong line from above, then click "Upload and
Download". You can see that the result of uploading and downloading such a program line will be
different than the original program line (2.3.2 changes to 1.2.1.).
The purpose:
• rearrange the customized OLP command menus/submenus that display when clicking the Add
buttonfrom the Olp Commands editor,
without losing the connection between existing customized commands in the database and their editing
dialog.
For cases when users created OLP commands with the following xml code:
<OlpCommandRef>
<OlpCommand>XXX</OlpCommand>
</OlpCommandRef>
</Dialog>
And now they wish to change the title of the dialog, they should add the Id attribute with the old title
name and then change the title to the new one:
Title="Customized|Supplier1|Robot|Job1">
<OlpCommandRef>
<OlpCommand>XXX</OlpCommand>
</OlpCommandRef>
</Dialog>
In case there already is an Id attribute and users wish to change the dialog title again, they should
change theTitleattribute only:
<Dialog Id="Customized|Supplier1|Robot|Job1"
Title="Customized|Supplier1|Robot|Job2">
<OlpCommandRef>
<OlpCommand>XXX</OlpCommand>
</OlpCommandRef>
</Dialog>
Id is the information stored in the database that links to the OLP commands with the dialog that is used
to edit them. In case Id is not defined, "Title" is used as the default Id .
Syntax :
<Dialog Title="Glue>
<OlpCommandRef>
<OlpCommand>OLP_1</OlpCommand>
<OlpCommand>OLP_2</OlpCommand>
<OlpCommand>OLP_3</OlpCommand>
<OlpCommand>OLP_1</OlpCommand>
</OlpCommandRef>
</Dialog>
To separate the commands, users can select Ungroup from the context menu:
<Dialog Title="PL2Glue|-"