Posts by Hermann

    Ja, auch die 'normale Bahnplanung' läuft auf VXWorks.

    Die ganzen roboterspezifischen Dinge laufen unter VXWorks, Windows stellt im Grunde nur die Bedienoberfläche zur Verfügung.

    .. Denn was ich so erfahren habe, arbeitet der Roboter das Programm in der KRL-Sprache nicht in Echtzeit ab. KUKA KRL läuft auf Windows...

    Da hast du falsche Dinge erfahren.

    Edit: Da war jemand knapp schneller :)

    Schöne Grüße an den Aufgabensteller:

    Die Aufgabe stammt aus einem anderen Jahrtausend. In Karel soll man schon lange keine Bewegungen mehr programmieren.

    Die Aufgabe lässt sich in TP vollständig lösen.

    Hilft dir jetzt auch nicht wirklich, aber es sind ja schon mal diverse Hilfestellungen in Form von konkreten Befehlen genannt. Da könnte man z. Bsp. in der Karel Doku danach suchen, da sind häufig Beispiele drin.

    Wie macht man sowas bei KAREL?

    Am besten gar nicht ;)

    Hintergrund dazu ist, dass man m. M. Karel wenn irgend möglich meiden sollte. Das ist kaum zu debuggen, Bewegungen sollten damit eh nicht programmiert werden (alter Bahnplaner). Ohne Quellcode, der meist irgendwann verloren geht, steht man komplett an der Wand.

    Es sei denn man möchte sich unentbehrlich machen oder eine Art Kopierschutz implementieren.


    Man kann den Ausgang, der da konfiguriert ist natürlich auch in Karel abfragen. Genauer Befehl fällt mir gerade nicht ein.

    Ohne Karel Handbuch wirst dich da eh schwer tun dich halbwegs schnell einzuarbeiten.

    Entscheidend ist zu wissen, dass man in der Konfiguration diese Referenzposition mit Achswerten und einem Ausgang dazu einstellen kann.

    Bei Kuka habe ich eine Referenzierung mittels Gabellichtschranke gesehen...

    Nein, das sind zwei induktive Sensoren in einem Gehäuse. Der Rest passt.

    Allerdings kann man die Konfiguration auch so ändern, dass ein Eingang über die Safe SPS verwendet wird, woher dieses Signal dann kommt liegt im Verantwortungsbereich des Anlagenbauers.

    Im Prinzip kannst da m. M. jeden x beliebigen Sensor hernehmen, von mechanischen würde ich da jetzt vielleicht Abstand nehmen, da die doch etwas anfälliger sind.

    In Deutschland könnte ich mir durchaus vorstellen, dass jemand auf die Idee kommt sowas wie einen sicheren Türschalter zu nehmen, und den passiven Teil am Roboter zu befestigen, damit auch ja alles extrem sicher und teuer wird.


    Was das jetzt alles mit der Änderung der Norm zu tun hat ist mir trotzdem ein Rätsel.

    Aber irgendwie müssen Studenten ja beschäftigt werden. 😁

    Ich bin raus.

    Da macht ihr euch zu viele Gedanken. Arbeitest du denn für einen Roboterhersteller? Dann vielleicht nicht.

    Es gibt auch Roboter, die sehr grosse Werkzeuge angebaut haben. Es wird bisher immer nur die Geschwindigkeit des TCP überwacht, bei grossen Werkzeugen gewährleistet das nicht, dass andere Teile des Werkzeugs höhere Geschwindigkeiten erreichen (bei Umorientierungen).

    M. M. dürften die internen sicheren Überwachungen der Norm genügen, wenn man die richtig konfiguriert, dann ist auch der Fall mit den grossen Werkzeugen abgehakt. Am Ende heisst das im Grunde doch nur, dass keine Roboter mehr ohne diese Sicherheitsfunktionen (safe move, dcs, safe operation...) verkauft werden dürfen.

    Da hat sich wieder mal die Lobby durchgesetzt, und sorgt für größeren Umsatz.

    Was sollten denn das für E/A's sein?

    Wenn da zum Beispiel Ventile geschaltet oder Sensoren abgefragt werden sollen, geht das problemlos ohne SPS. Einfach ein Busmodul mit dem entsprechenden Bus an den Roboter anschliessen, die Konfiguration entsprechend einstellen und fertig.

    Beim ABB ist, denke ich, aber auch CAN-Bus standardmässig möglich, da kann man die ABB-Module mit digitalen E/A's direkt anschliessen, sind einfacher zu konfgurieren.


    Busmodule für Profinet gibt es massenweise von allen einschlägigen Herstellern: Siemens, Balluf, Turck .....

    Also jetzt wird's ganz komisch.

    Dieses Wiest und Captron Zeugs ist zum exakten Vermessen des TCP gedacht, so dass die Anwendung (hier wohl Schweissen) technisch funktioniert. Das hat jetzt so ziemlich gar nix mit der Sicherheit (z.Bsp. die Geschwindigkeitsüberschreitung in T1) zu tun.

    Wenn das Werkzeug (Schweissbrenner) dermassen verbeult ist, dass die Sicherheit nicht mehr gewährleistet ist, dann funktioniert die Anwendung (Schweissen) doch sowieso schon lange nicht mehr. Keine Ahnung was Du da vor hast.

    Normalerweise geben die Roboterhersteller vor welche Sicherheitsvorkehrungen für die Sichere Überwachung einzuhalten sind. Und die sollte/muss man dann auch einhalten. Da gibt es Hersteller, da wird diese Kontrolle ein mal nach dem Einschalten gemacht, bei anderen zyklisch und bei manchen gar nicht. Sich selber da irgendwas zusammenzubasteln macht m.M. keinen Sinn.

    Fun fact: ich hab's sogar schon mal irgendwie geschafft, dass während der Anwahl des Cell-Programms durch die SPS.SUB der DirLoader noch dabei war, Dateien aus dem (virtuellen Windows-)Arbeitsspeicher (Verzeichnis R1 im Roboter) zu löschen. Dadurch wurde dann tatsächlich Windows zum Grundsystem asynchron, ohne dass die Steuerung es bemerkte, und es gab ein paar SEHR seltsame Effekt...


    Ich bin mit DirectoryLoader vertraut, weshalb ich es nicht mehr verwende..

    Jo, genau. Mir hat es schon gereicht die Anleitung zu lesen, und sofort gewusst, dass das Ding nie im Leben zuverlässig läuft.

    Einzige Möglichkeit sehe ich auch darin mit cwrite vorher zu versuchen die Datei zu öffnen.

    Wenn das Meldungen vom Kunden sind,

    würde ich da erst mal die Programme ansehen (ein aoa schicken lassen).

    Vielleicht haben die da diverse Kopien angefertigt, die man aber getrost löschen kann, oder sonst irgend welche 'Schweinereien' veranstaltet. Bei einer einzigen Maschine und 6 Typen muss das schon ein mächtig gewaltig kompliziertes Programm sein, um den Speicher zu füllen.

    Auf der krc2 heißt die Datei kuka_con.mdb, genaues Verzeichnis fällt mir gerade nicht ein, ist aber auf alle Fälle unter c:\

    Würde da halt ein Mal einen Bereich definieren, der übertragen wird und dann hoffentlich ausreicht.

    Alles andere ist zu viel Aufwand. Da bräuchte es eine weitere Schnittstelle. KRC Profinet ist afaik nicht fähig mit zwei Controllern gleichzeitig zu kommunizieren.