Übersicht: MC3-Typen

MC3-Funktionsbausteine verwenden typisierte Achsreferenzen, um die erforderlichen Fähigkeiten einer Achse festzulegen. Jeder Typ repräsentiert eine bestimmte Motion-Fähigkeit. Die Fähigkeit kann beispielsweise die Eignung als Kopplungsmaster sein oder die Möglichkeit der Achse, einen Positionssollwert entgegenzunehmen. Jedes Motion-Objekt (AXIS_REF, ENCODER_AXIS_REF) implementiert nur die Fähigkeiten, die es tatsächlich unterstützt.

Der Compiler prüft, ob das Motion-Objekt den für den Funktionsbaustein erforderlichen Typen implementiert. Ist dies nicht der Fall, lässt sich das Programm nicht kompilieren. Damit wird verhindert, dass Operationen für Motion-Objekte aufgerufen werden, die diese nicht unterstützen. Am Funktionsbaustein werden nur Fähigkeiten abgefragt und nicht das Motion-Objekt selbst. Der Compiler prüft, ob das Motion-Objekt diese Fähigkeit implementiert.

Die Grafik skizziert die Abhängigkeiten und Ursprünge der Typen (Type_*) und Motion-Objekte (AXIS_REF, ENCODER_AXIS_REF). In der Mitte sind die entscheidenden Ebenen zu erkennen:

• Typen: Type_Master1D usw., die definieren, was ein Motion-Objekt kann.
• Motion-Objekte: AXIS_REF und ENCODER_AXIS_REF, die im PLC-Programm deklariert werden.

Die MC3-Funktionsbausteine verwenden die spezialisierten Motion-Objekte oder die Typen direkt.

Verwendung

Die Funktionsbausteine der Tc3_Mc3Base, Tc3_Mc3Ptp, Tc3_Mc3Camming und Tc3_Mc3FluidPower setzten eine Parametrierung mit spezialisierten Typen (Type_*) oder allgemeinere Motion-Objekte (AXIS_REF) voraus. Der oberen Grafik ist zu entnehmen, dass die allgemeineren Motion-Objekte ausgewählte Typen implementieren.

Die Benutzung der Typen an z. B. Kopplungsbausteinen ermöglicht die Wiederverwendung der Funktionsbausteine mit verschiedenen Motion-Objekten. Bei einem Funktionsbaustein-Eingang des Typen Type_Camming1D ist ersichtlich, dass dieser Parameter ein Objekt erfordert, das als Slave-Objekt für Kurvenscheiben fungieren kann. Eine fehlerhafte Verwendung von Motion-Objekten fällt bereits während der Kompilierung und nicht erst zur Laufzeit des Anwenderprogramms auf.

Die Tabelle zeigt eine Auswahl an Funktionsbausteinen und die verwendeten Motion-Objekte oder Typen.

Beispiel

Deklaration:

VAR
    myAxis1        : AXIS_REF;
    myAxis2        : AXIS_REF;
    myEncoder      : ENCODER_AXIS_REF;
    myGearIn       : MC_GearIn;
    myTypeInstance : Type_Master1D;
END_VAR

Implementierung:

// valid call
myGearIn(
    Master:= myAxis1,
    Slave:= myAxis2,
    Execute:= TRUE);

// valid call
myGearIn(
    Master:= myEncoder,
    Slave:= myAxis2,
    Execute:= TRUE);

myGearIn(
    Master:= myAxis1,
    Slave:= myEncoder, // Compiler error
    Execute:= TRUE);

myGearIn(
    Master:= myTypeInstance, // FB runtime error 16#8145
    Slave:= myAxis2,
    Execute:= TRUE);

Das Kommando MC_GearIn erwartet am Eingang Slave ein Objekt vom Typ AXIS_REF. Somit ist es nicht möglich, eine Encoder-Achse vom Typ ENCODER_AXIS_REF zu verwenden, dies führt zu einem Compilerfehler. Gleiches gilt z. B. für das Kommando MC_CamIn, da ENCODER_AXIS_REF nicht den Typ Type_Camming1D anbietet.

MC3-Typen enthalten keinen Implementierungscode. Sie werden im Solution Explorer nicht für eine Verknüpfung zwischen einer MC3-Achse und einer Instanz in der PLC angeboten. Im letzten Beispiel ist eine Instanz des Typen Type_Master1D dem Eingang Master zugewiesen. Dies führt nicht zu einem Compilerfehler, da der Typ grundsätzlich der richtige ist. Die Logik des Funktionsbaustein erkennt aber eine fehlende Verknüpfung zu einer Achse und quittiert dies mit dem Fehler 16#8145.

Migration NC2 zu MC3