Beiträge von kcinnaySte

Grundsätzlich noch ein Tipp:

Wenn man die Variable $STOPNOAPROX auf "TRUE" setzt, dann hält der Roboter im T1 und T2 an der entsprechenden Stelle, welche den Vorlaufstop verursacht mit einer Quit-Meldung an, dadurch lässt sich sehr einfach testen, ob ein Befehl einen Vorlaufstop verursacht.

Wenn es eine Systemvariable ist, dann wird man den Schreibschutz nicht aufheben können.

Je nachdem welche Variable es ist, kann man sie aber vielleicht im Roboter oder Submitinterpreter setzen.

Also erstell einfach mal ein Modul, in welchem die Variable beschrieben wird, und ruf es mit dem Roboterinterpreter oder Submitinterpreter auf.

Hey,

zu 1)

Schau mal in Zeile 47, da verwendest du den falschen Handle (nHandleUeberwachung statt nHandleAussschuss) (Kopierfehler)

zu 2)

kannst auch result = Clear_KrlMsg(nHandleXXXXXX) benutzen. Musst dann halt die Variable "result" noch deklarieren. Durch das WaitFor hat man das halt verhindert das man die Variable nicht definieren muss, da ich den Rückgabewert nicht auswerte.

Hey Woody,

foo und bar sind Beispielvariablen.

Das er in der Schleife hängt ist ja sogesehen noch okay, allerdings ist das Problem, dass wenn innerhalb dieser Wartebedingung die Variable sich ändert, wird die Repeat_Until schleife sofort verlassen, somit wird das Clear_KrlMsg() nicht mehr aufgerufen. Wenn dann müsste man die Wartebedingung vor der IF-Anweisung einfügen, aber auch dann besteht noch die gefahr, dass sich die Variable genau in dem Satz-Wechsel ändert.

Außerdem wird in diesem Fall natürlich nur eine Meldung abgesetzt, da der Submit-Zeiger dann in der Repeat_Until schleife hängen bleibt, bis die Meldung wieder gelöscht werden kann.

Bezüglich der von mir verwendeten Funktionen (welche die Meldungen absetzen):

Guck mal in die KRC://R1/System/MsgLib.src , dort ist bereits von Haus-Aus eine Libary, mit der recht einfach Meldungen abgesetzt werden können. (Auch Hinweismeldungen usw) Ist in dem Kommentar recht gut beschrieben. In den meisten Fällen reicht diese Libary erfahrungsgemäß aus. Natürlich kannst du es aber auch komplett selber Programmieren

Deine "Übersetzung" ist grundsätzlich korrekt, es ist jedoch anzumerken, das die Variable nHandle für jede Meldung extra angelegt werden muss, da diese ja auch einzelt wieder gelöscht werden soll.

Also:

IF (JobnR == 1) and (nHandleSchutztuer <= 0) THEN
  MsgState(nHandleSchutztuer, "Sicherheit", "Fehler Hilfskontakte Schutztuer")
 ENDIF
 IF not (JobnR == 1) and (nHandleSchutztuer > 0) THEN
  Wait for Clear_KrlMsg(nHandleSchutztuer) or true
  nHandleSchutztuer = -1
 ENDIF 

 IF b_Ueberwachung_AUS and (nHandleUeberwachung <= 0) THEN
  MsgState(nHandleUeberwachung, "Sicherheit", "Arbeitsraeume sind Deaktiviert!!!")
 ENDIF
 IF not b_Ueberwachung_AUS  and (nHandleUeberwachung > 0) THEN
  Wait for Clear_KrlMsg(nHandleUeberwachung) or true
  nHandleUeberwachung= -1
 ENDIF 

Kleiner Nachtrag:

Ich empfehle die Variable iHandleBar und iHandleFoo in der INIT Zeile vom Submitinterpreter auf -1 zu setzen, sodass auch nach dem Submittinterpreterreset immer eine Meldung ausgegeben wird.

Hallo Woodys,

Folgende Probleme fallen mit bei diesem Code auf:

Je nachdem wann die Vairiable geändert wird, bspw Zeile 15, würde die Meldung nicht Gelöscht.

Ich würde die Variable nHandle nach dem löschen der Nachricht wieder auf "0" oder ähnliches setzen.

Was meinst du mit "andere Meldungen?" es wird nur die Meldung mit dem Jeweiligen Handle gelöscht.

Ich persönlich mache es so:

 IF foo and (iHandleFoo <= 0) THEN
  MsgState(iHandleFoo, "Foo Message", "Foo")
 ENDIF
 IF not foo and (iHandleFoo > 0) THEN
  Wait for Clear_KrlMsg(iHandleFoo) or true
  iHandleFoo = -1
 ENDIF

 IF bar and (iHandleBar <= 0) THEN
  MsgState(iHandleBar, "Bar Message", "Bar")
 ENDIF
 IF not bar and (iHandleBar > 0) THEN
  Wait for Clear_KrlMsg(iHandleBar) or true
  iHandleBar = -1
 ENDIF

Einblenden nein, Freischalten ab Grippertech 4.0 ja.

Ab Grippertech 4.0 kann man aber Voraussetzungen für das Schalten einers Greiferbefehls vergeben. Sollte eine Greiferfunktion dann geschaltet werden, kommt die Meldung "Voraussetzung nicht erfüllt"

Nein, dies ist nicht möglich.

Es gab aber auch bei der KRC2 (mit Zusatzhardware) die Möglichkeit das KCP ab zu koppeln. Danach könnte man natürlich dann ein anderes Anschließen. Nur sind die Stecker nicht sehr schön um diese jedes mal zu lösen.

In KRL:

DEF XmlCallBack( )
  INT i
  DECL EKI_STATUS RET
  $FLAG[1]=FALSE

  INTERRUPT DECL 89 WHEN $FLAG[998]==TRUE DO GET_DATA()
  INTERRUPT ON 89
 
 RET=EKI_Init("XmlArray")
 RET=EKI_Open("XmlArray")
 
 RET=EKI_SetInt("XmlArray","JOBSTEP/CURRENT", 1)
 RET = EKI_Send("XmlArray","JOBSTEP")
 

 WAIT FOR $FLAG[1]
 
 RET=EKI_Close("XmlArray")
 RET=EKI_Clear("XmlArray")
END

DEF GET_DATA()
 DECL EKI_STATUS RET
 
 RET=EKI_GetFrameARRAY("XmlArray","JOBSTEP/POSITIONS",FRAMEARRAY[])
 
  $FLAG[998]=FALSE
  $FLAG[1]=TRUE
END

Die Config:

<ETHERNETKRL>
<CONFIGURATION>
<EXTERNAL>
<IP>192.168.0.1</IP>
<PORT>59152</PORT>
</EXTERNAL>
</CONFIGURATION>
<RECEIVE>
<XML>
<ELEMENT Tag="JOBSTEP/POSITIONS" Type="FRAME"/>
<ELEMENT Tag="JOBSTEP" Set_Flag="998"/>
</XML>
</RECEIVE>
<SEND>
<XML>
<ELEMENT Tag="JOBSTEP/CURRENT"/>
</XML>
</SEND>
</ETHERNETKRL>

Die Antwort vom Server:

<JOBSTEP>
    <POSITIONS X="210.3" Y="825.3" Z="234.3" A="84.2" B="12.3" C="43.5" />
    <POSITIONS X="310.3" Y="825.3" Z="234.3" A="84.2" B="12.3" C="43.5" />
    <POSITIONS X="410.3" Y="825.3" Z="234.3" A="84.2" B="12.3" C="43.5" />
</JOBSTEP>

Wie gesagt, das Array FRAMEARRAY darf wie gesagt max. 3 Felder groß sein.

Hey,

Tatsächlich, die Funktionen sind mit noch gar nicht aufgefallen.

Habe es gerade mal getestet, man muss die Daten wiefolgt anlegen:

<ELEMENT Tag="JOBSTEP/POSITIONS" Type="FRAME"/>

Also, die Tatsache das es ein Array ist einfach Ignorieren.

Danach kann man die Werte in KRL einfach in ein Array lesen, mit:

RET=EKI_GetFrameArray(configFileName[],"JOBSTEP/POSITIONS",FRAMEARRAY[])

Wichtig ist hier scheinbar, dass das KRL-Seitige Array (hier FRAMEARRAY) nicht größer sein darf, als die Daten, welche gesendet werden, da der Roboterinterpreter ansonsten in der Funktion EKI_GetFrameArray() hängen bleibt.

Und wieder einmal haben wir was gelernt

Hey,

Ich vermute dass das gar nicht geht. Zumindest sind in VisionTech, welches auch Ethernet-KRL benutzt die Zusatzattribute auch auf mehrere Variablen aufgeteilt, also:

<ELEMENT Tag="VTResponse/TaskResult/Attributes/Attribute1/Key" Type="String" />
<ELEMENT Tag="VTResponse/TaskResult/Attributes/Attribute1/Value" Type="String" />
<ELEMENT Tag="VTResponse/TaskResult/Attributes/Attribute2/Key" Type="String" />
<ELEMENT Tag="VTResponse/TaskResult/Attributes/Attribute2/Value" Type="String" />
...

Hier ist auch zu sehen, dass es sich bei dem Type nicht um einen ARRAY[CHAR] oder ähnliches handelt, sondern um einen eigentlich in der KRL unbekannten Typen String

Es wäre aber natürlich möglich die Struktur so auf zu bauen, dass man mehrere Variable noch durchnummeriert, also:

<ELEMENT Tag="JOBSTEP/POSITIONS/Val1" Type="FRAME"/>
<ELEMENT Tag="JOBSTEP/POSITIONS/Val2" Type="FRAME"/>
<ELEMENT Tag="JOBSTEP/POSITIONS/Val3" Type="FRAME"/>
...
<ELEMENT Tag="JOBSTEP/POSITIONS" Type="FRAME"/>

Oder in der Recive-Datei:

<JOBSTEP>
    <POSITIONS>
        <Val1 X="0.0" Y="0.0" Z="0.0" A="0.0" B="0.0" C="0.0" />
        <Val2 X="0.0" Y="0.0" Z="0.0" A="0.0" B="0.0" C="0.0" />
        <Val3 X="0.0" Y="0.0" Z="0.0" A="0.0" B="0.0" C="0.0" />
    </POSITIONS>
</JOBSTEP>

Die Daten kann man dann ja sehr einfach in KRL in ein Array schreiben:

DECL FRAME Positions[3]
RET=EKI_GetReal(configFileName[],"JOBSTEP/POSITIONS/Val1", Positions[1])
RET=EKI_GetReal(configFileName[],"JOBSTEP/POSITIONS/Val2", Positions[2])
RET=EKI_GetReal(configFileName[],"JOBSTEP/POSITIONS/Val3", Positions[3])

Oder, falls es sich um ein sehr großes Array handelt, den String auch mit C_WRITE direkt erstellen lassen.

Anzumerken wäre noch, dass XML-Tag-Namen nicht mit einer Nummer Anfangen dürfen, deshalb in dem Beispiel "Valn"

Ein wirkliches Array hat ja in XML auch keine Nummerierung, weshalb ich mir die durchnummerierung auch schwierig vorstelle, das müsste dann ja bei der Deserialisierung geschehen, und in verschiedene Speicheradressen abgelegt werden.

Hey Woodis,

das Problem war vermutlich, dass es sich bei Is_key_pressed() um eine Funktion handelt, und nicht um ein Systemvariable als Array. Ansonsten sollte es passen. Die entsprechende Tastennummer lässt sich dann ja durch Probieren oder eine Schleife welche in ein Array schreibt recht einfach herausfinden.

Ich kenne jetzt leider die Signalanalysen von ABB nicht.

Aber ich starte immer automatisch einen "Ringspeicher" als Trace über den SPS.SUB (siehe TraceRingspeicher.zip)

In der TraceConfig kann mann dann ja auf einen Eingang Triggern (KRCIO -> IN) oder über eine Variable (KRCIpo -> Variablenwert), und den Trigger auch etwas nach vorne verschieben, sodass man auch die Ausgangssituation noch mit im Trace hat.

Hey,

auf was wollt ihr denn Triggern? Ich Trigger meist auf irgend ein Flag, oder ein Output, und setzt es dann bei bedarf im SPS.SUB selbst.

Oder einfach auf eine Fehlernummer.

Gruß

Yannick

Hallo mm0987,

das kommt sicherlich vor allem auf den Bit bzw die Schraubanart an.
Mit FTCtrl kannst du die Kräfte auf den TCP in X, Y und Z sowie um A, B und C messen und entsprechend darauf reagieren. So kannst du Beispielsweise den Roboter in X und A "weichschalten" und die anderen Koordinaten hat belassen.
Sollte die Schraube also Recht fest am Roboter montiert sein, könnte es funktionieren. Eine Kreizschraube sieht hingegen eher schlecht aus.

Gruß

Yannick

Hallo dsommer,

wie die Beschleunigungen ausgeführt werden, hängt auch von den Lastdaten ab.
Für derartige Simulationen reicht auch Office Lite, er wird kein Kuka Sim Pro benötigt. Wenn du mir ein komplettes .SRC File plus Lastdaten und Robotertyp schickst, kann ich es dir auch gerne Simmulieren, und dir eine Aufzeichnung der Daten zukommen lassen.
An sonsten hilft dir auch sicherlich der Counsulting von KUKA gerne weiter.

Gruß

Yannick

Hallo nahpets

in der Regel kommt max. Getriebemoment, nicht wie die Bezeichung vermuten lässt vom Getriebe, sondern eher vom Servoregler, ich würde einfach mal den Regler quertauschen (Bei der KRC4 bitte auf die FsoE adressen achten) bzw. dem KUKA Service kommen lassen. Der Fehler ist meist sehr schnell behoben.

Gruß

Yannick

Es kann daran liegen das sich Fehlerhafte Sektoren auf der Partition C befinden.
Entweder die Festplatte ausbauen und mal an nen Rechner hängen und da CHKDSK ausführen, oder die neue Recovery Stick Version Herrunter laden, die macht immer Vorher nen CHKDSK.
http://www.update-recovery-usb.kuka-robotics.com

Ist zwar etwas älter aber trotzdem noch der Hinweiß.
Wenn es nur an der Fahrfreigabe mangelt, kann man unter der Konfig der Eingänge für Aut. Ext. bei $Move_Enable den Eingang 1025 eintragen. Diese bedeutet "immer 1".

Genau so kenne ich das auch, manche Stapler können vorne die Gabel auch drehen, das ist dann die "Luxusvarriante"