Abkürzungen

AXHLI Achsspezifisches High-Level-Interface

CFC freigraphische Funktionsplaneditor

CM Continuous Motion (Endlosdrehen)

DM Discrete Motion (Positionieren)

FB Function Block (Funktionsbaustein)

FBSD FB-State Diagram

HLI High-Level-Interface zwischen MC und PLC

MC Motion Controller

MCP Motion Control Platform

MCE Motion Control Engine

MC-FB Motion Controller Function Block

NL-Slope Nicht-Linearer Slope

PLC Programmable Logic Control

SAI Single Axis Interpolator


Begriffserklärungen

Funktionssatz: Internes Beauftragungsformat des ISG Motion-Controllers.

HLI-Bibliothek: Zugriff auf die Speicherschnittstelle zur ISG-MCE.

ISG-MCE: Damit ist der ISG NC-Kern gemeint der im Zusammenhang mit dieser Dokumentation auch als Motion Control Engine bezeichnet wird.

MC-FB: Bezeichnet die SPS-Funktionsbausteine, die zur Beauftragung des ISG-MC verwendet werden.

Motion-Bibliothek: SPS-Softwareapplikation die Funktionsbausteine zur Bewegung von Achsen entsprechend der PLCopen-Spezifikation, sowie weitere FB die Aufgaben der Bewegungserzeugung übernehmen, enthält.


Was ist die ISG Motion Control Platform ?

Die ISG-MCP ist eine SPS-Bibliothek, die je nach Kundenwunsch auch in IEC 61131-Source ausgeliefert werden kann. Sie ermöglicht dem SPS-Anwendungsprogrammierer die Programmierung von Bewegungsaufgaben nach der PLCopen-Spezifikation innerhalb einer IEC 61131 SPS. Sämtliche zur Bewegungserzeugung intern notwendige Funktionen wie z.B. Interpolation, Lageregelung, Bedienung der Antriebsschnittstellen usw. bleiben dabei dem SPS-Anwendungsprogrammierer verborgen. Die ISG-MCP stellt die in der PLCopen-Spezifikation [1] definierten Funktionsbausteine, Datenstrukturen und Zustandsmodelle zur Verfügung.

Bild 1-1: Der SPS-Anwendungsprogrammierer sieht die ISG-MCP als einzige Programmierschnittstelle.


Elemente der ISG Motion Control Platform

Die ISG Motion Control Platform umfasst verschiedene SPS Anwenderbibliotheken. Diese beinhalten FB und Datentypen nach den PLCopen-Spezifikationen und solche, die von Steuerungshersteller spezifiziert wurden. Durch den vorgestellten Präfix können diese Elemente leicht unterschieden werden. Alle mit dem Präfix MC_ gekennzeichneten Elemente sind in den verschiedenen Teilen der PLCopen-Spezifikation aufgeführt. Diejenigen Elemente mit dem Präfix MCV_sind durch den Steuerungshersteller spezifizeirt worden.

Mehr:

button HLI-Bibliothek - Speicherschnittstelle zur ISG-MCE

button Plattform-Bibliothek

button Motion-Bibliothek - PLCopen Part1

button Achsgruppen-Bibliothek - PLCopen Part4

button Globale Variablen


HLI-Bibliothek - Speicherschnittstelle zur ISG-MCE

TwinCAT CNC: Überblick

HLI-Bibliothek  Speicherschnittstelle zur ISG-MCE

Ein Bestandteil der ISG-MCP ist die Anwenderbibliothek TcCncHliV3.lib. Sie enthält die Definition der Speicherschnittstelle HLI zur ISG-MCE. Über diese Schnittstelle setzen die PLCopen-FB die Kommandos zur Bewegung ihrer zugeordneten Achse ab und erhalten Meldungen der ISG-MCE bezüglich jeder Achse.

Eine SPS-Applikation muss eine Instanz des FB MCV_HliInterface als allerersten Baustein aufrufen, der global angelegte Zeiger zum Zugriff auf die Bereiche des HLI initialisiert. Erst nach erfolgreicher Initialisierung dürfen Programme und FB aus den nachfolgend beschriebenen Anwenderbibliotheken aufgerufen werden.


Plattform-Bibliothek

In der Anwenderbibliothek TcCncBase.lib sind die Datenstrukturen definiert, die im Rahmen der PLCopen-Spezifikationen als Referenz die Objekte darstellen, durch deren Anwendung die Bewegungsaufgaben gelöst werden sollen.

Die entsprechenden Variablen der Referenzen sind als globale Variablen in dieser Bibliothek definiert.

Weiterer zentraler Bestandteil dieser Bibliothek ist der FB MCV_PlatformBase, der in jeder SPS-Applikation instanziert werden muss, die Bewegungsaufgaben auf der Basis der PLCopen-Spezifikationen löst. Dieser FB übernimmt die Aufgabe die Strukturen auf die Referenzen zu initialisieren und die Konsistenz der Schnittstelle HLI auf Seiten der MCE und der SPS zu prüfen. Erst wenn dieser FB seinen Ausgang Done auf TRUE gesetzt hat, können Bewegungsaufträge erfolgreich über die FB der nachfolgend aufgeführten Motion-Bibliothek an den MC abgesetzt werden (siehe Frame_PLCopenP1 )


Motion-Bibliothek - PLCopen Part1

TwinCAT CNC: Überblick

Motion-Bibliothek  PLCopen Part1

In der Anwenderbibliothek TcCncPlcopenP1.lib sind neben FB, die der PLCopen-Spezifikation Part 1 entsprechen, auch FB definiert, die zusätzliche Funktionalität abdecken und zur Realisierung einer Applikation eingesetzt werden müssen. Diese Bibliothek wird im weiteren Motion-Bibliothek genannt. Der Versionsumfang kann sich je nach verwendeter SPS-Plattform unterscheiden.

Das nachfolgende Bild zeigt den strukturellen Aufbau der Motion-Bibliothek. Anschließend werden die wesentlichen Elemente dieser Bibliothek näher erläutert.

Bild 1-2: Übersicht über die Motion Bibliothek TcCncPlcopenP1.lib

Mehr:

button PLCopen Funktionsbausteine

button Funktionsbaustein MCV_Axis

button Funktionsbaustein MCV_P1_PLATFORM


PLCopen Funktionsbausteine

Iin der PLCopen-Spezifikation Part 1 werden die dort definierten FB entsprechend ihrer Verwendung in administrative und bewegungsbezogene FB unterteilt. Innerhalb dieser beiden Bereiche wird eine weitere Unterscheidung bezüglich der Anwendung auf eine (single axis) oder mehrere (multiple axis) Achsen getroffen.

Die nachfolgende Tabelle ist entsprechend organisiert und zeigt die Funktionsblöcke nach PLCopen-Spezifikation Part 1.

Die kursiv gedruckten und mit einem * versehenen FB sind nicht in der Motionbibliothek Part1 implementiert. Jedoch kann es in den Bibliotheken FB geben, die eine ähnliche Funktionalität besitzen, aber durch den Steuerungshersteller spezifiziert wurden.

Administrative |  | Motion
Single Axis | Multiple Axis | Single Axis | Multiple Axis
MC_Power | MC_CamTableSelect | MC_MoveAbsolute | MC_CamIn
MC_ReadStatus |  | MC_MoveRelative | MC_CamOut
MC_ReadAxisError |  | MC_MoveAdditive | MC_GearIn
MC_ReadParameter |  | MC_MoveSuperimposed | MC_GearOut
MC_ReadBoolParameter* |  | MC_MoveVelocity | MC_Phasing
MC_WriteParameter |  | MC_Home | MC_GearInPos*
MC_WriteBoolParameter* |  | MC_Stop |
MC_ReadActualPosition |  | MC_PositionProfile* |
MC_Reset |  | MC_VelocityProfile* |
MC_TouchProbe |  | MC_AccelerationProfile* |
MC_AbortTrigger |  | MC_TorqueControl* |
MC_ReadDigitalInput* |  | MC_MoveContinuous* |
MC_ReadDigitalOutput* |  | MC_Halt |
MC_WriteDigitalOutput* |  |  |
MC_SetPosition |  |  |
MC_SetOverride |  |  |
MC_ReadActualVelocity* |  |  |
MC_ReadActualTorque* |  |  |
MC_DigitalCamSwitch* |  |  |

Tabelle 1-1: Einteilung der PLCopen-FB Part1 in administrative und bewegungsbezogene FB


Funktionsbaustein MCV_Axis

Aktualisiert werden die Daten einer Struktur AXIS_REF durch den FB MCV_Axis, der als Ein-/Ausgabevariable eine Struktur AXIS_REF besitzt. Dieser FB übernimmt zusätzlich folgende Aufgaben:

q Anmeldung einer Achse an der MCE über das HLI. Dies geschieht durch Setzen des Flags plc_present_w auf dem achsspezifischen HLI-Bereich

q Anmeldung der SPS über das HLI, damit die SPS Spindel-Reset, Reglerfreigabe, Vorschubfreigabe und Antrieb EIN für eine spezifische Achse an die MCE kommandieren kann.

q Bei der Initialisierung wird die Konsistenz des HLI verifiziert, indem die Versionskennung und die Größe des HLI überprüft wird.

q Übernahme der Fehlermeldungen, die von der MCE achsspezifisch gemeldet werden.

In jeder SPS-Applikation, die PLCopen-Part1 FB der ISG-MCP benutzt, muss für jede verwendete Achse eine Instanz dieses FB angelegt sein, und diesem eine Struktur AXIS_REF in der Form g_array_axis_ref[i] als VAR_IN_OUT-Parameter zugewiesen werden.

Um dies zu gewährleisten enthält die ISG-MCP den FB MCV_P1_PLATFORM (siehe Kap. 1.2.3.3), der in einem Programm einer SPS-Applikation aufgerufen werden muss. Damit ist gewährleistet, dass die Arbeitsdaten einer Achse in jedem SPS-Zyklus aktualisiert werden.

Bild 1- 4 : Bereitstellung der AXIS_REF über den FB MCV_Axis

Programmierbeispiel:

Deklaration in ST:

cam_in_1 : MC_CamIn;

Aufruf in ST:

cam_in_1 (Master:= g_array_axis_ref[0], Slave := g_array_axis_ref [1]);


Funktionsbaustein MCV_P1_PLATFORM

Für die MCP wurde folgende Festlegung getroffen:

· Die generischen FB MCV_Axis der PLCopen-Achsen werden in der ISG-MCP instanziert und sind im FB MCV_P1_PLATFORM implementiert.

· In jeder SPS-Applikation, die Bewegungsaufgaben unter Verwendung von FB nach den PLCopen-Spezifikationen Part 1 und 2 löst, muss zyklisch genau eine Instanz des FB MCV_P1_PLATFORM vor der Berechnung der FB zur Lösung der Bewegungsaufgabe durchgerechnet werden.

· Für die Instanzierung und den Aufruf aller PLCopen-FB, die zur Programmierung der Applikation (z.B. Bewegungsablauf) dienen, hat der Anwendungsprogrammierer in einem Applikationsprogramm zu sorgen.

· Vor dem erstmaligen Aufruf der Instanz von MCV_P1_PLATFORM müssen das HLI (Schnittstelle zum MC) initialisiert sein und die Instanz des FB MCV_PlatformBase die erfolgreiche Initialisierung der MCP melden.

Bild 1-5: SPS-Basisprogramm für Motion-Applikationen

Im Funktionsblock MCV_P1_PLATFORM wird in der Initialisierungsphase jeder Achse eine Struktur AXIS_REF zugeordnet, die als Elemente des global definierten Feldes g_array_axis_ref vorliegen.


Achsgruppen-Bibliothek - PLCopen Part4

TwinCAT CNC: Überblick

Achsgruppen-Bibliothek  PLCopen Part4

In der Anwenderbibliothek TcCncPlcopenP4.lib sind neben FB, die der PLCopen-Spezifikation Part 4 entsprechen, auch FB definiert, die zusätzliche Funktionalität abdecken und zur Realisierung einer Applikation eingesetzt werden müssen. Diese Bibliothek wird im weiteren Achsgruppen-Bibliothek genannt. Der Versionsumfang kann sich je nach verwendeter SPS-Plattform unterscheiden.

Das nachfolgende Bild zeigt den strukturellen Aufbau der Motion-Bibliothek. Anschließend werden die wesentlichen Elemente dieser Bibliothek näher erläutert.

Bild 1-7: Übersicht über die Motion Bibliothek TcCncPlcopenP4.lib

Mehr:

button Funktionsbaustein MCV_AxesGroup

button Funktionsbaustein MCV_P4_PLATFORM

button PLCopen Funktionsbausteine


Funktionsbaustein MCV_AxesGroup

Aktualisiert werden die Daten einer Struktur AXES_GROUP_REF durch den FB MCV_AxesGroup, der als Ein-/Ausgabevariable eine Struktur AXES_GROUP_REF besitzt. Dieser FB übernimmt zusätzlich folgende Aufgaben:

q Anmeldung einer Achsgruppe an der MCE über das HLI. Dies geschieht durch Setzen des Flags plc_present_w auf dem kanalspezifischen HLI-Bereich

q Bei der Initialisierung wird überprüft, ob einer Achsgruppe bereits Achsen zugeordnet sind. Ist dies der Fall werden diese Achsen der SPS internen Achsgruppenabbildung hinzugefügt, ohne dass eine MC_AddAxisToGroup beauftragt werden muss.

q Übernahme der Fehlermeldungen, die von der MCE kanalspezifisch gemeldet werden.

In jeder SPS-Applikation, die PLCopen-Part4 FB der ISG-MCP benutzt, muss für jede verwendete Achsgruppe eine Instanz dieses FB angelegt sein, und diesem eine Struktur AXES_GROUP_REF in der Form gAxesGroupRef[i] als VAR_IN_OUT-Parameter zugewiesen werden.

Um dies zu gewährleisten enthält die ISG-MCP den FB MCV_P4_PLATFORM (siehe Kapitel 1.2.4.2), der in einem Programm einer SPS-Applikation aufgerufen werden muss. Damit ist gewährleistet, dass die Arbeitsdaten einer Achse in jedem SPS-Zyklus aktualisiert werden.


Funktionsbaustein MCV_P4_PLATFORM

Für die MCP wurde folgende Festlegung getroffen:

· Die generischen FB MCV_AxesGroup der PLCopen-Achsgruppen werden in der ISG-MCP instanziert und sind im FB MCV_P4_PLATFORM implementiert.

· In jeder SPS-Applikation, die Bewegungsaufgaben unter Verwendung von FB nach den PLCopen-Spezifikationen Part 4 löst, muss zyklisch genau eine Instanz des FB MCV_P4_PLATFORM vor der Berechnung der FB zur Lösung der Bewegungsaufgabe durchrechnen.

· Für die Instanzierung und den Aufruf aller PLCopen-FB, die zur Programmierung der Applikation (z.B. Bewegungsablauf) dienen, hat der Anwendungsprogrammierer in einem Applikationsprogramm zu sorgen.

· Vor dem erstmaligen Aufruf der Instanz von MCV_P4_PLATFORM müssen das HLI (Schnittstelle zum MC) initialisiert sein und die Instanz des FB MCV_PlatformBase die erfolgreiche Initialisierung der MCP melden.

Bild 1-9: SPS-Basisprogramm für Achsgruppen-Applikationen

Im Funktionsblock MCV_P4_PLATFORM wird in der Initialisierungsphase jeder Achsgruppe eine Struktur AXES_GROUP_REF zugeordnet, die als Elemente des global definierten Feldes gAxesGroupRef vorliegen.


PLCopen Funktionsbausteine

In der PLCopen-Spezifikation Part 4 werden die dort definierten FB entsprechend ihrer Verwendung in administrative und bewegungsbezogene FB unterteilt.

Innerhalb dieser beiden Bereiche wird weiter unterschieden, ob ein FB sich nur auf die Achsgruppe bezieht (coordinated) oder ob durch den FB eine Funktionalität im Zusammenspiel mit Komponenten außerhalb der Achsgruppe beauftragt (synchronized) wird.

Die nachfolgende Tabelle ist entsprechend organisiert und zeigt die Funktionsblöcke nach PLCopen-Spezifikation Part 4.

Die kursiv gedruckten und mit einem * versehenen FB sind nicht in der Motionbibliothek Part4 implementiert. Jedoch kann es in den Bibliotheken FB geben, die eine ähnliche Funktionalität besitzen, aber durch den Steuerungshersteller spezifiziert wurden.

Administrative | Motion
Coordinated | Coordinated | Synchronized
MC_AddAxisToGroup | MC_GroupHome * | MC_SyncAxisToGroup *
MC_RemoveAxisFromGroup | MC_GroupStop | MC_SyncGroupToAxis *
MC_UngroupAllAxes | MC_GroupHalt | MC_TrackConveyorBelt *
MC_GroupReadConfiguration | MC_GroupInterrupt * | MC_TrackRotaryTable *
MC_GroupEnable * | MC_GroupContinue * |
MC_GroupDisable | MC_MoveLinearAbsolute |
MC_SetKinTransform * | MC_MoveLinearRelative |
MC_SetCartesianTransform * | MC_MoveCircularAbsolute * |
MC_SetCoordinateTransform * | MC_MoveCircularRelative * |
MC_ReadKinTransform * | MC_MoveDirectAbsolute * |
MC_ReadCartesianTransform * | MC_MoveDirectRelative * |
MC_ReadCoordinateTransform * | MC_MovePath |
MC_GroupSetPosition * |  |
MC_GroupReadActualPosition |  |
MC_GroupReadActualVelocity * |  |
MC_GroupReadActualAcceleration * |  |
MC_GroupReadStatus |  |
MC_GroupReadError |  |
MC_GroupReset |  |
MC_PathSelect |  |
MC_GroupSetOverride |  |
MC_SetDynCoordTransform * |  |

Tabelle 1-2: Einteilung der PLCopen-FB Part4 in administrative und bewegungsbezogene FB


Sicherheitskonzept, Einhaltung der EN775

Mehr:

button Grundsätzliches zum softwaretechnischen Sicherheitskonzept

button Ist-Geschwindigkeitsüberwachung

button Bidirektionale Kongruenzprüfung der HLI Speicher Schnittstelle

button Priorität des FB MC_Stop

button Geschwindigkeitsüberwachung während aktiver Drehmomentbegrenzung

button Verhindern von unbeabsichtigten MCFB-Bewegungen im T1-Mode

button Sicherheitskleingeschwindigkeit für nicht referenzierte Achsen


Grundsätzliches zum softwaretechnischen Sicherheitskonzept

Softwaretechnische Sicherheitsfunktionen im obigen Sinne sind grundsätzlich innerhalb der ISG-MCE bzw. der MCP realisiert.

Der sichere Zustand ist grundsätzlich der Default-Zustand, d.h. dieser sichere Default-Zustand kann über speziell dafür vorgesehene, sicherheitsrelevante Funktionsbausteine nur ausgeschaltet werden.

Die erforderlichen Funktionsbausteine zur Deaktivierung sind nicht Bestandteil der ISG Lieferung.

Da es sich beim HLI um eine speichergekoppelte Schnittstelle handelt, ist für die Kommunikation sicherheitsrelevanter Kommandos eine Realisierung gewählt worden, die sicherstellt, dass das einmalige Ausschalten einer sicherheitsrelevanten Funktion, das durch Setzen einer Speicherstelle beauftragt wird, nicht anstehen bleibt, falls die SPS den entsprechenden Sicherheitsfunktionsbaustein nicht mehr aufruft.


Ist-Geschwindigkeitsüberwachung

In der ISG-MCE ist eine istwertseitige Geschwindigkeitsüberwachung realisiert.

Der Grenzwert für die Geschwindigkeitsüberwachung ist für Linearachsen fest auf 250 mm/s einkompiliert.

Für Rundachsen oder Spindeln ist eine Parametrierbarkeit wegen des Bauteildurchmessers erforderlich. Deshalb wird der Grenzwert per Getriebeparameter vb_monitor (P-AXIS-00311) in der ACHS_MDS-Liste eingestellt. Ist der Parameter in der Liste nicht enthalten oder 0, so wird die Ist-Geschwindigkeit auf vb_not_referenced (P-AXIS-00268) überwacht.

q Im SAI wird die Fehlermeldung 60241 (P-ERR-60241) Programmierte Geschwindigkeit überschreitet Überwachungsgrenze ausgegeben, falls ein Fahrauftrag mit höherer Geschwindigkeit beauftragt wird.

q Die Geschwindigkeitsüberwachung ist in der ISG-MCE per Default aktiv und kann mit einem speziellen Sicherheitsfunktionsbaustein, der zyklisch aufzurufen ist, deaktiviert werden.

q Die Ist-Geschwindigkeit wird in der BF LR zyklisch im Systemtakt überwacht. Bei Überschreitung der zulässigen Ist-Geschwindigkeit wird die Fehlermeldung 70225 (P-ERR-70225) Max. Ist-Geschwindigkeit während aktiver Geschw.-Überwachung überschritten ausgegeben und die Achse durch Schließen der Bremse und Wegnahme der Reglerfreigabe gestoppt.


Bidirektionale Kongruenzprüfung der HLI Speicher Schnittstelle

Die ISG FB beauftragen die ISG-MCE über das sogenannte HLI. Da es sich um eine speichergekoppelte Schnittstelle handelt, ist eine Speicherdeckungsgleiche (=kongruente) Nachdefinition dieser Schnittstelle in der SPS die Voraussetzung für eine einwandfreie Funktion des Gesamtsystems. Deshalb ist innerhalb der MCP Bibliothek eine Kongruenzprüfung realisiert, die sicherstellt, dass die HLI-Schnittstelle nicht mit einer fehlerhaften HLI-Nachbildung betrieben wird.


Priorität des FB MC_Stop

Das HLI der ISG-MCE hat pro Achse genau eine Beauftragungs- und Quittierungsschnittstelle für MC-Aufträge. Beauftragungs- und Quittierungsschnittstelle sind jeweils als Verbrauchsdatum realisiert. Daraus ergibt sich, dass pro SPS-Zyklus maximal 1 FB-Auftrag abgesetzt werden kann. Wird innerhalb eines SPS-Zyklus ein zweiter FB angetriggert, so kann dieser nicht durchgesetzt werden. Falls der (innerhalb eines SPS-Zyklus) nachfolgende Auftrag ein MC_Stop ist, wird der bereits im Beauftragungsspeicher stehende durch diesen MC_Stop überschrieben, so dass der MC_Stop immer die höchste Priorität hat.


Geschwindigkeitsüberwachung während aktiver Drehmomentbegrenzung

TwinCAT CNC: Überblick

Geschwindigkeitsüberwachung während aktiver Drehmomentbegrenzung

Für die Ist-Geschwindigkeitsüberwachung während aktiver Drehmomentbegrenzung soll eine zusätzliche Überwachungsfunktion realisiert. Diese ist im ACHS_MDS-Parameter vb_torq_limit_max (P-AXIS-00314) parametrierbar.

q Die Ist-Geschwindigkeit während aktiver Drehmomentbegrenzung wird in der BF LR ebenfalls zyklisch überwacht. Bei Überschreitung der zulässigen Ist-Geschwindigkeit wird die Fehlermeldung Max. Ist-Geschwindigkeit während aktiver Drehmomentbegrenzung überschritten (P-ERR-70220) ausgegeben und die Achse durch Schließen der Bremse und Wegnahme der Reglerfreigabe gestoppt.


Verhindern von unbeabsichtigten MCFB-Bewegungen im T1-Mode

Einrichtbetriebsarten:

T1-Mode = Einrichtbetrieb mit reduzierter Geschwindigkeit

T2-Mode = Einrichtbetrieb ohne reduzierter Geschwindigkeit

Die ISG-MCE hat keine direkte Kenntnis über die Betriebsart der Anlage. Der SPS-Programmierer, dem diese Informationen zur Verfügung stehen, kann mit dem Sicherheitsfunktionsbaustein den sicheren Zustand (=Stillstand) verlassen. Für die Einhaltung der EN775 besteht folgende Forderung:

Im kritischen Zustand, d.h. ein Bediener befindet sich im Gefahrenbereich der Anlage und es herrscht Betriebsart T1 oder T2, dürfen Bewegungen nur aufgrund bewusster Bedienhandlungen (bei einem Roboter: Zustimmungstaste + START Taste) beauftragt werden können.

In diesem Zustand muss das Loslassen der Starttaste nur zum Feedhold, nicht aber zum Auftragsabbruch führen.

Bei einem Betriebsartwechsel von Automatik auf T1 oder T2 fallen i.d.R. ohnehin die Freigaben der Antriebe ab.

Wird die Zustimmungstaste gedrückt, dann werden PLCopen Aufträge gepuffert, die Bewegung beginnt jedoch noch nicht.

Der SPS-Programmierer kann dann das Drücken der Starttaste zur Versorgung des Sicherheitsfunktionsbausteins verwenden, um die gewohnte Funktionalität der Starttaste zu gewährleisten.


Sicherheitskleingeschwindigkeit für nicht referenzierte Achsen

Falls eine Achse noch nicht referenziert/justiert ist, bzw. den Referenzpunkt/Justage verloren hat, ist damit der Maßbezug zu einem maschinenfesten Punkt ebenfalls verloren und somit kann keine Softwareendschalter-Überwachung stattfinden.

In diesem Zustand können die Achsen deshalb nicht absolut positioniert werden. Es sind ausschließlich MC_MoveRelative und MC_MoveVelocity möglich. Diese relativen Positionierarten werden mit reduzierter Geschwindigkeit ausgeführt, die im ACHS_MDS Parameter

getriebe[0].vb_not_referenced (P-AXIS-00268)

konfiguriert werden kann.


Realisierungsdetails innerhalb der ISG-MCP

In diesem Kapitel sollen diejenigen Aspekte der ISG-MCP Realisierung diskutiert werden, bei denen das Verhalten der FB allein mit der PLCopen-Spezifikation 1.0 nicht genau vorhersagbar sind.

Gründe hierfür können sein:

q Unzureichende Festlegungen in der PLCopen-Spezifikation 1.0

q Eigenschaften der Motion Control Engine

Mehr:

button Hochlauf

button Grundsätzliches zur Arbeitsweise der PLCopen FB

button Realisierung der FB

button Interaktion der FB mit dem FBSD, Fehlerhandling

button Versionierung

button Weitere allgemeine Systemeigenschaften


Hochlauf

Beim Kaltstart des SPS-Programms werden verschiedene Initialisierungen der ISG-MCP durchlaufen.

Während dieser Initialisierungsphase befindet sich der AXSD im Zustand 0 (INIT_STATE).

Sämtliche FB der MCP verhalten sich während dieser Phase passiv, sprich sie greifen nicht schreibend auf das HLI zu. Falls ein FB einen Auftrag absetzt, bevor die Initialisierungsphase beendet ist, z.B. durch die Initialisierung eines Enable Inputs mit TRUE, meldet zeigt der FB den Fehler 16 (FB_ERR_TNA_INIT_STATE) an.


Grundsätzliches zur Arbeitsweise der PLCopen FB

Die PLCopen FB besitzen intern keine Funktionalität zur Interpolation. Vielmehr dienen Sie lediglich dazu Bewegungsaufträge an die Motion Control Engine abzusetzen und entsprechende Quittierungen entgegen zu nehmen.


Realisierung der FB

Die PLCopen FB bilden intern folgendes Zustandsdiagramm ab.

Bild 1-12: Zustände innerhalb eines FB.

Der nachfolgend aufgezeigte Zustandsautomat in IEC 61131-3 Structured Text zeigt das Gerüst für die Realisierung der Beauftragung innerhalb eines FB. Die einzelnen Aktionen sind dabei im Pseudo-Code gehalten.

(*==========================================================*)

(* Zustandsverteiler für die HLI Beauftragung *)

(*==========================================================*)

CASE fb_state OF

(*==========================================================*)

(*==========================================================*)

FB_IDLE,

FB_ERROR:(* *)

IF ( tr_execute.Q = TRUE OR retry ) THEN

(* checking of the FB's input parameters *)

(* check whether transition is allowed *)

(* try to send the MC order. *)

(* IF (sendorder = OK) THEN fb_state := FB_ACTIVE; END_IF *)

END_IF

(*==========================================================*)

(*==========================================================*)

ACTIVE:(* *)

IF ( tr_execute.Q = TRUE OR retry) THEN

(* check whether FB's ax_ref connection has changed since idle state*)

(* checking of the FB's input parameters *)

(* check whether transition is allowed *)

(* try to send send the MC order. *)

END_IF

(* collection of Acknowledge *)

(* IF (Acknowledge = OK) THEN fb_state := FB_IDLE; END_IF *)

(*==========================================================*)

(*==========================================================*)

ELSE

(*// default: Unerlaubter Zustand *)

END_CASE;

Die FB kennen keine Reset-Transition, vielmehr wird nach einem vorangegangenen FB_ERROR nach erneutem Antriggern des FB einfach versucht die neue Beauftragung durchzusetzen. Deshalb unterscheidet der Zustandsverteiler für die HLI Beauftragung nicht zwischen FB_IDLE und FB_ERROR.

Der Zustand FB_RETRY tritt nicht als expliziter Zustand im Zustandsverteiler auf sondern wird in den Zuständen FB_IDLE, FB_ERROR und FB_ACTIVE jeweils in einer Variablen gehalten für den Fall, dass der FB im entsprechenden Zustand nicht auf Anhieb eine Beauftragung durchsetzen kann.

Die eindeutige Auftragsnummer wird als globales SPS Datum gehalten und von den FB nur zum Zeitpunkt nach einer erfolgreichen Beauftragung aus den Zuständen FB_IDLE und FB_ERROR heraus inkrementiert, und in seinen Instanzdaten vermerkt.

Bei einer Beauftragung aus dem Zustand FB_ACTIVE heraus wird ein neuer Auftrag mit der selben Auftragsnummer an den MC geschickt und ein FB-interner Zähler, wie viele Aufträge einer Auftragsnummer unterwegs sind, inkrementiert.

Diese Methode erspart eine aufwändige Verwaltung der Auftragsnummern die beauftragt wurden und der zugehörigen eingegangenen Quittierungen.

Wenn ein FB angetriggert wird, überprüft er, ob der Zustandsübergang, der durch die Ausführung des FB im FBSD ausgelöst würde (konjunktiv!), im momentanen Zustand des FBSD überhaupt erlaubt ist (transition allowed). Falls dies nicht der Fall ist, wird der Auftrag gar nicht erst abgesetzt sondern der FB meldet einen Beauftragungsfehler (= Fehler auf FB Ebene). Der Achszustand ändert sich in einem solchen Fall niemals, da ja überhaupt gar kein Auftrag abgesetzt wurde. Näheres dazu finden Sie im folgenden Kapitel.


Interaktion der FB mit dem FBSD, Fehlerhandling

Die in der PLCopen Spezifikation beschriebene Zustandsmaschine FB state behaviour bezieht sich immer auf eine Achse. Deshalb macht es Sinn diesen Achszustand in den achsspezifischen Arbeitsdaten der SPS zu halten und allen FB jeweils über die AXIS_REF-Struktur zur Verfügung zu stellen. Ebenso wird der Index der korrespondierenden Ax-HLI Schnittstelle in der AXIS_REF-Struktur vermerkt.

Da der Achszustand in den achsspezifischen Arbeitsdaten der SPS gehalten wird, ist klar, dass dieser FBSD zunächst nur den Beauftragungszustand enthalten kann.

Dies wird auch durch folgende PLCopen Regel zum Ausdruck gebracht:

The axis is always in one of the defined state (see diagram below). Any motion command is a transition that changes the state of the axis

Bei der Beauftragung eines FB muss dieser anhand des aktuellen Zustands des FBSD die Zulässigkeit der Beauftragung überprüfen.

Mehr:

button Fehlerbehandlung auf FBSD Ebene

button Fehlerbehandlung auf FB Ebene

button Definierte Fehler auf FB-Ebene

button Achsfehler aus dem Motion Controller


Fehlerbehandlung auf FBSD Ebene

An dieser Stelle könnte man nun zu der Ansicht gelangen, dass der FB bei einer unzulässigen Beauftragung den FBSD in einen Fehlerzustand versetzt, weil es sich ja um einen Beauftragungszustandsautomaten handelt. Dem ist jedoch nach PLCopen Spezifikation nicht so, denn für den FBSD gilt:

Note 3: The transition Error refers to errors from the axis and axis control, and not from the Function Block instances.

These axis errors may also be reflected in the output of the Function Blocks FB instances errors.

Das bedeutet: ein Bewegungs-FB versetzt den FBSD niemals in den Zustand ERROR, sondern nur ein Fehler, der vom Motion-Controller gemeldet wird. Dazu ist es erforderlich, dass ein achsspezifischer Handler-Prozess die Fehlermeldungen vom HLI entnimmt und in den achsspezifischen Arbeitsdaten, sprich im FBSD, ablegt. Die einzelnen FB sehen den Fehlerzustand der Achse dann über ihre AXIS_REF.

Bild 1-13: Error-handler versorgt die achsspezifische FBSD Arbeitsdaten


Fehlerbehandlung auf FB Ebene

Die Fehlerausgänge der einzelnen FB beziehen sich auf Fehler, die im Rahmen der Beauftragung einer FB Instanz aufgetreten sind, nicht auf die Fehler der Achse. Deshalb versetzt eine fehlerhafte Beauftragung nur den beauftragten FB in einen Fehlerzustand. Der fehlerhafte Auftrag selbst wird vom FB gar nicht erst beauftragt, so dass die Achse (FBSD) erst gar nicht in einen Fehler gebracht wird. Andere FB Instanzen, die auf der selben Achse sitzen, merken davon also nichts.


Definierte Fehler auf FB-Ebene

Die spezifischen Fehler, die in den einzelnen FB auftreten können, sind im Dokument [3] beschrieben.


Achsfehler aus dem Motion Controller

Der Motion Controller nutzt die achsspezifischen Schnittstellen des HLI, um Meldungen über eine Achse für die SPS bereitzustellen. Die Informationen werden dabei über eine Datenstruktur des Typs HLI_ERROR_SATZ ausgetauscht.

TYPE

HLI_ERROR_SATZ :

STRUCT

error_id : UDINT; (*Fehlernummer*)

fb_zeitangabe : HLI_FB_ZEITANGABE; (*Systemzeit beim Auftreten des Fehlers*)

bf_type : WORD; (*BF-Typ*)

behebungs_klasse : WORD; (*Fehlerbehebungsklasse*)

reaktions_klasse : WORD; (*Fehlerreaktionsklasse*)

reserved : WORD;

END_STRUCT;

END_TYPE

Diesen achsspezifischen HLI-Bereich überprüfen Instanzen des FB MCV_Axis in jedem SPS-Zyklus, da diese im Programm MCV_P1_PLATFORM instanziert sind und entsprechend den Erläuterungen in Kapitel 1.2.3.3. dieses Programm als erstes in die SPS-Task eingebunden werden muss. Die MCV_Axis-Instanz entnimmt jede neu aufgetretene Meldung und überträgt diese in die AXIS_REF-Struktur der zugeordneten Achse, die ein Feld für 6 Datenstrukturen des Typs HLI_ERROR_SATZ enthält.

Ist eine Meldung als Fehler klassifiziert setzt die MCV_Axis-Instanz den aktuellen Zustand des Achszustandsdiagramm (AXSD) auf ERROR_STOP.

Fehlermeldungen sind alle diejenigen Meldungen, bei denen der Wert der Variablen behebungs_klasse > 0 ist.

Ist der Wert von behebungs_klasse = 0, ist die Meldung eine Warnung.

Der Zustand ERROR_STOP wird von den anderen PLCopen-FB-Instanzen detektiert, denen dieselbe Achse zugeordnet ist. In der Folge setzen diese ihre Ausgangsvariable Error auf TRUE und an der Ausgangsvariable ErrorID wird der Wert 1 (FB_ERR_MC_AXIS, s. [3]) angezeigt.


Versionierung

Die Versionsinformation wird entsprechend den durch das SPS-Laufzeitsystem vorgegebenen Rahmenbedingungen und der Anforderung auch ohne Entwicklungssystem oder laufende SPS-Applikation verfügbar zu sein, zum einen im Namen der SPS-Bibliotheken abgelegt und zum anderen sind Funktionsbausteine implementiert, die in der Applikation die Überprüfung der Versionsstände der einzelnen Bestandteile (SPS-Bibliotheken, HLI-Definitionen auf MC bzw. SPS-Seite) der ISG-MCP durchführen.

Mehr:

button Versionsüberprüfung durch FB


Versionsüberprüfung durch FB

Die Implementierung der Versionsüberwachung durch FB beruht auf dem Prinzip, dass jede Komponente der ISG-MCP die Version derjenigen Schnittstellen und SPS-Bibliotheken überprüft, von denen sie selbst direkt abhängt. Deshalb sind in der HLI-Bibliothek und in der Motion-Bibliothek einige FB implementiert. Diese führen die Überprüfung der Komponenten durch, oder sie liefern die Version der Bibliothek.

Generell muss sich der Anwender nicht um diese Überprüfung kümmern, da diese bereits im Hochlauf der SPS-Applikation durch die Instanzen des FB MCV_Axis durchgeführt wird. Diese MCV_Axis-Instanzen sind im Programm MCV_P1_PLATFORM instanziert, welches zyklisch aufgerufen wird.

Treten Inkonsistenzen auf, werden die anderen FB-Instanzen der Applikation darüber in Kenntnis gesetzt und diese zeigen an ihrem Ausgang Error FALSE und am Ausgang ErrorID eine spezifische Fehlerkennung [3].


Weitere allgemeine Systemeigenschaften

q Endschalterüberwachung (nicht wirksam bei Moduloachsen): wird eine Verfahrwegsgrenze erkannt, so wird mit den Werten der Beschleunigung im Eilgang gebremst (Grenzbeschleunigung an der Stromgrenze, siehe P-AXIS-00004 bzw. P-AXIS-00005, P-AXIS-00006), nicht mit der Standard-Beschleunigung.

q Zustand Discrete Motion (MC_MoveRelative) bricht Zustand Continuous Motion mit hoher Drehzahl ab, so dass der Bremsweg mehr als einen Modulobereich beträgt. Das zu erwartende Verhalten geht aus der PLCopen-Spezifikation nicht hervor. Die ISG-MCP verhält sich bei Modulo-Achsen wie folgt: Die Zielposition wird im Augenblick des Auftragsabbruchs vermerkt. Es wird über so viele Umdrehungen auf die Position gebremst, dass die Beschleunigungsvorgaben eingehalten werden. Bei Linearachsen wird der gesamte Bremsweg rückwärts gefahren, weil es nur eine mathematische Möglichkeit gibt, um die Zielposition zu erreichen.


Grundsätzliches

Die PLCopen-Spezifikation definiert ein gewisses Verhalten der PLCopen-FB. Die genaue Kenntnis der PLCopen-Spezifikation ist Grundvoraussetzung für eine erfolgreiche SPS-Anwendungsprogrammierung unter Verwendung der PLCopen-FB und der ISG-MCP. Des weiteren wird für die folgenden Ausführungen ein sicherer Umgang mit TwinCAT vorausgesetzt.


Wesentliches in Kürze

Mehr:

button Verhalten der Execute" und Done" Ein / Ausgänge der PLCopen-FB

button Knackpunkt: Auftragsdurchsetzung und -quittierung


Verhalten der Execute" und Done" Ein / Ausgänge der PLCopen-FB

TwinCAT CNC: Überblick

Verhalten der Execute und Done Ein / Ausgänge der PLCopen-FB

Ein PLCopen-FB wertet nur die AUF - FLANKE des Execute-Signals aus.

D.h. bevor ein FB erneut beauftragt werden kann, muss er mindestens einmal mit Execute = FALSE aufgerufen werden !

Das Done-Signal eines PLCopen-FB wird nur aufgrund der AB - FLANKE des Execute-Signals gelöscht.

D.h. wenn z.B. der Done-Ausgang eines FB auf den Execute-Eingang eines zweiten FB gelegt wird, kann sich im Zusammenhang mit einer Triggerbeauftragung folgendes Problem ergeben:

Wenn der erste FB getriggert wird und Execute wird FALSE bevor Done TRUE wird, so bleibt dieses Done am ersten FB solange stehen, bis dessen Execute eine neuerliche AB - FLANKE des Execute-Signals durchläuft. Da der zweite FB direkt mit dem ersten verbunden ist, kann auch sein Execute erst dann wieder eine Auf-Flanke detektieren, wenn der erste FB eine komplette Triggerung durchgemacht hat. Bis dahin ist er jedoch blockiert !


Knackpunkt: Auftragsdurchsetzung und -quittierung

Das HLI des ISG MC hat pro Achse genau eine Beauftragungs- und Quittierungsschnittstelle für MC-Aufträge. Beauftragungs- und Quittierungsschnittstelle sind jeweils als Verbrauchsdatum realisiert. Daraus ergibt sich, dass pro SPS-Zyklus maximal 1 FB-Auftrag abgesetzt werden kann. Wird innerhalb eines SPS-Zyklus ein zweiter FB angetriggert, so meldet dieser den FB-spezifischen Fehler: 4 (FB_ERR_MC_DID_NOT_TAKE_ORDER) weil die Beauftragungsschnittstelle durch den vorangegangenen Auftrag blockiert ist.

Deshalb gilt folgende Regel:

Es darf maximal ein PLCopen-FB Auftrag pro Achse und SPS-Zyklus abgesetzt werden.

Obwohl pro Achse und SPS-Zyklus maximal ein Auftrag durchgesetzt werden kann, können aus SPS-Sicht auch mehrere Aufträge unterwegs sein, für die auf Quittierungen gewartet wird.

Bild 2-1: Verstopfungszustand falls ein FB nicht mehr aufgerufen wird

Jede FB Instanz entnimmt nur diejenigen Quittierungen (Auftragsnummern), die sie beauftragt hat. Ein Verstopfungszustand ergibt sich falls ein FB, nachdem er eine Beauftragung abgeschickt hat, vor Erhalt seiner Quittierung nicht mehr aufgerufen wird. Dann können auch die anderen, noch aktiven, keine Quittierung mehr erhalten.

Eine solche Situation kann nur durch einen Fehler im SPS-Anwendungsprogramm oder durch ungeordnetes Herunterfahren und starten der SPS bei laufender NC eintreten.

Deshalb gilt folgende weitere wichtige Regel:

Ein PLCopen-FB muss nach einer Beauftragung solange aufgerufen werden bis er einen seiner Ausgänge Done, CommandAborted oder Error setzt.

Zur Detektierung eines solchen Problems kann im SPS-Programm eine Überwachungsfunktion eingebaut werden, die überprüft, ob ein und dieselbe Quittierung mehr als 2 SPS-Durchläufe lang auf dem HLI anliegt. Dies kann bei einem fehlerfreien SPS-Programm nicht sein.


Tipps und Tricks zur SPS-Anwendungsprogrammierung

Typischerweise erfolgt die SPS-Anwendungsprogrammierung in Schrittfolgen. Werden dabei die oben aufgeführten Beauftragungs- und Aufrufarten gemischt, kann es leicht zu einem unerwarteten Verhalten des Anwendungsprogramms kommen.

Bezüglich der Beauftragungsart PLCopen-FB kann unterschieden werden:

q Triggerbeauftragung (Execute nur ein Takt lange TRUE)

q Pegelbeauftragung (Execute liegt mindestens an bis Done = TRUE)

Der SPS-Anwendungsprogrammierer sollte sich vorab Gedanken machen welche der beiden Beauftragungsarten er verwenden möchte und sollte diese innerhalb eines Projektes beibehalten.

Bezüglich der Aufrufart PLCopen-FB kann unterschieden werden:

q Aufruf immer aller FB in jedem SPS-Zyklus

q Aufruf nur der jeweils relevanten FB pro Schritt

Auch hier sollte sich der SPS-Anwendungsprogrammierer vorab Gedanken machen welche der beiden Aufrufarten er verwenden möchte und sollte auch diese innerhalb eines Projektes beibehalten.


Tipps zur Laufzeitoptimierung

Bei größeren Applikationen mit vielen Achsen kann es notwendig werden, die Instanzen der Funktionsbausteine zeitoptimiert aufzurufen, d.h. die FB-Instanzen sollen nur dann ausgeführt werden, wenn sie auch benötigt werde.

Der folgende kurze Codeabschnitt in StructuredText soll die Technik verdeutlichen, mit der die Laufzeit einer Applikation verringert werden kann. Als Beispiel wird hier der Funktionsbaustein MC_MoveVelocity verwendet.

Mit der Variablen MC_MoveVelocity_Active wird der Funktionsbaustein gesteuert. Sie kann dabei die folgenden Werte annehmen:

Wert | Bedeutung
0 | Funktionsbaustein wird nicht ausgeführt.
1 | Funktionsbaustein wird ausgeführt, der Eingang Execute/Enable ist TRUE.
2 | Funktionbaustein wird ausgeführt, bis die entsprechend abgefragte Quittierung (z.B. Done, CommandAborted etc.) gesetzt ist. Execute/Enable ist FALSE.

Zu Beginn wird MC_MoveVelocity_Active in Abhängigkeit vom Eingang Execute/Enable auf 1 gesetzt. Damit wird der Funktionsbaustein MC_MoveVelocity ausgeführt. Solange der Eingang nicht zurück gesetzt wird, bleibt dieser Zustand erhalten.

IF ( Execute_MoveVelocity = TRUE ) AND

( MC_MoveVelocity_Active = 0 ) THEN

MC_MoveVelocity_Active := 1;

END_IF;

Erst, wenn der Eingang Execute/Enable auf FALSE gesetzt wird, ändert sich der Wert von MC_MoveVelocity_Active auf 2. Der Funktionsbaustein wird jetzt noch solange gerechnet, bis eine Quittierung am Ausgang anliegt (hier: Done oder CommandAborted). Im Fehlerfall, der hier nicht berücksichtigt ist, ist entsprechend ähnlich zu vorzugehen.

IF MC_MoveVelocity_Active > 0 THEN

MC_MoveVelocity( Axis := AxisReference,

Execute := Execute_MoveVelocity,

Velocity := Velocity_MoveVelocity,

Acceleration := Acceleration_MoveVelocity,

Deceleration := Deceleration_MoveVelocity,

Jerk := Jerk_MoveVelocity,

Direction := Direction_MoveVelocity );

AxisReference := MC_MoveVelocity_0.Axis;

InVelocity_MoveVelocity := MC_MoveVelocity_0.InVelocity;

CommandAborted_MoveVelocity := MC_MoveVelocity_0.CommandAborted;

Error_MoveVelocity := MC_MoveVelocity_0.Error;

ErrorID_MoveVelocity := MC_MoveVelocity_0.ErrorID;

IF MC_MoveVelocity_Active = 2 AND

( InVelocity_MoveVelocity = TRUEOR

CommandAborted_MoveVelocity = TRUE ) THEN

MC_MoveVelocity_Active := 0;

ELSIF Execute_MoveVelocity = FALSE THEN

MC_MoveVelocity_Active := 2;

END_IF;

END_IF;


Programmierbeispiel

Auf der Basis des SPS-Projektes Frame_PLCopenP1.pro, wird gezeigt wie eine einfache Bewegungsaufgabe gelöst wird. In dieser Rahmenapplikation werden im Programm MAIN alle Programme und Funktionsbausteine aufgerufen, die die Verbindung zum Motion Controller aufbauen und die Arbeitsdaten der SPS initialisieren.

Mehr:

button Schritt 1: Erforderliche Bibliotheken

button Schritt 2: Anlegen des Applikationprogrammes HelloWorld

button Schritt 3: Programm HelloWorld: Instanzieren der PLCopen FB

button Schritt 4: Anbinden der Achse an die PLCopen FB

button Schritt 5: Belegen der Baustein-IN/OUT-Varibalen

button Schritt 6: Programm HelloWorld in Programm MAIN einfügen

button Schritt 7: Zuordnung der Programme zu einer Task

button Schritt 8: Applikation übersetzen, Einloggen , Starten

button Schritt 9: Setzen der Freigaben für die Achse

button Schritt 10: Fertig, Achse ist verfahren!


Schritt 1: Erforderliche Bibliotheken

Zur Lösung einer Bewegungsaufgabe unter Verwendung von PLCopen-FB müssen die SPS-Bibliotheken

· STANDARD.LIB, gehört zum SPS-Laufzeitsystem

· hli_rts_lib.lib, enthält Utility-FB

· TcCncHliV3.lib, Nachbildung des Speichers zwischen SPS und MC

· TcCncBase.lib, stellt Verbindung zu MC her, Bereitstellung von Datenstrukturen und FB die in weiteren Bibliotheken verwendet werden

· TcCncPLCopenP1.lib, FB nach PLCopen Spezifikation Part 1 und 2

in der Applikation eingebunden sein. Im Beispielprogramm Frame_PLCopenP1.pro ist dies bereits der Fall.

Bild 3-17: Erforderliche Bibliotheken in Projekt eingebunden

Dieses Beispielprogramm wird geöffnet und als HelloWorld.pro gespeichert, bevor die weiteren Arbeitsschritte zur Lösung der Aufgabe durchgeführt werden.


Schritt 2: Anlegen des Applikationprogrammes HelloWorld

Die Bewegungsaufgabe wird im Programm HelloWorld implementiert. Zur Implementierung soll der freigraphische Funktionsplaneditor (CFC) verwendet werden. Entsprechend diesen Vorgaben wird das Programm im bereits vorhandenen Ordner Application angelegt:

Bild 3-18: Definition des Programms HelloWorld

Bild 3-19: Einordnung der Programme Main und HelloWorld in Projektbaum


Schritt 3: Programm HelloWorld: Instanzieren der PLCopen FB

Die nachfolgend aufgeführten Instanzen von FB werden zur Lösung der Aufgabe benötigt und im Programm HelloWorld angelegt, in dem die Bewegungsaufgabe implementiert werden soll.

PLCopen-FB | Instanzname | Bemerkungen
MC_Power | MC_Power_1 | Dient zum Setzen der Regler- und Vorschubfreigabe
MC_ReadActualPosition | MC_ReadActualPosition_1 | Zeigt die Position der Achse an der OUT-Variable Position
MC_MoveRelative | MC_MoveRelative_1 | Bewegt die Achse um den Wert der IN-Variable Distance relative zur aktuellen Position.

Tabelle 3-4: Instanzen der im Programm HelloWorld verwendeten FB

Die nachfolgende Darstellung zeigt den Variablen-Definitionsbereich in dem die erforderlichen Funktionsblöcke definiert wurden und ihre Erscheinung im Funktionsplaneditor:

Bild 3-20: Im Programm HelloWorld instanzierte PLCopen-FB


Schritt 4: Anbinden der Achse an die PLCopen FB

Jetzt wird die Achsreferenz g_array_axis_ref[0], die auf die erste Achse im System verweist, an alle PLCopen-FB angelegt.

Bild 3- 21 : Anbinden der ersten Achse im System an PLCopen-FB über g_array_axis_ref[0]


Schritt 5: Belegen der Baustein-IN/OUT-Varibalen

An die benötigten Ein-/Ausgänge der PLCopen-FB werden Variablen angeschlossen, die später im Betrieb mit Werten beschrieben werden können und so die Bewegung kommandieren. Die Initialisierungswerte können der Tabelle entnommen werden:

Variable | Datentyp | Initialisierungswert
Instanz MC_Power_1 |  |
EnablePower | BOOL | FALSE
EnablePositive | BOOL | FALSE
EnableNegative | BOOL | FALSE
Instanz MC_ReadActualPosition_1 |  |
EnableReadActPos | BOOL | TRUE
Position | REAL |
Instanz MC_MoveRelative_1 |  |
Distance | REAL | 100000.0
Velocity | REAL | 10000.0
Acceleration | REAL | 2000.0
Deceleration | REAL | 2000.0
Jerk | REAL | 2000.0
Done | BOOL |

Tabelle 3-5: Variablen zur Verbindung mit Ein-/Ausgängen der PLCopen-FB

Im Variablen-Definitionsbereich sind nun die Variablen angelegt und teilweise mit Initialwerten vorbelegt worden. Im Funktionsplaneditor erkennt man, dass die Variablen bereits an die entsprechenden Ein-/Ausgangspins der Funktionsblöcke angeschlossen wurden:

Bild 3- 22 : Ein-/Ausgabevariablen an PLCopen-FB angeschlossen


Schritt 6: Programm HelloWorld in Programm MAIN einfügen

In der Beispielapplikation Frame_PLCopenP1.pro ist bereits das Programm MAIN angelegt gewesen, das alle zur korrekten Funktion der MCE erforderlichen Funktionsbausteine und deren Aufruf beinhaltet. Damit das Programm HelloWorld ausgeführt wird, wird es nun nach dem Kommentar Insert your PLC application code after this comment eingefügt:

Bild 3-23: Einfügen von Programm HelloWorld in Programm MAIN


Schritt 7: Zuordnung der Programme zu einer Task

In der Beispielapplikation Frame_PLCopenP1.pro ist das Programm MAIN bereits einer Task zugeordnet. Die Darstellung zeigt die entsprechenden Einstellungen:

Bild 3-24: Programm MAIN ist der Task Standard zugewiesen


Schritt 8: Applikation übersetzen, Einloggen , Starten

Es erfolgt das Übersetzen und das Einloggen der Applikation. Nach dem Start der Applikation sind die Initialwerte an den Variablen bereits sichtbar:

Bild 3-25: Programm HelloWorld nach dem Starten der Applikation


Schritt 9: Setzen der Freigaben für die Achse

Zuerst wird die Regler- und Vorschubfreigabe für den Antrieb der Achse gegeben. Dies erfolgt durch Überschreiben oder Forcen der Eingangsvariablenwerte am Funktionsblock MC_Power_1.

Bild 3-26: : Setzen von Regler- und Vorschubfreigabe an MC_Power_1


Schritt 10: Fertig, Achse ist verfahren!

Die Verfahrbewegung der Achse wird ausgelöst indem der Wert der Variable StartMotion am Funktionsblock MC_MoveRelative_1 auf TRUE gesetzt wird. Die aktuelle Istposition der Achse kann nun an der Variable Position am FB MC_ReadActualPosition_1 abgelesen werden.

Die Darstellung zeigt den Zustand der Funktionsblöcke und Variablen am Ende der Bewegung. Erkenntlich ist das Ende der Bewegung, weil die Variable Done nun den Wert TRUE besitzt. Dieser Ausgang bleibt solange TRUE, bis eine fallende Flanke am Eingang Execute detektiert wird. Dies wird erreicht indem die Variable über wieder auf FALSE gesetzt wird.

Bild 3-27: Zustand am Ende der Bewegung