SPS-Submit schmiert ab

Servus,

generell muss die Zuweisung $TOOL = TOOL_DATA[1] , oder sonst irgendein Frame Funktionieren!

Im SPS-Sub kannst du mit

...
If (VarState("$POS_ACT") == #INITIALIZED) Then
...

erkennen ob eine Variable initialisiert wurde.

HTH

Tobi

Zitat von Georg24

Im SPS-Submit will ich karthesiche Positionen abfragen.
(Mit $pos_act)

Das geht nicht. Du kannst korrekt im submit nur die einzelnen Achspositionen abfragen.
Das hat nix mit deiner Definition des Tools zu tun.

Wenn der Submit kein gültiges Tool oder Base hat kann er auch keine Wert für $POS_ACT liefern.

Wenn Du das aktuelle Tool kennst kannst Du die die $POS_ACT selber berechnen:

Wie Georg24 schon sagt nur die $AXIS_ACT sicher abfragen. Und dann kannst Du ja folgenden Code für die Umrechnung anpassen:

SetBaseTool (0,0) ; (Base,Tool)


	If TRUE Then 
		ERR_STATUS = 0	; Überprüfung der Achswinkel auf SW-Nocken
	Else
		ERR_STATUS = 1	; keine Überprüfung der Achswinkel
	Endif


	If TRUE Then 
		$TARGET_STATUS = #BEST		;  Status des Zielpunktes ist der kürzeste Achsweg
	Else
		$TARGET_STATUS = #SOURCE	;  Status des Zielpunktes wird vom Startpunkt übernommen
	Endif


;;==========================================================
;            UeberkopfSingularitat   (Alpha 1)
;;==========================================================
;  0 Achse 1 wird auf 0 Grad festgelegt.
;  1 Achse 1 bleibt vom Start- bis zum Zielpunkt gleich.
;;==========================================================
;            StrecklagenSingularitat (Alpha 2)
;;==========================================================
;  0 Achse 2 wird auf 0 Grad festgelegt.
;  1 Achse 2 bleibt vom Start- bis zum Zielpunkt gleich.
;;==========================================================
;            HandachsenSingularitat  (Alpha 5)
;;==========================================================
;  0 Achse 4 wird auf 0 Grad festgelegt.
;  1 Achse 4 bleibt vom Start- bis zum Zielpunkt gleich.
;;==========================================================


;	$SINGUL_POS[1] = 1
;	$SINGUL_POS[2] = 1  
;	$SINGUL_POS[3] = 1  


;;==========================================================
;        Variables used through transformation
;;==========================================================
;  $BASE
;  $TOOL
;  $ROBROOT
;  $IPO_MODE


  mE6POSTmp[1] = FORWARD (XHOME, ERR_STATUS)

Stellt sich nur die Frage,warum ich $POS_ACt nicht sicher abfragen kann?
Varstate==#INITIALIZED sollte es ja eigentlich sicher machen...
Interressant ist eigentlich warum es manchmal klappt, also programm anwählen, und manchmal nicht.
Ich war mit der Frage schon bei der Hotline und die haben dafür auch keine Lösung...

Hallo,

$Pos_act im Submit vergessen. Wird nie 100% sicher funktionieren.
Irgendwann erwischt er genau die $pos_act Abfrage/Zuweisung, wenn Du zurücksetzt oder abwählst.
Aufruf im Roboterinterpreter immer machen mit:
Bas(#Tool, 1)
So wird TCP, Lastdaten!!! wie auch Tool für Handverfahren auf einmal aktiviert.

$Tool=Tool_data[2] aktiviert Dir nur TCP 2 fürs Programm, aber nicht die Lastdaten von Werkzeug 2.

Gruss SJX

warum probierst du nicht die $pos_act abfrage in eine IF-Bedingung einzubauen.

if "programm angewählt" und "progranm läuft" then
xxx=$pos_act.x ; oder was du halt möchtest
endif

weis leider nicht auswendig wie die Variablen für angewählt und läuft heissen.

Beim Kuka nach dem warum zu fragen hab ich mir schon abgewöhnt. Da gehen immer wieder mal seltsame Dinge vor, die auch Kuka nicht beantworten kann.

Dein Submit läuft vermutlich deshalb weiter, weil Du die initialisiert Abfrage drin hast.

Weiterhin viel Erfolg!

Gruß
Stromer

Schmiert er denn bei der If Abfrage oder bei der Zuweisung ab?

Was genau willst Du denn zur Sackfahrt wissen? Steht sicherlich in der Doku drin aber frag mich jetzt nicht wo.

Gruß
Stromer

Hallo zusammen,

der Kuka weiß im Submitinterpreter manchmal net recht was Phase ist im Roboterinterpreter vor allem mit VARSTATE.

hatte das selbe Problem mit nem String in der Zeile 10 ist die Variable Initialisiert
in 11 schon net mehr.

hab das entprellt in dem ich je nach Variablen Typ ein paar Sub Zyklen schaue ob sie initialisiert ist und bleibt erst dann benutze ich sie net schön aber wenn der Sub schnell ist und es net auf den mm ankommt nach meiner Erfahrung sicher.

nachdem ich es am laufen hatte hab ich mit einem von Kuka gesprochen was man in so einem Fall machen kann.
er riet mir unabhängig die selbe lösung.

willst du die Positon immer überschreiben? wie wäre es nur zu schreiben wenn der Robter steht $ROB_STOPPED und wenn $PRO_IP.P_ARRIVED 1 ist hast du wenigstens SAK erreicht und damit ne gültige $POS_ACT wenn ich mich grad net irre

wenn du nur im Fehlerfall den Punkt brauchst kannst du den auch in IR_STOPM.SRC speichern
schön in ner Struktur mit Uhrzeit Datum und vieleicht ein paar Infos im FIFO

Gruß Loipe

Georg24:
- was ist denn so grausam an der KUKA-Doku ?
- genau so gut wie Deine Fehlerbeschreibung ?
- welche Softwareversion benutzt Du ?
- was heißt der "Submit schmiert ab" ?
- Fehlermeldung ? bleibt nur stehen ? Submit LED rot ?

Beschreibung SAK ? In meiner Doku "Prog für Endanwender V5.5" ist
SAK (Verahrarten, wann, wie,..) über 25 mal beschrieben.

Danke im Voraus für Deine genaue Fehlerbeschreibung

hallo Georg

ich hab auch noch keine offizielle Doku gesehen aber wenn du die Forumssuche nutzt bin ich mir sicher das du etwas darüber findest. ist ja nicht so das es was extrem neues wäre.
und ein Programmbeispiel von Inverse findest du in jedem Kuka Roboter unter c:\Krc\Util\Kueweg\
abgesehen davon würde ich immer eine Axis Position im Submit bevorzugen da sie erstens nicht von Tool oder BaseDaten abhängig ist und mir die absolute Position verrät.
Wenn ich was Kartesisches brauche kann ich es mir, auch wenn ich keine offizielle Doku habe, mit Forward diese umrechnen, und zwar in jedes Verhältniss das ich möchte.

Die Aktuelle Position ist nach abwählen des Programms ungültig, da weder Tool noch Base gültig sind. Noch ein Grund Axis zu nehmen. Warum das so ist musst du in Gersthofen fragen, ich persönlich hab damit kein Problem.

Und das mit dem Submit kannst du relativ einfach mit einem Livebit das du von der Sps bekommst und zurückspiegelst lösen.

wenn kein Programm angewählt ist und du eins anwählst muss die erste bewegung PTP sein bin mir ziemlich sicher das so sinngemäß in der Doku steht.
Damit eine definierte Achsstellung gewährleistet ist.

jedes Robotersystem hat so seine Eigenheiten und Macken und damit schon fast Menschlich

Gruß Loipe

Hallo Georg,
Loipe hat ja schon fast alles geschrieben.
Hast ja recht - einen Preis wird die KUKA-Doku wahrscheinlich nie gewinnen
Desshalb gibt es das Roboterforum

Deine speziellen Fragen nochmal:
- Wir haben nichts über Funktionen gefunden. (FORWARD, INVERSE usw.)

Am Anfang waren diese Funktionen nur für „den internen Gebrauch“ gedacht. Kunden sollte das nicht benutzen.
Im Laufe der Zait haben aber immer mehr Kunden von diesen Funktionen erfahren, und wollte sie unbedingt benutzten. Deshalb bekamen sie die Informationen.
Ich denke in der Zwischenzeit sollte man die Funktionen auch in der offiziellen Doku im Expertenteil beschreiben (wird gemacht).

- Warum ist die $POS_ACT nach den abwählen eines Programmes undefiniert?

Falsch! Die Variablen $TOOL und $BASE sind nach dem Abwählen eines Programms nicht undefiniert.
Sie sind nach einer Anwahl eines Programms undefiniert. Und als Folge davon ist dann $POS_ACT undefiniert.
Und auch nach Programm-Reset sind sie undefiniert, da Reset einfach die Kombination aus Anwahl und sofortiger Wiederanwahl ist.
Der Grund, warum nach Anwahl eines Programms TOOL und BASE undefiniert sind ist der folgende:
Wäre das nicht so, und am Anfang des Programms wir kein TOOL und BASE gesetzt, so würde ein TOOL und BASE vom Vorgängerprogramm gelten. Und das kann irgendeines sein. è Crashgefahr !!!!!!

- warum gibt es kein Signal an die SPS, das der Submit läuft?

Weil es von den Kunden nie gefordert wurde. Da muss der Kunde ein LiveBit (Pulse auf $OUT, usw) selbst programmieren

- Welche erste Bewegung muß eine PTP-Bewegung sein?
Die Bewegung in der Cell.src oder auch die in jeden Prg das von der Cell aufgerufen
wird ?(Sorry, Ich bin das halt vom Stäubli anders gewohnt)

Die erste Bewegung nach Programmanwahl muß eine vollständige (keine Lückenprogrammierung) PTP-Bewegung sein.
Werden von diesem Programm dann andere Programme aufgerufen, so kann dort durchaus als erste Bewegung ein LIN oder CIRC stehen.
Der Grund dafür ist, dass der erste Zielpunkt auch von Status und Turn her eindeutig angefahren werden muß.
Ist das nicht der Fall so liegen je nach Status und Turn andere Achswinkel vor, und wenn dann irgendwann PTP-Bewegungen kommen,
so ergibt sich eine andere Bahn. è Crashgefahr !!!!
Nur bei PTP wird gewährleistet, dass der programmierte Status und Turn angenommen wird. Bei CP-Bewegungen wird der Status, der am Start vorliegt
beibehalten und der Turn ergibt sich durch den Bewegungsverlauf.
Wenn also der Stäubli das nicht so macht, dann sehe ich das sehr bedenklich.

- Fehler: irgendwas mit: XYZabc-Tool ...
Tool undefiniert und des Submit bleibt stehen

noch frohes Schaffen
a+