Allgemeine Regeln für MC-Funktionsbausteine

Ausschließlichkeit der Ausgänge

Die Ausgänge Busy, Done, Error und CommandAborted schließen sich gegenseitig aus, es kann also an einem Funktionsbaustein nur einer dieser Ausgänge zu einer Zeit TRUE sein. Sobald der Eingang Execute TRUE wird, muss einer der Ausgänge TRUE werden. Ebenfalls kann nur einer der Ausgänge Active, Error, Done und CommandAborted zu einer Zeit TRUE sein.

Eine Ausnahme von dieser Regel ist MC_Stop. MC_Stop setzt Done=TRUE sobald die Achse gestoppt ist. Dennoch bleiben Busy und Active TRUE, da die Achse verriegelt wird. Erst nachdem Execute=FALSE gesetzt wird, wird die Achse entriegelt und Busy sowie Active auf FALSE gesetzt.

Ausgangs-Zustand

Die Ausgänge Done, InGear, InSync, InVelocity, Error, ErrorID und CommandAborted werden mit einer fallenden Flanke am Eingang Execute zurückgesetzt, wenn der Funktionsbaustein nicht aktiv ist (Busy=FALSE). Allerdings beeinflusst eine fallende Flanke an Execute die Kommandoausführung nicht. Falls Execute bereits während der Kommandoausführung zurückgesetzt wird, so ist sichergestellt, dass einer der Ausgänge am Ende des Kommandos für einen SPS-Zyklus gesetzt wird. Erst danach werden die Ausgänge zurückgesetzt.

Falls Execute während der Ausführung eines Kommandos mehrfach getriggert wird, so gibt der Funktionsbaustein keinerlei Rückmeldung, führt aber auch kein weiteres Kommando aus.

Eingangs-Parameter

Die Eingangs-Parameter werden mit steigender Flanke an Execute übernommen. Um die Parameter zu ändern, muss das Kommando neu getriggert werden nachdem es beendet wurde oder es muss während der Kommandoausführung eine zweite Instanz des Funktionsbausteins mit neuen Parametern getriggert werden.

Falls ein Eingangs-Parameter nicht an den Funktionsbaustein übergeben wird, so bleibt der zuletzt an diesen Baustein übergebene Wert gültig. Beim ersten Aufruf ist ein sinnvoller Default-Wert gültig.

Position und Distanz

Der Eingang Position bezeichnet einen definierten Wert innerhalb eines Koordinatensystems. Distance ist dagegen ein relatives Maß, also der Abstand zweier Positionen. Sowohl Position, als auch Distance werden in technischen Einheiten, z. B. [mm] oder [°], entsprechend der Skalierung der Achse angegeben.

Dynamik-Parameter

Die Dynamikparameter für Move-Funktionen werden in technischen Einheiten mit der Zeitbasis Sekunde angegeben. Ist eine Achse beispielsweise in Millimetern skaliert, so sind die Einheiten für Velocity [mm/s], Acceleration [mm/s²], Deceleration [mm/s²] und Jerk [mm/s³].

Fehlerbehandlung

Alle Funktionsbausteine haben zwei Fehlerausgänge um Fehler während der Kommandoausführung anzuzeigen. Error zeigt den Fehler an und ErrorID gibt eine ergänzende Fehlernummer aus. Die Ausgänge Done, InVelocity, InGear und InSync bezeichnen eine erfolgreiche Kommandoausführung und werden nicht gesetzt, wenn Error TRUE wird.

Am Ausgang der Funktionsbausteine werden Fehler unterschiedlichen Typs signalisiert. Der Fehlertyp wird nicht explizit angegeben, sondern hängt von der Fehlernummer ab, die systemweit eindeutig vergeben ist.

Fehlertypen

• Funktionsbausteinfehler sind Fehler, die ausschließlich den Funktionsbaustein und nicht die Achse betreffen (z. B. fehlerhafte Parametrierung). Funktionsbausteinfehler müssen nicht explizit zurückgesetzt werden, sondern werden selbständig zurückgesetzt, wenn der Eingang Execute zurückgesetzt wird.
• Kommunikationsfehler (der Funktionsbaustein kann die Achse z. B. nicht adressieren). Kommunikationsfehler deuten oft auf eine fehlerhafte Konfiguration oder Parametrierung hin. Ein Reset ist nicht möglich, sondern der Funktionsbaustein kann neu getriggert werden, nachdem die Konfiguration korrigiert wurde.
• Achsfehler (logische NC-Achse) treten üblicherweise während der Fahrt auf (z. B. Schleppabstandsfehler) und führen dazu, dass die Achse in den Fehlerzustand geht. Ein Achsfehler muss durch MC_Reset zurückgesetzt werden.
• Antriebsfehler (Regelgerät) ziehen evtl. einen Achsfehler, also ein Fehler der logischen NC-Achse, nach sich. In vielen Fällen können Achsfehler und Antriebsfehler gemeinsam durch MC_Reset zurückgesetzt werden. Abhängig vom Antriebsregler kann aber auch ein separater Reset-Mechanismus notwendig sein (z. B. Schalten einer Reset-Leitung zum Regelgerät).

Verhalten des Done Ausgangs

Der Done Ausgang (oder auch alternativ InVelocity, InGear, InSync etc.) wird gesetzt, wenn ein Kommando erfolgreich ausgeführt wurde. Wenn mit mehreren Funktionsbausteinen an einer Achse gearbeitet wird und das laufende Kommando durch einen weiteren Baustein unterbrochen wird, so wird der Done Ausgang des ersten Bausteins nicht gesetzt.

Verhalten des CommandAborted Ausgangs

CommandAborted wird gesetzt, wenn ein Kommando durch einen anderen Baustein unterbrochen wird.

Verhalten des Busy Ausgangs

Der Busy Ausgang zeigt an, dass der Funktionsbaustein aktiv ist. Der Baustein kann nur dann mit einer steigenden Flanke an Execute getriggert werden, wenn Busy FALSE ist. Busy wird sofort mit der steigenden Flanke an Execute gesetzt und wird erst zurückgesetzt, wenn das Kommando erfolgreich oder auch nicht erfolgreich beendet wurde. Solange Busy TRUE ist, muss der Funktionsbaustein zyklisch aufgerufen werden um das Kommando ausführen zu können.

Verhalten des Active Ausgangs

Wenn die Bewegung einer Achse durch mehrere Funktionsbausteine gesteuert wird, so zeigt der Active Ausgang jedes Bausteins an, dass das Kommando durch die Achse ausgeführt wird. Der Zustand Busy=TRUE und Active=FALSE bedeutet, dass das Kommando noch nicht oder nicht mehr ausgeführt wird.

Enable Eingang und Valid Ausgang

Im Gegensatz zu Execute führt der Enable Eingang dazu dass eine Aktion permanent und wiederholt ausgeführt wird, solange Enable TRUE ist. MC_ReadStatus aktualisiert beispielsweise zyklisch den Zustand einer Achse solange Enable TRUE ist. Ein Funktionsbaustein mit einem Enable Eingang zeigt durch den Valid Ausgang an, dass die an den Ausgängen angezeigten Daten gültig sind. Die Daten können jedoch ständig aktualisiert werden während Valid TRUE ist.

BufferMode

Einige Funktionsbausteine haben einen Eingang BufferMode, über den der Kommandofluss mit mehreren Funktionsbausteinen geregelt wird. Der BufferMode kann beispielsweise festlegen, dass ein Kommando ein anderes unterbricht (ungepufferter Betrieb) oder aber dass das nachfolgende Kommando erst im Anschluss an das vorherige Kommando ausgeführt wird (gepufferter Betrieb). Im gepufferten Betrieb kann über den BufferMode ebenfalls festgelegt werden, wie die Bewegung am Übergang von einem Kommando zum nächsten aussehen soll. Man spricht hier von einem Blending, das die Geschwindigkeit am Übergangspunkt festlegt.

Um den BufferMode zu verwenden, ist immer ein zweiter Funktionsbaustein nötigt. Es ist nicht möglich, einen Move-Baustein mit neuen Parametern zu triggern, während er noch aktiv ist.

Im ungepufferten Betrieb führt ein nachfolgendes Kommando zu einem Abbruch eines laufenden Kommandos. Das vorherige Kommando setzt dann den CommandAborted Ausgang. Im gepufferten Betrieb wartet ein nachfolgendes Kommando, bis ein laufendes Kommando beendet wurde. Hier ist zu beachten, dass eine Endlosbewegung (MC_MoveVelocity) kein gepuffertes Folgekommando zulässt. Gepufferte Kommandos führen immer sofort zum Abbruch einer Endlosbewegung wie im ungepufferten Betrieb.

Es wird nur ein Kommando gepuffert, während ein anderes ausgeführt wird. Wird mehr als ein Kommando während eines laufenden Kommandos getriggert, so wird das zuletzt gestartete und zu puffernde Kommando mit einem Fehler abgewiesen (Fehler 0x4292 Buffer Full). Falls jedoch das letzte Kommando ungepuffert gestartet wird (Aborting), so wird es in jedem Fall aktiv und unterbricht das laufende und ein bereits gepuffertes Kommando.

BufferModes

• Aborting : Default-Modus ohne Pufferung. Das Kommando wird sofort ausgeführt und unterbricht gegebenenfalls ein laufendes Kommando.
• Buffered : Das Kommando wird ausgeführt, sobald die Achse kein anderes Kommando mehr ausführt. Die vorherige Bewegung wird bis zum Stopp ausgeführt und das nachfolgende Kommando wir aus dem Stillstand gestartet.
• BlendingLow : Das Kommando wird ausgeführt, sobald die Achse kein anderes Kommando mehr ausführt. Im Gegensatz zu Buffered stoppt die Achse an der vorherigen Zielposition nicht, sondern durchläuft diese Position mit der niedrigeren Geschwindigkeit zweier Kommandos.
• BlendingHigh Das Kommando wird ausgeführt, sobald die Achse kein anderes Kommando mehr ausführt. Im Gegensatz zu Buffered stoppt die Achse an der vorherigen Zielposition nicht, sondern durchläuft diese Position mit der höheren Geschwindigkeit zweier Kommandos.
• BlendingNext : Das Kommando wird ausgeführt, sobald die Achse kein anderes Kommando mehr ausführt. Im Gegensatz zu Buffered stoppt die Achse an der vorherigen Zielposition nicht, sondern durchläuft diese Position mit der Geschwindigkeit des zuletzt beauftragten Kommandos.
• BlendingPrevious: Das Kommando wird ausgeführt, sobald die Achse kein anderes Kommando mehr ausführt. Im Gegensatz zu Buffered stoppt die Achse an der vorherigen Zielposition nicht, sondern durchläuft diese Position mit der Geschwindigkeit des zuerst beauftragten Kommandos.

Grafische Darstellung der BufferModes

Optionale Blending-Position

Das Blending bei den verschiedenen Buffer-Modes wird jeweils an der Zielposition des gerade laufenden Kommandos durchgeführt. Im Falle des MoveVelocity ist keine Zielposition definiert und in anderen Fällen kann es sinnvoll sein, die Blending-Position zu ändern. Dazu kann über den Options-Eingang des Funktionsbausteins (siehe unten) eine BlendingPosition festgelegt werden, die dann für das neue Kommando verwendet wird. Die optionale BlendingPosition muss vor der Zielposition des vorherigen Kommandos liegen, anderenfalls wird das neue Kommando mit einer Fehlermeldung abgewiesen (0x4296). Wenn die optionale BlendingPosition bereits überfahren worden ist, so wird das neue Kommando instantan umgesetzt, verhält sich also wie ein Aborting-Kommando.

Options Eingang

Viele Funktionsbausteine haben einen Options Eingang der in einer Datenstruktur zusätzliche, selten benötigte Optionen enthält. Um die Grundfunktion des Funktionsbausteins auszuführen, werden die Optionen oft nicht benötigt, sodass der Eingang offen bleiben kann. Nur wenn in der Dokumentation ausdrücklich auf bestimmte Optionen hingewiesen wird, muss die Options Datenstruktur vom Anwender belegt werden.

Slave-Achsen

Bewegungskommandos können auf gekoppelte Slave-Achsen angewendet werden, wenn diese Option in den Parametern der Achse explizit aktiviert worden ist. Ein Bewegungskommando wie MC_MoveAbsolute führt dann automatisch zum Abkoppeln der Achse und das Kommando wird anschließend ausgeführt. In diesem Fall ist ausschließlich der Buffer-ModeAborting möglich.