SPS.sub Unterschiedliche Zuweisungen bei unterschiedlichen Programmen

Hallo,

mein Vorschlag:

eine Integer Variable global deklarieren mit dem Namen Programmnummer.

Diese Variable jeweils unterschiedlich am Anfang eines Modules beschreiben.

Im sps.sub eine Switch-Case Anweisung mit den unterschiedlichen Programmnummern und Abfragen programmieren.

Grüße
K(A)RL

Man könnte so einfache Verknüpfungen auch zu Beginn des jeweiligen Hauptprogrammes auf ein $CYCFLAG linken, und dann in der SPS.SUB nur noch das $CYCFLAG abfragen.

Was auch geht, ist: aus der SPS.SUB in eigene Routinen des Hauptprogramms verzweigen, in welchen der spezifische Code steht. Das hat allerdings den Nachteil, dass das Hauptprogramm nicht mehr teachbar oder änderbar ist, solange der Submit-Interpreter rennt.

Grüße,
Michael

Zitat

Wie erstelle ich eine globale Variable? Schreibe ich dort den Namen meines Hauptprogrammes rein?

Du kannst z.B. in der Config.dat eine Variable anlegen, etwa so:

DECL INT Programmnummer = 0

In deinem Hauptprogramm (oder Unterprogramm) schreibst du dann einen Wert in diese Variable, a la:

Programmnummer = 1

In der SPS.Sub fragst du diese Programmnummer ab und reagierst entsprechend:

IF (Programmnummer == 0) THEN
 Mache GarNix
ENDIF


IF (Programmnummer == 1) THEN
 Mache was für Programm_1
ENDIF


IF ((Programmnummer > 1) AND (Programmnummer <= 10)) THEN
 Mache was für Programm_2_bis_10
ENDIF

usw.

Du kannst das natürlich auch mit einer SWITCH-CASE Anweisung machen, aber das ist sicherlich Geschmacksache.

@ Corvax: Generell möchte ich Dich warnen wollen, diese administrativen Aufgaben in die SPS.SUB auszulagern. Das führt sehr schnell zu Verstrickungen und Selbstblockaden sowie zu Unübersichtlichkeiten bei zeitlichen Abhängigkeiten zwischen beiden Tasks.
Ich habe jetzt bei mehreren Anlagen große Teile der Anlagensteuerung in den Submit-Interpreter ausgelagert, das geht erstaunlich problemlos. Aber immer wenn sowohl Roboter-Task als auch Submit-Interpreter dieselben Parameter beeinflussen wollen, wird's arbeitsintensiv. Es lohnt den Aufwand nicht.
In Deinem Codeschnipsel geht es scheinbar darum, einen Zähler zurückzusetzen, wenn bestimmte äußere Bedingungen gegeben sind. Mein Rat: lass sowas den Roboter machen und nicht die SPS.SUB, denn wenn Du es den Roboter machen lässt, kannst Du selbst entscheiden, WANN es geschieht. In Deinem Beispiel kann es Dir z. B. passieren, dass die SPS.SUB das Ergebnis noch mit der alten Programmnummer ausgewertet hat, der Roboter aber schon eine neue Programmnummer bekommen hat, die eigentlich die andere Vorgehensweise benötigt hätte. Und wenn Du sagst, dass Du mehrere solche Stellen hast, dann musst Du auch zu verhindern wissen, dass z. B. die Umstellung der Programmnummer irgendwo mittig dazwischen stattfindet, das Ergebnis wäre sonst chaotisch. Und das ist nur EIN Beispiel.

Du kannst Dir ein eigenes Modul machen, was immer auf der Steuerung verbleibt, mit globalen Unterroutinen, die solche Aufgaben übernehmen, dazu muss man nicht die SPS.SUB quälen. Dort kannst Du auch programmspezifische Abläufe reinbringen, je nach einer global gespeicherten Programmnummer oder sonstiger Parameter. Mach Dir eine Funktionsbibliothek, die dem Bewegungsprogramm die nötigen Antworten zurückgibt, das wird jemanden mit wenig KUKA-Erfahrung am ehesten weiterbringen.

Nur ein Vorschlag...
Grüße,
Michael

Ja genau.
So eine Zählung muss auf alle Fälle in das Roboterprogramm.
Sowas gehört auf gar keinen Fall in den SPS.SUB.

Kann man so nicht pauschal beantworten. Kommt immer auf den konkreten Fall an.
Normalerweise sollte doch z.Bsp. beim Lösen eines Werkstückgreifers auch auf einen Eingang gewartet werden,
wenn man die Zählergeschichte dahinter erledigt, dann hat sich das mit dem Vorlauf auch schon von selbst erledigt.