Beiträge von Programmiersklave

    Wobei es diese Funktionalität noch nicht so ganz lange gibt, soweit ich weiß. Aber mittlerweile mache ich mir auch nach diesem Muster ganze Funktionsbibliotheken.
    Bei den alten KRC2 ff. muss man halt auf ein Schema ausweichen, wie es heute noch in der BAS.SRC beispielhaft zu finden ist. Das ist auch ganz praktikabel, wenn auch für Funktionen weniger geeignet.


    Grüße,
    Michael

    Version der Software?


    1.) Neue Flash-Disk(?)
    2.) System erstellen (mit RobotStudio bei IRC 5 oder RobInstall bei S4C+ ... wenn noch älter, dann Boot-Disketten)
    3.) System einspielen ("booten")
    4.) Backup restore
    5.) falls nötig, Umdrehungszähler aktualisieren
    -> fertig.


    Grüße,
    Michael

    "Zeit" und "Druck" beim Fräsen ist mir unbekannt.
    Es gibt Fräserdrehzahl, Vorschubgeschwindigkeit und die Lage der Fräsbahn. Ersteres hat mit ABB nur zu tun, falls irgendein Analogausgang einen Umrichter beeinflusst. Die beiden Letzteren lassen sich problemlos ändern, sofern der Programmierer die Berechtigung hat.


    Grüße,
    Michael

    Das ist ein sehr ungewöhnlicher Wunsch, würde ich sagen. Tasks werden im System verankert.
    Was gibt es denn für Anforderungen, die man nicht mit unterschiedlichen Modulen, im schlimmsten Falle sogar dynamisch nachgeladen, erschlagen könnte?


    Grüße,
    Michael

    Ach, das war ja auch so'n Sch...., irgendwas hamma da vergessn.
    Wolltste mal meine neue Kreation in der Hinsicht testen? Sollte deutlich besser funktionieren und kann auch mehr. Schicke ich aber nur per Mail, ist 'ne Beta-Version und ästhetisch peinlich.


    Michael

    Nee, stoppt nicht alles. Das Programm läuft zuende, wenn es denn ein Ende hat, erst dann kann man zugreifen.
    Im Automatikbetrieb hat man auf die stehenden Tasks dann sofort vollen Zugriff und kann z. B. sogar den Robbi warmstarten. Ist natürlich auch eine Frage der Programmphilosophie - ich beende meine Programme gerne vollständig und lasse über die SPS "StartMain" machen. Das heisst, man kann zwischendurch (nach jedem Zyklus) die Gewalt über den Robbi an sich reißen. Auch der Stop-Button funktioniert ja ferngesteuert.


    Das Problem ergibt sich bei Optimierungsarbeiten "zwischendurch", das heisst, im mehr oder weniger laufenden Betrieb, vielleicht sogar bei verketteten Anlagen. Man will "mal eben" eine Änderung einspielen, die man vorher vielleicht offline programmiert hat. Im Zustand "Schreibzugriff im Automatikbetrieb" erkennt die SPS (und meistens auch der Bediener/Einleger) nicht, dass der Robbi gerade 'ne kurze Auszeit nimmt. Das führt bei schlecht programmierter SPS oder auch bei schlecht ausgebildeten Bedienern/Einlegern zu massiven Verwirrungszuständen, denen von dieser Seite durch hektischen Aktionismus begegnet wird: SPS-seitig durch Übertaktung z. B., bedienerseitig durch wildes Herumgedrücke auf irgendwelche Tasten, was dann auch wieder die SPS überfordert.
    Im interessantesten Fall läuft es dann auf einen Crash hinaus, weil das Startsignal seitens der SPS noch im Queue ist, inzwischen aber die Bedingungen völlig anders sind.


    Grüße,
    Michael

    Vielleicht sollte man im Hinterkopf behalten, dss der ABB seine EIO.cfg normalerweise selbst schreibt, syntaktisch und semantisch richtig. Dazu ändert man die Maschinenparameter auf der Steuerung, die EIO.cfg ist dann kaum mehr als eine Sicherungsdatei. Auf diese Weise ist es kaum möglich, einen Fehler zu erzeugen.
    Bequemes offline-Editieren ist natürlich erlaubt, aber es besteht keine zwingende Notwendigkeit, das Ding von Grund auf selbst zu schreiben.


    Grüße,
    Michael

    TASK0 ist die Haupttask, die Bewegungstask und einzige Task bei Robotern ohne Multitasking, insofern ohne Bedeutung.
    Der Fehler muss irgendwo anders liegen. Erst mal müsstest Du schauen: stoppt das Programm auch wieder tatsächlich, wenn Du dann auf die "Stopp"-Taste drückst? Wenn ja, ist es schonmal nichts, was im Hintergrund noch reinpfuscht. Dann versucht der Robbi tatsächlich, die Position zu erreichen, aber kann nicht.
    Um sicher zu gehen, dass keine Einflüsse reinspielen, die aus der Berechnung kommen, würde ich das erste Testprogramm mit MoveAbsJ-Bewegungen (ist im Auswahlmenü auf einer der nachrangingen Seiten versteckt, musst ein bisschen blättern) programmieren (Achswinkelstellungen), und ein neues Tool dafür benutzen oder Tool0.
    Wenn das geht, als Werkobjekt Wobj0. Wenn Du eine von den alten Daten benutzt, besteht das Risiko, dass sie für den Roboter in dieser Kombination unmöglich sind.
    Eigentlich müsste er aber auch einen Fehler auswerfen, kontrolliere mal alle Logs.


    Grüße,
    Michael

    Dann schau doch mal in den Systemparametern und lösche die Hintergrundtask (falls vorhanden) und evtl. Ereignisroutinen (ich denke eher, es ist eine Ereignisroutine auf Start, die stört).
    Verschiedenes -> Systemparameter -> Steuerung -> Ereignisroutinen und/oder Tasks
    Anschließend warmstarten.


    Falls irgendwas davon noch gebraucht wird: VORHER Backup auf Diskette machen. Da sind dann auch alle Programme drauf, so daß man den Quatsch im Speicher löschen kann.
    "Programm" neu anlegen ist wahrscheinlich irreführend; was Du bräuchtest, ware ein neues MODUL mit einer ROUTINE darin. Unter PROGRAMM versteht der ABB nämlich ALLES, was im Speicher ist, und da ist ja schon eins. Weiß gar nicht mehr, wie das da war ... könnte damit zu tun haben.


    Grüße,
    Michael

    Soweit ich mich erinnere, darf zwischen SWITCH und dem ersten CASE gar nichts sein. Jedenfalls kann ich mich erinnern, mal ziemlich lange gesucht zu haben, warum der Kuka mein Programm nicht haben wollte - es war, weil ich einen Kommentar zwischen SWITCH und CASE hatte.


    Grüße,
    Michael


    Es gibt ja schon sowas ähnliches,wo man den Roboter mit der Hand an die Punkte führen kann. Aber das habe ich auch noch nie im Einsatz gesehen.


    Soweit ich weiß, ist das bei Lackieraufgaben mehr gefragt (gewesen), weil das Führen der Sprühpistole wohl eine Art von schwarzer Magie darstellt, wenn man einen gleichmäßigen Auftrag erhalten will. Jedenfalls gibt man dem menschlichen Lacker dann einfach den TCP in die Hand, um das zu erreichen. Meine ich zumindest mal so gehört zu haben.


    Grüße,
    Michael

    "Unsichere Synchronisierung" bedeutet nur, dass ein Synchronpunkt mehrfach benutzt wird - das läßt sich manchmal gar nicht anders machen und ist völlig unkritisch. Davon bleibt die Maschine nicht stehen.
    50056 ist eine Kollisionswarnung, da zeigt er normalerweise auch, was gerade kollidiert ist oder zu schwer geht. Entweder eine Roboterachse oder die externe Achse. Da liegt auf jeden Fall das Problem, nicht bei der Synchronisierung.


    Grüße,
    Michael

    Könnte man nicht auch einfach eine Textdatei lesend öffnen, den gelesenen String umwandeln und in die Variable schreiben?


    edit: Befehle
    open ... \read
    ReadStr
    close
    StrToVal oder StrToByte (?)
    ...
    ...


    Open ... \write
    write
    close



    Grüße,
    Michael