- Überblick
- Plugin-Fenster
- Funktionsweise
- Vorlagen
- Projektdatei
- Platzhalter
- JavaScript-API
- Roboterdaten lesen & prüfen
- Unterstützte Dateiformate
- Vollständiges Beispiel
- Mitgelieferte Vorlagen
- Weiterführende Links
▲ Überblick
Das Plugin Robot Data Spy durchsucht ein oder mehrere Roboterarchive nach Daten, die der Anwender in einer einfachen XML-Projektdatei festlegt, und erstellt aus den Ergebnissen einen Bericht.
Statt eines festen Satzes gesuchter Werte beschreibt der Anwender selbst, wonach gesucht wird (Dateien, reguläre Ausdrücke, INI-Gruppen) und wie die Ergebnisse dargestellt werden – mit kleinen JavaScript-Snippets, die von der integrierten JavaScript-Engine ausgeführt werden.
Ein Projekt besteht aus einer XML-Datei, die festlegt, welche Dateien geöffnet und nach welchen Mustern gesucht wird, sowie aus einer oder mehreren JavaScript-Dateien, die die gefundenen Daten sammeln und als HTML-Bericht (und optional als CSV-Export) ausgeben.
Das Plugin kann ein einzelnes Roboterarchiv oder einen ganzen Stapel von Archiven auf einmal verarbeiten. Für jedes verarbeitete Archiv wird der Bericht um einen neuen Abschnitt erweitert, und am Ende des Stapels wird automatisch ein Inhaltsverzeichnis mit Links zu den Abschnitten aller Roboter erzeugt.
Typische Anwendungen, die als fertige Vorlagen mitgeliefert werden: Suche nach der Verwendung einer bestimmten VKRC-/Fanuc-Variablen in allen Programmen, Auflisten verwendeter Werkzeuge/Basen/Kollisionen, Lesen von Masterdaten- oder Kalibrierdateien, Vergleich von TPVW-Programmversionen, Lesen des Kuka-Masterdaten-Logs oder Aufbau einer vollständigen Variablen-Referenztabelle zur späteren Verwendung (z. B. durch das Plugin Documentation Generator Pro).
▲ Plugin-Fenster
Das Plugin ist im Menü Others unter Robot Data Spy verfügbar.
Das Fenster listet alle in der Datei templates.ini registrierten Vorlagen auf. Nach der Auswahl einer Vorlage und eines oder mehrerer Roboterarchive führt das Plugin die zugehörige XML-Projektdatei für jedes ausgewählte Archiv aus und zeigt den erzeugten Bericht an.
Definiert die ausgewählte Vorlage einen input-Tag, wird vor dem Start der Suche ein kleiner Dialog angezeigt, in dem der Anwender die Suche parametrieren kann (z. B. auswählen, nach welchem Variablentyp gesucht wird).
Nach Abschluss der Suche wird der Bericht normalerweise in einem Speicherdialog angezeigt, in dem er
als HTML, PDF oder – wenn die Vorlage INNER_CSV füllt – als CSV gespeichert werden kann. Setzen Sie das
Attribut noContent des Tags RobotDataSpy auf true, um diesen
Dialog zu überspringen, z. B. wenn die Vorlage nur eine Referenzliste oder eine Liste von found-Ergebnissen erstellt.
Das Fenster bietet außerdem die Option Force rebuild reference table. Sie wirkt so, als wäre buildRef="true" bei jedem file-Tag der ausgeführten Vorlage gesetzt – unabhängig davon, was die Projektdatei tatsächlich angibt.
▲ Funktionsweise
Die Projektdatei wird von oben nach unten abgearbeitet; jeder Tag wird an der Stelle ausgeführt, an der er im Dokument steht.
- onReportBegin wird einmal aufgerufen, bevor das erste Roboterarchiv verarbeitet wird. Normalerweise wird hier das leere Berichtsdokument vorbereitet.
- Für jedes ausgewählte Roboterarchiv, der Reihe nach:
- Alle in der Datei gefundenen importscript- und input-Tags werden ausgewertet (importierte Skripte und die vom Anwender gewählten Werte gelten für den gesamten Lauf und werden nicht pro Roboter neu ausgewertet);
- jeder js- oder file-Tag wird in der Reihenfolge ausgeführt, in der er im Dokument steht. Ein js-Tag vor allen file-Tags dient typischerweise dazu, die Variablen zurückzusetzen, die die Daten des aktuellen Roboters sammeln (z. B. beginRobotSection());
- für jeden file-Tag werden alle zu path/wildcard passenden Dateien geöffnet, und jeder untergeordnete regexp- oder group-Tag wird auf ihren Inhalt angewendet, wobei für jeden Treffer der angegebene callback aufgerufen wird;
- ein abschließender js-Tag nach allen file-Tags dient typischerweise dazu, die gesammelten Daten als HTML-Fragment für den aktuellen Roboter auszugeben und an den Bericht anzuhängen (z. B. generateRobotSection()).
- onReportFinish wird einmal aufgerufen, nachdem alle Roboterarchive verarbeitet wurden. Normalerweise wird hier das Inhaltsverzeichnis angehängt und das Berichtsdokument abgeschlossen.
Die Variablen und Funktionen zum Sammeln und Ausgeben der Daten beschreibt das Kapitel JavaScript-API; eine nach diesem Ablauf aufgebaute Projektdatei zeigt das vollständige Beispiel.
▲ Vorlagen
Jeder im Plugin-Fenster verfügbare Eintrag ist in der Datei template\RobotDataSpy\templates.ini registriert. Jede Vorlage hat ein eigenes Unterverzeichnis mit ihrer XML-Projektdatei und optional einer eigenen JavaScript-Datei.
[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
| Eigenschaft | Werte | Beschreibung |
| [template_id] | Beliebiger gültiger Text ohne Leerzeichen | Eindeutige Kennung der Vorlage (Name des INI-Abschnitts). |
| name | Beliebiger gültiger Text | Name der Vorlage, der in der Vorlagenliste des Plugin-Fensters angezeigt wird. |
| description | Beliebiger gültiger Text | Kurzbeschreibung, die neben dem Namen der Vorlage angezeigt wird. |
| xml | Pfad zur Projektdatei | Pfad (relativ zu templates.ini) zur Projektdatei, die beschreibt, wonach gesucht wird. |
| js | Pfad zu einer JavaScript-Datei |
Pfad (relativ zu templates.ini) zur eigenen JavaScript-Datei der Vorlage, die die gefundenen Daten
sammelt und ausgibt. Optional – eine Vorlage, die bei ihren file-Tags nur buildRef setzt, um die Variablen-Referenzliste (neu) aufzubauen, benötigt keine. |
▲ Projektdatei
▲ Die XML-Projektdatei beginnt mit dem Haupttag RobotDataSpy.
<RobotDataSpy debug="" onReportBegin="" onReportFinish="" noContent="">
</RobotDataSpy>
Zwischen diesen Tags legt der Anwender die gesamte Such- und Berichtslogik fest. </RobotDataSpy>
| Eigenschaft | Werte | Beschreibung |
| debug | [ true | false ] | Gibt während der Berichtserstellung zusätzliche Debug-Informationen mit der Funktion print in der Konsole des Plugins aus. |
| onReportBegin | JavaScript-Funktionsaufruf | Wird einmal ausgeführt, bevor das erste Roboterarchiv verarbeitet wird. Bereitet typischerweise das (noch leere) Berichtsdokument vor, z. B. reportBegin(). |
| onReportFinish | JavaScript-Funktionsaufruf | Wird einmal ausgeführt, nachdem alle ausgewählten Roboterarchive verarbeitet wurden. Hängt typischerweise das während der Verarbeitung aufgebaute Inhaltsverzeichnis an und schließt das Berichtsdokument ab, z. B. reportFinish(). |
| noContent | [ true | false ] | Bei true wird nach Abschluss der Suche kein Speicherdialog für den erzeugten Berichtsinhalt angezeigt. Sinnvoll für Vorlagen, die nur die Variablen-Referenzliste (buildRef) oder eine found-Ergebnisliste statt eines druckbaren Berichts erstellen. |
Der Tag RobotDataSpy kann folgende Untertags enthalten: importscript, input, js, file.
▲ Der Tag importscript lädt vor der Berichtserstellung eine externe JavaScript-Datei in die Engine. Normalerweise wird damit eine gemeinsame Bibliothek mit Hilfsfunktionen und globalen Variablen importiert, die von mehreren Vorlagen genutzt wird (siehe global.js).
<importscript file="" />
| Eigenschaft | Werte | Beschreibung |
| file | Pfad zu einer JavaScript-Datei | Pfad (relativ zur XML-Datei des Projekts) zum zu importierenden Skript, z. B. ../global.js. |
▲ Der Tag input definiert einen kleinen Dialog, der vor dem Start der Suche angezeigt wird und mit dem der Anwender die Suche parametrieren kann. Der Dialog erscheint nur einmal, bevor das erste Roboterarchiv verarbeitet wird; der eingegebene Wert wird dann für jedes weitere Archiv des Stapels wiederverwendet (und sein callback erneut ausgeführt).
<input type="select" text="" options="" showIndex="" callback="" />
| Eigenschaft | Werte | Beschreibung |
| type | [ select | text | int | double ] |
Typ des Eingabeelements. select – Dropdown-Liste aus options. text – einzeiliges Textfeld. int – Drehfeld für Ganzzahlen. double – Drehfeld für Gleitkommazahlen (3 Nachkommastellen). |
| text | Beliebiger gültiger Text | Beschriftung über dem Eingabeelement, z. B. Select variable. |
| options | Kommagetrennte Liste | Nur bei type="select". Liste der wählbaren Werte, z. B. i,bin,t,ana,anain,binin,p,E,A,M,F,T,S. |
| showIndex | [ true | false ] | Nur bei type="select". Bei true wird neben der Dropdown-Liste ein zusätzliches, unabhängiges Zahlen-Drehfeld angezeigt, in das der Anwender eine weitere Zahl eingeben kann (z. B. den Index einer Variablen, sodass E aus der Liste und 5 im Drehfeld zusammen die Variable E5 beschreiben). Der Platzhalter __INDEX__ wird in callback nur bei showIndex="true" ersetzt; verwenden Sie ihn sonst nicht. |
| callback | JavaScript-Funktionsaufruf |
Wird ausgeführt, sobald der Anwender seine Auswahl bestätigt (und erneut mit demselben Wert für jedes weitere
Roboterarchiv). Die verfügbaren Platzhalter hängen von type ab: select – __OPTION__ (Text der gewählten Option) und, nur bei showIndex="true", __INDEX__ (die im zugehörigen Drehfeld eingegebene Zahl), z. B. set_var_fn('__OPTION__','__INDEX__'). text / int / double – __VALUE__ (der eingegebene Text bzw. die eingegebene Zahl). |
Wie alle anderen im Kapitel Platzhalter beschriebenen Platzhalter werden
__OPTION__, __INDEX__ und __VALUE__ als reiner Text ersetzt – setzen Sie sie in
callback selbst in Anführungszeichen, wenn ein String-Argument erwartet wird.
▲ Der Tag js führt einen JavaScript-Funktionsaufruf an der Stelle aus, an der er im Dokument steht. Er kann beliebig oft verwendet werden; am häufigsten werden damit direkt vor dem Durchsuchen der Dateien die Variablen des aktuellen Roboters zurückgesetzt und direkt danach das Berichtsfragment für den aktuellen Roboter erzeugt.
<js callback="" />
| Eigenschaft | Werte | Beschreibung |
| callback | JavaScript-Funktionsaufruf | Auszuführende Funktion, z. B. beginRobotSection() vor den file-Tags und generateRobotSection() danach. Siehe Funktionsweise. |
▲ Der Tag file wählt eine Menge von Dateien im Roboterarchiv aus, in denen gesucht wird.
<file path="" recursive="" wildcard="" format="" buildRef="">
...
</file>
...
</file>
| Eigenschaft | Werte | Beschreibung |
| path | Beliebiger gültiger relativer Pfad | Zu durchsuchendes Verzeichnis, relativ zum Stammverzeichnis des Roboterarchivs, z. B. KRC/R1/Folgen/. Für das Stammverzeichnis des Archivs einen leeren Wert oder ./ angeben. |
| recursive | [ true | false ] | Bei true wird das Verzeichnis rekursiv einschließlich seiner Unterverzeichnisse durchsucht. |
| wildcard | Kommagetrennte Liste von Dateifiltern |
Dateinamenfilter zur Auswahl der zu durchsuchenden Dateien, z. B. folge*.src,up*.src,makro*.src oder
*.ls. Die üblichen Platzhalter */? werden unterstützt. Bleibt das Feld leer, wird path als vollständiger relativer Pfad zu einer einzelnen Datei statt zu einem Verzeichnis behandelt, z. B. öffnet path="am.ini" ohne wildcard genau diese eine Datei. |
| format | [ TXT | KRC | VKRC | VFANUC | INI ] | Legt fest, wie die gefundenen Dateien geöffnet und geparst werden. Einzelheiten siehe Unterstützte Dateiformate. |
| buildRef | [ true | false ] | Bei true wird die Variablen-Referenzliste des Roboters aus den gefundenen Dateien aufgebaut (oder aktualisiert). Das ist dieselbe Referenzliste, die der Tag reference von Documentation Generator Pro verwendet. Wird nur buildRef verwendet, ist kein untergeordneter regexp-/group-Tag erforderlich. |
buildRef="true" überschreibt die aktuelle Variablen-Referenzliste des Roboters. Stellen Sie vor der Suche sicher,
dass dies beabsichtigt ist – insbesondere, wenn ein anderes Plugin (z. B. Documentation Generator Pro) noch
auf die bisherige Referenzliste angewiesen ist.
Der Tag file kann mehrere untergeordnete regexp-Tags (für die Formate TXT, KRC, VKRC, VFANUC) oder group-Tags (für das Format INI) enthalten.
▲ Der Tag regexp definiert einen regulären Ausdruck, der auf jede Zeile der vom übergeordneten file-Tag ausgewählten Dateien angewendet wird.
<regexp pattern="" callback="" />
| Eigenschaft | Werte | Beschreibung |
| pattern | Regulärer Ausdruck (Syntax von QRegularExpression) |
Regulärer Ausdruck, der ohne Beachtung der Groß-/Kleinschreibung auf jede Zeile der durchsuchten Datei angewendet wird. Benennen Sie jeden Teil des Musters, den Sie in callback benötigen, als benannte Erfassungsgruppe in der Form (?<__NAME__>...) – der Name ist frei wählbar und sollte beschreiben, was erfasst wird, z. B. (?<__VALUE__>\d+) oder, wie in used_coll.xml, (?<__CMD__>A(?<__COLL__>(8[1-9]|9[0-6]))\s*=[^$]+), das sowohl den gesamten Befehl als __CMD__ als auch, darin verschachtelt, nur die Kollisionsnummer als __COLL__ erfasst. Jede benannte Gruppe wird zu einem in callback verfügbaren Platzhalter – wie er ersetzt wird (anders als die integrierten Platzhalter), beschreibt das Kapitel Platzhalter. |
| callback | JavaScript-Funktionsaufruf |
Wird für jede zu pattern passende Zeile ausgeführt. Die im Callback-Text verfügbaren integrierten Platzhalter und
Platzhalter aus benannten Erfassungsgruppen listet das Kapitel Platzhalter auf – beachten Sie,
dass beide Arten unterschiedlich ersetzt werden. Gibt die Callback-Funktion eine Zahl ungleich null zurück, wird das Durchsuchen der restlichen Zeilen der aktuellen Datei beendet – nützlich, um vorzeitig abzubrechen, sobald alle benötigten Werte gefunden sind (siehe user_stop() in der Schwestervorlage kuka_maschinendaten_E1.js des vollständigen Beispiels). Ein Skriptfehler in callback (ungültige Syntax, Aufruf einer nicht definierten Funktion, ...) ist fatal und beendet den gesamten Lauf für alle verbleibenden Roboterarchive des Stapels, nicht nur für das aktuelle. |
▲ Der Tag group wird anstelle von regexp verwendet, wenn das format des übergeordneten file-Tags INI ist. Er durchläuft jeden Schlüssel in einer passenden [group]/Sektion der Datei.
<group name="" callback="" />
| Eigenschaft | Werte | Beschreibung |
| name | Gruppenname oder regulärer Ausdruck (Syntax von QRegExp) | Name der zu lesenden [group]/Sektion, z. B. Version. Mit einem regulären Ausdruck können mehrere Gruppen auf einmal erfasst werden, z. B. MotorDifference\s+for\s+Tool\s+\d+. Der Ausdruck muss auf den gesamten Gruppennamen passen, nicht nur auf einen Teil davon. |
| callback | JavaScript-Funktionsaufruf |
Wird für jeden Schlüssel in der bzw. den passenden Gruppe(n) einmal ausgeführt. Die im Callback-Text verfügbaren Platzhalter
__GROUP__, __KEY__ und __VALUE__ beschreibt das Kapitel Platzhalter. Gibt die Callback-Funktion eine Zahl ungleich null zurück, werden die restlichen Schlüssel der aktuellen Gruppe übersprungen (die Suche wird ggf. mit der nächsten passenden [group]-Sektion fortgesetzt). |
Mit mehreren Kombinationen aus file/group lassen sich verschiedene Sektionen aus derselben oder aus verschiedenen INI-Dateien lesen – siehe kuka_tpvw.xml, das die Gruppe [Version] aus am.ini liest, oder die *.cal-Datei von vkrc_calibration, die AbsolutMotorValues, CalibrationDifference und jede Sektion MotorDifference for Tool N in einem Durchgang liest.
▲ Platzhalter
Platzhalter sind reine Textmarken, die durch den tatsächlich gefundenen Wert ersetzt werden, bevor der callback-Text als JavaScript-Code ausgewertet wird. Es gibt zwei Arten, die unterschiedlich ersetzt werden – sie zu verwechseln ist der häufigste Fehler beim Schreiben einer neuen Vorlage.
| Art | Ersetzung | Verwendung in callback |
| Integrierter Platzhalter | Wird durch den rohen Wert ersetzt (ohne Anführungszeichen), z. B. wird __LINE__ zu RobWzg = 3 ;comment. | Setzen Sie ihn selbst in Anführungszeichen, wenn das Argument der Zielfunktion ein String sein muss, z. B. '__LINE__', '__FILEBASENAME__'. Für ein numerisches Argument ohne Anführungszeichen verwenden, z. B. __LINENUMBER__. |
| Benannte Erfassungsgruppe aus einem regexp-Muster | Wird durch den erfassten Wert ersetzt, den das Plugin bereits in doppelte Anführungszeichen setzt, z. B. wird __TOOL__ bei (?<__TOOL__>\d+) und dem Treffer 3 zu "3". | In callback ohne Anführungszeichen verwenden, z. B. robot_used_tool_fn('__MATCHED__', '__FILEBASENAME__', __TOOL__). Eigene Anführungszeichen ('__TOOL__') machen den erzeugten JavaScript-Code ungültig. |
Die folgende Tabelle listet alle integrierten Platzhalter auf; eigene Platzhalter aus benannten Erfassungsgruppen heißen wie die Gruppe selbst (siehe regexp).
| Platzhalter | Verfügbar in | Beschreibung |
| __MATCHED__ | regexp | Der gesamte von pattern erfasste Text. |
| __LINE__ | regexp | Vollständiger Text der Zeile, in der der Treffer gefunden wurde. |
| __LINENUMBER__ | regexp | Nummer (ab 1) der Zeile, in der der Treffer gefunden wurde. |
| __FILEBASENAME__ | regexp, group | Name der gerade durchsuchten Datei ohne Pfad. |
| __FILEABSOLUTEPATH__ | regexp, group | Absoluter Pfad der gerade durchsuchten Datei. |
| __GROUP__ | group | Name der gefundenen [group]/Sektion. |
| __KEY__ | group | Name des in der gefundenen Gruppe gefundenen Schlüssels. |
| __VALUE__ | group, input (text/int/double) | Wert des in der gefundenen Gruppe gefundenen Schlüssels (group) oder der vom Anwender eingegebene Text bzw. die eingegebene Zahl (input vom Typ text, int oder double). |
| __OPTION__ | input (select) | Text der vom Anwender in der Dropdown-Liste gewählten Option. |
| __INDEX__ | input (select, nur bei showIndex="true") | Nicht die Position der gewählten Option, sondern die Zahl, die der Anwender in das zusätzliche Drehfeld neben der Dropdown-Liste eingibt, wenn showIndex="true" gesetzt ist. |
| __NAME__ | regexp |
Ein beliebiger eigener Name einer benannten Erfassungsgruppe in pattern, geschrieben als
(?<__NAME__>...). Der Name ist völlig dem Autor der Vorlage überlassen – er wird zu einem neuen
in callback verwendbaren Platzhalter, der wie oben beschrieben ersetzt wird (als bereits in Anführungszeichen gesetzter String). Beispielsweise definiert used_coll.xml (?<__CMD__>A(?<__COLL__>(8[1-9]|9[0-6]))\s*=[^$]+), wodurch sowohl __CMD__ (der gesamte gefundene Befehl) als auch __COLL__ (nur die Kollisionsnummer) in callback="robot_requested_coll_fn(__CMD__, '__FILEBASENAME__', __COLL__)" verfügbar sind; andere mitgelieferte Vorlagen nennen ihre Gruppen passend zum erfassten Inhalt __VAR__, __VALUE__, __TOOL__, __BASE__, __GROUP__, __AXIS__ oder __VERSION__. |
▲ JavaScript-API
Die in der Projektdatei verwendeten Callback-Funktionen sind gewöhnliche JavaScript-Funktionen, die entweder mit importscript importiert oder direkt in der eigenen .js-Datei der Vorlage definiert werden (in templates.ini als js= registriert).
Einige Variablen und Funktionen stellt die Engine selbst bereit, andere die gemeinsame Bibliothek global.js, die mit dem Plugin ausgeliefert und von jeder Vorlage mit <importscript file="../global.js" /> importiert wird.
Von der Engine bereitgestellt
| Name | Beschreibung |
| ROBOT_NAME | Name des gerade verarbeiteten Roboterarchivs. |
| ROBOT_TOOL_DATA ROBOT_BASE_DATA ROBOT_LOAD_DATA |
Werkzeug-, Basis- und Lastdaten, die automatisch aus dem aktuellen Roboterarchiv gelesen werden, unabhängig von den
im Projekt definierten file-Tags – gesetzt direkt nach ROBOT_NAME, bevor irgendein
input-/js-/file-Tag des Projekts
ausgeführt wird. Der Aufbau ist bei Kuka- und Fanuc-Archiven unterschiedlich: Kuka – nur nach Nummer indiziert, z. B. 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, sonst nicht gesetzt; set: 1, wenn der Eintrag konfiguriert ist, sonst 0). ROBOT_LOAD_DATA[n] = { m, x, y, z, a, b, c, jx, jy, jz, set }. Fanuc – indiziert nach Bewegungsgruppe, dann Nummer, z. B. 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 }. Wie die beiden Strukturen mit Object.keys() durchlaufen werden, zeigen robot_info/kuka_robot_info.js und robot_info/fanuc_robot_info.js. |
| robot_counter | Anzahl der im aktuellen Lauf bereits verarbeiteten Roboterarchive (0 beim ersten). |
| print(text) | Schreibt text in die Debug-Konsole des Plugins. Nur sinnvoll bei debug="true" im Tag RobotDataSpy. |
| found(robotName, absoluteFilePath, name, matchedText, lineNumber) |
Trägt einen Eintrag in die Liste found results des Plugins ein, die in der Registerkarte References angezeigt wird.
Wird z. B. von der Vorlage find variable verwendet, um eine interaktive Liste aller Vorkommen der
gesuchten Variablen zu erstellen. Erfordert genau diese 5 Argumente in dieser Reihenfolge – ein Aufruf mit einer anderen Anzahl von Argumenten wird stillschweigend ignoriert. |
Von global.js bereitgestellt
| Name | Beschreibung |
| INNER_HTML | Sammelvariable für den Inhalt des erzeugten Berichts. Wird von der Engine nach Ausführung von onReportFinish gelesen, um den endgültigen HTML-Bericht zu erstellen, der dem Anwender angezeigt bzw. gespeichert wird. |
| INNER_CSV | Sammelvariable für einen optionalen CSV-Export, aufgebaut wie INNER_HTML (Beispiel siehe kuka_masterdata.js/kuka_maschinendaten_E1.js). |
| table_of_contents | Sammelvariable für die Inhaltsverzeichniszeile pro Roboter; wird in jeder Funktion nach Art von generateRobotSection() ergänzt und von reportFinish() in den Bericht geschrieben. |
| robots_contents_html | Sammelvariable für den eigentlichen Berichtsinhalt, ein Abschnitt pro verarbeitetem Roboter. |
| robot_counter_info robot_counter_warning robot_counter_error |
Zähler pro Roboter, die in jeder Funktion nach Art von beginRobotSection() zurückgesetzt und für eine kleine Info-/Warnungs-/Fehlerübersicht neben dem Abschnittstitel jedes Roboters verwendet werden. |
| icon_info icon_warning icon_error icon_arrow_up |
Kleine, base64-eingebettete Symbole zur Gestaltung des Berichts. |
| sort_numbers(a, b) | Allgemeine numerische Vergleichsfunktion für Array.sort(). |
| sort_program_name(s1, s2) | Vergleichsfunktion für Array.sort(), die gefundene Dateinamen so sortiert, wie Folge-/UP-/Makro-Programme üblicherweise aufgelistet werden. |
| reportBegin() | Standardimplementierung von onReportBegin: öffnet das (leere) HTML-Berichtsdokument. |
| reportFinish() | Standardimplementierung von onReportFinish: hängt das Inhaltsverzeichnis und die Abschnitte aller Roboter an den Bericht an und schließt dann das HTML-Dokument. |
Jede Vorlage sollte in ihrer eigenen .js-Datei zusätzlich mindestens eine Funktion beginRobotSection() (setzt die Variablen zurück, die die Daten des aktuellen Roboters sammeln) und eine Funktion generateRobotSection() (gibt die gesammelten Daten als HTML-Fragment aus und hängt es an robots_contents_html/table_of_contents an) definieren, die aus den js-Tags der Projektdatei aufgerufen werden. Siehe das vollständige Beispiel unten.
▲ Roboterdaten lesen & prüfen
ROBOT_TOOL_DATA/ROBOT_BASE_DATA/ROBOT_LOAD_DATA haben bei Kuka- und Fanuc-Archiven einen völlig unterschiedlichen Aufbau (andere Felder, andere Indizierung – siehe die Tabelle JavaScript-API oben). Dieselben drei Variablennamen werden bei beiden Roboterherstellern nur der Einheitlichkeit halber verwendet, damit Vorlagen für beide Hersteller ähnlich lesbar sind – die tatsächliche Datenstruktur, die verfügbaren Felder und die Art, wie festgestellt wird, ob ein Werkzeug-/Basis-/Lasteintrag wirklich konfiguriert ist, unterscheiden sich je Hersteller und müssen getrennt behandelt werden.
Das mitgelieferte Vorlagenpaar Robot info ist die maßgebliche Referenz dafür: robot_info/kuka_robot_info.xml + robot_info/kuka_robot_info.js (Kuka) und robot_info/fanuc_robot_info.xml + robot_info/fanuc_robot_info.js (Fanuc) geben jeden Werkzeug-/Basis-/Lasteintrag im Bericht aus und prüfen ihn – sie gleichen die von der Engine gelieferten Daten mit dem ab, was in den Programmen des Roboters tatsächlich verwendet wird, und markieren alles, was nicht gesetzt, nicht konfiguriert, nicht kalibriert oder unbenutzt erscheint. Die folgenden Tabellen sind direkt aus dieser Prüflogik abgeleitet.
Kalibrierdaten (AbsolutMotorValues/CalibrationDifference/MotorDifference bei Kuka,
Justage Data bei Fanuc) sind nicht Teil von ROBOT_TOOL_DATA/ROBOT_BASE_DATA/
ROBOT_LOAD_DATA – beide Vorlagen lesen sie selbst aus dem Archiv mit einem gewöhnlichen
file-/group-Tag (Kuka, *.cal, INI) bzw.
file-/regexp-Tag (Fanuc, sysmast.va, TXT)
und gleichen sie dann mit den von der Engine gelieferten Werkzeugdaten ab, um nicht kalibrierte Werkzeuge/Achsen zu markieren.
Kuka – robot_info/kuka_robot_info.xml + robot_info/kuka_robot_info.js
Welche Werkzeug-/Basisnummern tatsächlich verwendet werden, wird getrennt ermittelt: Jedes folge*.src-/up*.src-Programm wird mit zwei regexp-Mustern durchsucht, RobWzg\s*=\s*(?<__TOOL__>\d+) und Base\s*=\s*(?<__BASE__>\d+), die robot_used_tool_fn()/robot_used_base_fn() aufrufen – daraus wird die Spalte Used in gefüllt, und darauf beruhen die unten beschriebenen Abgleiche „nicht kalibriert“/„nicht verwendet“, unabhängig davon, was ROBOT_TOOL_DATA/ROBOT_BASE_DATA selbst enthält.
| Feld | Bedeutung | Wie es geprüft wird |
| ROBOT_TOOL_DATA[n].name ROBOT_BASE_DATA[n].name |
Konfigurierter Werkzeug-/Basisname, z. B. "T1 Gripper"/"B1 Table". | Das Präfix T<number>/B<number> wird mit /T\d+\s*/i/ /B\d+\s*/i entfernt; bleibt nichts übrig → "Tool N name not set"/"Base N name not set". |
| ROBOT_TOOL_DATA[n].type ROBOT_BASE_DATA[n].type |
1 = TCP, 2 = BASE, jeder andere Wert bedeutet nicht gesetzt. | Angezeigt als 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, wenn der Eintrag im Archiv tatsächlich konfiguriert ist, sonst 0. | set != 1 → "Tool N not configured"/"Base N not configured", und die Werte x/y/z/a/b/c werden rot angezeigt. |
| ROBOT_TOOL_DATA[n].x, y, z, a, b, c ROBOT_BASE_DATA[n].x, y, z, a, b, c |
Versatz des Werkzeug-/Basiskoordinatensystems (Position + Orientierung). | Unverändert ausgegeben; nur indirekt über set (siehe oben) markiert. |
| (Abgleich) | Ob eine scheinbar konfigurierte Werkzeugnummer jemals kalibriert wurde. | Fehlt robot_cal_MotorDifference[tool_no] (aufgebaut aus der Gruppe MotorDifference for Tool N der *.cal-Datei) → "Tool N not calibrated". |
| (Abgleich) | Ob ein in einem Programm tatsächlich verwendetes Werkzeug auch Lastdaten hat. | Fehlt ROBOT_LOAD_DATA[tool_no] oder ist sein set nicht 1 → "Load data for TN not set". |
| ROBOT_LOAD_DATA[n].m, x, y, z, a, b, c, jx, jy, jz | Lastmasse, Schwerpunktversatz und Trägheitsmomente. | Die Zeile wird bei set != 1 rot angezeigt (→ "Tool N used but load data not set"); eine konfigurierte Last, deren Werkzeugnummer nie in robot_used_tool vorkam, löst "Load data set but TN not used" aus, und ein fehlendes robot_cal_MotorDifference[tool_no] wiederholt hier auch die Warnung "Tool N not calibrated". |
Fanuc – robot_info/fanuc_robot_info.xml + robot_info/fanuc_robot_info.js
Die Verwendung wird auf die gleiche Weise ermittelt, jedoch nur innerhalb der Programmabschnitte /POS ... /END und nur für die Bewegungsgruppe 1: section_POS_fn()/section_END_fn() verfolgen den Abschnitt (^/POS\s*$/^/END\s*$), set_GP_fn() verfolgt die aktuelle Gruppe (^\s*GP(?<__GROUP__>\d+)), und UF\s*:\s*(?<__BASE__>\d+)\s*,\s*UT\s*:\s*(?<__TOOL__>\d+) ruft robot_used_UF_UT_fn() auf und füllt damit die Spalte Used in (only GP1).
Anders als bei Kuka vertraut diese Vorlage dem von der Engine gesetzten Fanuc-Flag ROBOT_LOAD_DATA[group][n].set
nicht: Eine Konfigurationsdatei kann ein Standardgewicht (z. B. 210) enthalten, auch wenn der Rest der Last
nie wirklich gesetzt wurde. fanuc_robot_info.js berechnet es deshalb vor der Verwendung selbst neu:
data.set = (x!=0 || y!=0 || z!=0 || jx!=0 || jy!=0 || jz!=0) ? 1 : 0 – angezeigt werden nur Zeilen mit mindestens
einem Versatz- oder Trägheitswert ungleich null.
| Feld | Bedeutung | Wie es geprüft wird |
| ROBOT_TOOL_DATA[group][n] ROBOT_BASE_DATA[group][n] |
{ number, group, name, x, y, z, w, p, r, config, set } – beachten Sie w, p, r (Orientierung) statt a, b, c bei Kuka. | Ein Eintrag wird nur aufgelistet (als User Tool Data/User Frame Data), wenn mindestens einer der Werte x, y, z, w, p, r ungleich null ist; ein Eintrag mit lauter Nullen gilt als nicht konfiguriert und wird übersprungen. |
| (Abgleich) | Ob ein aufgelistetes Werkzeug auch Lastdaten hat. | Für jedes aufgelistete ROBOT_TOOL_DATA[group][n]: Fehlt ROBOT_LOAD_DATA[group][n] oder ist sein (neu berechnetes) set nicht 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 } – beachten Sie comment statt name bei Kuka und das Fehlen von a, b, c (die Orientierung ist nicht Teil der Fanuc-Lastdaten). | Zeilen mit einem neu berechneten set von 0 werden stillschweigend übersprungen, nicht rot markiert. |
| (Abgleich, Justage/Kalibrierung) | Ob die Kalibrierung ($NUM_SET) der Achse 1 für Bewegungsgruppe 1 gesetzt ist. | Gelesen aus sysmast.va über \$VCAX_REF_GR\[(?<__GROUP__>\d+)\]\.\$REF_DATA\[1\]\.\$REF_AXIS\[(?<__AXIS__>\d+)\]\.\$NUM_SET ... =\s*(?<__VALUE__>\d+) in robot_cal[group][axis]; value != 1 → rot angezeigt und "Axis N not calibrated" (nur Gruppe 1). |
▲ Unterstützte Dateiformate
| Format | Beschreibung |
| TXT | Dateien werden als reiner Text geöffnet und Zeile für Zeile durchsucht. Dies ist die schnellste und allgemeinste Option und wird von den meisten mitgelieferten Vorlagen verwendet. |
| KRC / VKRC | Kuka-Dateien .src/.dat werden mit demselben Parser geöffnet, den der VKRC-Betrachter/-Editor verwendet. Langsamer als TXT, aber der Text wird genauso normalisiert, wie er im Betrachter angezeigt wird, was die benötigten regulären Ausdrücke vereinfachen kann. Außerdem erforderlich (zusammen mit buildRef="true"), um die Variablen-Referenzliste des Roboters (neu) aufzubauen. |
| VFANUC | Fanuc-Programmdateien .ls werden mit dem VFanuc-Parser geöffnet. |
| INI | key=value-Dateien, gegliedert in [group]-Sektionen (z. B. am.ini, *.cal). Verwenden Sie untergeordnete group-Tags statt regexp. |
Einige mitgelieferte Vorlagen (z. B. used_coll.xml, kuka_masterdata.xml) enthalten einen auskommentierten
Block <file ... format="KRL"> mit einem leeren untergeordneten <pattern>-Tag. Weder
KRL noch pattern sind implementiert – erkannt werden nur die fünf oben genannten Formate mit
untergeordneten regexp-/group-Tags. Wird
format="KRL" in einem aktiven (nicht auskommentierten) file-Tag verwendet, wird "File format KRL not supported
yet" protokolliert und der Tag übersprungen.
▲ Vollständiges Beispiel
Die folgende Projektdatei (mitgeliefert als Vorlage Used collisions) durchsucht Kuka- und Fanuc-Archive nach deklarierten, angeforderten und freigegebenen Kollisionsnummern und listet für jede Kollision auf, in welchen Dateien sie gefunden wurde.
<?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>
Die zugehörige JavaScript-Datei definiert die drei Kollisionstabellen, setzt sie in beginRobotSection() zurück, füllt sie in robot_requested_coll_fn() / robot_released_coll_fn() / robot_declared_coll_fn() und gibt schließlich in generateRobotSection() drei Tabellen aus (eine pro Kollisionsart), wobei das Ergebnis an robots_contents_html und eine Zeile an table_of_contents angehängt wird – genau wie unter Funktionsweise beschrieben.
▲ Mitgelieferte Vorlagen
Die folgenden Vorlagen werden mit dem Plugin ausgeliefert und sind in templates.ini registriert.
| Vorlage | Beschreibung |
| VKRC robot info | Zeigt Basisinformationen aus einem Kuka-Roboterarchiv an (verwendete Werkzeuge/Basen, Kalibrierdaten). |
| Fanuc robot info | Zeigt Basisinformationen aus einem Fanuc-Roboterarchiv an. |
| Used collisions | Zeigt deklarierte, angeforderte und freigegebene Kollisionen aus Kuka- und Fanuc-Roboterarchiven an. |
| VKRC find variable | Findet jede Verwendung einer vom Anwender gewählten VKRC-Variablen im Roboterarchiv. |
| VKRC Maschinendaten E1 | Findet die Einstellungen Maschinendaten E1 in $machine.dat. |
| VKRC TPVW check | Vergleicht die in am.ini angegebene TPVW-Version mit dem Versionskopf jedes Programms. |
| Find all variables | Findet alle VKRC- & Fanuc-Variablen im Roboterarchiv und baut die Variablen-Referenztabelle (neu) auf (buildRef, es wird kein Bericht angezeigt – noContent="true"). |
| Find all variables in $machine.dat | Findet alle VKRC-SYS-Variablen in $machine.dat und baut die Variablen-Referenztabelle (neu) auf. |
| Kuka masterdata | Findet alle Kuka-Masterdaten (Meldungen zur Erstjustage und zu weiteren Justagen) im Justage-Log. |
▲ Weiterführende Links
- Documentation Generator Pro – verwendet die mit buildRef aufgebaute Variablen-Referenzliste
- Qt QRegularExpression syntax (benannte Erfassungsgruppen, verwendet in regexp-Mustern)