Beiträge von ottosieben

Moin,

sowohl der Wellendichtring als auch die Getriebeeingangswelle lassen sich ohne Demontage des Karussells wechseln. Grüße

Moin,

wie Fubini schon schrieb, läuft die Steuerung komplett auf der Ramdisk. ALLES wird dahin geladen. Macht aber das System. Das Anlegen von Programmen auf WINDOWS-Ebene ist nicht zulässig. Alle Änderungen müssen auf HMI Ebene des Systems gemacht werden, die KRC sorgt im Hintergrund dafür, dass die Änderungen auf die Festplatte geschrieben werden. (Sicherung) Von dort wird dann z.B. beim Einschalten auch ALLES geladen. Modifiziert man Daten auf der Windows-Ebene , wird das System inkonsistent, da umgekehrt Änderungen auf der Festplatte nicht zur Ramdisk synchronisiert werden. Das ist auch nicht vorgesehen.

Moin,

wenn's so einfach ist, mache es.

Ich würde von dem Klump die Finger lassen. Die Steuerung sieht sehr nach einem Vorläufer der KRC1 aus, also mindestens 20 Jahre alt. Ebenso alt ist vermutlich auch der Manipulator. Die Elektronik ist wahrscheinlich komplett Schrott, beim ersten Einschaltversuch wird es unter Umständen ordentlich rauchen. Der Manipulator braucht bestimmt einen Ölwechsel, eventuell vorhandene Zahnriemen sind versprödet, ebenso die Motor- und Geberleitungen. Eventuell haben die Motoren durch die Lagerung im Freien (Plane hin oder her) schon Isolationsfehler. Vor Korrosion an Steckern und Motorwellen ist man hier auch nicht mehr sicher.

Eine eigene Steuerung dafür zu kreieren setzt konkretes Wissen über die Hardware des Manipulators voraus.

Viel Erfolg

Moin,

ich würde davon abraten die globalen Punkte über verschiedene .dat zu verteilen. Irgendwann verliert man den Überblick, was wo deklariert ist. Die zentrale Verwaltung ist da einfacher zu warten.

Moin.

Solche Effekte habe ich auch noch nie beobachtet. Sehr merkwürdig. Lädst Du wirklich das geänderte, soeben aktivierte Projekt zurück nach WoV. (Bitte nicht schlagen, aber manchmal ist der Teufel ein Eichhörnchen... )

Moin,

vermutlich ist TCP Bestimmung gemeint. In dem Fall ist nicht der Roboter die bestimmende Größe für die Genauigkeit, sondern der Ausführende. Wobei, ich kann mich irren, ein KR210 mit einer 180kg Schweisszange für mich schon andere Fragen aufwirft, welche das Ergebnis der Vermessung negativ beeinflussen können. Ist mit dem Roboter und dieser Zange mal eine Lastdatenermittelung durchgeführt worden?

Moin Hermann,

dann korrigiere ich den Satz mal auf "einen Daimler Standard". Mir sind bisher auch nur Powertrain und Integra untergekommen. Es sei nicht unerwähnt, dass dies beschriebene Prozedere auch schon zu Zeiten der KRC2 so in den "mir bekannten Daimler-Standards" eingebaut war.

Und: Für einen Automatikstart braucht es eine SAK Bedingung, auch wenn diese nur dadurch erreicht wird, indem die ohnehin aktuelle Position ohne jegliche Bewegung angefahren wird.

Also wird ohne Anwahl und anschliessendes "Anfahren eines Punktes" von Hand zur Erreichung der SAK Bedingung grundsätzlich nichts.

ToGe4811

Mir erschließt sich das Ansinnen Deines Kunden aber auch nicht. Warum muss denn die Betriebsart EXT überhaupt verlassen werden? Im Normalfall doch eher nicht, im Sonderfall schon. Aber im Sonderfall ist eben auch die SAK Fahrt eben doch kein Ereignis, welches es zu vermeiden gilt.

Moin,

PTP $POS_ACT wäre eine Lösung.

Ich möchte aber zu bedenken geben, dass ein derartiges Vorgehen erhebliches Crashpotential birgt, wenn die derzeitige Position eben nicht dazu geeignet ist, den nächsten Punkt kollisionsfrei anzufahren!

Das kann in der Konstellation IMMER der Fall sein, da die aktuelle Position auch von Hand angefahren sein kann.

Mir ist bekannt, dass der Daimler-Standard mit $POS_ACT beim Starten des Hauptprogramms arbeitet, wobei dann eine sofortige Prüfung der Position stattfindet. Die Prüfung bewertet den räumlichen Abstand der aktuellen Position zur HOME und verhindert bei Überschreitung der vom Programmierer festzulegenden Grenzwerte die weitere Programmabarbeitung. Der nächste Satz ist dann das automatische Anfahren von HOME. Die Grenzwerte sind natürlich stark abhängig von den räumlichen Gegebenheiten, so dass dieses Programm die Sache eher noch verkompliziert, wenn diese verletzt werden. Denn dann ist das Anfahren in die Nähe von HOME von Hand notwendig . (Zumindest, wenn man nicht weiss, wie man die Prüfung umgehen kann.)

Zitat von fe_001

Hello.

Aus eigener leidvoller Erfahrung möchte ich hier mal wieder drauf hinweisen, dass das Manipulieren von OV_PRO im Programm zu sehr gefährlichen Situationen führen kann!

Man stelle sich vor, jemand, der das Programm nicht kennt, soll mal eben was nachteachen.

Manchmal muss man dazu die Tür überbrücken und in EXT langsam laufen lassen.

Und plötzlich sagt das Programm: Attacke, 100%! -> Aua!!

Besser ist, die Variable $RED_VEL (= zus. Hintergrundreduzierung) für sowas zu verwenden!

Gruß, Frank

Alles anzeigen

Moin,

das ist ein nogo! Türen überbrücken haben schon einige mit dem Leben bezahlt.

Allerdings ist das Beschreiben von $OV_PRO auch sehr gefährlich, Crashgefahr beim Einrichten...

Moin,

wende Dich an den KUKA Service. Gib die Seriennummern der Geräte an und Du bekommst vom freundlichen Service die Ausstattungslisten speziell zum jeweiligen Gerät.

Grüße

Zitat von panic mode

austausch .. aber nur softwaremäßig...

Moin,

nicht nur Software. Die Hardware (also der KPC) musste teilweise auch schon ausgetauscht werden.

Betrifft nicht alle mit 8.2 ausgelieferten Steuerungen, aber einen Teil.

Das Upgrade von 8.2 auf eine höhere Version ist ausserdem (mit bestehenden Programmierungen) jedesmal eine Herausforderung, da u.a, in der 8.2 die MADA nicht Teil des WorkVisual Projektes waren. Die wurden da nach Schema der KRC2 noch auf der Steuerung selbst hineinkopiert. Solange keine Sonderkinematiken an der Steuerung hängen, ist das aber kein großes Problem. Sollte das nicht der Fall sein, braucht man für die Sonderkinematik noch die korrekten $ondermada-Katalogelemente. Insbesondere wenn Safeoperation o.ä. im Spiel ist.

Weiterhin stellte sich bei solchen Aktionen meist noch das Profinet quer, weil das Katalogelement für die Buskonfiguration aufgrund der anderen Treiberversion ein anderes ist. Da muss dann der SPSler auch noch dran. und, und, und

Ich habe in der Vergangenheit mehrerererere 8.2 - > 8.3 Upgrades durchgeführt. Jedesmal gab es etwas neues Unschönes...

Zeitaufwand meist zwischen 4 - 6 Stunden, bis es wieder produzierte. Aber bin auch nicht der schnellste

Nun ja,

die 8.6 wird eventuell nicht auf der Hardware aller 8.2er Steuerungen laufen. Da waren im Zuge von Upgrades von 8.2 auf 8.3 schon Austauschaktionen notwendig. €€€ Ist das Teil des Angebotes?

Moin.

Nur der Vollständigkeit halber die Frage. Ist der Roboter korrekt justiert?

Moin,

KSS 8.2.x , hochaktuell also.

Passiert das beim Fahren oder Anhalten? Eventuell ist da auch schon eine Bremse nicht mehr in Ordnung. Soll heißen, da rutscht mal was durch beim Stop.

Lastdaten sind i.O.? Könnte auch Auslöser sein (falsch berechnete Bremsrampe)

Zum Verhalten mit dem Zustimmtaster ist zu sagen, dass das normal ist. Das Loslassen des Zustimmtasters ist NICHT zum geordneten Anhalten geeignet, weil das einem Notstop gleichkommt. Die Antriebsenergie wird sofort ausgeschaltet, die Bremsen fallen sofort ein -> es erfolgt kein bahntreues Bremsen.

Moin.

Frage: Ist das eine neue Steuerung? Die Fehlermeldungen deuten darauf hin.

Wenn ja:

Pufferbatterien anschliessen (X305 auf der CCU)

Die Sicherheitskonfiguration muss noch übernommen werden.

Fi Schutzschalter? Standard FI geht nicht, Was ist den verbaut?

Bild 3 und 4 öffnet irgendwelche Links. Pfui!

Fazit: Erst BA lesen dann einschalten.

Zitat von Hermann

Das kannst komplett vergessen. FSoE heisst Fail Safe over Ethercat, das hat mit Profisafe nix zu tun.

Diese Fehlerbeschreibung in der was von FSoE steht ist zu allgemein gehalten, die gilt für Ethercat und Profisafe, da muss man dann noch den eigenen Verstand einschalten und die genannten Möglichkeiten, die für den verwendeten Bus nicht gelten selbstständig ignorieren.

Hast du es denn schon mal mit dem ACK_GL Block versucht, anstatt selbst an den Signalen rumzuschrauben?

Edit: der Fehlermeldung nach zu urteilen, solltest du noch mal die f_dest_addr mit der Safe-Id vergleichen. Und bei manchen Versionen kann man in der Konfiguration im Roboter die Profinet Version auswählen, da würde ich dann mal noch die andere Version testen.

Alles anzeigen

monGO

Den Hinweis von Hermann hatte ich bereits gegeben und möchte ihn nocheinmal wiederholen.

Die FSoE hat nichts mit Profinet zu tun!

Bitte lies einfach nocheinmal die Antworten. die bereits gegeben wurden.

Die Robotersteuerung ist Profinet-DEVICE (=Slave) gegenüber der F-SPS und wird die De-Passivierung nicht anfordern. Der CONTROLER (= Master) ist die F-SPS und muss die Depassivierung initieren.

Das diese nur über Signal-FLANKEN funktioniert ist beschrieben worden.

Eventuell ist es hilfreich, wenn Du den Link dieses Threads an den SPSler weiterleitest.

Moin.

Ich kenne KRL Mount nicht. Aber wenn ich mir die Pfadangaben anschaue, sieht das sehr nach einer Windowsfreigabe aus. Im Windowspfaden werden Backslashes verwendet, Du hast aber Slashes im Pfad.

Zitat

Heute habe ich nochmal mit einem SPS Spezie Telefoniert und er meinte es liegt definitiv am Teilnehmer (Krc4) , da der Teilnehmer gar keinen acknowledge request anfordert. Die Safety ID ist die selbe in der KRC4 und SPS und die FSoE Adresse kann ich nicht setzen , weil das Programm dann immer abstürzt.

Moin, die FSoE hat mit dem Profinet nichts zu tun.

Was heisst die KRC fordert keinen ' acknowledge request' an? Wann fordert diese keinen an?

Diese Aussage vom SPSler erinnert mich an einen Fall vor einigen Jahren , wo es ein ähnliches Fehlerbild gab. Die SPS ist Master und triggert den Slave , nicht umgekehrt...

Die Steuerung war also noch nicht eingeschaltet???

Moin,

die Fsoe im Profinet? Nein, es ist die SafetyID. Die ist an der Robotersteuerung auf 1 eingestellt.

Auf der PLC sind die Parameter F_Source_Add und F_Dest_Add zuständig. Ob diese Einstellung so aber funktioniert, kann ich nicht beurteilen. Ich habe diese Einstellungen schon mal gesehen und kann mich erinnern, dass der SPSler da ein wenig gewirbelt hat, bis es ging. Was schlussendlich die Ursache für die anfängliche Fehlfunktion war, kann ich nicht mehr sagen.

Aber checke mal: für den Roboter die RICHTIGE Gerätebeschreibungsdatei in die Hardwarekonfig eingebunden? WorkVisual liefert ja mehrere mit. Das KRCNexxt (Version) sowie die Steuerungssoftware (VKRC oder KRC + Version) sind die entsprechenden Parameter für die Auswahl. In der Hilfe von KRCNexxt sollte das genau stehen. Notfalls mit den Infos mal die Hotline anrufen , Mo-Fr 08:00 17:00 0821 797 1926.