Beiträge von Matu

Hallo zusammen,

ich habe schon einiges recherchiert und auch hier im Forum ein wenig herumgestöbert, aber noch nicht ganz die passenden Antworten zu meiner Frage gefunden...
Daher hoffe ich, ich darf das gesammelte Crowd-Wissen bzw. die Erfahrung des Forums abfragen

Mich beschäftigt die Frage, ob es ein alternatives Simulationssystem gibt, dass eine ähnliche Komponentenbibliothek wie KUKA.Sim / Visual Components besitzt, mit der man sich bei vielen Simulationsaufgaben wirklich auf die reine Robotersimulation konzentrieren kann und einige Dinge wie z.B. Conveyor nicht mehr selbst erst erzeugen muss, um Werkstücke damit in Bewegung zu bringen u.Ä.
Optimal wäre das Tool dann noch für die Offline-Programmierung von diversen Robotertypen nutzbar

Bei vielen Anbietern finde ich zu solchen Komponentenbibliotheken, die über die unterstützen Roboter hinausgehen, leider nicht viele bis keine Angaben. Bei den meisten müsste man sich einen Termin für eine Online-Demo reservieren, um einen besseren Einblick zu erhalten.

Ich hoffe, da bin ich schneller am Ziel, wenn vielleicht dem ein oder anderen hier schon etwas Entsprechendes über den Weg "gelaufen" ist. Auch wenn ihr meint, eine vergleichbare Komponentenbibliothek gibt es sonst nicht, wäre diese Info auch hilfreich.

Vielen Dank vorab für eure Beiträge.

Markus

Hallo,

bei drei KRC4 compact mit KR3-Robotern erscheinen folgende Fehlermeldungen:
KSS26014 allgemeiner Versorgefehler (1). Verursacher: Antrieb
KSS26150 Hardware-Fehler (Supply) (1). Verursacher: Antrieb
Nach dem Quittieren der Fehler in T1/T2 laufen die Roboter normal.

Bei drei weiteren KRC4 compact mit KR6-Robotern erscheinen diese Fehler nicht.

Hat jemand eine Idee, woher die Fehlermeldungen rühren könnten und wie sie behoben werden können?

Vielen Dank vorab für eure Unterstützung!

Das kann ich bestätigen.
Den ersten Thread in einem von mir eröffnetem Thema kann ich einen Tag später nicht mehr bearbeiten und somit den Status auch nicht von [offen] auf [gelöst] setzen.

Danke für den Tipp!
Mit Offset = INV_POS(P1):P2 hat es geklappt

Hallo,

ist es möglich, den geometrischen Operator so zu verwenden, um mit ihm quasi rückwärts zu rechnen?

Mein Ziel:
Ich habe zwei Punkte P1 und P2.
Nun möchte ich den Offset ermitteln, um im Tool-Koordinatensystem von Punkt P1 nach P2 zu fahren.
Oder anders ausgedrückt:
Die Rechnung P1:Offset soll wieder P2 ergeben.

Vielleicht hat jemand eine Idee, wie man das mit dem geometrischen Operator selber hin bekommt, ohne selber viel mit Sinus/Cosinus-Funktionen rechnen zu müssen...

Danke schon mal vorab!

Markus

Hallo Karl,

vielen Dank für Deine Antwort!
Wenn man einen Achsraum als Schutzraum definiert, bei dem beispielsweise für A1 der Bereich 90-100 Grad und für A2 -30 bis -10 Grad parametriert wurden, müsste der Raum verletzt sein, wenn beide Achsen in den angegebenen Bereichen liegen - sie hätte ich es erwartet und auch deine Antwort so verstanden.
Ich erhalte aber bereits eine Raumverletztung, wenn eine der Achsen den entsprechenden Bereich "betritt", d.h. wenn z.B. Achse A1 die 90 Grad erreicht, stoppt der Roboter - unabhängig von der Position von Achse A2!!
Demnach wären nicht nur die einzelnen definierten Schutzräume "oder-verknüpft", sondern auch die einzelnen parametrierten Achsen innerhalb eines Schutzraumes...
Bisher hatte ich nur SafeOperation und dort bis auf eine Ausnahme (bei der nur eine Achse überwacht wurde) auch nur kartesische Überwachungsräume verwendet, daher bin ich aufgrund des jetzt erhaltenen Verhaltens etwas "verwirrt"...

Gruß,
Markus

Hallo zusammen,
ist es korrekt, dass bei SafeOperation bzw. SafeRangeMonitoring bei der Definition eines Schutzraums als Achsraum nicht etwa überwacht wird, ob jede der konfigurierten Achsen im angegebenen Achsbereich steht, sondern bereits bei der Verletzung einer der Achsbereiche bereits der Schutzraum als verletzt gilt?
Dann würde ich mich ja fragen, wofür man bei SafeRangeMonitoring 16 Überwachungsräume definieren kann. Theoretisch würden dann ein oder zwei Räume reichen, um ggf. alle sechs Achsen (ausgehend von einer Anlage ohne Zusatzachsen) zu überwachen, da eine Konfiguration eines einzigen Raumes mit Parametern für alle Achsen bereits die komplette Überwachung liefern würde - sobald die Grenze für eine Achse erreicht ist, wird gestoppt, somit kann man auch keine weitere Grenze in gleicher Achsrichtung definieren...

Die Überwachung wäre somit eigentlich mit den Softwareendschaltern gleichzusetzen.
Würde auch bedeuten, dass SafeRangeMonitoring nicht ausreicht, wenn in einer Zelle überwachen werden soll, dass in einem kleinen A1-Bereich A2 nicht weit "ausgeklappt" werden darf, sonder selbst dafür schon ein kartesischer Schutzraum mit SafeOperation angelegt werden müsste...

Hallo,

auch wenn das Thema schon etwas älter ist, hänge ich mich hier kurz mal rein, da die ursprüngliche Frage (zumindest in meinen Augen) noch nicht hinreichend beantwortet ist

Es wurde ja bereits geschrieben, dass die GSD-Datei auf der WoV-DVD nicht die richtige für Step 7 für die Beckhoff-Module ist.
Ist es dann korrekt, dass sowohl dann in WoV als auch in Step 7 die gleiche GSD-Datei (EL31095F.GS*) eingebunden werden muss, oder gibt es für die Step 7-Seite noch eine weitere Datei?

Danke,
Matu

Hallo zusammen,

wir bieten einen kaum gebrauchten (nur wenige Stunden tatsächliche Betriebszeit) Kawasaki Palettier-Roboter FD050N-C zum Verkauf an.

Details können der beigefügten Datei entnommen werden - weitere Fragen werden gerne beantwortet.
Besichtigung ist nach Absprache selbstverständlich auch möglich.

Preis VB.

Hallo zusammen,

ich habe grade gesehen, dass auf dem KUKA Hotline-FTP-Server mittlerweile WorkVisual v2.4.5 Build 91 verfügbar ist.

Hat schon jemand eine Info, welche Fehler hiermit ausgebügelt werden und was es ansonsten für Änderungen gibt?

Gruß,
Matu

Sagt ja auch keiner, dass man eine SPS braucht - wäre ja auch nicht ausreichend, da man die Sicherheitskreise immer zweikanalig schalten muss, insofern hängt meistens ein PNOZ o.Ä. am X11

Aber ein Sicherheitsrelais ist meiner Meinung was anderes, als Sicherheitskreise zu brücken - und letzteres soll bzw. darf laut KUKA (s. den verlinkten Beitrag von K(A)RL in meinem Beitrag oben) nicht mehr mit einem Brückenstecker gemacht werden, dazu gibt es jetzt halt extra den Inbetriebnahmemodus...
Möglich ist es auch Not-Halt-Kreise etc. zu brücken - darf man aber halt eigentlich nicht.

Ich glaube, AtoK09 meinte den "X11-Brückenstecker", nicht "X11" im allgemeinen

Somit bliebe also nur eine Prüfung per SPS.sub... Was allerdings absolut unzureichend ist, da man Positionen auch in T2 anwählen und anfahren kann, wenn der Submit-Interpreter nicht läuft...

D.h., die Kundenvorgabe, T2 sicher zu deaktivieren, kann somit ohne ProfiSafe und externer SPS nicht umgesetzt werden, ist dies korrekt?

hervorkram....

Gibt es bei der KRC4 überhaupt eine Möglichkeit, T2 ohne ProfiSafe und externer SPS zu deaktivieren, d.h. auch nicht irgendwo versteckt die Möglichkeit, T2 bei der Betriebsartenanwahl einfach auszublenden??

Gruß,
Matu

Eigentlich sollte nur noch der Inbetriebnahme-Modus verwendet werden!

Siehe auch den Hinweis von K(A)RL hier: http://www.roboterforum.de/rob…perren/msg52730/#msg52730

Gruß,
Matu

Ärgerlich ist schon alleine die Zeit, die man so verliert. Die Rekonfiguration dauert ja jedesmal eine ganze Zeit...

Kennt jemand eigentlich irgendeine Möglichkeit, solche Fehler an KUKA zu melden, oder geht auch das nur über die normale technische Hotline...?

Hallo,

ich habe hier ein blödes Problem und wollte einfach mal bestätigen lassen, ob es generell auftritt, oder nur bei mir

Ersteinmal die Voraussetzungen:
- WorkVisual 2.4.3 Build 78
- Roboter im Projekt der Steuerung zugewiesen
- Maschinendaten in SafeOperation (lokal) importiert

Wenn ich das Projekt direkt von der Steuerung öffne und dann ein Vergleich lokal - Steuerung durchführe, dann ergeben sich logischerweise (so gut wie) keine Unterschiede - zumindest nicht gravierendes.
Nehme ich dann allerdings nur eine kleine Änderung an irgendeiner Programmdatei vor und lasse den Code erzeugen (passiert ja auch bei jeder Übertragung zur Steuerung), dann haben sich automatisch folgende Dateien geändert:

Config:\User\Common\Mada\SimuAxes.xml
Config:\User\Common\Mada\NextGenDriveTech.xml
Config:\User\Common\Mada\KRCAxes.xml
Config:\User\Common\Mada\CFCore.xml
Config:\User\Common\Mada\SimuAxesKrc.xml
Hier werden jeweils nur in einer einzigen Zeile der Hinweis geändert, dass die Datei durch WorkVisual erstellt wurde - mit Datum und Zeit (und somit dann anders als auf der Steuerung).

Weiterhin noch die KRC:\R1\Mada\$machine.dat
Hier werden einfach vor allen Kommentaren die Leerzeichen entfernt! Wieder eine Änderung gegenüber der Version auf der Steuerung.

Das Ergebnis:
Bei jedem Übertragen stellt die Steuerung fest, dass sich diese Dateien geändert haben. Das bewirkt aber dann jeweils eine Rekonfiguration und damit ein Not-Halt.
Bedeutet, alle im Roboter-Not-Halt verkettete Maschinen bekommen ebenfalls Not-Halt!!

Das kann natürlich ganz dumm sein, wenn eine der Maschinen grade läuft und man mal nicht dran denkt - grade bei Werkzeugmaschinen kann es bei einem Not-Halt dann auch schon mal zu einem Werkzeugbruch führen.
Prinzipiell sollte ein Not-Halt natürlich für keine Maschine ein Problem sein, aber hier wird es wirklich absolut unnötigerweise durch einen Fehler in WorkVisual hervorgerufen, oder sehe ich das falsch?

Gruß,
Matu

Schon etwas her, aber ich komme erst jetzt dazu, wieder zu antworten

Das kopieren des Programms, um dann Positionen neu zu teachen, ist auch nicht das eigentliche Problem...

Aber der Bediener muss dann auch noch den Programmcode anpassen, in dem per Dialog der gewünschte Typ ausgewählt werden kann und das entsprechende Programm dann aufgerufen wird - das wollte ich eigentlich dem Bediener ersparen

Die Auswahl benötige ich, da bei Umschalten auf Automatikbetrieb ($EXT) beim Kunden Standard ist, dass dann auch das Programm angewählt wird, wenn es noch nicht angewählt ist.
Wenn je nach Typ ein anderes Startprogramm existiert, dann klappt das nicht...

Gruß,
Matu

Hallo,

ich habe mal eine ganz ausgefallene Frage (betrifft KRC4):

Ist es irgendwie möglich, Programme (mit zunächst unbekanntem Programm-/Dateinamen) in einem definierten Verzeichnis zu suchen um dann diese gefundenen Programme über deren Namen mit Parameterübergabe aufzurufen (Also sowas wie "CallByName" )?

Der erste Teil dürfte noch zu machen sein, ich meine, ich hätte mal etwas von entsprechenden Dateifunktionen gelesen... Aber danach wird es vermutlich unmöglich, oder kennt jemand einen Weg?

Kurz noch zum Hintergrund: Ich möchte für den Bediener quasi eine Komfortable Auswahl von Werkstücktypen vornehmen.
Dazu soll der Anlagenbetreiber einfach für neue Werkstücke vorhandene Programme kopieren, die ausschließlich Teachpositionen enthalten, die in diesen Programmen dann entsprechend umkopiert werden, damit sie im eigentlichen Ablauf verwendet werden können.
Die Betreiber müsste dann nur nach dem Kopieren diese Positionen entsprechend neu teachen.
Außerdem würde er in den jeweiligen Programmen eine Variable mit der Typbezeichnung ändern.

Diese Programme sollen dann per Parameter entweder dazu veranlasst werden, die Typbezeichnung zurück liefern (um daraus per Dialogmeldungen die Typauswahl zu ermöglichen), oder eben die Teachpositionen umkopieren.

Gruß,
Matu

Hmm, und wenn man kein PROFIsafe hat sondern die X13-Schnittstelle verwendet?
Hier kann man zwar auch die Räume so verwenden, dass die sicheren Ausgänge am X13 geschaltet werden, aber bekommt man das dann "intern" auch irgendwie mit?