Hallo CesMak,
leider weiß ich nicht was "eki" ist, aber eine parallele Ausführung würde über den Submit Interpreter gehen. Schau mal auf dein Robi Verzeichnis "R1/System", dort ist üblicherweise eine sps.sub in der du auch deine eigene Logik schreiben kannst - Allerdings keine Bewegungen!
Ich hoffe das hilft dir etwas und es war wonach du gesucht hast!
Hallo,
ich durchlaufe ein Programm für eine Kamera, welches mir dann die Koordinaten für den Roboter übermittelt. Allerdings dauert das ein paar Sekunden und solange wartet der Roboter. Wie kann ich das Programm parallel bzw. schon vorher durchlaufen um diese Wartezeit zu umgehen. Bzw. kann ich das in der SPS.Sub irgendwie anstoßen?
Entweder du definierst dir ein weiteres subprog oder du kannst es integrieren innerhalb der aktuellen sps.sub. Je nach dem wie groß und aufwendig es ist.
Sollte halt keine Roboterbewegungen enthalten sei . 😉
Wir haben wenig Informationen zu deinen Anforderungen!
Evtl. kann ein Signal definiert werden, welches ein Interrupt auslöst um die Daten nach Eingang zu registrieren/ weg zu speichern. Der Robbie kann wärend dessen alles andere abarbeiten, ggfls. schon zur Vorposition fahren, oder so.
Wie gesgt wir kennen deine Anforderungen nicht...
wie gesagt, ich muss eine SRC File durchlaufen, in der die Kamera das Bauteil sucht welches passend zum greifen ist. Die Koordinaten werden dann in Variablen für x,y,z usw. geschrieben, welche ich dann im nächsten Programm in einer Variable zusammenfasse und anfahre. Es funktioniert alles soweit, allerdings habe ich die Wartezeit was die Kamera braucht um diese src File zu durchlaufen um die Variablen zu beschreiben
Du kannst diesen src in der sps.sub einbinden. Sollte kein Problem darstellen.
Aber Achtung vor Warteanweisungeb, wenn benötigt dann ein separates sub Programm definieren, ist ganz easy.
könntest du mir da einmal ein Beispiel oder die Vorgehensweise genauer schildern. Ist neu für mich.
Kommt erstmal drauf an, wie alt Dein System ist.
Wenn Du beim Tap auf das "S" so ein Bild vorfindest:
dann kannst Du Dein Programm in eine *.sub benannte Datei auslagern und die einem der EX1..7 benannten Tasks zuweisen. Natürlich mit Endlosschleife etc.
Ist da "nur" der Submit-Interpreter, wird es schwieriger, dann brauchste eine Art Schrittkette oder sowas für die Kommunikation mit der Kamera.
Und vorab schon mal eine Warnung für Programme im Hintergrundtask: der Haupttask (das eigentliche Roboterprogramm) "weiß" nicht, was das Submit-Programm gerade macht. Du brauchst stets einen vernünftigen Handshake, so dass sichergestellt ist, dass erst und nur dann der Roboter die Koordinaten auswertet, wenn sicher ist, dass sie feststehen.
also mein Submit-Interpreter sieht so aus, ist neues aktuelles System. Wie bekomme ich die x.dat und x.src Datei in ein x.sub Datei, damit ich diese dann in EX1 auswählen kann?
.dat und .src haben mit .sub nicht wirklich etwas zutun, kann aber Funktionen aus solchen aufrufen...
Der Submitinterpreter öffnet nur *.sub-Dateien. Du musst also deinen Code in eine .sub-Datei kopieren und entsprechend anpassen. Der Austausch mit dem Bewegungsprogramm geht z.B. über GLOBAL deklarierte Variablen. Aber nochmal das zuvor genannte zusammen gefasst:
*.dat bleibt *.dat, die hält die Daten. Man kann *.dat ohne *.src haben und umgekehrt. Falls Du die gesamte x.src in die *.sub umziehen willst, wirst Du evtl. die Daten global machen müssen.
Die *.src kannst Du zuerst im Handbetrieb testen. Du wirst um die vorhandenen Funktionen noch einen Rahmen basteln müssen, denke ich. Du brauchst eine Initialisierung, und dann muss die ja von selbst immer in einer Loop laufen, wahrscheinlich durch die Anforderung eines externen Signals oder eines bools vom Roboter getriggert. Und wenn die Schleife durch ist, muss sie über eben sowas dem Roboter Bescheid sagen, dass sie jetzt die Daten hat, und dann wieder von vorne aus in Wartestellung gehen bis zum nächsten Trigger, und sie darf nie von selbst enden. Stehenbleiben und warten darf sie beliebig, wenn es nicht die eigentliche SPS.SUB ist, denn die ist drauf angewiesen, sofort reagieren zu dürfen. Alle anderen Subs dürfen warten, bis sie schwarz werden.
Im Grunde kannst Du aber auch die (vermutlich) extern programmierten x.src und x.dat einfach so lassen, wie sie sind, und von Deinem eigenen Rahmenprogramm (dem mit der Schleife) aus einfach nur aufrufen wie bisher, das geht (leider / zum Glück) kreuz und quer. Solltest dann allerdings darauf achten, dass NUR DIESE Instanz die Kameraprogramme aufruft, und nicht irgendeine versteckte Ecke des Roboterprogramms das AUCH tut. (Kann man nämlich auch kreuz und quer machen, nur dann hat man wirklich Datenkollisionen in der *.dat)
Wenn diese Rahmen-*.src fertig ist und funktioniert, dann benennst du sie einfach um in *.sub und benutzt den Button "Anzeigen/Zuweisen" wie im oberen Bild, dann testen, ob sie beim nächsten Neustart automatisch mitstartet.
Das wär's dann schon...
- Handshake des Bewegungsprogramms mit dem Submit
- Submit setzt ein Signal, wenn neue Daten vorliegen
- Daten von Submit in Bereich des Bewegungsprogramms kopieren, damit diese konsistent bleiben
- Bewegung setzt ein Signal, damit Submit weiß, das die Daten abgenommen wurden
Submit setzt Signale zurück und kann mit der Bearbeitung fortfahren
Und damit - sorry für diesen Interrupt - holt man sich u. U. wochenlange Debugging-Sessions rein.
Nie nicht darf ein Task einfach Daten überschreiben, schon gar nicht, nachdem er die Bereitstellung signalisiert hat. Das geht 42mal gut, beim 43. mal geschieht das gerade während des Lesens durch den anderen Task und es gibt brutalen Datensalat.
Ein Task muss Daten bereitstellen, danach sagen, dass sie gültig sind, und darf sie dann nicht mehr ändern, bis sie ungültig sind.
Der andere Task kann und darf sie nur lesen, wenn sie gültig sind, und danach selbst wieder ungültig machen.
Sollen Daten vom Task 1 aus initiiert zwischendurch ungültig gemacht werden können, wird das nur dann sauber, wenn der Task 2 dafür ein unabhängiges Freigabefenster zulässt. Es kann anderenfalls passieren, dass Task 2 die Gültigkeit abfragt, bestätigt bekommt, und dann unmittelbar danach der andere Task seinen Teil der Zeitscheibe bekommt - und dort die Gültigkeit verwirft und mit der Manipulation der Daten beginnt. Sind beide dann nicht mehr aufzuhalten.
Das ist ein generelles Problem bei der Synchronisation unabhängig laufender Programme und jeder EA-Kommunikation, allerdings stellt KRL intern dafür m. W. keine Werkzeuge bereit. Bei ABB Rapid hat man für den Abgleich zwischen den Tasks entsprechende Sprachelemente.
Wie ich schon schrieb... durch einen Interrupt Werte aus den Eingängen auf Variablen schreiben, ohne BRAKE/ BRAKE F. Robbie kann weiterfahren, weiter arbeiten, kein .sub, keine Sychronisierung.
Eventuell übersehe ich etwas und würde beim testen feststellen, dass das totaler Murks ist, ka.
Ich habe seit einiger Zeit den Eindruck meine Beiträge werden komplett überlesen... 
Dein Submit-Programm darf im Gegensatz des Bewegungsprogramms nicht stehen bleiben!
Das stimmt so nicht!
Du kannst soviele warteanweisungen einfügen wie man lustig ist…
Ausgenommen SPS.Sub…..
Deshalb ist ja die Integration eines separaten eigenen Task, sub Programms, gelegentlich von Vorteil, da hier dann unabhängig von anderen Abläufen ein völlig eigenständiger Ablauf existieren kann.
Display MoreKommt erstmal drauf an, wie alt Dein System ist.
Wenn Du beim Tap auf das "S" so ein Bild vorfindest:
dann kannst Du Dein Programm in eine *.sub benannte Datei auslagern und die einem der EX1..7 benannten Tasks zuweisen. Natürlich mit Endlosschleife etc.
Ist da "nur" der Submit-Interpreter, wird es schwieriger, dann brauchste eine Art Schrittkette oder sowas für die Kommunikation mit der Kamera.
Und vorab schon mal eine Warnung für Programme im Hintergrundtask: der Haupttask (das eigentliche Roboterprogramm) "weiß" nicht, was das Submit-Programm gerade macht. Du brauchst stets einen vernünftigen Handshake, so dass sichergestellt ist, dass erst und nur dann der Roboter die Koordinaten auswertet, wenn sicher ist, dass sie feststehen.
Falls das Bild nicht so aussieht, gibt es bei Kuka die Möglichkeit den MultiSubmitinterpreter zu bestellen als Optionspaket.
Hab den früher echt gerne genutzt.
Möglichkeit den MultiSubmitinterpreter zu bestellen als Optionspaket.
Ab 8.3 sogar Kostenlos
Ab KSS8.3.15... (und kostenlos)
Multisubmit in KSS8.3 ist etwas umstaendlich...
Und ... nur haupt submit kann EA ansteuern (egal was fuer KSS oder Multisubmit eingesaetzt sind).
