Posts by Programmiersklave

Quote from Martin Huber

das musst du dir dann schon selber basteln, ein Ansatz wäre die Greifertasten als "kritische" Tasten zu definieren, dann muss man diese 2x betätigen bevor eine Aktion ausgelöst wird.

Hey, cool, das geht? Hatte mit der "neuen" GripperTech noch nicht so dramatisches Zeug zu handlen.

Der Ansatz mit dem Dialog "wollen sie wirklich? Ja|Nein" ist extrem kontraproduktiv, sowohl vom Benutzerinterface her als auch von der Sicherheit, stellte sich raus.

In einer Maschine hatte ich drum in der "alten" Grippertech die Anforderung (mit Notification) "drücke innerhalb von drei Sekunden zweimal zum Öffnen", das war und ist richtig gut.

Für solche Fälle gäb's auch noch NumToDnum(). Schön, dass es läuft!

Ach warte, das ist gar nicht der Konfigurationsfehler 71349, sondern in Deinem Screenshot ist es 41566. Die Variable passt nicht zum Signal. Schreibst Du DNum rein? Num ist zu kurz. Handbuch schreibt:

Quote

Empfohlene Aktionen
Gruppensignale, bestehend aus 23 Bits oder weniger, können
durch den Datentyp „num“ und Gruppensignale mit 32 Bits oder
weniger durch den Datentyp „dnum“ dargestellt werden, falls
diese in einem RAPID-Programm verwendet werden.

16.13 kenne ich nicht. 6.13 muss gehen, und gerade hab' ichs mal mit ner virtuellen 5.15 probiert, da ging es auch.

Ganz blöde Frage, weil es mir immer wieder passiert ist an dieser Stelle: Du zählst ganz sicher das erste und letzte Bit in den von-bis mit? 100 - 132 sind nämlich 33, und die gehen wirklich nicht....

Quote from Roland Keller

Allerdings geht das mit den Gruppenausgängen nur bis zu einem Wort, 16Bit.

Sicher? (Mindestens) ab RW6 gehen 32 Bit.

Ansonsten das gute, alte, MoveXSync, und in der Routine dann die Aufteilung, wie ganz früher, als es noch keine DNum gab.

MoveLSync etc. erinnert von der Abarbeitung her allerdings manchmal an einen Hintergrundtask, da muss man ein ein bisschen auf die Zeiten aufpassen.

So geht's auch, als pragmatische Lösung und vor allem als bessere Lösung, denn hier spielt ja dann noch nicht einmal eine Rolle, was der Roboter glaubt.

Wird aber ein Problem wenn man nicht "wir" sagen kann, d. h. der Roboter nicht in der eigenen Firma steht und man eine lückenlose und idiotensichere Kalibrierkette einrichten muss. Sobald der Schlosser den Greifer wechselt, läuft einem das Problem hinterher.

Hab' aktuell 'nen Kunden, der betreibt 25 Jahre alte Anlagen mit dem originalen Roboter und dem originalen Bildverarbeitungssystem, der letzte, der sich auskannte, ist seit Jahren in Rente. Da stellste ALLES in Frage....

Ist das gleiche wie bei geteachten Positionen im *.DAT: die bleiben so, wie sie hinterlassen wurden, auch nach Neustart. Und ohne, dass man explizit eine "Speicherung" veranlassen müsste.

Ich glaube, das ist so ein Umstand, der Programmierern, die nicht mit Robotern groß geworden sind, erst einmal fremd ist. Auch der Programmierer meines Offline-Programmiersystems, der wirklich über Jahrzehnte auch seinen KUKA-Postprozessor pflegte, war baß erstaunt, als ich ihm klar machte, dass ich seine rausgeschriebenen Punkte auf dem Roboter easy modifizieren konnte und dasselbe File dann zum Zurücklesen bereitstellte. Für Puristen mag das eine unerträgliche Vermischung von Daten und Anweisungen sein, und ich verkneife mir beim Kunden immer den Kommentar, wenn einer meint, dass der Roboter ja nur das fahren würde, was man ihm programmiert habe.

Quote from privet199

Das bedeutet, dass die gemessenen TCP-Koordinaten zunächst auf den Ursprung des Roboterflansches umgerechnet werden müssen. Wie könnte man das machen?

Auch das geht, man muss dazu die Frames passend invertieren oder eben nicht und verknüpfen.

Invertieren geht mit INV_POS() (Suchfunktion verwenden), verknüpfen mit ":".

Und 'ne Menge Grübelei... ne Menge!

Quote from maxiTC3

Oder verstehe ich es immer noch falsch.

Glaub ja.

In *.DAT stehen die Strukturdefinitionen und die Variablendeklarationen. Und wenn man denen dort einen Wert mitgibt, dann wird der persistent gespeichert. Global, wenn Du willst. (Schlüsselwort "GLOBAL", ich sag's nochmal, oder eben $config.dat) Das ist der Datencontainer.

Und im Programm - in der *.SRC kannst Du diese Variablen aus der *.DAT überschreiben. Wenn Du unbedingt was mit 0 überschreiben musst, dann dort. "Initialisiert" sind die in der *.dat immer, denn es sind ja globale Persistenten, zumindest wolltest Du das bisher so. Man kann in der SRC auch Variablen deklarieren, aber die existieren dann nur zur Laufzeit der jeweiligen Routine, und müssen tatsächlich initialisiert werden. Wie Du sie mit 0 überschreibst, steht in Deinem eigenen Beitrag #3 oder in meiner Antwort #5.

Und überschreiben kannst Du sie, wann immer Du willst, zyklisch, nach Bedarf, einmal, oder nie. Ich empfehle nur: ein "Kaltstart" ist erfahrungsgemäß nicht unbedingt ein Grund, sie zu nullen. Musst Du selber wissen. Ein SPS.SUB-Start ist aber nicht dasselbe wie ein Steuerungsstart (ersterer passiert häufiger).

Weiß ja keiner, was Du vor hast. Wenn das dritte Mal ein Bediener mit 'ner Leiter 40kg schwere Motorenteile aus den Fächern holen muss weil Dein Programm willkürlich die Plätze genullt hat, dann wird er Dir unfreundlich seine Bedürfnisse übermitteln. Wenn er einfach 'nen Setzkasten in 'ne Schäferkiste ausleert ist es ihm vielleicht egal. Wenn dringend genullt werden muss, wirst Du das wissen; wenn die Zahlen einfach stehen bleiben oder überschrieben werden können, dann auch.

Rückmeldung über den Status des Angewähltseins gibt die Variable $PRO_STATE1.

Quote from Joka

Der bereits enthaltene Start über
...

Klappt nicht.

Vergiss das, das ist eine automatische Anwahl (nicht start) bei Start der SPS.SUB bei vorher angewähltem Ext-Betrieb.

Man kann sich verrückt machen mit dem Protokoll für externen Start, und das übliche Ablaufdiagramm verursacht Kopfschmerzen, aber "eigentlich" reichen zwei Systemsignale, um das Ding rennen zu lassen.

Ich empfehle eine von der $config.dat unabhängige Datei, ich hab' sie immer "globals.dat" genannt. Und dann mit dem Schlüsselwort "GLOBAL", siehe das Beispiel in meiner ersten Antwort. Erspart Ärger bei Systemupgrades und ist dann auch nicht durch andere Prozesse gebunden (Editieren der $CONFIG.DAT führt z. B. zum Stoppen des Submit-Interpreters, weil sich der auf Variablen darinnen bezieht).

Die Initialisierung baust Du als Routinenaufruf an den Beginn Deines Hauptprogrammes, es startet ja sowieso "von vorne". Je nach Organisation macht man das sogar schon im CELL-Programm.

Bei solchen Anwendungen (Handlingsaufgaben, wo sich der Roboter Informationen "merken" muss) hab ich auch immer gern als zweite Instanz den Benutzer gefragt. Programm merkt: hey, ich soll hier initialisieren, aber eigentlich war ich vorher noch mittendrin im Job - Benutzer, willst du wirklich, dass ich alles vergesse und von vorne anfange? Hast du alles leer gemacht? Oder soll ich nicht lieber da weitermachen, wo ich unterbrochen wurde?

Den Array mit den Variablen musst Du trotzdem einmal komplett schreiben (in "globals.dat" oder dergl.). Da sollte Dein Editor Hilfsmittel liefern, das kann man beliebig kompliziert haben ... UltraEdit z. B. kann JavaScript damit kann man sich einen automatischen Array-Bastler programmieren....

War jetzt etwas unverständlich gefragt.

Zum Initialisieren würde ich mir einen "nullshelf" machen, falls man das öfters braucht, ansonsten einfach reinschreiben:

DECL row nullshelf={fAbsolutPos_Y 0, fPrePos_Z 0, fAbsolutPos_X 0}

und dann reicht

FOR nShelfs = 1 TO 3 STEP 1
FOR nRows = 1 TO 10 STEP 1
Shelf[nShelfs,nRows] = nullshelf
ENDFOR
ENDFOR
blabla

Mit den Sachen in der SPS.sub ein bisschen vorsichtig, dein Beispiel oben initialisiert Dir das Ding immer, wenn die neu gestartet wird. Das kann aber auch andere Gründe haben als einen Neustart des Systems. Ein Systemstart ist beim Kuka andererseits gar nicht so kritisch, wenn Du keinen Neustart erzwingst. Kann also sein, dass Du Dir die Programmumgebung incl. Variablensituation ohne Not kaputt machst, wo Du eigentlich einfach weiterfahren könntest.

Anmerkung noch: Deine "Row"-Variable sieht aus, als könne man sie auch durch einen "FRAME" ersetzen. Dann hat man zwar drei Real (die Orientierungen) "über", hat aber ein paar interessante Möglichkeiten mehr, sich die Arbeit zu erleichtern, von ":" bis $NULLFRAME.

Niemand zwingt Dich, einen "FRAME" nur als "FRAME" zu benutzen... aber letztlich isses egal.

Quote from maxiTC3

Meine Ansätze zum Schreiben:

xVariable = Shelf[nShelf, nLevel].fAbsolutPos_Y

Das nimmt die Syntax aber nicht.

Im Grunde sollte das aber so gehen.

Ich hab' gerade mal in ein altes Projekt geguckt, und da hab' ich damals gemacht:

GLOBAL STRUC measdata REAL laserval,FRAME position,BOOL valid


DECL GLOBAL INT M_activearray=1
DECL GLOBAL INT M_store=18


DECL GLOBAL measdata messung[3,100]
messung[1,1]={laserval 406.590485,position {X 156.811462,Y 1221.34094,Z 245.797897,A -49.5099945,B -0.510035038,C -178.390},valid TRUE}
messung[1,2]={laserval 406.590485,position {X 156.811462,Y 1220.74097,Z 245.797897,A -49.5099945,B -0.510035098,C -178.390},valid TRUE}
messung[1,3]={laserval 406.590485,position {X 156.811462,Y 1220.14087,Z 245.797897,A -49.5099945,B -0.510035157,C -178.390},valid TRUE}
....

   messung[M_activearray,M_store].laserval=$SOFTPLCREAL[3]
   messung[M_activearray,M_store].position=$POS_ACT
   messung[M_activearray,M_store].valid=TRUE

und so weiter.

Ging also grundsätzlich.

Die Frage ist ja auch, warum macht man sowas.

In den seltensten Fällen braucht man das fertig berechnete Robtarget als Daten, die irgendwo rumliegen, sondern man möchte einfach variabel fahren. Und da tut's dann auch ein Offs(), dem man dann die entsprechenden Gleichungen übergibt.

Vielleicht erst mal schauen, ob noch alle drei Phasen der Zuleitung vorhanden sind....

Quote from Florian_IRC5

Ich muss dazu sagen, dass ich im Bereich Roboter ziemlich neu bin und somit des Öfteren Backups laden muss.

Nee, musst Du nicht.

Eigentl. ist gegen ein Restore beim ABB nichts einzuwenden - funktioniert normalerweise erstaunlich gut. Was in Deinem konkreten Fall schiefgegangen ist kann man so aus der Ferne nicht sagen. Was ich in dieser Richtung schon mal hatte, war, dass eine eventuell vorhandene Sicherheitskonfiguration nicht geladen wurde, weil die u. U. mit anderen Benutzerrechten restauriert werden muss. Wenn Du mit "PC" RobotStudio meinst, kann es sein, dass Du Dich regulär mit den höheren Rechten anmeldest, weil das irgendwann mal so eingestellt wurde...

Allemal besser ist es aber, sich mit den jeweiligen Fehlern, die man macht, auseinanderzusetzen. Bei der IRC ist das Backup äußerst überschaubar und besteht aus relativ wenigen Dateien. Die Konfigurationen (Syspar) kann man einzeln nachladen, und die Programmmodule (Rapid) auch. Man kann aus dem Backup dann auch die einzelnen Dateien laden, die man gerade versaut hat, wenn man nicht mehr weiter weiß.

Und das geht ja auch über Kreuz. Wenn Du das nicht mehr aktuelle Backup aus dem PC restauriert hast und dazu die aktuellen Programme im "RAPID"-Ordner des USB-Backups wiederfindest, dann kannst Du die einfach drüberladen und fertig.

Quote from RobiMan

S4c+ Steuerung?

Da sollte doch die Auswahl erscheinen das letzte gespeicherte Image zu benutzen

Nee, wenn's richtig hängt kommste auch nicht mehr ins Bootmenü, dann hilft nur noch die V24-Schnittstelle.

Aus irgendeinem Grunde war die Info darüber, wie und was man dann machen muss, klassifiziert als "nur für internen Gebrauch". Inwieweit man das in 2024 noch ernst nehmen muss weiß ich nicht, aber deshalb ging das 2008 wohl über PN.

Was ist denn 'ne A-Achse?

A-Achsen gibt's im CNC. Beim KUKA gehste erst im unterliegenden Koordinatensystem in x (rot), dann in y (grün) und dann in z (blau), wobei hier die Reihenfolge noch egal ist.
Danach aber nicht mehr: wennste an dem Punkt angekommen bist, drehste dich erst um blau (A), dann um grün (B) und dann um rot (C).

Deine beiden Positionen sehen relativ zum Roboter so aus. Aber hier weiß bisher keiner, ob diese Angaben überhaupt relativ zum Roboter gemacht wurden.

Wenn Du sicher bist, dass "VALLGEMEIN" konstant bleibt - die nächsten beiden Punkte sind MoveJ. Sicher, dass Dein subjektiver Eindruck von "langsamer" nicht trügt?

Mich wundert immer noch so'n bisschen, dass das Tool offenbar "on the fly" geändert wird, nachdem schon nach dem Greifen mit dem originalen Tool Bewegungen gemacht wurden. Das wäre nicht meins, damit fehlt mir auch die Erfahrung, was genau in einem solchen Fall passiert, zumal für jede Bewegung extrem gerechnet wird. Ist vermutlich okay, aber ich würd's nur sehr vorsichtig anfassen beim Versuch, da was zu optimieren....

Wer hat denn die offensichtlich zuerst auch vorgesehene Last- und Schwerpunktänderung wieder rausgenommen? War das noch der Integrator oder warst Du das?

Quote from BlockMove

Hintergrundfunktion die ohne Aufruf funktioniert

Wenn man es wirklich drauf anlegt, könnte man einen Interrupt auf eine Persistentenänderung (IPers) ansetzen - aber ich glaub', das gab's bei Deiner RW-Version noch nicht.