Posts by Hermann

    Eine Idee wäre noch das Null-Modem-Kabel als Fehlerquelle. Im Handbuch scheint das sehr umfangreich durchkontaktiert zu sein - ich kann nicht ausschließen, dass meines eher ein simples mit einfacher Kreuzung ist.

    Ich kann zum Roboter selber gar nix sagen. Aber zu meinen steinalten Erfahrungen von annodazumals mit seriellen Schnittstellen.

    Da war ganz allgmein recht häufig in der Verschaltung des Kabels der Hund begraben. Da würde ich mal als erstes suchen.

    Es war gang und gäbe, dass man einfach RTS mit CTS sowie DTR mit DSR gebrückt hat, dann gibt es zwar keinen Handshake mehr, ist aber kein Problem, wenn man eh alles von Hand eingibt, die heutigen Rechner sind eh so schnell, dass der bei 9600bd keinerlei Probleme hat.

    Genau, die Klammern sind unnötig, stören den Compiler/Interpreter nicht, weil syntaktisch korrekt.

    man könnte z.Bsp. auch schreiben:

    nIrgendwas := (100)+(20)*(10);

    sollte auch als korrekt angesehen werden. Sieht halt blöd aus und ist unnötig.

    So richtig parallel ist das ja nicht. Man schaltet halt zwischen verschiedenen Profilen um. Aber es funktioniert ganz gut, nervt nur oft, weil man meist erst beim Öffnen des Projekts merkt, dass noch das falsche Profil aktiv ist, dann muss man wieder schließen, Profil aktivieren, und dann glaube ich noch WoV neu starten.

    Nicht raten, nachdenken: Du hattest das Programm ablauftechnisch doch schon komplett richtig, das einzige Problem war, dass die Laufvariablen (Ebene,Reihe,Spalte) schon in der Berechnung oberhalb der Hauptschleife verwendet wurden. Dadurch verlieren die ihren Wert, bei dem das Programm evtl. abgebrochen wurde. Um das zu umgehen muss man einfach in der Berechung der Positionen komplett andere Variablen verwenden, die nichts mit der Hauptschleife zu tun haben. Das ist schon der ganze Zauber.

    Noch einfache wäre es nur die gerade benötigten 3 Positionen jedes mal innerhalb der Hauptschleife zu berechnen. Dann bräuchte es kein so großes Punktearray und das Problem mit den Variablen hätte sich auch quasi von selbst erledigt.


    Also z.Bsp. so:


    So, und dann kommen noch roboterspezifische Dinge dazu. Z.Bsp. dass man normalerweise nicht im Base[0] fährt, sondern bei einer Palettierung ein venünftiges Base vermisst, und dann die Punkte auch in diesem Base anfährt. Dann fehlt in dem Programm vor dem Abfahren der berechneten Punkte die Anwahl des richtigen Base! Und es fehlt das Setzen der richtigen Geschwindigkeiten. ....


    Wie schon gesagt: die Programmierung muss nicht an einem Roboter gelernt werden. Meiner Meinung nach ist es viel einfacher erst mal (oder auch parallel) mit der Programmierung am PC anzufangen. Das geht auch während Corona, und es gibt für alle möglichen Entwicklungsumgebungen sehr viele, gute und kostenlose Online Tutorials. Ebenso gibt es kostenlose Entwicklungsumgebungen wie Visual Studio (für Basic, C#) oder Lazarus (für Pascal).

    Empfehlungen für KUKA Roboter Programmierschulungen kann ich persönlich keine geben. Diese grundlegenden Programmiertechniken hatte ich schon einigermassen drauf, als ich mit der Programmierung von Robotern angefangen habe, da gab es noch nicht mal die KRC1.

    Weil bei uns heute Feiertag ist:


    Ich habe sowas leider noch nie gemacht!

    Naja, das ist keine richtige Entschuldigung, hoffe mal Du bis noch jung, dann hast ja noch Zeit sowas zu lernen ;). Denn man kann nicht alles schon mal gemacht haben, und dann bei einer Aufgabe die Lösung fertig in der Schublade/Kopf haben. Was man haben kann sind die Kenntnisse und Werkzeuge um eine neue Aufgabe zu lösen, in diesem Fall sind das grundlegende Programmierkenntnisse über Algorithmen, Daten- und Programmstrukturen, logisches Denken, Abstraktionsvermögen, Übung .....

    In diesen Fällen empfehle ich immer einen 'Progammierkurs' (wie auch immer der aussehen mag) in Basic, Pascal, C# oder auch C auf einem PC. Da ist es viel einfacher solche Programmiermethoden zu lernen und zu debuggen, und es gibt sehr viel mehr und ausführlichere Ressourcen als über roboterspezifische Programmiersprachen.

    Denn die Schwierigkeiten die Du da hast sind nicht roboterspezifisch, die stellen sich auch bei den oben genannten Programmiersprachen.

    Genau, aber du musst dir etwas überlegen, wie / wo diese Variablen dann für die nächste Palette wieder initialisiert werden. Z. Bsp. am Ende, da wo sie bisher auf die Maximalwert gesetzt werden. Das macht eh keinen Sinn.

    Und ausserdem musst du in der Berechnung der Vorpositionen andere Zählervariablen verwenden, sonst werden die ja dort schon mit neuen Werten überschrieben.

    Ändert trotzdem nix.

    Da gibt es Insiderwissen das der Allgemeinheit, in der dargebotenen Form nichts bringt.

    Macht mir persönlich nichts aus, aber wenn später mal jemand nach Profibus Problemen im Zusammenhang mit EWM sucht, kann das dann doch verwirren.

    Daher die Bemerkung.

    Nur als Hinweis:

    Das Posten der aktuellen Konfig hättest Dir sparen können. Der Informationswert geht gegen Null. Das einzige was man sieht, ist, dass ihr eine komplett neue Profibuskonfiguration erstellt habt. Da es unwahrscheinlich ist, dass jemand das selbe Setup hat / haben wird, bringt's halt nix, zumal die Boeckmann.ldb fehlt.

    Gruss und ein gutes neues Jahr.

    Jaja, lang ist's her, ich hatte da noch irgend welche 9poligen Stecker an der Vorderseite der Vertärker im Kopf. Kann sein, dass das die Programmierschnittstelle war. Mit der Zeit vergiss man sowas, dürfte schon bald 20 Jahre her sein, dass ich den letzten gesehen habe.

    Da hab' ich dann auch keinen weiteren Hinweis mehr.

    Die Servovertärker stammten soweit ich mich erinnern kann einst ursprünglich von Moog (kann aber sein, dass sich auch diese Info im Laufe der Zeit irgendwie verselbständigt hat, mit der Entsorgung der schriftlichen Unterlagen habe ich wahrscheinlich auch gleich im Oberstübchen aufgeräumt :)).

    Ja genau, das macht wirklich 0.0 Sinn. Wäre auch viel besser zu konfigurieren, denn die wenigsten Greifer / Werkzeuge sind rund/kugelförmig.


    War aber wohl zumindest bei der Krc2 so, ob das bei der KRC4 immer noch so ist weiss ich nicht, da hab' ich mal das Gegenteil gehört, leider noch nicht selbst getestet. Aber eine bessere Erklärung für das Problem fällt mir auch nicht ein.

    Wo hast du den denn ausgegraben? ^^

    Die Fehlermeldungen deuten auf ein Kommunikationsproblem zu den Servoverstärkern hin, die sind per Can Bus mit der Steuerung verbunden. Also erst mal da die Leitungen checken.

    Ganz ohne PIC Programm wirst du die Kiste aber nicht wirklich zum Laufen bringen Laufen bringen. Das verbindet die externen Signale mit denjenigen der Robotersteuerung.

    Hatte ich wohl übersehen, aber "MACID" (heisst so bei Devicenet, bei Profibus eher Adresse) 1 ist ziemlich ungewöhnlich.

    Aber wenn man genau hinsieht, dann erkennt man, dass der Slaveteil die Adresse 1 hat (MODUL_ADDRESS=1 in der pfbms.ini, heisst das nicht MODULe_ADRESS?).

    Da hat der unbekannte Erhard wohl den Master und Slave des Roboters auch noch direkt miteinander verbunden.

    Kann man z. Bsp. zur internen Steuerung des Automatik Extern Betriebs verwenden.

    Da fehlt dann aber auch noch ein Eintrag der Form:

    Code
    INB10=127,0,x3
    OUTB10=127,0,x3

    Das bindet dann den internen Slave noch mit ein.

    Also müsste die Profinetleitung vom Masteranschluss auf den Slaveanschluss des Roboters und dann zur EWM gehen.

    Konfiguration des Profibus Master. Aber der scheint ja schon passend zu sein. Zumindest ist da was konfiguriert, und im Kommentar steht ja auch was von EWM dabei.

    Bei manchen Steuerungen war der auf der Festplatte D vorhanden.

    Man kann auch den S7 Manager von Siemens (also das S7 SPS Programmiertool) hernehmen. NCM Manager ist davon ein kleiner Teil.

    Scheint als ob da die EWM schon konfiguriert ist. Die E/A sind da ab Nummer 41/57 zu finden.

    Ausserdem ist da noch der Slave im Roboter aktiv, d. h. es ist noch ein anderer Master beteiligt.

    Roboter dürfte schon mal in dieser Konfiguration irgendwo eingebaut gewesen sein.

    Also eigentlich immer noch zu wenig Infos.

    Im Prinzip dürfte da nur eine Profibus Leitung zwischen Roboter und EWM eingebaut werden müssen, und das Module_used auf 0 gesetzt werden.