MultiMove Independent mit zwei Robotern und einem Controller

Eine Steuerung, EINE E/A-Liste, EINE IP. Es ist sozusagen EIN Roboter mit ZWEI Manipulatoren.

Zu dem Anderen: in der Titelleiste (ganz oben) ist dieses Symbol mit dem Pfeil nach unten, das am weitesten rechte in der Sammlung links. Dort im Untermenü "Windows" gucken, ob "Dateien" angehakt ist.

Grüße,
Michael

Dazu kann ich Dir leider gar nichts sagen. Excel öffne ich nur, wenn mich einer unter Androhung lebensverkürzender Maßnahmen dazu zwingt :evil1:

Grüße,
Michael

Hm, bin mir nicht ganz sicher, was Du mit Standardvariablen meinst. Es gibt sog. Systemsignale (Eingänge und Ausgänge), die mit physischen Signalen verbunden werden können, aber immer nur mit einem.
Und vieles davon gilt natürlich für das gesamte System. Andere kannst Du (bzw. musst Du) bei der Konfiguration mit einem Tasknamen ausstatten, für welche Task das Signal gilt.
Motoren ein und Start und Stop etc. gilt natürlich immer für das gesamte System. Wenn Du einzelne Roboter starten und anhalten willst, dann musst du das im Programm individuell regeln.
Generell ist es nicht ohne weiteres möglich, nur einen Task zu starten. Wenn man auf Automatik umschaltet, aktiviert die Steuerung immer alle Tasks und weist auch explizit darauf hin. Dann lässt der Systemeingang für "Start" eben alle Programme laufen. Was man dann im Programm damit macht, ist eine andere Sache.
Wie gesagt, betrachte das ganze als einen Roboter mit zwei Manipulatoren. Jeder hat eine eigene Programmtask und eigene Koordinatensysteme, aber nicht eigene Signale oder eigene Sicherheiten. Die nächstkleinere Hierarchietrennung unterhalb von "System" ist "Task". E/A und Parameter gelten systemweit, wobei viele Parameter sich auf einzelne Tasks beziehen können. CONST und VAR sind maximal taskweit, nur PERS können taskübergreifend sein. MODULE und alles darin sind schon die nächste Hierarchieebene unterhalb von TASK.

Grüße,
Michael

Zitat von irProgrammierer

Hallo,

ich bin neu in der ABB-Welt und muss nun mein erstes Projekt bearbeiten. Ein MultiMove System mit den Optionen Multitasking, MultiMove Independent.

In Robotstudio werden ja beide Roboter unter einer Steuerung angezeigt. Teilen sie sich sozusagen eine EA-Liste oder kann man irgendwo zwei von einander getrennte Listen anlegen? Wo oder wie kann ich jedem Roboter eine eigene IP verpassen?

Ebenso finde ich im RobotStudio diesen I/O Configurator nicht, wo man Excel-Listen in und exportieren kann. Laut Handbuch soll im Reiter RAPID, dann links wo Steuerung steht, noch ein zweter Reiter mit "Files" sein, wo ich z.B. die EIO.cfg bearbeiten kann. Ich sehe diesen Reiter aber nicht. Für Tipps wäre ich äußerst dankbar.

Ich benutze noch die unaktivierte Vollversion.

Alles anzeigen

Hallo irProgrammierer!

Ich habe solche liste wenn du brauchst!
Ist es sehr einfach die einzige nachteil ist das es mit 32bit VBA erstellt wurde!

MFG

Tamas

Die Systemsignale sind nur einmal "verwendbar", solange sie nicht taskbezogen sind. Es gibt ja nur ein "System". Es kann nur das ganze System gestoppt werden auf diese Weise. Es gibt ein paar, die einer Task zugeordnet werden können, z. B. gibt es neuerdings was, womit man auslesen kann, dass eine Task läuft. Die gehen dann auch mehrfach. Aber start und stop gehören nicht dazu.
Die Unit bezeichnet nicht den Roboter, sondern die verwendete E/A-Karte. Da kannste ja mehrere haben, z.B. einen Buskoppler hier und einen dort, oder mehrere Device-Net Buskoppler und irgendwo noch eine Profibusanbindung, solche Szenarien. Das hat mit den Manipulatoren rein gar nichts zu tun.
Du kannst dann ein Systemsignal mit einem echten Signal verknüpfen, welches irgendwo auf eine dieser Units gemapped ist. (Das muss man ebenfalls selbst konfigurieren.) Die Steuerung weiss dann beispielsweise: wenn auf dem Signal 42 auf der Unit DN_Board666 der Zustand von low nach high wechselt, dann bedeutet das, ich muss den Programmzeiger in allen Tasks auf "Main" setzen und starten. Das parametrierbare Systemsignal ist quasi nur ein definierter System-Interrupt. System! Nicht Task.

Wenn Du willst, dass einer der Roboter aufhört, während der andere weitermacht, dann geht das nur so, dass im Programm ein beliebiger (anderer) Eingang abgefragt wird, der die fraglichen Bewegungstask dann durch eine Warteschleife oder Selbstbeendigung einschläfert. Wobei die Selbstbeendigung vielleicht nur halb in Deinem Sinne wäre, denn starten lässt sich eine tote Task natürlich nicht so ohne weiteres. Die Task selbst ist ja tot, und das System lässt sich nicht starten, solange eine andere Bewegungstask noch läuft.
Du hast in dieser Konfiguration eine irre Menge an Möglichkeiten, die eigentlich jedes wünschenswerte Szenario abdeckt. Nur so, wie Du es Dir gerade vorstellst, geht es nicht.

Wenn die Anlage weniger als ~100 Signale hat, würde ich außerdem empfehlen, die Konfiguration in RobotStudio selbst zu machen, statt mit einem Editor oder gar Excel EIO.CFGs zu generieren, denn letzteres erzeugt eine Menge Frust.

Solange die Roboter noch nicht da sind, kann man sich mit einer virtuellen Steuerung in RobotStudio behelfen. Man muss dann nur (weil man den echten Schlüssel ja noch nicht hat) darauf achten, die gleichen Optionen anzuwählen, die beim System mitbestellt wurden. Übrigens: wenn die Roboter da sind, zuerst sofort ein Backup machen und gut verwahren!

Grüße,
Michael

Hallo, ich habe ein ähnliches Problem mit Multimove indeependent und möchte mich deshalb hier ranhängen.

Zitat

Du hast in dieser Konfiguration eine irre Menge an Möglichkeiten, die eigentlich jedes wünschenswerte Szenario abdeckt. Nur so, wie Du es Dir gerade vorstellst, geht es nicht.

Wäre folgendes auch möglich:
Roboter1 fährt Crash (normalerweise stoppt dann ja das Programm), Roboter2 zwei läuft ganz normal weiter, Programm von Roboter1 kann, ohne Roboter2 zu beeinflussen, neu gestartet werden? Wenn ja, wie? Danke

Zitat von robnull

Hallo, ich habe ein ähnliches Problem mit Multimove indeependent und möchte mich deshalb hier ranhängen.

Das ist kein Problem, das ist ein Feature. Wenn Du willst, dass die Roboter völlig unabhängig laufen, dann brauchst Du zwei separate Steuerungen. MultiMove ist dafür gedacht, dass mehrere Roboter ZUSAMMEN im Team arbeiten, wenn auch vielleicht mit unabhängigen Bewegungen und Programmabläufen. Teamarbeit bedeutet, dass es nur ein Start-Signal gibt, und dass das ganze Team stoppt, wenn einer im Team ein ernsthaftes Problem kriegt. Ein Crash ist ein ernsthaftes Problem.

Is' wie auf'm Sportplatz. Steht ein umgefallener Spieler sofort von selbst wieder auf und rennt weiter, ist alles gut. Muss er vom Platz getragen werden, wird das Spiel unterbrochen und muss explizit neu gestartet werden. Nicht zwangsläufig von vorne, aber doch auf Kommando des Schiedsrichters. Sollen zwei Spiele unabhängig laufen, brauchste zwei Sportplätze und zwei Schiedsrichter.

Grüße,
Michael

Danke, die Erklärung mit dem Sportplatz könnten sogar die Entscheider verstehen, die gerne mal die zweite Steuerung wegsparen.

Ja.
Es müssen schon verschiedene Signale sein. Gibt drei Möglichkeiten:
1.) Du brauchst sie gar nicht - dann kannst Du sie weglassen.
2.) Du brauchst sie einzeln - dann brauchst Du einzelne Signale
3.) Du brauchst sie verODERt oder verUNDet - dann legst Du sie auf virtuelle Signale, die in der Konfiguration der CrossConnections dann mit einem phys. Singnal verknüpft werden.

Grüße,
Michael

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

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'.

Zitat

Signalfolge 'Stop' 'StartMain' 'Start'.

Das letzte Start kannst du weglassen "StartMain" setzt den PZ auf Main und startet das programm