Bei 4 Bits und einer Definition als Gruppeneingang (INT) geht die Sache gerade noch erträglich:
IF ((GI == 7) OR (GI==11) OR (GI==13) OR (GI==14) OR (GI==15)) THEN
;ist okay
ENDIF
Was man dann noch abkürzen kann zu IF ((GI == 7) OR (GI==11) OR (GI>=13)) ....
Binärdarstellung macht's nicht kürzer, höchstens offensichtlicher. Wenn man's im Interrupt haben muss, dann mit Cycflag.
Bei mehr Bits würde ich durchzählen.
Ups... ja, sicher. 
Ich sollte vor 10 Uhr nicht hier reingucken.
Ist doch schräg, dann muss man immer gucken, wo der Index gerade steht.
Mach doch einen FiFo:
FOR i = 9 to 1 STEP -1
Messung[i+1] = Messung[i]
ENDFOR
Kamerawert = Messung[1]Auf die Weise wird der Array eine Position weitergetaktet, [10] verschwindet im Nirvana und in [1] steht immer der jüngste Wert. Je höher der Index, umso älter.
Bei aktivem Programm: Bearbeiten (Softbutton unten rechts) -> Ansicht -> DEF-Zeile an/abhaken.
Ändert aber vermutlich nichts an Deinem Problem.
In der Tat ist es möglich, durch versehentliches unbedachtes Löschen oder Editieren eine solche Ansicht hinzubekommen, insbesondere, wenn dann noch Folds im Spiel sind. Ich würde Dir empfehlen, einen gesicherten Stand aus einem Archiv einzuspielen.
chrisfriedo : wenn Du einfach nur willst, dass bei Bedarf nach dem Umschalten das CELL-Programm angewählt wird, WENN NICHTS ANGEWÄHLT IST, sieht der Code im Loop-Teil so aus:
IF (($MODE_OP==#EX) and ($pro_state1==#p_free)) THEN
CWRITE($CMD,STAT,MODE,"RUN /R1/CELL()")
ENDIFDie zweite Bedingung guckt, ob ein Programm angewählt ist, und wenn nicht, wählt er cell an.
Da braucht man weiter auch keine Bedingungen und Verrenkungen.
WENN ein Programm angewählt ist, bleibt es freilich drin. Das ist normalerweise das erwünschte Verhalten: wenn im Ablauf irgendwas schiefgeht, kann man auf Hand und wieder zurück, ohne den Programmzeiger zu verlieren.
Was natürlich nichts hilft, wenn Du mit dem Code verhindern willst, dass irgendein Trottel eine andere Routine oder dergl. angewählt hat und dann startet. Aber wie tief soll man das treiben?
Was ich auch gelegentlich mache: bei schweren Fehlern das Programm selbsttätig ABwählen mit
if (kill_task AND (NOT($pro_state1==#p_free))) then
CWRITE($CMD,STAT,MODE,"CANCEL")
kill_task=FALSE
endifdirekt drunter. Muss man kill_task halt im Fehlerfall irgendwo setzen.
chrisfriedo , scheint mir, als sei Dir unklar, dass Du keine Kette bilden musst (darfst). Nach dem Aufruf eines Unterprogramms und dessen unterem Ende (END oder ENDFCT) springt der Programmzeiger von selbst in die Zeile unterhalb des Aufrufs zurück.
Sei vorsichtig, das sind keine ABB-Bewegungsbefehle. Da hat einer eigene Routinen konstruiert, um dann sinngemäß gleiche Bewegungsbefehle darin auszuführen, aber mit einem zusätzlichem Parameter. Meine Vermutung: die Zahl ganz hinten hilft bei 'ner eigenen Homrun-Strategie, kann aber auch was anderes sein.
Bei den ursprünglichen Bewegungsanweisungen wäre das Pre-Processing des RZ-Winkels allerdings völlig unkritisch, bessere Ausgangsbedingungen könntest Du gar nicht haben (Anfahren mit AbsJ, und dann RelTool).
Ob das Ding, welches die Zahl braucht, mit der veränderten Orientierung immer glücklich ist, kann man aber erst sagen, wenn man weiß, was es tut.
IF winkel > 180.0 winkel :=winkel - 360.0;
reicht nicht?
Da ein schönes Wort für zu haben wäre für mich auch interessant, auch weil es jetzt in Richtung Selbständigkeit geht bei mir... besonders, wenn man eben kein Ingenieur ist und sich noch nicht mal offiziell "Techniker" schimpfen darf, aber seit 'nem Vierteljahrhundert im Business ist.
Und so kommen dann die Angebote bei Xing: hey, willste nich Schweißroboter teachen? Herausforderung! Herausforderung!!!
Mich erinnert's trotzdem an die Schwierigkeiten beim Einbinden des DIrLoaders. -
Der zeitweilig laufende Submit-Task bindet Daten in Base_Teachen.dat, und das aufrufende Unterprogramm greift zügig, nachdem der Submit-Task gekillt wird, auf diese *.dat zu.
Ich stelle mir halt vor, dass das System manchmal noch dabei ist, die Daten zu sichern, je nachdem, wo es den Submit-Interpreter gerade erwischt hat, und dabei dann Inkonsistenz erzeugt. Da er ja nicht mehr läuft, versagen vielleicht auch die internen Mechanismen, die normalerweise die Konsistenz der Daten überwachen... oder so. Ich würde mal nach dem Warten auf #P_FREE mindestens 'ne Zehntelsekunde Wartezeit einfügen. Aber wie gesagt, ist nur geraten.... ist schon ein recht ungewöhnlicher Ansatz.
Okay...
ich muss gestehen, so sehr mich diese Lösung auch fasziniert, aber ich bin noch nie auf die Idee gekommen, einen Hintergrund-Task bedarfsweise an- und abzuwählen, und habe auch nicht die geringste Idee, wie sich das auswirkt.
Jedoch:
wenn ich Dich richtig verstehe, wird Zeile 19 in Deinem ersten Code scheinbar nicht ausgeführt, und BaseKorr bleibt auf dem vorigen Wert.... was ich nur sehe: Du übergibst an Base_Teachen den Frame "BaseKorr" als Parameter. Es ist meist eine schlechte Idee, globale Variablen als Parameter zu übergeben. Entweder sie ist global, oder sie ist ein Parameter. Hier ist sie beides, das könnte das Problem sein.
Edit: ach quark, ist ja lokal im aufrufenden Programm. Hm.
nd das Unterprogramm erneut angewählt hab (ohne zu starten) um mir die aktuellen Werte des Korrektur Frames anzuschauen waren komischerweise noch die neu geteachten Daten drin, obwohl das Programm abgewählt war, aber ins .dat wurden sie halt nicht geschrieben.
Ersteres ist erklärbar: da wird der Submit-Interpreter die globalen Daten noch gebunden haben. Den Submit wirst Du ja wohl nicht abgewählt haben...
Auch für das "nicht-schreiben-Problem" vermute ich mal einen Zusammenhang mit dem Hintergrundtask. Welcher Teil der Routine holt sich wann die Daten... unterschätze bitte nicht die taskübergreifende Programmierung beim KUKA. Keiner der Tasks wartet von selbst, bis irgendwas anderes fertig ist, das musst Du alles händisch selbst tun (Flags als Semaphore setzen und auslesen etc.). Insbesondere, wenn Du auf dieselben Daten lesend und schreibend zugreifst, kann alles Mögliche passieren (arbeite lieber mit Kopien der Daten und halte Lesen und Schreiben getrennt).
Für den Programmierer mag der Ablauf manchmal logisch schlüssig aussehen, die Taskumschaltung erwischt dann aber trotzdem manchmal gerade den Moment, den man am wenigsten gebrauchen kann.
Vorsicht auch vor Selbstbetrug: manchmal geht der Fehler "fast" weg, wenn man dann eine Wartezeit in den SPS-Task einbaut, einfach deshalb, weil der Taskswitch dann "meistens" innerhalb der Wartezeit passiert. Aber eben nur meistens und nicht garantiert....
Das gibt es nicht. Was heisst "aussteigen" in dem Zusammenhang? Da müsste dann ein "exit" drinstehen. Was ja auch möglich ist, ich lege immer gern einen Exit auf einen virtuellen Ausgang, dann kann man den BG-Task schnell stoppen. Aber nicht von selbst. Der Programmzeiger muss irgendwo sein. Bediener soll hat nichts anfassen, wenn es das nächste mal auftritt.
Zu Punkt 4... wurde zwar nicht explizit erfragt, aber falls Du vor hast, mehrere Robbis zusammenarbeiten zu lassen, lässt sich ein ABB-System recht einfach als "Multimove"-System aufsetzen, mit mehreren Manipulatoren an einer Steuerung und taskübergreifenden Programmbestandteilen. Das ist oft ein Killerfeature.
Wenn der Task auf einen Fehler läuft, stoppt er. Das Fehlerlog müsste darüber Auskunft geben, außerdem kann man dann im Editorfenster oder über RobotStudio ganz normal sehen, wo der Programmzeiger stehengeblieben ist.
Bei meiner Anwendung geht es darum, dass ein Vision System Positionen an einem Werkstück erkennt, und der Roboter dann diese Positionen mit einem Werkzeug anfährt. Die Werkstücke sind unterschiedlich, auch die Lage variiert. Irgendwie muss ich doch die Informationen über die Bearbeitungspositionen vom Vision System zur Robotersteuerung übertragen.
Wenn meine Herangehensweise so exotisch ist, dann ist das vielleicht ein Hinweis, dass ich einen Denkfehler in meinem Konzept haben könnte. Lässt man die Bilderkennung sonst direkt auf der Robotersteuerung laufen? Oder sind die Anwendungen üblicherweise statisch und es werden nur vorher geteachte Positionen angefahren?
Nee, das ist schon okay, wie Du das vor hast, und so herum klingt es dann ja auch wie gewohnt.
Auf der Steuerung läuft das Roboterprogramm und arbeitet ein definiertes Programm ab, und das nimmt jetzt Informationen von außen entgegen und reagiert bei Bedarf darauf.
Meistens über irgendeine Form von standardisierten Feldbus, z. B. Profinet, aber auch über Ethernet, ist ebenfalls üblich. Entscheidend hier, dass das Ablaufprogramm auf der Steuerung die Kontrolle behält und den Roboter bewegt, und externe Sensorik wie Vision-Systeme etc. die nötigen Informationen beistellt.
Die Robotersteuerung hat ja normalerweise interne Informationen (Sicherheitsbedingungen, Tool, Base, Load, Achsbegrenzungen, Achskonfiguration uvm.), welche das externe System nicht kennt und auch nicht interessiert. Der Roboter hat das hingegen schon eingebaut und braucht das.
Gemeinsame "Gesprächsbasis" sind Koordinatensysteme (Tool und Base, manchmal auch Referenzlagen), und ausgetauscht werden dann Abweichungen, meistens in Form von Frames. Das lässt sich sehr gut mit so einem Datenaustausch realisieren, über die übliche EA-Schnittstelle hinaus. Jene wiederum enthält frei konfigurierbare Signale einerseits und Systemsignale wie Start, Stop, Fehlerquittierung usw.
Dass es dann von Außen noch eine Beeinflussung der Geschwindigkeit und ähnlicher Parameter gibt, ist nicht ungewöhnlich, wird aber nur implementiert, wenn man es tatsächlich braucht.
Kann natürlich sein, dass bei einem "Spielzeug"roboter auf die "normale" E/A-Schnittstelle verzichtet wurde und man alles über z. B. EthernetKRL macht. Auch in dem Falle läuft es aber trotzdem darauf hinaus, dass die auszutauschenden Informationen in irgendeiner Benutzerkonfiguration deklariert werden und in irgendeinem Benutzerprogramm ausgewertet werden und nichts ist, was komplett vom System bereitgestellt wird.
[Zeitliche Überschneidung mit Hermann bei der Beitragserstellung]
Vielleicht ist meine Frage naiv, aber ein Roboter ohne Möglichkeit der Steuerung durch einen externen PC o.ä. scheint mir wenig nützlich zu sein. Da hätte ich erwartet, dass standardmäßig irgendeine Möglichkeit der Ansteuerung mitgeliefert ist. Gibt es so etwas?
Nur zur Einordnung: ich hab' jetzt 21 Jahre Industrie-Roboter in Betrieb genommen und noch nie die Not gehabt, den von einem externen PC ansteuern zu müssen.
Welche Option käme denn infrage, um von einem externen PC aus z.B. über Ethernet Positionen vorzugeben und Statusinformationen (z.B. ob die Zielposition schon erreicht ist) abzufragen?
Mit EthernetKRL könnte man u. A. das. Aus KUKA-Sicht ist das freilich mehr eine EA-Schnittstelle zum KRL-Programm und nichts, was selbiges umgeht.
Dann gibt's noch RSI (habe ich keine Erfahrung mit).
Für den Überblick über die wichtigsten Eigenschaften des Roboters ein Archiv erstellen und in dessen Wurzelverzeichnis in die am.ini schauen.
Leslie33 , Du solltest hier aus Deiner Gedankenwolke erst einmal zweierlei herauskristallisieren lassen:
Als Vergleichsobjekte zu 1. Input stellst Du sprachgesteuerte Assistenzsysteme hin, das ist 'ne hohe Messlatte. Google, Amazon und co. machen das mit KI im Netz (und teilweise Menschen als Mitarbeitern, weshalb man sich so'n Ding nur zu Hause hinstellt, wenn es einem zu gut geht), das kannst Du nicht vergleichen. Einfache Sprachsteuerung geht allerdings auch lokal, man kann heutzutage ja auch Autos schon soweit belabern, dass sie im Navi das richtige Ziel wählen oder Tante Erna anrufen.
Ich würde behaupten, der Bereich, in welchem man den Aufwand verorten kann, erstreckt sich hier mindestens über 4 Zehnerpotenzen, wenn man das nicht definiert hat.
Als Vergleich zu 2. Output nennst Du eine mit Laser projizierte Tastatur, bei der ist aber der Input-Teil interessant. Einfach nur ein Bild zu projizieren ist heutzutage Pillepalle (siehe Mini-Beamer). Wenn Dein "Ding" hingegen auch die Bewegungen der Hände erfassen und darauf reagieren soll, ist das wieder eine viel, viel größere Baustelle.
Hier würde ich von mindestens 2 Größenordnungen im Planungsbereich reden.
Solange Du diese Eckdaten nicht definiert hast im Sinne von "das brauche ich", ist Dein virtuelles Vorhaben m. E. real chancenlos.
Heißt also, dass die beste Herangehensweise für eine Programmierung im Büro folgende ist (es ist nur noch die Programmstruktur zu erstellen - alle Konfigurationen sind gemacht)
Hm, das ist ja eigentlich ein Umweg (obwohl ich den auch gerne nehme, muss ich gestehen).
Wenn Du offline programmierst, geht es eigentlich unter "Konfiguration und Inbetriebnahme" im Tab "Dateien". Dort steht die volle Funktionalität ja zur Verfügung, und man befindet sich bei "5" in meiner Liste. Was man dort macht, landet dann im Projekt, das man dann über die "Zusammenführen"-Vergleichsoption mit dem auf der Steuerung aktiven Projekt zusammenführen kann. Wenn das dann aktiviert ist, sollte erst einmal Gleichstand gegeben sein (nach dem lokalen Speichern des Zusammenführungsergebnisses).
Der Umweg über "Programmierung und Diagnose" (die Online-Funktionen) ist dann nicht nötig.... was mich treibt, das trotzdem manchmal auch so zu tun, ist die Furcht, die Anlage re-initialisieren zu müssen. Das war früher häufiger so eine Art von Kontrollverlust über das Geschehen. Bei "Programmierung und Diagnose" macht man ja nur das, was man auch auf dem KCP machen kann, das fühlt sich irgendwie sicherer an....
Das ist eine Quelle ständiger Verwirrung..
Im Grunde gibt es maximal 6 verschiedene Stände:
6 ist eine Momentaufnahme von 2, während 2 sich automatisch mit 1 synchronisiert. 6 kann von 2 durch Bearbeiten beliebig asynchron werden, bis man es wieder angleicht. 3, 4 und 5 sind davon völlig unabhängig, und wird nur angeglichen, wenn man ein Projekt lädt oder speichert. Beim Laden eines Projektes auf die Steuerung gibt es zum Glück das Vergleichstool, da geschieht dann 5->4->3->Vergleich mit 2->2->1, 6 ist völlig raus.
Mit "Online und Diagnose" hat man nur die Kette 6->2->1, Projektunabhängig.
Zu beachten auch: bei Proconos/Multiprog kann man noch weiter von der Seite reingrätschen und die SoftPLC direkt mit Multiprog ändern, während der Kollege gerade mit WoV arbeitet. Die Bootdatei der SoftPLC ist aber Bestandteil des Projektes...
