Our 3D CAD supplier models have been moved to 3Dfindit.com, the new visual search engine for 3D CAD, CAE & BIM models.
You can log in there with your existing account of this site.
The content remains free of charge.
Um zu verstehen, wozu der Reverse TypeCode Regeleditor benötigt wird, werfen wir einen Blick auf die Suchfunktionalität im Allgemeinen.
Suchfunktionalität sollte auch die Suche nach Bestellnummer und Typenschlüssel ermöglichen. Bei Teilen ohne Wertebereichsfelder ist es ein Leichtes für jede Projektzeile die entsprechenden Werte zu indizieren. Bei Teilen mit Wertebereichsfeldern dagegen ändert sich Bestellnummer/Typenschlüssel mit jeder Änderung eines Wertebereichsfeldes (ausgenommen z.B. Funktionsmerkmale).
Bei Katalogen mit
sehr komplexen Wertebereichen, bei deren Auflösung Millionen und Milliarden
von Kombinationsmöglichkeiten entstehen würden, was den per Konfig gesetzten
Grenzwert überschreitet (siehe Abschnitt 3.2.18.8, „Auflösen von
Wertebereichen (gelben Feldern) begrenzen per Konfigschlüssel“), verwendet die Suche nicht
den Index. Anstatt dessen wird der im PARTdataManager bei der Suche
nach Bestellnummer/Typenschlüssel eingegebene Suchbegriff an das Skript pnoreverse.vbb
übergeben. Das
Skript berechnet anhand der in der Konfigurationsdatei pnoreverse.cfg
enthaltenen
regulären
Ausdrücke (verallgemeinertes Suchmuster für Zeichenketten) die
einzelnen Werte der Wertebereichsfelder.
Der Einsatzzweck
des Reverse TypeCode
Regeleditor (für den Rest des Kapitels wird die Bezeichnung
"Editor" verwendet) ist es, die Konfigurationsdatei pnoreverse.cfg
für
Katalogprojekte zu erstellen.
Der Editor hat verschiedene Funktionen, die das Erstellen vereinfachen. Unter Abschnitt 5.8.2.1.15.20.4, „Dialogbereiche des Editors“ sind die Funktionen beschrieben.
Der folgende Abschnitt gibt einen Überblick zum kompletten Ablauf.
Auflösungscheck, welcher bereits eine Auflistung der zu bearbeitenden Projekte liefert.
Für die
Kataloghauptebene wird eine pnoreverse.cfg
mit regulären
Ausdrücken erstellt, über welche die aufzulösenden Projekte gefunden
werden (Hauptkonfig).
Auf
Projektebene wird für jedes Projekt eine project_name_pnoreverse.cfg
erstellt, die reguläre Ausdrücke für die einzelnen Variablen, welche die
Bestellnummer bzw. den Typenschlüsse aufbauen, enthält.
Die Antwort liefert das Plugin Auflösungscheck.
Führen Sie auf Katalogebene unter Automatisierung den Befehl Auflösungscheck aus.
-> Die Analyse liefert detaillierte Ergebnisse u.a. über die Anzahl der nicht auflösbaren Projekte.
Die folgende
beispielhafte Abbildung zeigt, dass 31 Projekte Wertebereiche haben
(Anzahl komplexe Projekte) und davon 21
Projekte über dem Limit sind, also nicht auflösbar sind. Anzahl Projekte mit Reverse sind 0. Es
wurde also noch für kein Projekt eine pnoreverse.cfg
erstellt. Der
Prozentwert von 67,74 % ergibt sich aus dem Verhältnis von Anzahl Projekte über Limit zu Anzahl komplexe Projekte.
Details zum Auflösungscheck finden Sie unter Abschnitt 5.8.2.1.15.17, „Reverse search ‒ Auflösungscheck (automatisch)“.
-> Excel/Notepad (je nach Systemeinstellung) wird geöffnet. (Optional können hier Änderungen vorgenommen werden. Siehe Abschnitt 5.8.2.1.15.17, „Reverse search ‒ Auflösungscheck (automatisch)“.)
-> Auf
Kataloghauptebene wird die pnoreverse.cfg
angelegt.
|
Die
automatisch erstellte pnoreverse.cfg
hat folgenden
Aufbau:
[PRJ_PATH] ABC=folder/project1.prj XYZ=folder/project2.prj
Beim Auflösungscheck wird versucht, den Wert vor dem "=" zu errechnen. Im einfachsten Fall fangen alle Bestellnummern mit dem gleichen String wie z.B. ABC oder XYZ an, was aber bei komplexeren Fällen nicht garantiert ist. Nach dem = steht der relative Pfad zu den Projekten.
Der Auflösungscheck liefert wertvolle Informationen.
Allerdings
ist die automatisch erzeugte pnoreverse.cfg
im
Ursprungszustand noch nicht verwendbar, da
Die
automatisch erstellte pnoreverse.cfg
enthält
dennoch wichtige Informationen:
Sie gibt einen Überblick über alle zu bearbeitenden Projekte, so dass der Umfang der Arbeiten eingeschätzt werden kann.
Sie zeigt jeweils den eindeutigen Teilstring, der zum Projekt führt (z.B. AKM1, AKM2, etc.).
Die Hauptkonfig kann vor Beginn der eigentlichen Arbeiten an den REGEX-Regeln der Projekte entsprechend sortiert werden.
Letztlich wird natürlich auch Arbeitszeit beim Erstellen der Hauptkonfig eingespart.
Automatisch
erstellte pnoreverse.cfg
- REGEX-Regeln
fehlen noch!
Gültige,
manuell fertig gestellte pnoreverse.cfg
- REGEX-Regeln
vorhanden. Siehe hierzu unten.
Optional: Rufen Sie den Editor auf Kataloghauptebene auf, um zu prüfen, ob die Liste der aufzulösenden Projekte erstellt wurde.
-> Der Reverse Editor öffnet sich mit Dialogfenster List of projects in main pnoreverse.cfg.
Schließen Sie das Fenster mit Klick auf .
Erstellen Sie in Notepad++ die benötigten regulären Ausdrücken (REGEX), mit denen aus der Bestellnummer bzw. dem Typenschlüssel ein bestimmter String herausgefiltert wird, über den die Projekte gefunden werden können.
Öffnen Sie die
Hauptkonfig pnoreverse.cfg
(Katalogebene)
mit Notepad++.
(Aus dem geöffneten Editor können Sie dies im Menü Edit mit Klick auf Open main pnoreverse.cfg erreichen.)
Erstellen Sie auf Basis der einfachen Liste aus dem Auflösungscheck die benötigten REGEX.
Liste, die vom Auflösungscheck geliefert wurde:
[PRJ_PATH] ABC=folder/project1.prj XYZ=folder/project2.prj
Die REGEX-Schlüssel müssen beginnend mit 0 hochgezählt werden. REGEX0, REGEX1, REGEX2, etc.
^ bedeutet, dass der folgende String am Anfang stehen muss.
Die runde Klammer bezeichnet den im Fokus stehenden Teilstring.
REGEX10=^(HD\d{2}B).*-
Bedeutung des regulären Ausdrucks: Am Anfang steht "HD" gefolgt von 2 beliebigen Ziffern und einem "B". Das ist der Teilstring, der zum Projekt führt. Es folgen beliebige Zeichen und ein Strich.
Es folgt als zweiter Schlüssel der entsprechende Teilstring des Typenschlüssels / der Bestellnummer und als Schlüsselwert der Projektpfad. Bei mehreren Treffermöglichkeiten erfolgt die Pfadangabe mehrfach.
HD24B=thomsonlinear\linear_actuators\electrakhd\electrakhd_asmtab.prj HD12B=thomsonlinear\linear_actuators\electrakhd\electrakhd_asmtab.prj
#(HD12B)017-0100EXX1MMSF REGEX10=^(HD\d{2}B).*- HD24B=thomsonlinear\linear_actuators\electrakhd\electrakhd_asmtab.prj HD12B=thomsonlinear\linear_actuators\electrakhd\electrakhd_asmtab.prj #(MX12-)B8M05P0CC REGEX11=^(MX\d{2}-) MX24-=thomsonlinear\linear_actuators\max_jac\max_jac_asmtab.prj MX12-=thomsonlinear\linear_actuators\max_jac\max_jac_asmtab.prj #(W1202)-58A10XA1BD REGEX12(W\d{4})- W2404=thomsonlinear\linear_actuators\whispertrak\whispertrak_asmtab.prj W2402=thomsonlinear\linear_actuators\whispertrak\whispertrak_asmtab.prj W1204=thomsonlinear\linear_actuators\whispertrak\whispertrak_asmtab.prj W1202=thomsonlinear\linear_actuators\whispertrak\whispertrak_asmtab.prj
Öffnen Sie den Editor auf dem Katalogverzeichnis.
-> Das Dialogfenster List of projects in main pnoreverse.cfg wird geöffnet.
Führen Sie auf
dem zu bearbeitenden Projekt einen Doppelklick aus. Im Folgenden ist
beispielhaft .../thomsonlinear/linear_actuators/electrakhd/electrakhd_asmtab.prj
verwendet.
Entscheidend für den gesamten nun folgenden Prozess ist die PN variable.
Diese zeigt den internen Aufbau (Merkmalalgorithmus) der Bestellnummer bzw. des Typenschlüssels.
| ||||
[a] Evtl. enthalten Variablen selbst wieder Merkmalsalgorithmen, wobei nicht jede dort verwendete Variable wirklich benötigt wird. |
Holen Sie nun eine Variable nach der anderen in den Editor und erstellen Sie den passenden REGEX.
PN = '$MIVPN.$STDLC.$S.$EMCSOPT.$HOPT.$RAOPT.$FAOPT.$AORI.-D'
Im vorliegenden Beispiel ist die PARTNUMBER von folgenden Variablen abhängig:
Selektieren Sie im Dialogfenster Variable table die Variable, die Sie in den Editor holen möchten. Zum Beispiel STDLC. Siehe Abb. „Variable in Editor holen“.
-> Die Variable wird im Editor im Dialogbereich Variable geladen.
Passen Sie die Einstellungen an.
|
Klicken Sie auf den Button Add/Update selected variable to editor.
-> Der reguläre Ausdruck wird auf Basis der Einstellungen im Dialogbereich Variable erstellt.
Nehmen Sie gegebenenfalls im Editor noch manuelle Änderungen vor.
-> Das Ergebnis wird angezeigt.
Regex: HD.{2}(.+-) Sample: HD12B017-0100EXX1MMSF Match: HD12B017- ---------------------- Group 1: B017- -> (.+-)
Der Regex "HD.{2}(.+-)" findet im Sample "HD12B017-0100EXX1MMSF" den Match "HD12B017-".
Jetzt kommen die runden Klammern ins Spiel. Diese bezeichnen den Teil des Ausdrucks, der gesucht wird.
Group zeigt das Ergebnis des Klammerausdrucks. Vor -> steht das Ergebnis. Nach -> steht der Suchausdruck.
Mit (.+-) wird also B017- gefunden.
Wurden mehrere Klammern verwendet, erscheinen mehrere Gruppen. Unterschiedliche Farben verdeutlichen die Gruppen.
Speichern Sie die Konfiguration mittels File Menü -> Save.
|
Führen Sie den Prozess für alle benötigten Variablen durch.
Sonderfall Variablenmapping: Wenn der im Typenschlüssel verwendete Teilstring nicht mit dem Wert der Sachmerkmalstabelle identisch ist, muss ein Variablenmapping durchgeführt werden. Details hierzu finden Sie unter Abschnitt 5.8.2.1.15.20.6, „Variablenmapping“.
Im vorliegenden Beispiel muss für die Variable MIV zusätzlich noch ein Mapping durchgeführt werden. Grund hierfür ist, dass der im Typenschlüssel verwendete Teilstring nicht mit dem Wert der Sachmerkmalstabelle identisch ist.
Um den Editor zu
starten, stellen Sie bitte sicher, dass sich die Dateien reverseeditor.vbb
und die
dazugehörige reverseeditor.cfg
im Verzeichnis
$CADENAS\libs\all\plugins
befinden.
Sind die Dateien vorhanden, kann der Editor als Plugin innerhalb von PARTproject gestartet werden.
Der Benutzer kann den Editor im Indexbaum per Kontextmenübefehl unter Automatisierung -> Reverse typecode search editor auf verschiedenen Ebenen starten.
Startet der Benutzer den Editor auf dem Verzeichnis "23d-libs", erscheint Das Dialogfenster Catalog list.
1 – Catalog name Spalte – Hier wird der Katalogname aus 23d-libs angezeigt. Mit Klick auf den Spaltennamen können die Katalog alphabetisch sortiert werden.
2 – Config exists Spalte – YES wenn für diesen Katalog eine Haupt-Konfig existiert, NO wenn keine Haupt-Konfig existiert.
3 – File locked Spalte – YES wenn die Haupt-Konfig schreibgeschützt ist, NO wenn die Haupt-Konfig beschreibbar ist.
4 – Config path Spalte – Anzeige des Konfig-Pfades, wenn die Haupt-Konfig existiert.
5 – Open selected Button - Nachdem
der User den Katalog selektiert und auf den Button Open selected geklickt hat,
erscheint ein Dialogfenster mit einer Liste aller Projekte, die eine Datei
pnoreverse.cfg
haben. Um dieses
Fenster zu öffnen, können Sie alternativ auch einen Doppelklick auf dem
Katalog machen. Das Dialogfenster ist unter Abschnitt 5.8.2.1.15.20.3.2, „Editor auf
Katalogverzeichnis starten“
beschrieben.
Wenn Sie den Editor auf dem Katalogverzeichnis starten, erscheint das Dialogfenster List of projects in main pnoreverse.cfg.
In diesem Fenster erscheint eine Liste der Projekte, die in der Haupt-Konfig des betreffenden Katalogs zugefügt wurden.
1 – Project name – Name des Katalogprojekts
2 – Config
exists – YES, wenn pnoreverse.cfg
für das
betreffende Projekt existiert. NO wenn keine pnoreverse.cfg
für das
betreffende Projekt existiert.
3 – File locked - YES, wenn
pnoreverse.cfg
für
das betreffende Projekt schreibgeschützt ist. NO, wenn sie beschreibbar
ist.
4 – Project path – Absoluter Pfad zum Katalogprojekt
5 – Open selected - Nachdem der User das Projekt selektiert und auf geklickt hat, öffnet sich der TypeCode Editor mit geladener Konfigurationsdatei des selektierten Projekts. Um dieses Fenster zu bekommen, kann alternativ auch ein Doppelklick auf dem Projektnamen gemacht werden. Im nächsten Abschnitt sehen Sie die im Editor geladene Konfigurationsdatei.
Wenn der Benutzer den Editor direkt auf einem Projekt startet, wird er mit der geladenen Konfiguration für dieses Projekt geöffnet.
Nachdem der
Benutzer das Plugin zum ersten Mal gestartet hat, wird unter $CADENAS_USER
ein Verzeichnis
mit Namen reverseeditor erstellt.
Darin findet
sich das Verzeichnis configuration mit den
Konfigurationsdateien reverseeditor.cfg
und vartypes.cfg
.
vartypes.cfg
– enthält
Variablentypen, die üblicherweise für das Erstellen von pnoreverse.cfg
Konfigurationsdateien verwendet werden. Die Liste kann mittels Editor
modifiziert werden.
reverseeditor.cfg
– wird
verwendet um den Verlauf der zuletzt geöffneten Projekte aufzuzeichnen,
Schriftstil/Schriftgröße und den Pfad zu Notepad.
In diesem Abschnitt werden die einzelnen Dialogbereiche des TypeCode Editors erläutert.
Nachdem ein Projekt geöffnet wurde, wird der Dialogbereich Variablentabelle mit allen Projektvariablen des geöffneten Projekts geladen. Der Benutzer kann Name, Status und Format der Variablen sehen.
Funktionen im Dialogbereich Variablentabelle:
Mit Klick auf den -Button werden die Variablen angezeigt, die den eingetippten Text im Namen haben.
Mit Klick auf wird die in der Variablenliste selektierte Variable in den Editor-Dialogbereich übertragen. Dasselbe erreichen Sie durch Doppelklick auf die Variable.
Mit Klick in den Spaltenkopf unter Name werden die Variablen nach ihrem Namen sortiert.
Neben dem Variablennamen kann im Dialogbereich Variablentabelle auch Folgendes überprüft werden:
Sobald Sie eine Variable im Dialogbereich Variablentabelle selektieren, werden die Variablenformel bzw. die Variablenwerte unterhalb angezeigt.
Der TypeCode Tester macht genau dasselbe wie PARTdataManager.
Dieses Modul wird verwendet zum Testen der Projektkonfiguration durch Finden des TypeCodes (oder einer Liste von TypeCodes) mittels des REGEX in der Konfigurationsdatei.
1 - Wenn der User nur EIN TypeCode-Beispiel testen möchte -> Tragen Sie den TypeCode im Eingabefeld ein und starten Sie den Test per Klick auf den Button .
2 - Dieser Button startet den Test (für den Fall, dass nur EIN Typecode getestet werden soll)
3 - - zum Testen einer Liste von TypeCodes - Es muss keine weitere Aktion erfolgen. Der Test startet automatisch sobald die Datei mit der Liste selektiert wurde.
4 - - Beenden des Testlaufs der TypeCode-Liste
5 - - Öffnen des Dialogfensters Typecode generator
Typecode generator wird verwendet, um eine Testliste für das geöffnete Projekt zu generieren.
Hierzu muss der User die korrekte Variable für den Typecode (Variable for PN) und eine Anzahl von zu generierenden TypeCodes (Number of PNs) auswählen.
Mit Klick auf wird auf eine Liste von TypeCodes auf der Basis von zufällig bestimmten Wertebereichswerten (aus gelben Feldern) erstellt.
Im obigen Beispiel enthält die Testliste 100 verschiedene TypeCodes.
Wird das Auswahlkästchen Open folder afterwards aktiviert, wird nach der Generierung der Testliste das Verzeichnis mit der erstellten Liste geöffnet.
Während der Generierung der Testliste kann der User auf den Button , um das Fenster zu minimieren den Prozess im Hintergrund ablaufen zu lassen.
Die Testliste
ist im CSV-Format und kann im Texteditor geöffnet werden. Speicherort ist:
$CADENAS_USER\reverseeditor\test_lists\catalogname\firstletterofprojectname\projectname
.
Die folgende Abbildung zeigt ein Beispiel einer Testliste:
6 - Anzeige der Gesamtanzahl von getesteten TypeCodes (test all), erfolgreiche Tests (test ok) und fehlgeschlagene Tests (test not ok)
7 – Anzeige der Testergebnisse:
8 – : Anzeigebereich (siehe 7) löschen
9 – Auswahlkästchen: Aktivieren Sie, wenn Sie nur EINEN Typecode testen und die Details sehen möchten. Die Aktivierung hat keinen Effekt, wenn der User die ganze Liste testet ( ).
10 – : Export der Testergebnisse in eine CSV-Datei. In Abhängigkeit von der gewählten Option werden alle (All), nur die erfolgreichen (Yes) oder nur die fehlgeschlagenen (No) TypeCodes exportiert.
Dieses Modul dient als Debugging/Logging Fenster. Der User kann verschiedene Arten von Nachrichten sehen, die z.B. warnen, wenn etwas fehlschlägt (z.B. "cfg is read only") oder informieren über ausgeführte Aktionen (z.B. "variable deleted").
1 – Hauptfenster: Der Bereich zeigt
den Inhalt der Konfigurationsdatei pnoreverse.cfg
.
Strg + S ist das Tastaturkürzel, um den Inhalt zu abzuspeichern.
1b - Kommentar: Beeinflusst nicht die Funktionalität oder Testergebnisse. Wird nur verwendet, um den Prozess der Erstellung des REGEX-Ausdrucks zu erleichtern.
1c – REGEX-Wert: – Dieser REGEX wird verwendet, um zu definieren, wonach in der unter 1a spezifizierten Variablen, gesucht werden soll.
2 - "PNvariable" Dialogbereich
2a – Bestimmen Sie im Listenfeld die Variable für den Typenschlüssel.
PN = '$MIVPN.$STDLC.$S.$EMCSOPT.$HOPT.$RAOPT.$FAOPT.$AORI.-D'
Hinweis | |
---|---|
Für alle Variablen, die in der Variablen PN (PARTNUMBER) enthalten sind bzw. diese beeinflussen, müssen REGEX-Regeln definiert werden. Meist sind die in PN enthalten Variablen Wertebereichsvariablen, aber nicht notwendigerweise. Fixe Werte wie "-D" im Beispiel oben müssen nicht in den Editor übernommen werden. |
3 – Sample of Type Code: Das Beispiel hängt ab von der unter 2a selektierten Variablen. Wird die Auswahl unter 2a geändert, wird automatisch auch das Beispiel hier angepasst. Hauptzweck ist, das Beispiel für den Kommentar und die automatische Klammerplatzierung innerhalb des Kommentars zu generieren (vgl. oben 1b).
4 – Regex: Zeigt alle REGEX aller einzelnen Variablen summiert in EINEM REGEX-Wert. Beim Zufügen oder Updaten zuvor hinzugefügter Variablen erfolgt hier automatische Anpassung. Es ist hier keine User-Interaktion notwendig/möglich.
5 – "File info" Dialogbereich: Informationen zur Status der Konfigurationsdatei: Konfigurationsdatei beschreibbar (readwrite) oder schreibgeschützt (read-only) oder Hinweis, wenn die Konfigurationsdatei noch nicht erstellt wurde.
6 – "Variable added" Dialogbereich: Hier können Variablen, die der Konfigurationsdatei bereits zugefügt wurden wieder gelöscht werden.
7 – Anzeigebereich zum manuellen Editieren der aktuell selektierten Variablen. Um die Änderungen zu übergeben, klicken Sie auf den Button (7a).
8 - "Variable" -Dialogbereich: Konfiguration und Zufügen von Variablen zur Konfigurationsdatei.
Selektieren Sie eine Variable, den Variablentyp und die Länge. Klicken Sie dann auf den Button (8i), um sie zuzufügen.
Name: Anzeige der aktuell selektierten Variablen. Das Listenfeld enthält alle im Projekt enthaltenen Variablen.
Type: Variablentyp (das
Listenfeld wird gefüllt mit den Daten aus vartypes.cfg
)
Length: Variablenlänge. Bestimmen Sie die Anzahl der Zeichen der Variable. Im Falle, dass die Variable verschiedene Längen haben kann, wird hier die minimale Anzahl von Zeichen bestimmt.
To: Im Falle, dass die Variable verschiedene Längen haben kann, wird hier die maximale Anzahl von Zeichen bestimmt.
Preview: des REGEX basierend auf den Eingaben unter 8b, 8c, 8d
REGEX: Standard- und häufigster Fall ist, wenn nur EIN REGEX zum Finden der Variable benötigt wird. In diesem Fall wird "-1" angezeigt.
In der Konfigurationsdatei wird der REGEX für diese Variable ohne ihren numerischen Wert angezeigt.
Manchmal wird für das Finden der Variablen mehr als EIN REGEX benötigt, wie in folgendem Fall:
In diesem Fall werden die REGEX hochgezählt.
Zum Editieren des gewünschten REGEX wählen Sie im Listenfeld den entsprechenden Wert.
Soll REGEX1 editiert werden, ändern Sie den Wert im Listenfeld auf 1. Die Nummer kann manuell eingetippt werden oder mittels Pfeiltasten angepasst werden.
: Mit Klick auf den Button wird das Dialogfenster Variable mapping geöffnet, wo das Mapping von Variablenwerten editiert werden kann. Details finden Sie unter Abschnitt 5.8.2.1.15.20.6, „Variablenmapping“.
: Mit Klick auf den Button wird die Variable der Konfigurationsdatei zugefügt.
9 – - Es ist obligatorisch auf diesen Button zu klicken, wenn irgendwelche manuellen Änderungen im Editor vorgenommen wurden. Verwenden Sie den Button bevor Sie neue Variable zufügen oder oder verwenden.
Hinweis | |
---|---|
Wenn Sie die Konfiguration tatsächlich speichern wollen, müssen Sie im Menü File auf Save klicken! |
10 – - Stellen Sie sicher, dass Sie zuvor auf geklickt haben. Die Funktion ist klassisches Undo, welches die letzten Änderungen zurücknimmt.
11 – - Stellen Sie sicher, dass Sie zuvor auf geklickt haben. Verwenden Sie die Funktion, um Änderungen durch zurückzunehmen.
12 – - Löschen aller temporären / unterstützenden / festen Variablenwerte aus dem Editor, wie bespielsweise folgende:
WKHZ ist keine Variable dieses Projekts. Sie ist nur ein fester Wert 'WKHZ' am Beginn des Beispiels (Sample), aber sie kann unterstützend während des Erstellungsprozesses der Konfigurationsdatei zum Editor zugefügt werden, um den Prozess zu erleichtern.
Das Modul Regex tester ist auf der Basis der Webseite "regex101.com" als Zusatztool gestaltet, welches beim Erstellen und Testen von REGEX helfen soll.
Zuerst werden die Buttons und Features erläutert und dann die Verwendung des Tools.
1 – Tragen Sie den REGEX ein, den Sie für die Suche verwenden möchten.
2 – Tragen Sie den TypeCode ein, welchen Sie mit dem REGEX aus 1 finden wollen.
3 – : Mit Klick auf den Button wird die aktuell unter Variable added selektierte Variable verwendet.
-> Der für diese Variable definierte REGEX wird ins Feld 1 übertragen.
-> Das Beispiel unter Sample wird ins Feld 2 übertragen.
4 – - Startet den REGEX-Test – Es wird eine Suche ausgeführt mit der versucht wird, mit dem Ausdruck unter 1 den Beispielwert unter 2 zu finden.
5 – Results of REGEX test: Die Bedeutung der angezeigten Ergebnisse wird erläutert unter Abschnitt 5.8.2.1.15.20.4.6.2, „Modul-Verwendung“.
6 – : Löschen der Ergebnisse unter 5 (die ganze Box).
7 – Always clear: Wenn das Auswahlkästchen aktiviert wird, dann werden die Testergebnisse aus 5 jedesmal gelöscht, wenn man auf den Button klickt.
In diesem Abschnitt werden die Testergebnisse erläutert:
Variable – Variablenname, deren REGEX getestet wird
Regex – REGEX, der zum Finden des Beispiels verwendet wird
Sample – Beispiel, das mit dem REGEX gesucht wird
Match – Ergebnis, welches durch den REGEX ermittelt wurde. Wenn nichts gefunden wird, erscheint 'No match'.
Wenn runde Klammern im REGEX verwendet werden, werden die Werte innerhalb der Klammern gesucht und in den Testergebnissen als Gruppen angezeigt.
Runde Klammern beeinflussen nicht die Suchergebnisse. Sie werden verwendet, wenn untersucht werden soll, was mit einem spezifischen Teil des REGEX gefunden wird.
Beispiel 1: Es soll untersucht werden, was das erste \w findet und was das zweite \w findet.
Das erste \w findet b, das zweite \w findet c, was unter Group 1 und Group 2 angezeigt wird. Die unterschiedlichen Farben verdeutlichen lediglich die Gruppen.
Mit \d{4} wird versucht 4 Zahlen in Folge zu finden. Das Beispiel "aaa123bcd" enthält aber nur 3 Zahlen in Folge.
Kann TypeCode 'aaa123bcd' mit REGEX '\w{3}\d{3}(\w)(\w)(\w)' gefunden werden? (Der Fokus liegt auf dem Ausdruck in runden Klammern.)
\w repräsentiert 1 Buchstaben und wenn 'aaa' gefunden werden soll, wird versucht es mit \w{3} zu finden.
\d repräsentiert 1 Ziffer und wenn '123' gefunden werden soll, wird versucht es mit \d{3} zu finden.
Die Buchstaben b, c, d könnten mit \w{3} gefunden werden, aber man kann sie auch separat suchen. Wenn man annimmt, dass sie Werte von verschiedenen Variablen sind, sucht man sie mit dreimaligem \w.
Kann TypeCode 'aaa123bcd' mit REGEX '\w{4}\d{3}(\w)(\w)(\w)' gefunden werden?
\w{4} ist ein REGEX für einen Block aus 4 Buchstaben und ist platziert am Beginn des Ausdrucks. Im Beispiel gibt es aber am Beginn keine 4 Buchstaben und der REGEX kann nichts finden. Es gibt keine Übereinstimmungen und daher wird in den Testergebnissen 'No match' angezeigt. -> Der REGEX sollte korrigiert werden!
Wie schon am Anfang des Kapitels erwähnt, ist dieser Regex-Tester basierend auf der Webseite "regex101.com" entwickelt. Es gibt jedoch einen Unterschied.
Der REGEX findet auch partielle Übereinstimmungen. Das 'aaa' am Beginn des Beispiels wird übergangen.
Unser Regex-Tester wird nichts finden, wenn der REGEX nicht von Beginn an korrekt ist, weil beim Testen und Zufügen neuer Variablen zur Konfigurationsdatei angenommen wird, dass alle zuvor erstellten Variablen korrekt sind.
Im File-Menü finden sich folgende Optionen:
Außerdem sehen Sie eine Liste der kürzlich geöffneten Projekte.
Paste PRJ path – Befindet sich der Pfad zur Projektdatei oder der Pfad zur Projekt-Konfigurationsdatei im Zwischenspeicher, wird mit Klick auf den Befehl die entsprechende Konfiguration im Reverse-Editor geladen.
Open main pnoreverse.cfg – Haupt-Konfigurationsdatei des Katalogs wird geöffnet
Copy path for main pnoreverse.cfg – Vorbereiten der Daten, die in der Haupt-Konfig das Projekt eindeutig identifizieren und Kopieren in den Zwischenspeicher.
Open CFG in notepad – Die Konfiguration des aktuell im Reverse-Editor geöffneten Projekts wird im eingestellten Texteditor (z.B. Notepad++ [siehe "Settings"-Menü -> Config]) geöffnet.
Refresh data – Aktualisieren der Anzeige im Reverse-Editor - Verwenden Sie diese Funktion, wenn die Konfiguration außerhalb, z.B. direkt in Notepad++, geändert wurde).
Der Befehl Test list generator öffnet das Dialogfenster Typecode generator. Details hierzu finden Sie unter Abschnitt 5.8.2.1.15.20.4.3, „TypeCode Tester“.
Im Prinzip ist der Typecode iterator eine Art Test list generator. Anders als der Test list generator, der eine Typecode-Liste durch zufälliges Auswählen von Variablen und deren Werten erstellt, wird der Typecode iterator nur durch die selektierten Variablen iterieren und wird Typecodes mit allen möglichen Werten jeder selektierten Variablen erstellen.
Der Test list generator ist während des Prozesses der Erstellung der REGEX-Regeln für Variablen hilfreicher, aber der Typecode iterator ist genauer beim Überprüfen der REGEX-Regeln und sorgt so letztlich für eine bessere QA.
1 – Variable for PN: Selektion der Typecode-Variablen
2 – Klick auf öffnet eine Liste von Wertebereichsvariablen (gelbe Felder) für das gewählte Projekt. Der Benutzer kann hier Variablen selektieren, durch die er iterieren möchte und die in die Typecode-Liste aufgenommen werden.
3 – Max Number of Values per ValueRange - Ist die Variable eine Wertebereichsvariable, kann der Benutzer die maximale Anzahl von Werten bestimmen.
4 – Geschätzte Anzahl von Typecodes, die mit dem Iterator generiert werden.
Der Multithread tester ist eine erweiterte Version des TypeCode tester, der unter Abschnitt 5.8.2.1.15.20.4.3, „TypeCode Tester“ beschrieben ist.
1 – Soll nur EIN Typecode-Beispiel getestet werden, tragen Sie den Tpyecode ein und starten Sie den Test mit Klick auf oder Enter.
2 – - Test starten (wenn nur EIN Typecode getestet wird)
3 – - Testen der Typecode-Liste – Sie müssen nichts weiter tun. Der Test startet automatisch, sobald die Liste geladen ist.
4 – - Mit Klick auf den Button kann das Testen der Typecode-Liste abgebrochen werden.
5 – - Erneutes Testen der zuletzt geladenen Liste
6 – - Erstellen einer Testliste, die nur aus den Typecodes besteht, die den Test der letzten getesteten Liste nicht bestanden haben. Diese neue Testliste wird im selben Ordner gespeichert wie die letzte getestete Liste.
7&10c – Beachten Sie, dass diese Option nur verwendet werden kann, falls Sie mit einer Testliste testen, die mit dem Typecode iterator erstellt wurde. Sobald eine Liste beendet ist, kann jeder Typecode der Liste individuell getestet werden. Kopieren Sie einfach Typecode in das Eingabefeld 1 und klicken Sie auf . Der Mident für diesen Typecode wird in 10c angezeigt und außerdem wird ein neuer Button angezeigt. Wenn Sie auf diesen Button klicken und PARTdataManager geöffnet ist, wird das Teil dort geöffnet. Der Button wird auch angezeigt, wenn Sie nur EINEN Typecode testen und für den Fall, dass der Test OK ist, für diesen Typecode.
8 - - Aktivieren Sie das Auswahlkästchen, wenn Sie nur EINEN Typecode testen und Details sehen möchten wie "welcher Wert wurde mit welcher REGEX-Regel gefunden", "ist der Typecode verknüpft mit einer korrekten Konfigurationsdatei", etc. Beim Testen einer gesamten Liste hat diese Option keine Auswirkung.
9 – - Wenn das Auswahlkästchen aktiviert ist, werden Typecodes, die den Test nicht bestanden haben, in KEINER Liste zusammen mit gesuchtem Typecode angezeigt.
10 – Registerseite All: Anzeige aller Ergebnisse aller getesteten Typecodes.
10a - Registerseite Yes list: Anzeige aller Typecodes, die den Test bestanden haben.
10b - Registerseite No list: Anzeige aller Typecode, die den Test nicht bestanden haben.
11 – Threads - Anzahl der logischen Prozessoren des PC, die für das Testen verwendet werden. Je mehr logische Prozessoren, desto weniger Zeitaufwand für das komplette Testen der Testliste.
12 – Threads Auswahlkästchen - Bei Aktivierung wird mit (13) eingefügter Typecode automatisch getestet (wie bei Klick auf ).
13 – - Standard-Einfüge-Funktionalität. Aber besonders praktisch zusammen mit aktiviertem Auswahlkästchen unter 12. Nach Klick auf wird eingefügter Typecode automatisch getestet.
14 – Eingabefeld für Katalogname, wenn nur EIN Typecode getestet wird. Beim Testen einer ganzen Liste, muss hier nichts eingetragen werden.
Das Dialogfenster Project information enthält zusätzliche Projektinformationen.
2 – Pfad zur
Konfigurationsdatei pnoreverse.cfg
, welche alle
Reverse Typecode Regeln enthält.
3 – Name des Katalogs und des geöffneten Projekts
4 – Klassifikations-Information. Hier können Sie überprüfen, ob das geladene Projekt in PARTproject unter Projekt bearbeiten -> Registerseite Allgemein -> Menüpunkt Variablen -> Variable with Order Number und/oder Variable with Type Code klassifiziert ist.
Regex tokens
– Das Dialogfenster Edit regex tokens wird
geöffnet - Hier können Sie einzelne REGEX-Kürzel zufügen, editieren
oder löschen. Diese werden unter vartypes.cfg
gespeichert.
(Neuen zufügen) –> – Füllen Sie die Felder Type, Description und Regex tokens aus und klicken Sie auf (Anwenden).
(Bestehenden editieren) – Selektieren Sie die zu editierende Zeile, klicken Sie auf (Editieren) und bestätigen Sie abschließend mit (Anwenden).
(Bestehenden löschen) – Selektieren Sie die zu löschende Zeile und klicken Sie auf (Löschen).
Config – Hier können Sie
Schriftart und Schriftgröße für den Editor bestimmen, außerdem den
Pfad zu Notepad. Alle Änderungen werden in reverseeditor.cfg
unterhalb
$CADENAS_USER\reverseeditor\configuration
gespeichert.
Wenn der per REGEX-Regel gefundene Teilstring des Typenschlüssels nicht genau dem Variablenwert in der Sachmerkmalstabelle entspricht, dann müssen die beiden Werte aufeinander gemappt werden.
Mappings werden im Dialogfenster Variable mapping angegeben. Dieses wird geöffnet mit Klick auf den Button .
Beim einfachen Variablenmapping wird im REGEX EIN Klammerausdruck verwendet.
REGEX=(MS\d{2})L
Beispielprojekt:
thomsonlinear/linear_motion_systems/ms/ms_asmtab.prj
Es wird nach der Variablen TU im gegebenen Typcode gesucht. Die Variable TU kann die Werte MS25 oder MS33 annehmen, aber in der Sachmerkmalstabelle steht nicht nur MS25, sondern MS25 = MS25 unit. Das bedeutet, dass MS25 auf MS25 = MS25 unit (den sichtbaren Wert in der Sachmerkmalstabelle) gemappt werden muss.
Mehrfaches Variablenmapping wird ausgeführt durch mehrfache Verwendung eines Klammerausdrucks innerhalb ein und desselben REGEX.
REGEX3=.+(SAE)=(\d{1,2})-
Mehrfaches Variablenmapping kann aus zwei Gründen verwendet werden:
Näheres hierzu finden Sie in den beiden nächsten Abschnitten.
Beispielprojekt:
bimba/trd/trd_d1/cylinders/ms_parts/ms_asmtab.prj
Um korrekte Werte der Variablen PT zu finden, muss Mapping verwendet werden.
Sie sehen, dass REGEX3 und REGEX10 ähnliche Regeln für die Suche verwenden. Der einzige Unterschied ist, dass REGEX10 Typcodes mit "#" einschließen soll.
Die folgende Abbildung zeigt Mappings für REGEX3 und REGEX10. In beiden Regeln soll die erste Klammer "SAE" finden (der rote Teil), die zweite Klammer den Zahlenwert (der blaue Teil).
Mit Verwendung von Mehrfachmapping kann dasselbe Mapping für beide REGEX Regeln verwendet werden. Mit Einfachmapping würden die beiden REGEX-Regeln folgendermaßen aussehen:
REGEX3=.+(SAE=\d{1,2})- REGEX10=.+(SAE=[#]\d{1,2})-
In diesem Fall müssten dann allerdings 6 Mappings verwendet werden anstatt 3.
SAE=4=0.4375 SAE=#4=0.4375 SAE=5=0.5 SAE=#5=0.5 SAE=6=0.5625 SAE=#6=0.5625
Beispielprojekt:
bimba/trd/mh_tas/mh_parts/mh_asmtab.prj
In diesem Projekt kann die Variable RE die Werte KK1, KK2, KK3, KK4.... annehmen. Normalerweise ist dieser Wert im Typenschlüssel sichtbar, aber es gibt ein paar Spezialfälle, wo KK4 nicht im Typenschlüssel sichtbar ist. Damit dieser Typencode dennoch gefunden wird, muss das Auftreten des Wertes KK4 anhand anderer Variablen ermittelt werden. Im vorliegenden Beispiel wird nach den Werten von 4 anderen Variablen gesucht und KK4 in Abhängigkeit von den Ergebnissen dieser 4 Variablen getriggert.
Erste Variable (MP1, MP2, MS2…) ist MOUNT
Zweite Variable (325,400,500..) ist BORE
Vierte Variable (F,RE1000..) ist REE
Im vorliegenden Beispiel gilt Folgendes: Nimmt die Variable MOUNT den Wert MP1, MP2 oder MS2 an, dann ist KK4 aktiviert, aber nicht sichtbar im Typenschlüssel. Wenn es aber zusätzlich auch noch Fälle gibt wo bei MP1, MP2 und MS2 der Wert der Variablen RE NICHT KK4 ist, dann muss die Regel mit weiteren Variablen verfeinert werden.
Beispielprojekt:
bimba/trd/ss/parts/ss_ms_asmtab.prj
Das Mappen eines leeren Strings wird verwendet, wenn die Anwesenheit einer Variablen im Typencode nicht sichtbar ist, sobald spezifische Werte dieser Variablen selektiert werden.
Im vorliegenden Beispiel suchen wir nach einer Zahl neben dem Buchstaben "H". Diese Zahl ist in diesem Projekt in den meisten Fällen Wert der Variablen CLH, außer wenn keine Zahl neben dem Buchstaben "H" steht. Wenn keine Zahl neben dem Buchstaben "H" steht, dann ist der Wert der Variablen CLH 2. Das ist der Grund, warum wir einen leeren String auf die Zahl 2 mappen.