Beiträge von rmac

    Mahlzeit,


    ich hatte gestern Abend im RobotStudio zu diesem Thema noch etwas mit Prozedur-Aufrufen , Stop- und Exit-Instruktionen etc. im PowerUp-Ereignis experimentiert und die Ergebnisse waren eher ernüchternd: je nach Komplikation laufen die semistatischen Task nicht mehr hoch u.dgl. Das ging teilweise bis zum Komplett-Absturz der virtuellen Steuerung und/oder des RobotStudios.


    Ich denke, ich lass das mit den Experimenten auf der realen Steuerung mal sein und belasse es bei meiner aktuellen, prinzipiell funktionierenden Lösung.


    Danke für eure Beiträge...

    Wie gesagt, ich werde das bei Gelegenheit auch mal ausprobieren. Vielleicht versucht die Steuerung ja Main zu starten und das schlägt dann fehl, weil Motoren nicht an, oder so. Das könnte man abfangen. Wenn der PZ danach bei der ersten Instruktion in Main steht und von da aus beim Neustart weiterläuft, wäre das ja auch OK.
    Ich poste dann...

    Ich meine "einfach" mal eine Eventroutine erstellen, Main mit Power_On verknüpfen... versuchen

    Huch, das habe ich wirklich noch nicht/nie ausprobiert, schließe mich da aber der Befürchtung von Programmiersklave an... Vor allen Dingen sollte beim "PowerUp" ja eigentlich nicht Main ausgeführt werden, sondern nur der PZ an den Start innerhalb von Main. Starten soll das erst beim "Motoren an und Start" seitens der SPS. Ich werde es trotzdem bei Gelegenheit mal ausprobieren...




    ?

    Jo, das hatte ich auch gesehen und ist auch so eingestellt! (ist ja auch Default):

    ...bringt aber nix, d.h. es funktioniert eben nicht so wie angegeben.
    Wenn ich in Automatik starte, bleibt der PZ trotzdem da wo ausgeschaltet wurde... X/


    Diese Aufgabenstellung ist ja nicht aus der Luft gegriffen, deswegen hatte ich gehofft, nur irgendwas übersehen zu haben.

    Moin,

    Danke für eure Antworten

    Funktioniert das evtl. über ein Power-On-Ereignis, einfach mal das Main in/mit "Power on" verknüpfen?

    Verstehe ich nicht so ganz was du mit [Main in/mit "Power on" verknüpfen?] meinst:

    Mit "SYS_POWERON()" verwende ich ja bereits das Ereignis "PowerOn", ohne es explizit in der Konfig. als Ereignis einrichten zu müssen. Das Ergebnis ist ja das gleiche...

    Mit "ExitCycle" in diesem Ereignis komme ich auch aus dem Zyklus heraus, allerdings wird der PZ nicht auf die erste ausführbare Zeile in Main gesetzt, so wie in der Doku beschrieben:

    Zitat von Technical Reference Manual

    ExitCycle: Stoppen des aktuellen Zyklus und Setzen des Programmzeigers

    auf die erste Instruktion in der Hauptroutine.

    Möglicherweise funktioniert das so wie beschrieben wenn die Bewegunsgstask läuft bzw. die "Motoren An" sind, aber das ist zum Zeitpunkt des PowerUp noch nicht der Fall. "ExitCycle" macht den PZ nur ungültig, setzt ihn aber nicht auf die erste Instruktion in Main!


    Wie eingangs erwähnt habe ich es ja am Laufen, mit:

    - Cross-Connection von virtuellem Ausgang auf virtuellen System-Eingang mit "PPToMain"
    - "ExitCycle" ausführen und Merker setzen im Ereignis "SYS_POWERON"

    - In parallel laufender (semistatischer) Task den Merker checken und so lange den virtuellen Ausgang pulsen bis ich per Interrupt-Handler das erfolgreiche Setzen von "PPtoMain" in der Bewegungstask gemeldet bekomme.


    Läuft, ist aber meiner Meinung nach recht viel Aufwand für so eine triviale Aufgabe.

    Vielleicht meldet sich ja noch jemand mit Verbesserungsvorschlägen...


    Danke nochmal

    Neuer Tag, neues Problem:


    Ich möchte, dass nach dem Hochfahren/Kaltstart der Roboter-Steuerung (RW 6.15.02) in Automatik, der Programmzeiger auf der ersten ausführbaren Zeile von Main steht, so das über eine SPS per "Motors On and Start"-Signal der Programmstart von dort aus erfolgt.


    Randbedingungen:

    - Ich habe nur das "Motors On and Start"-Signal als externes SIgnal zur Verfügung, kein "Start at Main", oder "PP to Main"!

    - das "Motors On and Start"-Signal wird auch zum Wiederanstarten verwendet, wenn das Programm unter einer Fehlerbedingung stoppt.
    Es kann also nicht auch für "PP to Main" o.dgl. verwendet werden.


    Was ich bisher habe:

    In der Bewegungstask (T_ROB1) habe ich folgende "SYS_POWERON"-Routine:

    Code
    PROC SYS_POWERON()
      ExitCycle;
    ENDPROC


    Die sorgt schon mal dafür, dass der PZ von seiner letzten Position (beim Abschalten) verschwindet.

    Nur leider wird der PZ dadurch nicht auf die erste Zeile von Main gesetzt, sondern ist lediglich verschwunden bzw. ungültig! D.h. beim "Motors On and Start"-Signal wird ein Fehler ausgelöst, da der PZ nicht gesetzt ist! Ich möchte aber vermeiden, dass der Anwender am TeachPanel "PZ -> Main" drücken muss, da das Panel für den normalen Werker nicht erreichbar ist!


    Ich habe das jetzt hinbekommen von einer zweiten Task aus, cross-connecteten Signalen etc., ist aber ziemlich un-elegant und schlecht wartbar.


    Frage: habt ihr andere Ideen oder Lösungen dazu, am besten irgendetwas Simples, was ich übersehen habe... ;)

    Danke!

    Ich schließe das Thema jetzt mal, wollte aber noch meinen letzten Kenntnisstand dazu mitteilen:


    Leider funktioniert das mit dem "ProcerrRecovery" nicht direkt in der Bewegungstask (also im RobotStudio schon - aber nicht in der echten Steuerung!), allerdings lässt sich das Prinzip von einer separaten (semistatischen) Task aus bewerkstelligen, also:

    - in der Background-Task per Interrupt (IError) Not-Aus (oder auch Kollision etc.) abfangen und

    - im Interrupt-Handler dann "ProcerrRecovery \..." aufrufen

    - nach dem Starten bzw. Fortsetzen der Bewegungstask (die ja durch Not-Aus angehalten wurde) wird dann der Error-Abschnitt der unterbrochenen Proc ausgeführt.


    Funktioniert!


    Weiterhin frohes Schaffen...

    nabnd,


    es ist der zweikanalige Not-Aus gemeint.


    Ich habe jetzt gerade (hoffentlich) eine Lösung gefunden, zumindest läuft das so im RobotStudio. In der Motiontask fange ich den EStop über einen Interrupt ein. Die Interrupt-Routine bleibt dann zwar auch zusammen mit der Task stehen, aber beim nächsten Start läuft das Programm dort in der Interrupt-Routine wieder an und da habe ich als nächste Anweisung ein:

    "ProcerrRecovery \SyncLastMoveInst;"


    Damit bekomme ich dann in der Bewegungsroutine den Sprung in die ERROR-Section hin (mit Fehler: ERR_PATH_STOP)


    ...hoffe, das funktioniert auch morgen an der Maschine so. :/


    Danke für deine Rückmeldung

    Mahlzeit,


    ich habe hier ein aktuelles Problem bei Steuerung RW 6.15.02:


    beim Auslösen von Not-Aus (QuickStop) möchte ich gerne, dass der Programmzeiger der Bewegungstask in den Fehlerbehandlungsabschnitt (ERROR) der aktuellen Routine springt.

    Da die Bewegungstask beim QStop ja ohnehin angehalten wird, würde es mir natürlich auch reichen, wenn der Programmzeiger nur in ERROR steht/springt, damit es beim nachfolgenden Start dort weitergeht...


    Irgendwelche Ideen dazu?

    Ich habe schon alles mögliche probiert: Event Routine, parallele Task, ...


    Bei einer (simulierten) Kollision (also mit "SimCollision" aus einer parallelen Task heraus) funktioniert das genauso wie gewünscht, nur beim Not-Aus bekomme ich es nicht hin.

    Vielleicht habe ich auch nur etwas ganz simples übersehen?


    Danke für Infos!

    Ja, bei dem (32Bit) Statusregister der Motor-Steuerung drösel ich direkt die Bits auf (Enabled, ZielErreicht, Schleppfehler, usw.), aber die meisten anderen Parameter (Rampen, Geschwindigkeiten, Positionen) sind i.d.R. 32Bit-Integer.


    Ich hatte ja gehofft, dass die Byteorder im Protokoll festgelegt ist bzw. sich die Hersteller an irgendwas einheitliches halten. Oder dass so etwas zumindest in den Steuerungen einstellbar ist, aber anscheinend ja nicht.

    Wäre ja ohne großen Aufwand zu implementieren... X/

    So, hat dann letztendlich doch funktioniert:

    Ich konnte In- und Output-Mappings als SubModule hinzufügen und konfigurieren.
    Hab ich beim ersten mal wohl nicht wirklich geschnallt.

    Allerdings ist das (Bit-)DeviceMapping ziemlich unübersichtlich, da die Bytereihenfolge nicht stimmt und entsprechend "umsortiert" werden muss. Elegant ist anders, aber Hauptsache funzt erstmal.


    pasted-from-clipboard.png


    Oder gibt es hier evtl. eine elegantere Methode?


    Danke nochmal... :thumbup:

    Das Inbetriebnahme-Tool (= Drive Assistant 5) habe ich hier am Laufen. Es ermöglicht die "manuelle" Parametrierung der Motorsteuerung (Geschwindigkeiten, Rampen, Positionen, etc.) und die Optimierung der Anwendung aus Controller-Sicht.

    Was die Profinet-Schnittstelle angeht, gibt es dort aber so gut wie nichts zu parametrieren, ausser eine Diagnose-Funktion zu aktivieren (für mich ohne erkennbare Auswirkungen) und die Möglichkeit einen Fehlercode beim Verbindungsabbruch auszulesen.


    Aktuell bin ich nicht an der Maschine und werde mal bei nächster Gelegenheit schauen ob ich weitere Submodule hinzufügen kann. Ich bin mir aber ziemlich sicher, dass ich beim letzten Mal da nichts übersehen habe.

    Aktuell ist der Plan, die Paramterierung des Motors über die SPS zu machen und vom Roboter nur Auf/Zu per IO an den Motor-Controller zu senden.


    Danke nochmal für deine Hinweise.

    Falls ich per Profinet doch weiterkomme, dann poste ich das hier.

    Hallo Potte1604,
    zunächst Danke für die Rückmeldung!


    Also ich habe keine Profinet-Schnittstellenbeschreibung, die über die GSDML-Datei hinausgeht, ansonsten noch Beispiele für Anbindung an SPS/Siemens/TIA.


    Beschreibungen über den interne Objekt-Katalog der Motor-Steuerung gibt's reichlich, aber das ist ja nicht das Problem und das meinst du sicher auch nicht.


    Was meinst du genau mit "Submodule anhängen": Elektrisch/Hardware, oder in der Konfiguration?
    Die Hardware (Motor-Controller) ist jedenfalls nicht erweiterbar.

    Hallo alle,


    nach jahrelanger Roboter-Abstinenz muss ich mich nun wieder mit dem ABB-Kollegen beschäftigen. Mit Profinet-Anbindung kenne ich mich leider so gut wir garnicht aus und stehe daher aktuell vor folgendem Problem:


    Ich habe über Profinet eine Dunkermotoren-Steuerung (BGE 5510 dPro PN) an einer ABB-Steuerung (RW 6.15.02 mit Profinet Controller Option) hängen und kann das Gerät auch im Robotstudio sehen und konfigurieren.

    Sieht so aus


    Da das Profil "PROFIdrive" von ABB scheinbar nicht unterstützt wird (zumindest nicht bei ABB-fremden, externen Reglern?), hatte ich die Hoffnung, über das DAP Submodule auf die Regler-internen Objekte zugreifen zu können.

    Hier kann ich auch bestimmte Regler-Objekte auf Parameter mappen (hier z.B. Geschwindigkeitssollwert auf Parameter10)


    Ab hier stehe ich auf'm Schlauch, denn ich weiß nicht wie ich nun per Programm lesend/schreibend auf diese Regler-Objekt-Daten zugreifen kann!
    - wenn ich Werte direkt setzen will (durch ändern des Value im obigen Screenshot), funktioniert das nicht, d.h. der Wert ändert sich in der Motorsteuerung nicht.
    Wenn ich die ABB-Steuerung allerdings warm-starte, dann werden die oben eingetragenen Werte einmalig in die Motorsteuerung übertragen!
    - Ich hatte versucht Signale anzulegen (Gruppen/Analog) und diese dann auf diese Parameter (Setting 1..n) zu mappen, aber das funktioniert leider auch nicht.
    Beim nächsten Warmstart kommt die Meldung, dass das entsprechende Signal nicht auf "Valid" gesetzt werden kann (!?)


    Bin für jeden sinnvollen Tipp/Hinweis dankbar!

    Danke erstmal für die Info.

    Wenn ich etwas dazu herausfinde, poste ich es hier....


    EDIT:

    Wie DS186 bereits vermutet hat, wird laut ABB das Profil PROFIdrive wohl nicht direkt unterstützt, prinzipiell könnte eine Steuerung aber erfolgen wenn die IRC als Profibus-Master konfiguriert/freigeschaltet ist. Schaun wir mal....

    Hallo zuzsammen,


    für ein anstehendes Projekt soll ein externer Motor (mit Dunkermotoren Controller BGE5510 PN) über Profinet direkt von

    einer IRC5 (brandneu) aus angesteuert werden. Der Motor-Controller unterstützt das Profil "PROFIdrive".


    - Funktioniert das generell, bzw. hat jemand bereits Erfahrung damit (IRC5 -> "PROFIdrive)?

    - Welche Voraussetzung auf der IRC5 benötigt man dafür (Hard-/Software)?

    - Sind irgendwelche Fallstricke/Probleme damit bekannt bzw. sollten berücksichtigt werden?


    Vielen Dank für Infos und schonmal schönes WE.

    Hallo,


    habe heute Rückmeldung erhalten:
    Scheinbar war diverse Hardware defekt (nur Netzwerkkarte oder komplette MFC? :huh: , keine Ahnung)
    Ist vom orangenen Service ausgetauscht worden, jetzt läuft wieder alles.... :applaus:


    Nochmal Danke für Eure Tipps
    Gruss
    rmac

    Hallo SJX,


    Danke für den Tipp/Vorschlag...!


    Leider stehen die Anlagen ca. 2,5 Autostunden entfernt und ich komme
    da erst wieder dran, wenn der entsprechende Auftrag vom Kunde erteilt wird.
    Mal schauen wie die sich entscheiden.....


    Thx und Gruss
    rmac

    Hallo SJX,
    ja, du hast natürlich recht: :genau:
    Es ist eine KRC1 V3.3 / 4.1.7 SP08


    Was mich wirklich wundert, ist das "komische" Fehlverhalten. :denk:
    Wenn es prinzpiell garnicht funzen würde, hätte ich mehr Ansätze zur Fehlersuche.
    Aber dass kleine Datenblöcke übertragen werden und größere Mengen nicht, ist schon sehr merkwürdig...


    Gruss
    rmac

    Hallo SJX,


    zunächst vielen Dank für die Info... :zwink:


    Werde das morgen mal prüfen (lassen).
    So weit ich weiß, sind diese Systeme wohl "refurbished" und schon mehrfach repariert worden.
    Vielleicht ergab sich dadurch auch eine gewisse "Inhomogenität" in der Hardwarezusammenstellung. :denk:

    Gruß
    rmac