Aber bei KRC4 ist sogar ein kartesisches Weichschalten des Roboters möglich.
Ist in der Doku zu KSS V8.2 unter Momentenbetrieb beschrieben.
Hallo,
ich habe hier das Dokument "KSS 8.2 SI V4 de" von 19.06.2012. Dort kann ich nichts zum kartesischen Momentenbetrieb finden. 
Ist dies nun wirklich möglich? 
EDIT: Meinst du den Punkt "Bei Kollisionen Schäden vermeiden"? Da kann man scheinbar mit weichgeschalteten Achsen auch Linearbewegungen durchführen...
Ja, aber dabei handelt es sich um drei verschiedene Bänder.
Wie muss ich mir das vorstellen, wenn mehrere Objekte gleichzeitig auf einem Band transportiert werden (was ja der Normalfall ist...)? Da muss ja ein Puffer gebildet werden und jedem Teil in diesem Puffer wird der entsprechende Wert des Conveyors zugeteilt (ich nenne es mal wieder Instanz)... Bei der Bewegung des Bandes verändert sich dieser Wert für jedes Teil im Puffer entsprechend. Bei Kuka gibt es aber nur die BASE 11 (beispielhaft) für alle Teile auf diesem Band.
Ich kann mir nur vorstellen, dass man die Conveyorposition zum Triggerzeitpunkt dem Teil "mit in den Puffer speichert" (mit $SEN_PREA_C[]) und beim späteren Anfahren des Punktes in BASE 11 mit in die Punktberechnung einbezieht. Das könnte ich nachvollziehen...
Wann setzt man aber dann den Conveyor zurück? Etwa niemals? Kann es dann zum Überlauf kommen? Ich weiß es nicht? 
Kann mir jemand erklären, wie man ein Teilepuffer mit ConveyorTech auf einem Band realisiert? In der Doku, die ich habe, ist das nicht beschrieben...
Danke
Moin Forum,
ich kenne das von Kawasaki Robotern, wo man den Wert eines Conveyors in mehreren Instanzen abfragen, sich mit ihm synchronisieren und auch zurücksetzen kann -> z.B. so:
CVRESET 7=INT_Instanz ;den Wert der Instanz "INT_Instanz" des ersten Bandes (7. Achse) zurücksetzen
INT_Temp=CVPOS2(INT_Instanz,7) ;den Wert der Instanz "INT_Instanz" des ersten Bandes (7. Achse) abfragen/speichern
CVCOOPJT 7 ;mit dem ersten Band synchronisieren (7.Achse) -> gilt für alle Instanzen des Conveyors...
CVLMOVE #Teachpunkt, ,INT_Instanz ;den Teachpunkt synchronisiert mit Band 1 anfahren -> Istwert von Instanz "INT_Instanz" als Basis verwenden
Bei KUKA scheint es laut Doku nur eine Instanz eines Conveyors zu geben -> $SEN_PREA_C[]???
Ich möchte den Bandlauf gerne in mehreren Prozessen unabhängig voneienander verwenden können.
Ist sowas möglich? 
Hi,
bei RESUME must Du auf deinen Vorlaufzeiger achten! evtl. $ADVANCE auf 0 setzen, kann sonst auch Probleme machen.
Gruß Chili1886
Wo? Am Anfang der Interrupt-Routine?
Vielen Dank für Eure Beiträge!!!
Habe das jetzt ähnlich wie Berrad gelöst:
=============================
frame p1,p2
real dx,dy,dz,winkel
$BASE=$NULLFRAME
$TOOL=$NULLFRAME
p1=$pos_act
p2=p1:{x 0,y 0,z 1000,a 0,b 0,c 0}
dx=p2.x-p1.x
dy=p2.y-p1.y
dz=p2.z-p1.z
winkel=abs(acos(dz/(sqrt((dx*dx)+(dy*dy)+(dz*dz))))-180)
==========================================
Habe alle möglichen Positionen getestet, Winkel wird ordnungsgemäß bestimmt. *FREU*
Moin Forum,
habe ein mathematisches Problem bei der Umsetzung einer Rückzugsstrategie.
Ich möchte erkennen, ob sich der Flansch senkrecht zum Boden (Weltkoordinatensystem) befindet (z.B. in einem Kegel mit 90° Öffnungswinkel).
Das muss über die Abfrage der Orientierungswinkel B und C von $POS_ACT lösbar sein, aber deren Vorzeichen machen mir im Moment noch das Leben schwer.
Freue mich auf gute Ratschläge...
Hui, hat sich ja toll entwickelt das Thema! 
Wie man die INI überschleifen kann wusste ich schon. Besonders interessant finde ich, dass es scheinbar nicht wenige Leute gibt, welche die cell nicht verwenden. Was sind denn Eure Gründe dafür? Abgesehen von dem Überschleifen komme ich damit nämlich recht gut zurecht. Und einige Kunden schreiben die Schnittstelle sogar ins Lastenheft.
In jedem Fall habe ich jetzt mit Eurer Hilfe Ideen sammeln können, wie man es alternativ machen kann. 
Hast du evtl. in einem deiner Unterprogramme auf irgendeine Art und Weise einen Vorlaufstop drin bevor es verlassen wird? Ausgang gesetzt etc. ?
Ich habe den Ansatz noch nicht umgesetzt! Wollte ja eigentlich nicht gänzlich von der ursprünglichen (original KUKA) cell abweichen, welche momentan noch im Programm arbeitet. Dass ich mir vorstellen könnte, dass es funktioniert, habe ich ja schon geschrieben. Wenn Du das im Test bereits bestätigen konntest, ist das schön. Danke dafür!
Auf welchen Wert steht dein Vorlaufzeiger? ($ADVANCE)
Steht auf 3. Müsste aber auch schon bei 1 gehen oder?
Also mit der orignal cell (oder einer leichten Abwandlung davon) sieht keiner eine Möglichkeit, stimmt das?
Wenn dein Kollege das hinbekommen haben sollte, eine PTP Bewegung während der Fahrt auf eine andere Position umzuleiten, wüsste ich gerne, wie das gehen soll
Nein, so war das nicht gemeint!
Ich habe es nicht gesehen, aber es wird wohl etwas in der Art gemeint sein:
DEF meine_cell()
LOOP
ProgNum=giProgNumSPS ;von mir aus sogar noch erweiterbar mit gespiegelter Programmnummer
SWITCH ProgNum
CASE 1
Ablauf_1()
CASE 2
Ablauf_2()
DEFAULT
;nichts??? keine Anhnung...
ENDSWITCH
ENDLOOP
ENDDas ist eine Cell ohne den Programmaufruf P00, also ohne die $EXT Schnittstelle, dafür mit vereinfachtem Handshake. Ich denke, das könnte von der Bewegung her so aussehen, wie ich es mir wünsche (überschliffen).
Ist aber auch ein sehr radikaler Ansatz, deshalb frage ich ja hier nach Möglichkeiten rund um die cell...
Danke auf jeden Fall für Deine Antwort!
Hallo Kollegen,
programmiere gerade an einer Anlage, welche so taktzeitkritisch ist, dass ich diese Frage stellen muss (Suche hat für mich nichts zu Tage gebracht):
Ist es denkbar, dass der Roboter eine Bewegung überschleift, auch wenn dazwischen ein Programmaufruf der cell steht? 
Momentan legt der Roboter dort nämlich ein sattes Ruhepäuschen ein. 
meine Wunschvorstellung:
- Roboter steht in Home
- Programm 1 wird mittels cell gestartet
- Roboter verrichtet fleißig seine Arbeit
- Roboter fährt nach Home (letzter Bewegungspunkt im aktiven Programm)
- Während der Fahrt nach Home wird die cell durchlaufen und startet ein neues Programm (kann aber auch wieder Programm 1 sein)
- Home wird ganz prima überschliffen und es wird fortgesetzt mit erstem Punkt aus neu angewähltem Programm
Von einem Kollegen habe ich gehört, dass er mit einer vereinfachten (selbstgeschriebenen) cell arbeitet, mit der das möglich ist. Kann ich mir schon vorstellen, möchte ich aber versuchen zu vermeiden...
Danke!
Alles anzeigen
Zeitraum 1 =
Von dem Zeitpunkt an dem Roboter1 die Zeile "WAIT FOR Rob1_Freigabe_Bereich_1 CONT" verarbeitet,
über die Zeit bis Rob1_Aus_Bereich_1=false bei der SPS ist,
bis zu dem Zeitpunkt wo Rob2_Freigabe_Bereich_1 = false beim Roboter2 angekommen ist.
Zeitraum 2 =
Von dem Zeitpunkt an dem Roboter2 die Zeile "WAIT FOR Rob2_Freigabe_Bereich_1 CONT" verarbeitet,
über die Zeit bis Rob2_Aus_Bereich_1=false bei der SPS ist,
bis zu dem Zeitpunkt wo Rob1_Freigabe_Bereich_1 = false beim Roboter1 angekommen ist.
Wenn sich Zeitraum1 und Zeitraum2 minimal überlappen fahren beide. Das passiert mit hoher Wahrscheinlichkeit irgendwann mal, also genügt das nicht als Verriegelung.
Auch Dir vielen Dank!
Das hat mir einiges verdeutlicht. Ich erkenne jetzt auch den negativen Einfluss einer hohen SPS-Zykluszeit bei der Thematik. 
Bleibt für mich die Frage: Wie kann ich es sicher machen? Die Anwsenheit des jeweils anderen Roboters im Bereich ist nunmal das einzige Kriterium die Freigabe zu entziehen.
Das Problem hatte ich überhaupt nicht auf dem Schirm.
EDIT: Dein Vorschlag werde ich mir morgen früh mal genauer anschauen. Danke für deine Mühe!
Danke erstmal für Deine Antwort!
der Fehler tritt immer wieder auf => Zykluszeit der SPS.
Das hätte ich jetzt ehrlich gesagt am wenigsten erwartet. Ich sehe den Einfluss selbst einer sehr hohen Zykluszeit hier nicht als Ursache an. Kannst Du mir das bitte erklären. Ich würde das sehr gern verstehen.
Zitatwürde auf alle Fälle mal die Gegenseitigen Signale in einem Interrupt überwachen, und die Roboter damit stoppen.
So ist auch ein Eingriff eines Bedieners abgesichert.
Sollten beide Roboter gleichzeitig im Bereich sein entzieht die SPS die Fahrfreigabe. Es hat ja auch noch nicht geknallt. Nur das kann nicht die Endlösung sein, weil der Prozess gestoppt wird.
ZitatMir ists am liebsten wenn die SPS ein Einfahrsignal für jeden Roboter sendet, das kann der SPS-Programmierer dann gegenseitig verriegeln.
Das ist der Status-Quo. Jeder Roboter hat natürlich seine eigene Einfahrfreigabe von der SPS...
ZitatOder du schickst zwischen den Roboter ein Signal welche Ablage der jeweilige Roboter bedient und riegelst nur den gefährlichen Bereich ab.
Ein Bereich zwei Roboter. Das ist nunmal das Problem... Da ist nicht genug Platz für beide.
Hallo Forum,
habe mal wieder ein Problem, bei dem ich Hilfe gebrauchen könnte.
Weiß nicht, ob es am Robi (z.B. Vorlaufzeiger), der SPS oder dem Profibus (Latenz) liegt.
Zwei Robis sollen in den selben Bereich einfahren. Der eine legt Teile auf eine Zwischenablage/einen Puffer (hier vier Teilenester), der andere entnimmt sie von dort. Prinzip soll sein: [glow=red,2,300]Wer zuerst kommt malt zuerst...[/glow] Der entnehmende Roboter hat eine etwas schnellere Taktzeit und baut somit den Teilepuffer ab.
Momentanes Problem ist, beide denken manchmal sie kämen zuerst, nämlich dann, wenn sie scheinbar gleichzeitig die Einfahrfreigabe einholen (kann schon mal zufällig trotz ungleicher Taktzeit geschehen). Die Nester liegen so dicht neben einander, dass im ungünstigsten Fall eine Berührung der Roboter möglich ist!!!
Roboter-Programm für Robi1 (in der Struktur identisch für beide Roboter)
WAIT FOR Rob1_Freigabe_Bereich_1 CONT
OUT Rob1_Aus_Bereich_1 State=FALSE CONT
...weiterer Programmablauf im Bereich...
SYN OUT Rob1_Aus_Bereich_1 TRUE at END Delay=0
PTP Aus_Bereich_1 CONTSPS-Programm für Robi 1 (ebenfalls für beide identisch)
UND Rob2_Aus_Bereich_1
= Rob1_Freigabe_Bereich_1Das Problem ist wie gesagt die Gleichzeitigkeit. Wenn der eine etwas später als der andere den Bereich anfordert, geht alles sicher von statten.
Seht Ihr ein Problem in meiner Programmierung? Habt Ihr Hinweise für mich?
Vielen Dank!
Deiner Schilderung zufolge, öffnet jetzt bereits der Instant Player. Das ist schon die halbe Miete. Dann kopiere einmal den folgenden Befehl in die Konsole (mit der rechten Maustaste)
> "%JAVADIR%\bin\java" -cp "%SIMUKR6DIR%\visu;%PLAYERDIR%\bin\instantreality.jar" kr6
Was passiert?
In der Konsole erscheint die Meldung: MFJ Arm Server
...dann ein paar Sekunden Stille...
...und dann kommt eine Fehlermeldung: java.lang.Error: please start vrml viewer first at kr6.main(kr6.java:107)
Sorry für die sehr späte Antwort.
Alles genau so wie Du sagst, nur die in 5) erwähnte Konsole erscheint nicht?
DAS ist ja stark!
Lustig, ganz genau das selbe wollte ich auch schon mal realisieren, bin aber leider an der crosscom gescheitert...
Finde ich auch klasse, dass der Quellcode gleich mit dabei ist, so könnte ich es mir vielleicht noch selbst beibringen eine Schnittstelle zu programmieren.
Also ganz großes 
an alle Beteiligten!
ABER: Trotz scheinbar richtiger Einstellungen (.bat) bewegt sich das Ärmchen leider nicht. Ports der Firewall müssten auch offen sein.
Danke für die Zusammenfassung! 
Hab ich auch wieder was neues gelernt.
Ist die Bewegung an der das Problem auftritt in irgendeiner Art und Weise berechnet, bzw. die Base oder so...
nö, alles nur schnöde Teachpunkte und nichts Berechnetes...
Es scheint letztendlich das Powermodul gewesen zu sein.
Seit dem ich das gestern morgen getauscht habe läuft er ohne Unterbrechung durch. Eine Chance geb ich dem ausgebauten Teil noch, wenn ich dazu komme es in einer anderen Steuerung im Haus zu testen. Sonst geht es zur Überholung.
Ganz schön nervig diese Art von Fehler...
Danke nochmal für Eure Unterstützung!
Hallo,
vermute mal, dass du die Stoßbewegungen (hin und rück) im TOOL Koordinatensystem fahren musst und nicht im BASE. Hab das damals auch schon mal gemacht, bekomme es ohne Nachschlagen jetzt aber nicht hin es hier zu beschreiben 
. Das Forum bietet zu dem Thema aber auch einiges...
EDIT: guckstu hier
http://www.roboterforum.de/rob…inatensystem-t5981.0.html
Sind irgendwelche Momenteüberschreitungen (Momentüberwachung) programmiert?
Wo könnte das passiert sein?
In der sps.sub und dem Bewegungsprogramm wurde jedenfalls nichts dergleichen programmiert...
Systemintern wird es das ja wohl irgendwo geben (Überlastmeldungen hatte ich schon mal - jedoch NICHT in diesem Fall, sondern an einer anderen Anlage).
