Beispiel: Initialisieren, Programm laden und starten

In diesem Artikel ist ein Beispiel (Programmiert im TIA Portal 16, Programmiersprache KOP) beschrieben, in dem HORST automatisiert von der SPS initialisiert wird. Daraufhin wird ein beliebiges, auf dem Schaltschrank gespeichertes Programm gestartet

1. Programmaufbau

Die detaillierte Beschreibung der horstControl Profinetschnittstelle (Registerbelegung, etc.) ist in Profinet Kommunikation beschrieben.

Das Programm ist in zwei Funktionsbausteine (FB) aufgeteilt. Jedem FB ist ein Datenbaustein (DB3 bzw. DB4) zugeordnet, in dem die lokalen Variablen zur Steuerung innerhalb der Netzwerke des FB definiert sind.

FB2 "Initialize_Axes" steuert die automatisierte Initialisierung aller Achsen von der SPS aus. Der zweite FB "Program_load_and_start" wird ausgef�hrt, sobald die Initialisierung abgeschlossen ist. Daf�r wird die Ausgangsvariable "#done" des FB "Initialize_Axes" als Startvariable f�r den FB "Program_load_and_start" gesetzt. Im FB "Program_load_and_start" wird das auf dem Schaltschrank des Roboters gespeicherte Programm mit dem entsprechenden Namen geladen und ausgef�hrt. Der modulare Aufbau des Gesamtprogramms in zwei einzelne Funktionsbausteine erm�glicht es, jeden FB durch Anpassung der In- und Outputs in andere Programmabl�ufe zu implementieren. 

1.1. Funktionsbaustein "Initialize_Axes"

F�r die SPS gesteuerte Initialisierung sind prinzipiell zwei M�glichkeiten implementiert.

Bei der ersten Variante wird f�r die Initialisierung eine Zeit �bergeben, innerhalb der alle Achsen automatisch initialisiert werden. Genaueres dazu unter Profinet Input Daten. Nachteil bei dieser Variante ist, dass der Roboter eine undefinierte Bewegung durchf�hrt, was zu Kollisionen mit St�rkonturen f�hren kann.

In der zweiten Variante wird f�r jede Achse ein definierter Winkel f�r die Initialisierung vorgegeben. Vorteil dieser Variante ist, dass der Roboter in eine definierte Position initialisiert werden kann, wenn die Grundstellung (aus der heraus initialisiert wird) bekannt ist. Um das sicherzustellen, sollte der Roboter am Ende jedes Programms in eine definierte Grundstellung gefahren werden. Diese Position kann vor der n�chsten Initialisierung abgefragt werden. Hierbei ist zu beachten, dass f�r die sichere Initialisierung ein minimaler Initialisierungswinkel nicht unterschritten werden sollte und die Initialisierungswinkel toleranzbehaftet sind. Genaueres dazu ist hier zu finden: Profinet Input Daten  (Initialization).

In diesem Beispiel werden alle Achsen �ber einen definierten Winkel initialisiert. Der Winkel wird �ber den Input "angle_to_Initialize" �bergeben. Gestartet wird der FB durch setzen der lokalen, booleschen Eingangsvariable "start", die hier durch ein Merkerbit gesteuert wird.

Als Ausgangsvariablen sind "done" und "busy" definiert. Ist der Parameter "busy" gesetzt (=true) wird die Initialisierung gerade ausgef�hrt. Sobald "done" gesetzt ist, ist die Initialisierung abgeschlossen. Dieser Ausgang kann zur Steuerung eines beliebigen weitern FB genutzt werden, der nach der Initialisierung ausgef�hrt werden soll.

Der interne Funktionsablauf ist in 6 Netzwerke aufgeteilt:

Netzwerk1 :

In diesem Netzwerk wird, nach Beendigung der Initialisierung (Netzwerk 7) das Statusbit #done gesetzt und direkt wieder zur�ckgesetzt.

Netzwerk 2:

Beim starten des FB werden (positive  Flanke #start) werden alle internen und externen Variablen auf die default-Werte r�ckgesetzt und die Statusbits #busy und #start_detected gesetzt.

Netzwerk 3 & 4:

In diesen Netzwerken werden PopUp's erkannt und quittiert. Jedes Popup kann, durch setzten des entsprechenden Bits mit verschiedenen Optionen quittiert werden. Die zugeordneten PopUp-ID's und welche Optionen f�r welches PopUp verf�gbar sind, kann hier eingesehen werden: Dokumentation Pop-up-Fenster.

Bei erstmaligen Einschalten des Roboters (ohne Wechsel der Betriebsart), wird immer folgendes Popup mit der ID404 aktiv:

Diesem PopUp ist die ID 404 zugeordnet. In Netzwerk 3 wird �ber Abfragen des Bits"HORST_IN".Pop_up die Popup-ID erkannt und durch setzten von "HORST_OUT".Pop_Up_Confirmation.Option_1 mit "Ja" best�tigt.

Als n�chstes wird folgendes Popup mit der ID350 angezeigt:

Dieses Popup wird in Netzwerk 4, wie im Schaltplan zu sehen, ebenfalls mit Option_1 (OK) quittiert. Vorher wird noch �ber den Schalter  "PopUp-ID>7" abgefragt, ob alle PopUpConfirmation-Befehel aus dem vorherigen Netzwerk zur�ckgesetzt wurden (die PopUp-ID's 1-7 geben an, welches PopUpConfirmation-Bit gerade gesetzt ist, siehe Profinet Input Daten).

 

Netzwerk 5:

Hier wird abgefragt, ob alle PopUp's quittiert wurden und der Roboter bereit f�r die Initialisierung ist.

 

Netzwerk 6:

Nachdem alle Popup's quittiert wurden (Statusbit #PopUp_done gesetzt), kann die Initialisierung gestartet werden. Daf�r wird der Initialisierungswinkel �ber einen MOVE-Block in die entsprechenden, internen Float-Register �bertragen. F�r jede Achse ist dabei ein Float-Register reserviert. Somit kann f�r jede Achse ein individueller Initialisierungswinkel �bergeben werden.

 

Netzwerk 7:

Sind die Initialisierungswinkel �bertragen, wird die Initialisierung durch setzten der entsprechenden internen Bits gestartet. Hier werden alle Achsen nacheinander initialisiert. Zuvor wir noch abgefragt (Initialization_Call_Interface_Enabled), ob horstFX bereit f�r den Start der Initialisierung ist (Bremsen ge�ffnet, Interface geladen, etc.).

Ist die letzte Achse (hier Achse 6) Initialisiert, werden die Statusbits #start_detected und #busy r�ckgesetzt und #done gesetzt.

Die Initialisierung ist nun abgeschlossen und der zweite FB "Program_load_and_start" wird gestartet.

1.2. Funktionsbaustein "Program_load_and_start"

Als Input wird dem FB der Programmname als String �bergeben (lokale Eingangsvariable #program_name). Das Programm mit dem entsprechenden Namen muss lokal auf dem Schaltschrank unter ""/home/fruitcore/fruitcore/save/" abgelegt sein. Als Ausgangsvariablen sind "is_runnning" und "done" definiert. "is_running" zeigt an, ob das geladene Programm gerade ausgef�hrt wird; "done" zeigt das Beenden des geladenen Programms.

Der interne Funktionsablauf ist in 5 Netzwerke aufgeteilt:

Netzwerk 1:

In diesem Netzwerk wird das setzten der Inputvariable #start detektiert, und die lokale Variable zum Start des Programmablaufs #start_detected gesetzt.

Netzwerk 2:

Nachdem #start_detected gesetzt ist, wird �ber einer vordefinierten Funktionsblock die �bergebene Zeichenkette (#program_name) in einen Array of Char umgewandelt und anschlie�end in die zugeh�rigen interne Register("Switch_Activity.Current_Program) geschrieben. Der darauf folgende MOVE-Block schreibt den Integer-Wert 1 an das "Switch-Ativity_Number" Register um in die Programm-Ansicht zu wechseln (vgl. Dokumentation Ansichten horstFX). Dadurch wird, nach setzten der zugeh�rigen Maske, das Programm mit dem �bergebenen Programmnamen geladen.

Netzwerk 3:

In diesem Netzwerk wird das geladen Programm gestartet. Daf�r wird zun�chst �ber die Abfrage des "Current_activity" Registers �berpr�ft, ob sich horstFX im Programmfenster befindet. Wurde Netzwerk 2 erfolgreich durchlaufen, ist ein Programm geladen und dieses wird nun durch Das Bit "Program_Calls.play" gestartet. Jetzt kann die lokale Startvariable #start_detectec zur�ckgesetzt werden.

Netzwerk 4:

Hier wird die Ausgangsvariable #is_running gesetzt. Daf�r werden die entsprechenden "Program_State" Bits auf dem Schaltschrank abgefragt ("HORST_IN".Program_State.Is_Running und "HORST_IN".Program_Executing_mode). Diese zeigen an, ob sich horstFX im Abspielmodus befindet und ein Programm gerade abgespielt wird (vgl. Profinet Input Daten). 

Netzwerk 5:

Hier wird die lokale Ausgangsvariable #done gesetzt, wenn das aufgerufene Programm beendet wurde.

2. Download 

Das zugeh�rige SPS-Programm kann hier heruntergeladen werden:

SPS-Programm