TIA Automatische Aufgabenplanung für einen Manipulator

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da hast du ja eine Menge schon Konkretes geschrieben ...
Ich denke mal, dass dein Werkstück-Datensatz dann eine Menge mehr Info's beinhalten muss. Ich werde das jetzt (aus meiner Sicht) mal ein wenig aufblasen und, da ich deine Maschine nicht wirklich kenne, sicherlich Dinge dabei übersehen.

Dann Werkstück-Datensatz muss dann ja schon mal beinhalten welche Schlüsselnummer es hat - das wäre die oben schon genannte Index-Nummer. Die kann sich im Laufe der Zeit natürlich wiederholen - es darf aber in der Maschine immer nur ein Werkstück mit derselben Nummer geben.
Dann müßten die Daten beinhalten von woher das Werkstück gekommen ist und wo es hin soll. Falls es hier aber so ist, dass das Werkstück kommend von Position 20 erst nach Pos.1 und dann nach 7 und dann nach 12 und dann nach 8 soll dann muss auch das darin stehen. Für jede dieser Positionen, hier würde ich ein Array anlegen, das die mögliche Stationenzahl berücksichtigt wobei hier dann ja auch dieselbe Station mehrfach angeleaufen werden kann, ein Bool, das aussagt ob die Bearbeitung der Station abgeschlossen und irgendwo auch einen Index, der dir sagt in welchem Bearbeitungsschritt das Werkstück gerade steckt.
Hat eine Station mehrere, möglicherweise sogar unterschiedliche Dinge zu tun dann würde ich auch das hinterlegen oder, falls das aus dem Rezept hervorgeht, würde ich die Rezept-Nummer hinterlegen und auch wieder die Info, welche Einzelschritte davon bereits bearbeitet worden sind - vielleicht auch noch eine Bewertung - es kann ja auch mal ein Teil nicht korrekt bearbeitet worden sein, warum auch immer, und es deshalb dann NIO sein. Auf jeden Fall kannst du auf diese Weise ziemlich sicherstellen, dass im Ablauf, sogar bei einer Unterbrechung, nichts vergessen werden kann. Um das jetzt aber weiter ausewinander zu puzzeln müßte ich mehr über die Varianten wissen - ich denke aber, dass es dir so als Denkansatz vielleicht schon mal hilft.
Wenn ich es richtig verstanden habe dann hast du max. 75 Werkstücke in der Anlage - du müßtest dann dies also als Array mit 75 UDT-Elementen anlegen - das wäre dann wenn du so willst dann auch deine schon genannte "Statemachine".

Die jeweilige Station würde nun (nach meiner Vorstellung) einfach nur mitgeteilt bekommen, mit welchen der Datensätze sie gerade arbeitet, also dort dann die Felder ausfüllt und wenn sie dann fertig ist eine Kennung an dein Zentral-Programm in dessen Arbeits-FIFO schicken, damit das Werkstück dann irgendwann, wenn der Robbi Zeit dafür hat, wieder entleert und ggf. neu beschickt wird.
Soweit meine Überlegungen dazu ... jetzt bin ich dann mal auf deine Antwort gespannt ...

 

[DCDCDC]

Hier gehts ja schon um viele Daten.. Larry hat da schon recht, ich hingegen würde aber das nicht alles in der Steuerung vorhalten sondern soweit wie möglich auf eine Datenbank auslagern.

@Tmbiz habt ihr da schon mal drüber nach gedacht und das evtl sogar schon evaluiert?

Sehe ich auch so. Da ich sicher mal zwischen "erfolgreiche" und nicht erfolgreich bearbeitet unterschieden muss, wäre ein Integer sicher eine gute Wahl. Also nach jedem Bearbeitungsschritt einen Wert X schreiben.

Wenn dir 0..255 reicht tut es auch ein Unsigned Integer, der spart Platz Ist bei der Menge der Daten die hier wohl anfallen auf der Steuerung nicht verkehrt sich mal über die verwendeten Datentypen auch Gedanken zu machen.. so kann viel Speicher gespart werden.

Auch in deinem Screenshot eins obendrüber. Muss es denn ein reiner Integer sein oder tut es auch ein signed oder sogar unsigned Integer?

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

@DCDCDC : ich glaube, dass die Datentypen erst einmal zweitrangig sind. Das Auslagern in eine Datenbank sehe ich bei dem skizzierten Szenario möglicherweise als zu zeit-intensiv an. So wie ich es verstanden habe werden die Datensätze ja erst einmal lokal und möglicherweise auch recht zügig umgeschaufelt ...

 

[DCDCDC]

@DCDCDC : ich glaube, dass die Datentypen erst einmal zweitrangig sind. Das Auslagern in eine Datenbank sehe ich bei dem skizzierten Szenario möglicherweise als zu zeit-intensiv an. So wie ich es verstanden habe werden die Datensätze ja erst einmal lokal und möglicherweise auch recht zügig umgeschaufelt ...

Die Rezepte wären ja eine Möglichkeit.. FIFOs und Materialhandling ohne WTs wird da schwieriger, so könnte man zumindest die Rezepte zentral "anfassen" ohne die Steuerungen zu beeinflussen. Qualitätsdaten werden ja auch irgendwie abgesetzt werden, schätze ich mal.

Natürlich sind Datentypen erstmal zweitrangig.. dennoch je nach Menge, irgendwann auch nicht mehr ganz unwichtig

 

[Oberchefe]

aber wie immer: Leerzeichen in Symbolik möglichst vermeiden!

 

[Tmbiz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich danke euch für die vielen und guten Hinweise und werde mal darauf eingehen:

Dann Werkstück-Datensatz muss dann ja schon mal beinhalten welche Schlüsselnummer es hat - das wäre die oben schon genannte Index-Nummer. Die kann sich im Laufe der Zeit natürlich wiederholen - es darf aber in der Maschine immer nur ein Werkstück mit derselben Nummer geben.

Kannst du mir sagen, was diese Index- oder Schlüsselnummer genau machen soll. Verständlich ist, dass damit eine eindeutige Zuordnung ermöglicht wird. Doch was möchtest du dann genau über diese eindeutige Erkennung/ Zuordnung machen. Ich habe da eine Vermutung, möchte dich aber nicht falsch interpretieren. Als Nummer könnte man z.B. alles Slots von 1 bis 75 nummerieren. Damit gibt es dann eine eindeutige Zahl. Zusätzlich ist es so, dass immer 25 Werkstücke auf einem Träger Liegen, der wird komplett gewechselt. Wir der Träger eingesetzt, kann der Status "bearbeitet" für alles 25 Slots auf "nicht bearbeitet" gestellt werden.

Dann müßten die Daten beinhalten von woher das Werkstück gekommen ist und wo es hin soll. Falls es hier aber so ist, dass das Werkstück kommend von Position 20 erst nach Pos.1 und dann nach 7 und dann nach 12 und dann nach 8 soll dann muss auch das darin stehen.

Es ist tatsächlich so, dass ein Werkstück einen beliebigen Weg nehmen kann. Die Regel ist aber es kommt von Slot x und geht zum gleichen zurück.
Die Abfolge des Flows kann theoretisch in allen möglichen Kombinationen erfolgen. Z.B. von Slot 1, Unit 1 zu Slot 2 Unit 20 zu Slot 1 Unit 3 usw.

Hat eine Station mehrere, möglicherweise sogar unterschiedliche Dinge zu tun dann würde ich auch das hinterlegen oder, falls das aus dem Rezept hervorgeht, würde ich die Rezept-Nummer hinterlegen und auch wieder die Info, welche Einzelschritte davon bereits bearbeitet worden sind

Eine Station kann immer nur eine Arbeit ausführen. Aber es kann sein, dass das mehrmals wiederholt wird aber dann mit unterschiedlichen Parametern. Ich würde diesen Schritt aber erst später einfügen. Aktuell geht es mir mal nur um den Förderprozess.

vielleicht auch noch eine Bewertung - es kann ja auch mal ein Teil nicht korrekt bearbeitet worden sein, warum auch immer, und es deshalb dann NIO sein.

Das halte ich für wichtig und werde ich so machen.

Wenn ich es richtig verstanden habe dann hast du max. 75 Werkstücke in der Anlage - du müßtest dann dies also als Array mit 75 UDT-Elementen anlegen - das wäre dann wenn du so willst dann auch deine schon genannte "Statemachine".

Ja, das geht in die Richtung meiner Gedanken.

Nun kann ich meinen Gedanken auch besser formulieren. Grundsätzlich muss ich davon ausgehen, dass für alle Werkstücke das gleiche Bearbeitungsprogramm angewandt werden kann. Also fördere das Werkstück aus Slot 1 zur Unit 10, dann zur Unit 4 und dann zurück zum Lager Slot 1. Alle Werkstücke würden dann den Weg gehen.

Ich brauche ja nun eine Logik, welche dem Roboter sagt, nimm Werkstück aus Slot 1 und bring ihn zu 10. Wenn der Prozess in 10 beendet ist, bring ihn zur Unit 4. Wenn der Prozess in 4 Aktiv ist, kann der Roboter das Werkstück aus Slo2 in die Unit 10 fördern usw. Ich muss ja eine Selektion der einzelnen Förderjobs vornehmen.

Daher meine Idee mit den 75 "Statemachines". Ich würde den Zustand und den Bearbeitungssgrad von jedem Werkstück speichern und daran auch die Auswahl der nötigen Jobs für den Roboter selektiren.

Die Frage ist, wie ich diese Selektion für die Roboterjobs machen kann. Theoretisch würde ich die 75 Arrays (von Slot 1 zu 2) durchsuchen und wenn ein Förderjob offen ist und die Unit empfnagsbereit, würde ich den Job ausführen. Der Roboter würde dann den Job bekommen und das Werkstück verschieben.

Was meint ihr zu dem vorgehen?

Hier noch ein Schema für den Speicher:


Hier würden mal die Anweisungen für den Förderprozess auf die 75 Werkstücke geschrieben. Jedes Werkstück kann 16 mal gefördert werden. Der letzte Schritt muss dann aber wieder zum Lager und Ausgangsslot führen.

Hier gehts ja schon um viele Daten.. Larry hat da schon recht, ich hingegen würde aber das nicht alles in der Steuerung vorhalten sondern soweit wie möglich auf eine Datenbank auslagern.

@Tmbiz habt ihr da schon mal drüber nach gedacht und das evtl sogar schon evaluiert?

Wenn dir 0..255 reicht tut es auch ein Unsigned Integer, der spart Platz Ist bei der Menge der Daten die hier wohl anfallen auf der Steuerung nicht verkehrt sich mal über die verwendeten Datentypen auch Gedanken zu machen.. so kann viel Speicher gespart werden.

Auch in deinem Screenshot eins obendrüber. Muss es denn ein reiner Integer sein oder tut es auch ein signed oder sogar unsigned Integer?

Vielen Danke für die Rückmeldung. Aktuell geht es tatsächlich nur mal um eine Strategie in der Programmierung für den Förderprozess. Aber du hast Recht, die Datentypen sind wichtung und ich werde das dann berücksichtigen.

FIFOs und Materialhandling ohne WTs

Was meinst du genau damit? Habe ich da etwas übersehen?

 

[DCDCDC]

Was meinst du genau damit? Habe ich da etwas übersehen?

Nene, keine Sorge!

Bei WTs usw könnten man dann noch mehr für Datenbank argumentieren.. über die Jahre hat man zumindest in den Projekten in denen ich war, immer mehr dazu tendiert nur die WT Nummer auf dem RFID vorzuhalten und den Rest über Datenbankanfragen zu machen.. da gabs auch noch andere alte Projekte wo man sämtliche Daten auf dem WT mitgeschleppt hatte, ist ja heutzutage aber nicht mehr notwendig/zeitgemäß.. du hast ja nur zwei Roboter die deine Werkstücke hin und her schmeissen, da ist das eher nicht so gut umzusetzen.

 

[Blockmove]

alte Projekte wo man sämtliche Daten auf dem WT mitgeschleppt hatte, ist ja heutzutage aber nicht mehr notwendig/zeitgemäß..

Du hast Recht. Notwendig ist es heute nicht mehr. Es wird aber aber trotzdem oft noch gemacht. Das RFID-Handling ist meist einfacher und schneller als Anfragen bei nem MES-System oder einer Datenbank.

 

[Tmbiz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mal schnell eine andere Frage:

Ich stehe gerade etwas auf dem Schlauch und sehen den Fehler nicht. Ich möchte nun das 2D Array durchsuchen. Dazu habe ich zwei FOR-Schleifen:

IF "DataHMI".startSuche THEN
"DataHMI".startSuche := 0;

// Slot Schleife:
FOR #SuchIndexSlot := 1 TO 75 DO
"DataHMI".test_SuchIndexSlot := #SuchIndexSlot;

// Job Schleife:
FOR #SuchIndexSlotTask := 1 TO 16 DO
"DataHMI".test_SuchIndexSlotTask := #SuchIndexSlotTask;

IF "DataFlowManager".Slot[#SuchIndexSlot].sequenz[#SuchIndexSlotTask].bearbeitungsstatus = 0 THEN
EXIT;
END_IF;

END_FOR;

END_FOR;
END_IF;

Die erste Schleife soll den Slot bestimmen 1-75. Die andere Schleife soll den Job (1-16) aus einem Slot wählen. Die Schleifen sollen solange laufen, bis sie einen Eintrag mit dem Wert "0" in der Variable "bearbeitungsstatus" finden. Aber aktuell werden die Schleifen nicht verlassen. Bzw. nur die 1-16

Kann mir jemand sagen, wie ich das machen muss?

 

[DCDCDC]

Ich glaube du musst die Schleifen verschachteln, wenn ich mich nicht täusche.

FOR <hier 0 bis 75> DO
    FOR <hier 0 bis 16> DO
        ...
    END_FOR;
    ...
END_FOR;

 

[DCDCDC]

Du hast Recht. Notwendig ist es heute nicht mehr. Es wird aber aber trotzdem oft noch gemacht. Das RFID-Handling ist meist einfacher und schneller als Anfragen bei nem MES-System oder einer Datenbank.

Je mehr Daten da drauf halt auch liegen desto länger und komplizierter wird auch lesen/schreiben + du musst genau aufpassen welche Bereiche du schreibst.. sonst geht dir der Fahrweg oder Qdaten verloren. Werden aber Daten direkt mit der Datenbank ausgetauscht sind sie direkt verfügbar, können zentral bearbeitet und weiterverwendet werden, sind direkt zugewiesen und der WT muss nicht viel wissen, die Station auch nicht.. steht ja alles in der Datenbank und kann dort direkt angefragt werden. Zudem lehne ich mich mal aus dem Fenster dass bei den Datenmengen mit denen ich zu tun hatte (es wurden über Jahre immer mehr und mehr..) es genauso lange dauert diese nach dem (Teil)Prozess diese wegzuschicken oder einmal alles am Ende auf den Rfid zu schreiben.

Zumindest bin ich, in dem Bereich in dem ich unterwegs bin/war, davon überzeugt, dass das auslagern in die Datenbank von so vielen Daten wie möglich, sinnvoll ist.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn dir 0..255 reicht tut es auch ein Unsigned Integer, der spart Platz

UINT spart gegenüber INT nur dann Platz, wenn der WerteBereich 32768..65535 genutzt werden soll, aber keine negativen Zahlen.
Man erspart sich dann die Verwendung des DatenTyps DINT, der 32 statt 16 Bit belegt.
Du meinst anscheinend den DatenTyp USINT, also Unsigned Short INTeger mit 8 Bit und WerteBereich 0..255.

Muss es denn ein reiner Integer sein oder tut es auch ein signed oder sogar unsigned Integer?

Ein "reiner INT" ist doch ein "signed INT". 16 Bit mit WerteBereich -32768..0..32767.
Und ein Unsigned INTeger (UINT) hat 16 Bit und einen WerteBereich 0..65535.

 

[DCDCDC]

UINT spart gegenüber INT nur dann Platz, wenn der WerteBereich 32768..65535 genutzt werden soll, aber keine negativen Zahlen.
Man erspart sich dann die Verwendung des DatenTyps DINT, der 32 statt 16 Bit belegt.
Du meinst anscheinend den DatenTyp USINT, also Unsigned Short INTeger mit 8 Bit und WerteBereich 0..255.

Ein "reiner INT" ist doch ein "signed INT". 16 Bit mit WerteBereich -32768..0..32767.
Und ein Unsigned INTeger (UINT) hat 16 Bit und einen WerteBereich 0..65535.

Genau, meinte den Short.. mein Kopf macht aus USInt immer nur unsigned.. mein Fehler!

 

[Tmbiz]

So, die Jobsuche funktioniert:

IF "DataHMI".startSuche THEN
"DataHMI".startSuche := 0;
#exitFor := 0;

// Slot Schleife:
FOR #SuchIndexSlot := 1 TO 75 DO
"DataHMI".test_SuchIndexSlot := #SuchIndexSlot;

// Job Schleife:
FOR #SuchIndexSlotTask := 1 TO 16 DO
"DataHMI".test_SuchIndexSlotTask := #SuchIndexSlotTask;

IF "DataFlowManager".Slot[#SuchIndexSlot].sequenz[#SuchIndexSlotTask].bearbeitungsstatus = 0 THEN
#exitFor := 1;
END_IF;

IF #exitFor THEN
EXIT;
END_IF;


END_FOR;

IF #exitFor THEN
EXIT;
END_IF;

END_FOR;
END_IF;

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kannst du mir sagen, was diese Index- oder Schlüsselnummer genau machen soll. Verständlich ist, dass damit eine eindeutige Zuordnung ermöglicht wird. Doch was möchtest du dann genau über diese eindeutige Erkennung/ Zuordnung machen. Ich habe da eine Vermutung, möchte dich aber nicht falsch interpretieren.

Ich hatte mir das so gedacht :
dein Werkstück-Datensatz liegt nur einmal in der Steuerung und hat als Identifikation halt diese Nummer.
In der Anlage mußt du ja nun einen Jobverteiler haben - hier würde jetzt z.B. dann nur Station 1 den Index 27 zugewiesen bekommen und die hat dann selbst herauszufinden was sie jetzt damit zu machen hat. Das muss dann aber natürlich auch tiefer gehen. Wenn nämlich wie du schreibst, ein Ablauf auch St.1 - St.5 - St.6 - St.1 usw. sein kann dann muss St.1 natürlich schauen, was sie jetzt (wieder) zu machen hat. Gleiches gilt für eine möglichen Wiederanlauf der Anlage nach einem Stop. Möglicherweise hat St.1 noch nicht alles abgearbeitet - dann muss sie halt als erstes schauen "ist mein Job bis hierhin erledgt ?" und dann dem Jobverteiler melden "ich habe fertig - Robbi nimm das Teil und gib es dem Nächsten" ... oder so
An dieser Stelle kann man natürlich richtig tief einsteigen und ggf. wirst du den Arbeitsplan (die "Statemachine") noch 3 bis 7 Mal überdenken ...

 

[Larry Laffer]

Noch etwas - fällt mir gerade noch ein :
Wenn deine St.1 (z.B.) dasselbe Ding mehrmals "in die Hand bekommt" - macht sie dann jedes Mal dassselbe damit ? Oder beim 2. Mal etwas Anderes als beim 1. Mal ? Wenn dies der Fall wäre dann müßte deine Statemachine natürlich auch noch die Info enthalten, was jeweils zu tun ist.

Ich habe mir deinen UDT jetzt nicht im Detail angesehen - ich denke aber auch mal, dass ich als Aussenstehender, der auch kein richtiges Gefühl für die Maschine hat, vieles sowieso nicht im Deatil einschätzen kann ...