Arbeitsplanskripte für Auswahl des Nachfolgeschritts
Das System unterstützt Skripte für die Auswahl des Nachfolgeschritts im Arbeitsplan.
An bestimmten Stellen im Arbeitsplan kann auf auftretende Fehler mit mehreren Nachfolgeschritten reagiert werden. Dieser Prozess kann je nach Installation variieren und in ein und demselben Arbeitsplan unterschiedlich ablaufen. Das System bietet diese Flexibilität durch eine benutzerdefinierte Skriptlogik. Nachdem ein Arbeitsschritt an einem Vorgang abgeschlossen ist, entscheidet die benutzerdefinierte Logik bei mehreren möglichen Nachfolgeschritten, an welchen Schritt die Produktionssteuerungsnummer (PSN) gesendet wird.
Hat ein Arbeitsschritt mehrere Nachfolgeschritte, gehen von dem Arbeitsschritt mehrere Verbindungslinien aus. Jeder Verbindungslinie kann ein Entscheidungsskript zugeordnet sein. Diese Skripte werden ausgewertet, wenn eine PSN den Schritt durchlaufen hat. Die Rückgabewerte aus all diesen Arbeitsschritten werden verwendet, um den Nachfolgeschritt für die PSNs zu bestimmen.
Jedes Skript ist mit den Pfaden zwischen den Arbeitsschritten verknüpft. Um in der Aktivität Arbeitspläne pflegen
das Skriptdialogfenster anzuzeigen, zeigen Sie die Registerkarte Arbeitsplan
an und doppelklicken Sie auf die Linie, die den Pfad zum Nachfolgeschritt darstellt.
Beispiel
In der folgenden Abbildung ist ein Arbeitsplan abgebildet, der eine Nacharbeitslogik enthält:
In obigem Beispiel enthält der Arbeitsplan eine einfache Logik zur Bestimmung des Schritts, der auf den Testvorgang (TEST
) folgt. Am Ende des Testvorgangs (TEST
) gibt es für die PSN vier Möglichkeiten.
Dies setzt voraus, dass der Konstrukteur für die möglichen Nachfolgeschritte folgendes Skript eingefügt hat:
Der Übergang vom Testvorgang zur Verschrottung (
TEST-to-SCRAP
) erfolgt, wenn die PSN den Test nicht besteht und zu viele Nachtests durchgeführt wurden (3-mal). Deshalb sollte für die Bestimmung des Nachfolgeschritts zwischen dem Testschritt (TEST
) und dem Verschrottungsschritt (SCRAP
) folgender Code eingefügt werden:if (NC_CODE!=null && LOOP_COUNT>=3) exit(true);Der Übergang vom Testvorgang zum PMR-Arbeitsplan (
TEST-to-PMR_ROUTER
) wird definiert für den Fall, dass die PSN den Test nicht besteht, die Schleifenanzahl jedoch kleiner ist als 3 (siehe Beispielcode):if (NC_CODE!=null && LOOP_COUNT<3) exit(true);Der Übergang vom Testvorgang zum Montagevorgang (
TEST-to-PMR_ASSEMBLE
) wird für den Sonderfall definiert, dass der Ausfall (die Abweichung) auf eine fehlende Komponente (MISSING_COMPONENT
) zurückzuführen ist und die PSN direkt an den Montagevorgang (ASSEMBLE
) zurückgesendet wird. Die Skriptlogik hierfür ist wie folgt:if (NC_CODE =="MISSING_COMPONENT") exit(true);Der Übergang vom Testvorgang zum Montagevorgang (
TEST-to-PMR_ASSEMBLE
) wird in diesem Beispielcode ohne Skript definiert Treten keine der oben beschriebenen Ausnahmen auf, darf die PSN zum Versandvorgang (SHIP
) übergehen.
Zusätzliche Bespiele für die Auswahl von Folgeschritten:
Einfache Schleife - Testen/Fehlersuche
In der folgenden Abbildung ist ein einfacher Arbeitsplan dargestellt, der mit einem Testvorgang (TEST
) beginnt und an den sich entweder der Versandschritt (SHIP
) oder der Fehlersucheschritt (DEBUG
) anschließt:
Beachten Sie, dass bei einem Nachtest auf den Fehlersucheschritt (DEBUG
) immer der Testschritt (TEST
) folgt.
In der folgenden Tabelle ist die Skriptlogik beschrieben, die mit dem Testschritt (TEST
) verknüpft ist:
Von-Schritt/Zu-Schritt | Skript |
|---|---|
Von |
|
|
|
Mit den anderen Nachfolgeschritten sind keine Skripte verknüpft. Im Zusammenhang mit diesem Arbeitsplan sind folgende zwei Szenarios möglich:
Die Produktionssteuerungsnummer (PSN) besteht den Testschritt (
TEST
) und wird an den Versandschritt (SHIP
) gesendet.Die PSN besteht den Testschritt (
TEST
) nicht und wird an den Fehlersucheschritt (DEBUG
) gesendet. Die PSN wird am Fehlersucheschritt (DEBUG
) repariert, indem ein Reparaturabweichungscode hinzugefügt wird. Die PSN wird anschließend zurück an den Testschritt (TEST
) gesendet. Sie besteht den Testschritt (TEST
) und wird an den Versandschritt (SHIP
) gesendet.
Fehlerabhängiger Arbeitsplan
In der folgenden Abbildung ist ein Arbeitsplan dargestellt, der die fehlerhafte PSN an zwei unterschiedliche Einbaupositionen sendet, je nach Abweichungscode (NC_CODE
):
Beachten Sie, dass dasselbe auf die Ausfall-ID zutreffen kann, die mit dem Abweichungscode (NC_CODE
) verknüpft ist.
In der folgenden Tabelle ist die Skriptlogik beschrieben, die mit dem Testschritt (TEST
) verknüpft ist:
Von-Schritt/Zu-Schritt | Skript |
|---|---|
Von |
|
|
|
|
|
Mit den anderen Nachfolgeschritten sind keine Skripte verknüpft. Im Zusammenhang mit diesem Arbeitsplan sind folgende Szenarios möglich:
Die Produktionssteuerungsnummer (PSN) besteht den Testschritt (
TEST
) und wird an den Versandschritt (SHIP
) gesendet.Die PSN besteht den Testschritt (
TEST
) nicht, weil Komponenten fehlen (AbweichungscodeMISSING_COMP
), und wird an den Montageschritt (ASSEMBLE
) gesendet. Der Montagefehler an der PSN wird am Montageschritt (ASSEMBLE
) behoben. Die PSN wird anschließend zurück an den Testschritt (TEST
) gesendet. Sie besteht den Testschritt (TEST
) und wird an den Versandschritt (SHIP
) gesendet.Die PSN besteht den Testschritt (
TEST
) nicht und wird an den Fehlersucheschritt (DEBUG
) gesendet. Die PSN wird am Fehlersucheschritt (DEBUG
) repariert, indem ein Reparaturabweichungscode hinzugefügt wird. Die PSN wird anschließend zurück an den Testschritt (TEST
) gesendet. Sie besteht den Testschritt (TEST
) und wird an den Versandschritt (SHIP
) gesendet.
Verwendung benutzerdefinierter Datenfelder
Dieser Arbeitsplan verwendet das benutzerdefinierte Feld, das mit dem Material der PSN verknüpft ist, um zu bestimmen, wohin die PSN bei nicht bestandenem Test zu senden ist.
Im Folgenden ist die Skriptlogik dargestellt, die mit dem nachfolgenden Testschritt (TEST
) verknüpft ist:
Von-Schritt/Zu-Schritt | Skript |
|---|---|
Von |
|
|
// Hole benutzerdefinierte Eigenschaft COST
// Setze Kosten auf 100 €
// Ist der Materialwert geringer als 500 €, gehe zu DEBUG
|
|
// Hole benutzerdefinierte Eigenschaft COST
// Setze Kosten auf 100 €
// Ist der Materialwert geringer als 500 €, gehe zum Material Review Board (MRB)
|
Die zwei längeren Skripte für den Fehlerfall zeigen, wie die Daten für die Objekte im System abzurufen sind, einschließlich der kundendefinierten Datenfelder.
Das Skript für TEST
bis MRB
ist unten beschrieben:
Ist kein Fehler vorhanden, sollte die PSN nicht dem Pfad vom Testschritt (
TEST
) zum Arbeitsschritt für die Materialprüfung (MRB) folgen:if (NC_CODE==null) exit(false);Diese Anweisung holt die benutzerdefinierte Kosten-Eigenschaft (
COST
) für das Material mit der MethodegetCustomItemProperty()
:cost=getCustomItemProperty("COST");Die nächste Anweisung legt einen Vorschlagswert für die Materialkosten fest, falls die Kosten-Eigenschaft (
COST
) nicht definiert ist:if (cost==null) cost =100;Die letzte Anweisung enthält die Logik, um zu bestimmen, ob die PSN an den Arbeitsschritt für die Materialprüfung (MRB) zu senden ist:
if (cost>=500) exit(true); else exit (false);
Die Skriptgröße ist nicht eingeschränkt, doch längere Skripte benötigen für die Ausführung mehr Zeit.