- Overview
- Plugin widget
- How it works
- Templates
- Project file
- Placeholders
- JavaScript API
- Reading & validating robot data
- Supported file formats
- Complete example
- Shipped templates
- Resources
▲ Overview
The Robot Data Spy plugin scans one or multiple robot archives for data defined by the user with a simple XML project file and builds a report from the results.
Instead of a single, fixed set of searched values, the plugin lets the user describe what to search for (files, regular expressions, INI groups) and how to present the results, using small JavaScript snippets executed by the built-in JavaScript engine.
A single project consists of an XML file describing which files to open and which patterns to look for, and one or more JavaScript files collecting the matched data and rendering it as an HTML report (and optionally a CSV export).
The plugin can process a single robot archive or a whole batch of archives at once. For every processed archive the report is extended with a new section, and at the end of the batch a table of contents linking to every robot's section is generated automatically.
Typical uses shipped as ready to use templates include: searching for the usage of a given VKRC/Fanuc variable across all programs, listing used tools/bases/collisions, reading masterdata or calibration files, comparing TPVW program versions, reading Kuka Masterdata log or building a complete variable reference table for later use (e.g. by the Documentation Generator Pro plugin).
▲ Plugin widget
The plugin is available from the Others menu as Robot Data Spy.
The widget lists all templates registered in the templates.ini file. After selecting a template and one or multiple robot archives the plugin runs the associated XML project file against every selected archive and presents the generated report.
If the selected template defines an input tag, a small dialog is shown before the scan starts, letting the user parametrize the search (e.g. choose which variable type to look for).
The report is normally shown to the user in a save dialog once the scan is finished, where it can be saved
as HTML, PDF or - if the template fills INNER_CSV - CSV. Set the
noContent attribute of the RobotDataSpy tag to true to skip this
dialog, e.g. when the template only builds a reference list or a list of found results.
The widget also has a Force rebuild reference table option, which behaves as if buildRef="true" was set on every file tag of the running template, regardless of what the project file actually declares.
▲ How it works
The project file is processed top to bottom, and every tag runs at the position it is written in the document.
- onReportBegin is called once, before the first robot archive is processed. It usually prepares the empty report document.
- For every selected robot archive, in order:
- every importscript and input tag found in the file is evaluated (imported scripts and the values chosen by the user are shared for the whole run, not re-evaluated per robot);
- every js or file tag is executed in the order it appears in the document. A js tag placed before any file tag is typically used to reset the variables collecting data for the current robot (e.g. beginRobotSection());
- for every file tag, all files matching path/wildcard are opened and every regexp or group child tag is evaluated against their content, calling the given callback for every match;
- a final js tag placed after all file tags is typically used to render the collected data as an HTML fragment for the current robot and append it to the report (e.g. generateRobotSection()).
- onReportFinish is called once, after every robot archive has been processed. It usually appends the table of contents and closes the report document.
See the JavaScript API chapter for the variables and functions used to collect and render the data, and the complete example for a project file put together following this pipeline.
▲ Templates
Every entry available in the plugin widget is registered in the template\RobotDataSpy\templates.ini file. Each template has its own subdirectory containing its XML project file and, optionally, its own JavaScript file.
[template_id]
name=Template name shown in the widget
description=Short description shown in the widget
xml=path\to\project.xml
js=path\to\script.js
name=Template name shown in the widget
description=Short description shown in the widget
xml=path\to\project.xml
js=path\to\script.js
| Property | Values | Description |
| [template_id] | Any valid text without spaces | Unique template identifier (INI section name). |
| name | Any valid text | Template name displayed in the plugin widget's template list. |
| description | Any valid text | Short description displayed next to the template name. |
| xml | Path to the project file | Path (relative to templates.ini) to the project file describing what to search for. |
| js | Path to a JavaScript file |
Path (relative to templates.ini) to the template's own JavaScript file collecting and
rendering the matched data. Optional - a template that only sets buildRef on its file tags to (re)build the variable reference list does not need one. |
▲ Project file
▲ The XML project file starts with the main tag RobotDataSpy.
<RobotDataSpy debug="" onReportBegin="" onReportFinish="" noContent="">
</RobotDataSpy>
Between those tags the user can define the entire search and report generation logic. </RobotDataSpy>
| Property | Values | Description |
| debug | [ true | false ] | Prints extra debug information to the plugin's console using the print function while the report is being generated. |
| onReportBegin | JavaScript function call | Executed once, before the first robot archive is processed. Typically prepares the (still empty) report document, e.g. reportBegin(). |
| onReportFinish | JavaScript function call | Executed once, after every selected robot archive has been processed. Typically appends the table of contents built while processing the robots and closes the report document, e.g. reportFinish(). |
| noContent | [ true | false ] | Skips showing the save dialog for the generated report content once the scan is finished if true. Useful for templates which only build the variable reference list (buildRef) or a found results list instead of a printable report. |
The RobotDataSpy tag can contain the following subtags: importscript, input, js, file.
▲ The importscript tag loads an external JavaScript file into the engine before the report is generated. It is normally used to import a shared library of helper functions and global variables reused by several templates (see global.js).
<importscript file="" />
| Property | Values | Description |
| file | Path to a JavaScript file | Path (relative to the project's XML file) to the script to import, e.g. ../global.js. |
▲ The input tag defines a small dialog shown to the user before the scan starts, letting the user parametrize the search. The dialog is shown only once, before the first robot archive is processed; the value entered by the user is then reused (and its callback re-executed) for every following archive in the batch.
<input type="select" text="" options="" showIndex="" callback="" />
| Property | Values | Description |
| type | [ select | text | int | double ] |
Input widget type. select - drop-down list built from options. text - single line text box. int - integer spin box. double - floating point spin box (3 decimal places). |
| text | Any valid text | Label displayed above the input widget, e.g. Select variable. |
| options | Comma separated list | Only used with type="select". List of selectable values, e.g. i,bin,t,ana,anain,binin,p,E,A,M,F,T,S. |
| showIndex | [ true | false ] | Only used with type="select". If true, an additional, independent number spin box is shown next to the drop-down list, letting the user enter an extra number (e.g. a variable's index, so that picking E from the list and 5 in the spin box together describe the variable E5). The __INDEX__ placeholder is only substituted in callback when showIndex="true"; do not use it otherwise. |
| callback | JavaScript function call |
Executed once the user confirms their choice (and again, with the same value, for every following robot
archive). Available placeholders depend on type: select - __OPTION__ (the selected option's text) and, only if showIndex="true", __INDEX__ (the number entered in the accompanying spin box), e.g. set_var_fn('__OPTION__','__INDEX__'). text / int / double - __VALUE__ (the entered text/number). |
Just like every other placeholder described in the placeholders chapter,
__OPTION__, __INDEX__ and __VALUE__ are substituted as plain text - wrap them in
quotes in callback yourself if a string argument is expected.
▲ The js tag runs a JavaScript function call at the position it is placed in the document. It can be used as many times as needed; the most common use is to reset the variables collecting data for the current robot right before its files are scanned, and to build the report fragment for the current robot right after.
<js callback="" />
| Property | Values | Description |
| callback | JavaScript function call | Function to execute, e.g. beginRobotSection() before the file tags and generateRobotSection() after them. See how it works. |
▲ The file tag selects a set of files inside the robot archive to search in.
<file path="" recursive="" wildcard="" format="" buildRef="">
...
</file>
...
</file>
| Property | Values | Description |
| path | Any valid relative path | Directory to search in, relative to the robot archive root, e.g. KRC/R1/Folgen/. Use an empty value or ./ for the archive root. |
| recursive | [ true | false ] | Scans the directory recursively, including its subdirectories, if true. |
| wildcard | Comma separated file filter list |
Filename filters used to select the files to scan, e.g. folge*.src,up*.src,makro*.src or
*.ls. Standard */? wildcards are supported. If left empty, path is treated as the full relative path to a single file instead of a directory to search in, e.g. path="am.ini" without wildcard opens exactly that one file. |
| format | [ TXT | KRC | VKRC | VFANUC | INI ] | Defines how the matched files are opened and parsed. See supported file formats for details. |
| buildRef | [ true | false ] | Builds (or refreshes) the robot's variable reference list from the matched files if true. This is the same reference list consumed by the Documentation Generator Pro's reference tag. When only buildRef is used, no regexp/group child tag is required. |
Setting buildRef="true" overwrites the robot's current variable reference list. Make sure this is
intended before running the scan, especially if another plugin (e.g. Documentation Generator Pro) still
relies on the previous reference list.
The file tag can contain multiple regexp (for TXT, KRC, VKRC, VFANUC formats) or group (for INI format) child tags.
▲ The regexp tag defines a regular expression checked against every line of the files matched by the parent file tag.
<regexp pattern="" callback="" />
| Property | Values | Description |
| pattern | Regular expression (QRegularExpression syntax) |
Regular expression, matched case-insensitively against every line of the scanned file. Name every part of the pattern you need in callback as a named capture group, written as (?<__NAME__>...) - choose any name that fits what it captures, e.g. (?<__VALUE__>\d+) or, as used in used_coll.xml, (?<__CMD__>A(?<__COLL__>(8[1-9]|9[0-6]))\s*=[^$]+) which captures both the whole command as __CMD__ and just the collision number as __COLL__, nested inside it. Every named group becomes a placeholder available in callback - see placeholders for how it gets substituted (differently than the built-in ones). |
| callback | JavaScript function call |
Executed for every line matching pattern. See placeholders for the
list of built-in and named-capture-group placeholders available inside the callback text - note that
the two kinds are substituted differently. If the callback function returns a non-zero number, scanning of the remaining lines of the current file is stopped - useful to abort early once all needed values have already been found (see user_stop() in the complete example's sibling template kuka_maschinendaten_E1.js). A script error inside callback (invalid syntax, calling an undefined function, ...) is fatal and stops the whole run for every remaining robot archive in the batch, not only the current one. |
▲ The group tag is used instead of regexp when the parent file tag's format is INI. It iterates over every key found in a matching [group]/section of the file.
<group name="" callback="" />
| Property | Values | Description |
| name | Group name or regular expression (QRegExp syntax) | Name of the [group]/section to read, e.g. Version. A regular expression can be used to match several groups at once, e.g. MotorDifference\s+for\s+Tool\s+\d+. The expression must match the whole group name, not just part of it. |
| callback | JavaScript function call |
Executed once for every key found inside the matching group(s). See placeholders
for the __GROUP__, __KEY__ and __VALUE__ placeholders available inside the callback
text. If the callback function returns a non-zero number, the remaining keys of the current group section are skipped (scanning continues with the next matching [group] section, if any). |
Multiple file/group combinations can be used to read several different sections from the same or different INI files - see kuka_tpvw.xml reading the [Version] group from am.ini, or vkrc_calibration's *.cal file reading AbsolutMotorValues, CalibrationDifference and every MotorDifference for Tool N section in one pass.
▲ Placeholders
Placeholders are plain text markers replaced with the actual matched value before the callback text is evaluated as JavaScript code. There are two different kinds, substituted differently - mixing them up is the most common mistake when writing a new template.
| Kind | Substitution | How to use it in callback |
| Built-in placeholder | Replaced with the raw value (no quotes added), e.g. __LINE__ becomes RobWzg = 3 ;comment. | Wrap it in quotes yourself if the target function argument must be a string, e.g. '__LINE__', '__FILEBASENAME__'. Leave it unquoted for a numeric argument, e.g. __LINENUMBER__. |
| Named capture group from a regexp pattern | Replaced with the captured value already wrapped in double quotes by the plugin, e.g. (?<__TOOL__>\d+) matching 3 makes __TOOL__ become "3". | Use it unquoted in callback, e.g. robot_used_tool_fn('__MATCHED__', '__FILEBASENAME__', __TOOL__). Adding your own quotes around it ('__TOOL__') breaks the generated JavaScript code. |
The table below lists every built-in placeholder; custom named capture group placeholders are named after the group itself (see regexp).
| Placeholder | Available in | Description |
| __MATCHED__ | regexp | The whole text matched by pattern. |
| __LINE__ | regexp | Full text of the line the match was found on. |
| __LINENUMBER__ | regexp | Line number (1-based) the match was found on. |
| __FILEBASENAME__ | regexp, group | Name of the file currently being scanned, without its path. |
| __FILEABSOLUTEPATH__ | regexp, group | Absolute path of the file currently being scanned. |
| __GROUP__ | group | Name of the matched [group]/section. |
| __KEY__ | group | Key name found inside the matched group. |
| __VALUE__ | group, input (text/int/double) | Value of the key found inside the matched group (group), or the text/number entered by the user (input of type text, int or double). |
| __OPTION__ | input (select) | Text of the option selected by the user from the drop-down list. |
| __INDEX__ | input (select, only with showIndex="true") | Not the position of the selected option - the number entered by the user in the extra spin box shown next to the drop-down list when showIndex="true". |
| __NAME__ | regexp |
Any custom name used in a named capture group inside pattern, written as
(?<__NAME__>...). The name is entirely up to the template author - it becomes a new
placeholder usable in callback, substituted as described above (as an already quoted string). For example, used_coll.xml defines (?<__CMD__>A(?<__COLL__>(8[1-9]|9[0-6]))\s*=[^$]+), which makes both __CMD__ (the whole matched command) and __COLL__ (just the collision number) available in callback="robot_requested_coll_fn(__CMD__, '__FILEBASENAME__', __COLL__)"; other shipped templates name their groups __VAR__, __VALUE__, __TOOL__, __BASE__, __GROUP__, __AXIS__ or __VERSION__ to fit what they capture. |
▲ JavaScript API
Callback functions used in the project file are plain JavaScript functions, either imported with importscript or defined directly in the template's own .js file (registered as js= in templates.ini).
A few variables and functions are provided by the engine itself, or by the shared global.js library shipped with the plugin and imported by every template with <importscript file="../global.js" />.
Provided by the engine
| Name | Description |
| ROBOT_NAME | Name of the robot archive currently being processed. |
| ROBOT_TOOL_DATA ROBOT_BASE_DATA ROBOT_LOAD_DATA |
Tool/base/load calibration data read automatically from the current robot archive, independently of any
file tag defined in the project - set right after ROBOT_NAME, before any
input/js/file tag of the project
runs. The shape is different for Kuka and Fanuc archives: Kuka - indexed by number only, e.g. ROBOT_TOOL_DATA[3].x: ROBOT_TOOL_DATA[n] / ROBOT_BASE_DATA[n] = { name, x, y, z, a, b, c, type, set } (type: 1=TCP, 2=BASE, else not set; set: 1 if the slot is configured, else 0). ROBOT_LOAD_DATA[n] = { m, x, y, z, a, b, c, jx, jy, jz, set }. Fanuc - indexed by motion group, then number, e.g. ROBOT_TOOL_DATA[1][3].x: ROBOT_TOOL_DATA[group][n] / ROBOT_BASE_DATA[group][n] = { number, group, name, x, y, z, w, p, r, config, set }. ROBOT_LOAD_DATA[group][n] = { number, group, comment, m, x, y, z, jx, jy, jz, set }. See robot_info/kuka_robot_info.js and robot_info/fanuc_robot_info.js for how each shape is walked with Object.keys(). |
| robot_counter | Number of robot archives already processed in the current run (0 for the first one). |
| print(text) | Writes text to the plugin's debug console. Only useful when debug="true" on the RobotDataSpy tag. |
| found(robotName, absoluteFilePath, name, matchedText, lineNumber) |
Registers one entry in the plugin's found results list, shown in the References tab. Used
e.g. by the find variable template to build an interactive list of every occurrence of the
searched variable. Requires exactly these 5 arguments, in this order - a call with any other argument count is silently ignored. |
Provided by global.js
| Name | Description |
| INNER_HTML | Accumulator for the generated report body. Read by the engine once onReportFinish has run to produce the final HTML report shown/saved to the user. |
| INNER_CSV | Accumulator for an optional CSV export, built the same way as INNER_HTML (see kuka_masterdata.js/kuka_maschinendaten_E1.js for an example). |
| table_of_contents | Accumulator for the per-robot table of contents row, appended to in every generateRobotSection()-style function and written into the report by reportFinish(). |
| robots_contents_html | Accumulator for the report body itself, one section per processed robot. |
| robot_counter_info robot_counter_warning robot_counter_error |
Per-robot counters, reset in every beginRobotSection()-style function and used to build a small info/warning/error summary next to every robot's section title. |
| icon_info icon_warning icon_error icon_arrow_up |
Small base64-embedded icons used to decorate the report. |
| sort_numbers(a, b) | Generic numeric Array.sort() comparator. |
| sort_program_name(s1, s2) | Array.sort() comparator ordering matched file names the way Folge/UP/Makro programs are usually listed. |
| reportBegin() | Default onReportBegin implementation: opens the (empty) report HTML document. |
| reportFinish() | Default onReportFinish implementation: appends the table of contents and every robot's section to the report, then closes the HTML document. |
Every template is expected to additionally define, in its own .js file, at least a beginRobotSection() function (resetting the variables collecting data for the current robot) and a generateRobotSection() function (rendering the collected data as an HTML fragment and appending it to robots_contents_html/table_of_contents), called from the project file's js tags. See the complete example below.
▲ Reading & validating robot data
ROBOT_TOOL_DATA/ROBOT_BASE_DATA/ROBOT_LOAD_DATA have a completely different shape for Kuka and Fanuc archives (different fields, different indexing - see the JavaScript API table above). The same three variable names are used on both robot brands only by convention, so that templates working with either brand read similarly - the actual data structure, the fields available, and how to tell whether a given tool/base/load slot is actually configured is different for each brand and must be handled separately.
The shipped Robot info template pair is the canonical reference for this: robot_info/kuka_robot_info.xml + robot_info/kuka_robot_info.js (Kuka) and robot_info/fanuc_robot_info.xml + robot_info/fanuc_robot_info.js (Fanuc) both print every tool/base/load slot into the report and validate it - cross-checking the engine-provided data against what is actually referenced in the robot's own programs, and flagging anything that looks unset, unconfigured, uncalibrated or unused. The tables below are built directly from that validation logic.
Calibration data (AbsolutMotorValues/CalibrationDifference/MotorDifference for Kuka,
Justage Data for Fanuc) is not part of ROBOT_TOOL_DATA/ROBOT_BASE_DATA/
ROBOT_LOAD_DATA - both templates read it themselves from the archive with an ordinary
file/group (Kuka, *.cal, INI) or
file/regexp (Fanuc, sysmast.va, TXT) tag,
then cross-references it against the engine-provided tool data to flag uncalibrated tools/axes.
Kuka - robot_info/kuka_robot_info.xml + robot_info/kuka_robot_info.js
Which tool/base numbers are actually used is collected separately, by scanning every folge*.src/up*.src program with two regexp patterns, RobWzg\s*=\s*(?<__TOOL__>\d+) and Base\s*=\s*(?<__BASE__>\d+), feeding robot_used_tool_fn()/robot_used_base_fn() - this is what fills the Used in column and drives the "not calibrated"/"not used" cross-checks below, independently of what ROBOT_TOOL_DATA/ROBOT_BASE_DATA itself contains.
| Field | Meaning | How it is validated |
| ROBOT_TOOL_DATA[n].name ROBOT_BASE_DATA[n].name |
Tool/base name as configured, e.g. "T1 Gripper"/"B1 Table". | The T<number>/B<number> prefix is stripped with /T\d+\s*/i/ /B\d+\s*/i; if nothing remains → "Tool N name not set"/"Base N name not set". |
| ROBOT_TOOL_DATA[n].type ROBOT_BASE_DATA[n].type |
1 = TCP, 2 = BASE, anything else means not set. | Shown as TCP/BASE/NONE; type === 0 → "Tool N type not set"/"Base N type not set". |
| ROBOT_TOOL_DATA[n].set ROBOT_BASE_DATA[n].set |
1 if the slot is actually configured in the archive, else 0. | set != 1 → "Tool N not configured"/"Base N not configured", and the x/y/z/a/b/c values are shown in red. |
| ROBOT_TOOL_DATA[n].x, y, z, a, b, c ROBOT_BASE_DATA[n].x, y, z, a, b, c |
Tool/base frame offset (position + orientation). | Printed as-is; only flagged indirectly through set above. |
| (cross-check) | Whether a tool number that appears configured was ever calibrated. | If robot_cal_MotorDifference[tool_no] (built from the *.cal MotorDifference for Tool N group) is missing → "Tool N not calibrated". |
| (cross-check) | Whether a tool that is actually used in a program also has load data. | If ROBOT_LOAD_DATA[tool_no] is missing or its set is not 1 → "Load data for TN not set". |
| ROBOT_LOAD_DATA[n].m, x, y, z, a, b, c, jx, jy, jz | Load mass, center of gravity offset and moments of inertia. | Row shown in red when set != 1 (→ "Tool N used but load data not set"); a configured load whose tool number never showed up in robot_used_tool triggers "Load data set but TN not used", and a missing robot_cal_MotorDifference[tool_no] repeats the "Tool N not calibrated" warning here as well. |
Fanuc - robot_info/fanuc_robot_info.xml + robot_info/fanuc_robot_info.js
Usage is collected the same way, but only inside /POS ... /END program sections and only for motion group 1: section_POS_fn()/section_END_fn() track the section (^/POS\s*$/^/END\s*$), set_GP_fn() tracks the current group (^\s*GP(?<__GROUP__>\d+)), and UF\s*:\s*(?<__BASE__>\d+)\s*,\s*UT\s*:\s*(?<__TOOL__>\d+) feeds robot_used_UF_UT_fn(), filling the Used in (only GP1) column.
Unlike Kuka, the Fanuc ROBOT_LOAD_DATA[group][n].set flag set by the engine is not trusted by
this template: a config file can carry a default weight (e.g. 210) even when the rest of the load
was never really set. fanuc_robot_info.js therefore recomputes it itself before using it:
data.set = (x!=0 || y!=0 || z!=0 || jx!=0 || jy!=0 || jz!=0) ? 1 : 0 - only rows with at least one
non-zero offset/inertia value are shown at all.
| Field | Meaning | How it is validated |
| ROBOT_TOOL_DATA[group][n] ROBOT_BASE_DATA[group][n] |
{ number, group, name, x, y, z, w, p, r, config, set } - note w, p, r (orientation) instead of Kuka's a, b, c. | A slot is only listed (as User Tool Data/User Frame Data) if at least one of x, y, z, w, p, r is non-zero; an all-zero slot is treated as not configured and skipped. |
| (cross-check) | Whether a listed tool also has load data. | For every listed ROBOT_TOOL_DATA[group][n], if ROBOT_LOAD_DATA[group][n] is missing or its (recomputed) set is not 1 → "GP1 UTn used but load data not set". |
| ROBOT_LOAD_DATA[group][n] | { number, group, comment, m, x, y, z, jx, jy, jz, set } - note comment instead of Kuka's name, and no a, b, c (orientation is not part of Fanuc load data). | Rows with a recomputed set of 0 are silently skipped, not flagged in red. |
| (cross-check, Justage/calibration) | Whether axis 1's calibration ($NUM_SET) is set for motion group 1. | Read from sysmast.va via \$VCAX_REF_GR\[(?<__GROUP__>\d+)\]\.\$REF_DATA\[1\]\.\$REF_AXIS\[(?<__AXIS__>\d+)\]\.\$NUM_SET ... =\s*(?<__VALUE__>\d+) into robot_cal[group][axis]; value != 1 → shown in red and "Axis N not calibrated" (group 1 only). |
▲ Supported file formats
| Format | Description |
| TXT | Files are opened and scanned as plain text, line by line. This is the fastest and the most generic option, used for the majority of the shipped templates. |
| KRC / VKRC | Kuka .src/.dat files are opened with the same parser used by the VKRC viewer/editor. Slower than TXT, but the text is normalised the same way it is displayed in the viewer, which can simplify the regular expressions needed to match it. Also required (together with buildRef="true") to (re)build the robot's variable reference list. |
| VFANUC | Fanuc .ls program files are opened with the VFanuc parser. |
| INI | key=value files organized in [group] sections (e.g. am.ini, *.cal). Use group child tags instead of regexp. |
A few shipped templates (e.g. used_coll.xml, kuka_masterdata.xml) contain a commented-out
<file ... format="KRL"> block with an empty <pattern> child tag. Neither
KRL nor pattern are implemented - only the five formats above, with
regexp/group children, are recognized. Using
format="KRL" in an active (non-commented) file tag logs "File format KRL not supported
yet" and the tag is skipped.
▲ Complete example
The following project file (shipped as the Used collisions template) searches Kuka and Fanuc archives for declared, requested and released collision numbers and lists, for every collision, in which files it was found.
<?xml version="1.0" encoding="UTF-8"?>
<RobotDataSpy debug="false" onReportBegin="reportBegin()" onReportFinish="reportFinish()">
<importscript file="../global.js" />
<js callback="beginRobotSection()" />
<!-- Kuka -->
<file path="KRC/R1/Folgen/" wildcard="folge*.src" format="VKRC">
<regexp pattern="^\s*(?<__CMD__>A(?<__COLL__>(8[1-9]|9[0-6]))\s*=[^$]+)" callback="robot_requested_coll_fn(__CMD__, '__FILEBASENAME__', __COLL__)" />
<regexp pattern="^\s*(?<__CMD__>A(?<__COLL__>(4[1-9]|5[0-6]))\s*=[^$]+)" callback="robot_released_coll_fn(__CMD__, '__FILEBASENAME__', __COLL__)" />
</file>
<file path="KRC/R1/Makros/" wildcard="makro45.src,makro50.src" format="VKRC">
<regexp pattern="^\s*(?<__CMD__>A(?<__COLL__>(4[1-9]|5[0-6]))\s*=[^$]+)" callback="robot_declared_coll_fn(__CMD__, '__FILEBASENAME__', __COLL__)" />
</file>
<!-- Fanuc -->
<file path="english/" wildcard="folge*.ls" format="TXT">
<regexp pattern="(?<__CMD__>DO\[(?<__COLL__>(8[1-9]|9[0-6]))\]\s*=[^;]+)" callback="robot_requested_coll_fn(__CMD__, '__FILEBASENAME__', __COLL__)" />
<regexp pattern="(?<__CMD__>DO\[(?<__COLL__>(4[1-9]|5[0-6]))\]\s*=[^;]+)" callback="robot_released_coll_fn(__CMD__, '__FILEBASENAME__', __COLL__)" />
</file>
<js callback="generateRobotSection()" />
</RobotDataSpy>
Its JavaScript file defines the three collision maps, resets them in beginRobotSection(), fills them in robot_requested_coll_fn() / robot_released_coll_fn() / robot_declared_coll_fn() and finally renders three tables (one per collision kind) in generateRobotSection(), appending the result to robots_contents_html and a row to table_of_contents - exactly as described in how it works.
▲ Shipped templates
The following templates are shipped with the plugin and registered in templates.ini.
| Template | Description |
| VKRC robot info | Displays basic information from a Kuka robot archive (used tools/bases, calibration data). |
| Fanuc robot info | Displays basic information from a Fanuc robot archive. |
| Used collisions | Displays declared, requested and released collisions from Kuka and Fanuc robot archives. |
| VKRC find variable | Finds every usage of a VKRC variable, chosen by the user, in the robot archive. |
| VKRC Maschinendaten E1 | Finds the Maschinendaten E1 settings in $machine.dat. |
| VKRC TPVW check | Compares the TPVW version declared in am.ini against the version header of every program. |
| Find all variables | Finds all VKRC & Fanuc variables in the robot archive and (re)builds the variable reference table (buildRef, no report is shown - noContent="true"). |
| Find all variables in $machine.dat | Finds all VKRC SYS variables in $machine.dat and (re)builds the variable reference table. |
| Kuka masterdata | Finds all Kuka masterdata (first mastering and further mastering messages) from the mastering log. |
▲ Resources
- Documentation Generator Pro - consumes the variable reference list built with buildRef
- Qt QRegularExpression syntax (named capture groups, used in regexp patterns)