16. Juni 2019, 20:42:32
Roboterforum.de - Die Industrieroboter- Anwender und Experten Community

[offen] MultiMove Independent mit zwei Robotern und einem Controller


veryhot_post Autor Thema: [offen] MultiMove Independent mit zwei Robotern und einem Controller  (Gelesen 5338 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

10. Oktober 2018, 11:57:04
Antwort #15
Offline

irProgrammierer


Mittlerweile steht die Anlage beim Kunden und wir sind in den Endzügen. Mir ist ein Problem begegnet, bei dem mir der ABB Support nicht helfen kann und ich mir nur über einen "Trick" weiterhelfen konnte.
Folgende Situation:
- 2 Roboter mit Multimove Independent über einen Controller und Multitasking
- je Roboter ein Main-Task + einen semistatischen SubTask
- Roboter 1 arbeitet mit einem ISRA Kamerasystem, dieses System wird auch über einen extra Task gesteuert
Beim ersten Mal starten der Automatik liefen die Programmzeiger der Main-Routinen nicht los, obwohl alle korrekten Startsignale der SPS kamen. (diMotonStart) Die Semistatischen Task starteten natürlich einwandfrei.
Ich konnte den Programmzeiger nur zum Starten zwingen, in dem ich eine Eventroutine angelegt habe. Die beim Startsignal durch die SPS den Task startet.
Laut Kollegen war das noch nie so und ich als Rookie kann man mir auch nicht erklären, warum man dafür eine extra Eventroutine anlegen muss. Hatte jemand schon mal das Problem oder kennt von der Beschreibung des Problems aus eine Lösung?
Beste Grüße irProgrammierer
« Letzte Änderung: 10. Oktober 2018, 12:19:33 von irProgrammierer »
  • gefällt mir    Danke

Heute um 20:42:32
Antwort #16

Werbung

Gast

10. Oktober 2018, 13:38:58
Antwort #16
Offline

Programmiersklave


Wenn die Event-Routine auf START als Systemereignis reagiert, dann wurde auch irgendwas gestartet. Daher wäre meine erste Vermutung, dass sich das, was immer da beim ersten Mal gestartet wurde, sich auch sogleich selbst wieder beendet oder von außen beendet wird. 

Was ich nur weiß, ist, dass das Startverhalten der Bewegungstasks unterschiedlich lange dauern kann. Wenn ich z. B. neue Module reinlade, dauert der Start bei dieser Task messbar länger. Ich hatte auch bei einer älteren Steuerung schon den Effekt, dass ein verbundenes RS für eine Verzögerung sorgte. 
Sollte also irgendwas im Hintergrund darauf hoffen, dass beide Haupttasks gleichzeitig und sofort starten und den Start ansonsten verwerfen, könnte das schiefgehen. 

Normalerweise achtet ABB auch peinlich darauf, dass man nirgends fatale Rekursionen bauen kann, und das, was Du gemacht hast, wäre theoretisch eine fiese solche. Deshalb denke ich, dass er einfach den MAIN-Entry nicht findet, so wie er konfiguriert ist. Teile dieses Systems  (nicht alle in letzter Konsequenz) sind CASE-sensitive. Ich würde die Hauptroutine einfach wieder "main" nennen, bei beiden, und dann mal gucken. 

Grüße,
Michael
  • gefällt mir    Danke

10. Oktober 2018, 13:53:30
Antwort #17
Offline

irProgrammierer


Wir haben beide Fälle probiert. Anfangs hießen beide Haupttasks normal "main", gleiches Problem wie nach der Umbennennung. Das lustige ist, dass er anzeigt, dass die Tasks laufen (GO-Symbol), nur bewegt sich halt der Zeiger nicht durch das Programm sondern bleibt an der ersten Zeile nach der Deklaration stehen.
Auch längeres warten hat bei uns nichts gebracht(30-60sek). Ich empfehle keinem ein Multimove-System :D

EDIT: Hier noch ein Screenshot der Fehlermeldung. Die MEldung ist aber widersprüchlich. Ich setzte auf dem FlexPendant alle Zeiger auf Main und versetzte den Roboter in Automatik, da läuft nichts mehr.
« Letzte Änderung: 10. Oktober 2018, 15:18:59 von irProgrammierer »
  • gefällt mir    Danke

10. Oktober 2018, 19:06:51
Antwort #18
Offline

Hermann


Die Fehlermeldung deutet daraufhin, dass über das Signal "StartMain" versucht wurde den PZ auf Anfang von Main zu setzen, die Task aber noch gelaufen ist. Für ein Setzen des PZ auf Main per "StartMain" muss das Programm vorher stehen! Also zuerst Signal 'Stop' dann 'StartMain' dann 'Start'. Evtl. liegt ja dort auch der Hase für das andere Problem begraben: Signalfolge 'Stop' 'StartMain' 'Start'.

  • gefällt mir    Danke

11. Oktober 2018, 09:16:21
Antwort #19
Offline

Robiman

Global Moderator
Zitat
Signalfolge 'Stop' 'StartMain' 'Start'.
Das letzte Start kannst du weglassen "StartMain" setzt den PZ auf Main und startet das programm
  • gefällt mir    Danke

Heute um 20:42:32
Antwort #20

Werbung

Gast

11. Oktober 2018, 10:03:26
Antwort #20
Offline

Programmiersklave


Was es auch gibt: Ereignisroutinen auf PowerOn oder gar auf Stop, die nie zum Ende kommen. 
Ich hatte mir vor Jahren mal einen solchen Bock geschossen, dass eine Ereignisroutine auf "Stop" nie fertig wurde. Blockierte zuverlässig das (5er) System und ließ sich auch nicht anhalten, nicht einmal durch aus- und einschalten. Musste einen Systemfehler provozieren, um da wieder raus zu kommen....

Allgemein - ich hab' praktisch nur noch mit MultiMove-Independent-Systemen zu tun und so gut wie nie Probleme damit. Die höchste Stufe des Ärgernisses sind nachträgliche Konfigurationsänderungen (Roboter 3 zu Roboter 1 machen und sowas.)

Grüße,
Michael
  • gefällt mir    Danke

11. Oktober 2018, 13:25:49
Antwort #21
Offline

irProgrammierer


Woran erkennt man denn, ob eine Event Routine "nicht fertig wird"?
Das mit dem Stop vor dem StartatMain werde ich definitiv probieren. Danke schon mal für die Hinweise.
@Programmiersklave: Ist unsere erste Multimove-Anlage .. wurde auch nur aus Kostengründen gewählt. Unser Standard war auch gar nicht darauf ausgelegt, was einfach viel Arbeit und Fummelei mit sich brachte. Wenn man die Eigenheiten kennt, dann ist es natürlich ab der zweiten oder dritten Anlage schon routinierter.
  • gefällt mir    Danke

11. Oktober 2018, 14:06:41
Antwort #22
Offline

Programmiersklave


Die entsprechenden Tasks betrachteten sich als "laufend", das übliche Bild also wie wenn ein Programm läuft, keine Änderungen möglich, ausgegraute Menüs, Zurückweisung von Startversuchen über Schnittstelle etc..
Besonderheit halt: Programmzeiger bewegt sich nicht und Task lässt sich nicht stoppen (weil Ereignisroutine im Hintergrund läuft und nicht ohne Weiteres stoppbar ist..) Letztlich bekommt man nur schwer mit, was genau eigentlich unstoppable läuft bzw. auf Daten wartet, die nie kommen, und woran es hapert. 

Grüße,
Michael
  • gefällt mir    Danke

15. Oktober 2018, 07:29:17
Antwort #23
Offline

irProgrammierer


ok Danke Michael. Das werde ich nächste oder übernächste Woche auf Baustelle gleich mal probieren in der Hoffnung, dass es des Problems Lösung ist. :)
  • gefällt mir    Danke

Heute um 20:42:32
Antwort #24

Werbung

Gast

26. Oktober 2018, 10:56:21
Antwort #24
Offline

irProgrammierer


Ist es möglich über Robotstudio mit den passenden Lastdaten den Bremsweg zu berechnen? Wenn nicht, wie kann ich das in der Praxis ohne ein entsprechendes Messgerät nachmessen(abgesehen von einem Maßband)? Ich habe leider nicht den 100% Einrichtbetrieb.
  • gefällt mir    Danke

28. November 2018, 15:12:52
Antwort #25
Offline

irProgrammierer


Habe das Robotersystem nochmal neu aufgesetzt, damit waren die Probleme mit der Event Routine vollständig gelöst. War also im Zweifelsfall ein Bug!


Teile per facebook Teile per linkedin Teile per pinterest Teile per reddit Teile per twitter
 

über das Roboterforum

Nutzungsbedingungen Impressum Datenschutzerklärung

Sponsoren des Roboterforums

ROBTEC GmbH