-> Hier kostenlos registrieren
Wenn es garantiert keinen Gegenverkehr geben soll, kann es an jeder Kreuzung nur zwei zulässige Richtungen geben?
TIA Routing Algorithmus für eine Förderstrecke gesucht
- Ersteller Bavilo
- Erstellt am
-> Hier kostenlos registrieren
Eine Kreuzung könnte 3 Richtungen haben.
- Abbiegen auf die "Gegenfahrbahn" aber dann weiter in deren Flussrichtung
- Geradeaus
- Abbiegen auf eine Einlagerstrecke
-> Hier kostenlos registrieren
Eine jede Station der Fördertechnik(mögliches Ziel) entspricht einem Knoten.
Jeder Knoten hat Kanten. Dies sind die möglichen Abzweigungen.
Der MFR schickt ein neues Ziel und du berechnest vom derzeitigen Standpunkt(Quell-Knoten) einmalig die Route bis zum Zielknoten.
Diese Route bleibt an der Palette bis Ziel erreicht oder es wird ein neues Ziel vorgegeben.
Du pflegst eine einzige Adjazenzliste(Beziehungen der Knoten zu den anderen Knoten).
Kommen Knoten(Weichen, Förderbänder…) dazu oder weg wird einfach die Beziehung zu anderen Knoten bearbeitet.
Ob du jetzt in den dezentralen Listen(Routingtable) rumsuchst oder einen Algorithmus auf die Beziehungen loslässt macht in der Wartbarkeit dann schon einen Unterschied.
Es empfiehlt sich ev. die Berechnung auf mehrere Zyklen aufzuteilen…
Obwohl, bei drei Kanten und eine Routenlänge von vielleicht 10 Knoten(da der MFR ja eh immer Teilstrecken vorgibt) ist die Route schnell ermittelt…
Jeder Knoten hat Kanten. Dies sind die möglichen Abzweigungen.
Der MFR schickt ein neues Ziel und du berechnest vom derzeitigen Standpunkt(Quell-Knoten) einmalig die Route bis zum Zielknoten.
Diese Route bleibt an der Palette bis Ziel erreicht oder es wird ein neues Ziel vorgegeben.
Du pflegst eine einzige Adjazenzliste(Beziehungen der Knoten zu den anderen Knoten).
Kommen Knoten(Weichen, Förderbänder…) dazu oder weg wird einfach die Beziehung zu anderen Knoten bearbeitet.
Ob du jetzt in den dezentralen Listen(Routingtable) rumsuchst oder einen Algorithmus auf die Beziehungen loslässt macht in der Wartbarkeit dann schon einen Unterschied.
Es empfiehlt sich ev. die Berechnung auf mehrere Zyklen aufzuteilen…
Obwohl, bei drei Kanten und eine Routenlänge von vielleicht 10 Knoten(da der MFR ja eh immer Teilstrecken vorgibt) ist die Route schnell ermittelt…
Das hört sich interessant an!
"du berechnest vom derzeitigen Standpunkt(Quell-Knoten) einmalig die Route bis zum Zielknoten"
Wie genau würde ich das anstellen? Da bräuchte ich ja wieder etwas wie den Dijkstra Algorithmus der mir den kürzesten Weg berechnet.
"Du pflegst eine einzige Adjazenzliste(Beziehungen der Knoten zu den anderen Knoten)."
Das habe ich nicht genau verstanden. Im Moment haben ja alle meine Knoten eine Liste in der alle Anderen Knoten enthalten sind und der nächste Weg um dort hinzugelangen.
Wie pflege ich nur "eine" Liste?
"du berechnest vom derzeitigen Standpunkt(Quell-Knoten) einmalig die Route bis zum Zielknoten"
Wie genau würde ich das anstellen? Da bräuchte ich ja wieder etwas wie den Dijkstra Algorithmus der mir den kürzesten Weg berechnet.
"Du pflegst eine einzige Adjazenzliste(Beziehungen der Knoten zu den anderen Knoten)."
Das habe ich nicht genau verstanden. Im Moment haben ja alle meine Knoten eine Liste in der alle Anderen Knoten enthalten sind und der nächste Weg um dort hinzugelangen.
Wie pflege ich nur "eine" Liste?
Der Dijkstra Algorithmus ist da passend. Die Wertigkeit der Route ergibt sich einfach dadurch, dass ja eine Schleife hochgezählt wird und du in der Beziehungsliste dies dadurch priorisierst. Wäre Über Kante 4 auch das Ziel wie über Kante 1 zu erreichen, dann zieht immer Kante 1(links rum). Ist eine Störung auf Route mit Kante 1, dann wird das Ziel nicht erreicht und kommt nach einigen Schleifendurchläufen über Kante 4 ans Ziel….
Stimmt, du hast eine Beziehungsliste an jedem Knoten.
Gehe davon aus, das eine CPU den Palettentransport mittels definierter Übergabezustände verwaltet.
Damit du nicht an jedem Knoten neu nachsehen musst, empfiehlt es sich bei Start des neuen Auftrags eine Route einmalig zu ermitteln und diese an der Palette(Ladeeinheit?) „mitzuführen“.
Steht die Ladeeinheit auf einer Kreuzung so wird dann diese dynamisch erstellte Liste abgearbeitet.
Stimmt, du hast eine Beziehungsliste an jedem Knoten.
Gehe davon aus, das eine CPU den Palettentransport mittels definierter Übergabezustände verwaltet.
Damit du nicht an jedem Knoten neu nachsehen musst, empfiehlt es sich bei Start des neuen Auftrags eine Route einmalig zu ermitteln und diese an der Palette(Ladeeinheit?) „mitzuführen“.
Steht die Ladeeinheit auf einer Kreuzung so wird dann diese dynamisch erstellte Liste abgearbeitet.
-> Hier kostenlos registrieren
Also die Liste auf der Kreuzung abzuarbeiten ist kein Problem.
Aber den Dijkstra Algorithmus zu implementieren wird glaube ich zur Mammutaufgabe.
Ich Stelle mir auch die Frage was ist bei einer Anlage mit über 100 Stellplätzen und mehreren Paletten die gleichzeitig einen Auftrag bekommen.
Ob da eine 1516-F ausreicht um die kürzesten Wege zu berechnen?
Außerdem...ist Dijkstra hierfür wirklich am besten? Die Kanten habe ja alle im Prinzip die selben Kosten. Es gilt ja nur den Weg mit den wenigsten Kanten zu finden...
Aber den Dijkstra Algorithmus zu implementieren wird glaube ich zur Mammutaufgabe.
Ich Stelle mir auch die Frage was ist bei einer Anlage mit über 100 Stellplätzen und mehreren Paletten die gleichzeitig einen Auftrag bekommen.
Ob da eine 1516-F ausreicht um die kürzesten Wege zu berechnen?
Außerdem...ist Dijkstra hierfür wirklich am besten? Die Kanten habe ja alle im Prinzip die selben Kosten. Es gilt ja nur den Weg mit den wenigsten Kanten zu finden...
- Beiträge
- 9.191
- Reaktionspunkte
- 2.936
Das war doch beim früheren RIP-Protokoll bei der Netzwerktechnik so. Da zählten nur die Anzahl der Hops, also die Anzahl der dazwischen vorhandenen Routern. Hatte aber ein paar Nachteile, warum mittlerweile dort auch ein Verfahren was den Dijkstra-Algorithmus verwendet zum Einsatz kommt.
Ergänzung: https://de.wikipedia.org/wiki/Distanzvektoralgorithmus
Ergänzung: https://de.wikipedia.org/wiki/Distanzvektoralgorithmus
- Beiträge
- 22.070
- Reaktionspunkte
- 6.861
Reicht es nicht, wenn jede Kreuzung den Weg zu jedem Ziel (oder zumindest Zielsektor) kennt? Und die Palette nur weiß, zu welchem Ziel sie fahren soll? Wenn eine Palette an einer Kreuzung ankommt, meldet sie wo sie hin will und die Kreuzung schickt sie weiter. Da braucht nicht viel gerechnet werden, insbesondere nicht in Schleifen gesucht werden. Es muß nur in hinterlegten Tabellen mit höchstens 100 Einträgen nachgeschaut werden. So wie Du im Beitrag #1 beschrieben hast.
Muss denn bei jedem Transport immer wieder mit teuren Höchstleistungs-CPU etwas aufwendig berechnet werden, was der Programmierer auch hätte einmalig vorberechnen können?
Harald
Muss denn bei jedem Transport immer wieder mit teuren Höchstleistungs-CPU etwas aufwendig berechnet werden, was der Programmierer auch hätte einmalig vorberechnen können?
Harald
MFreiberger
Level-3
- Beiträge
- 2.875
- Reaktionspunkte
- 763
-> Hier kostenlos registrieren
Moin,
eigentlich ist das ja nichts anderes, wie in der Netzwerktechnik. Jeder Knoten bzw. Entscheidungspunkt ist ein Router, in dem eine Routingtabelle hinterlegt ist.
Je nach MFR und Ausdehnung der Anlage kann es sinnvoll sein, in der Routingtabelle alle möglichen Ziele oder nur die nächsten möglichen Knoten (Router) zu hinterlegen.
Wenn alle möglichen Ziele hinterlegt sind (kleine Anlagen), kann der MFR direkt das Endziel vorgeben und jeder Knoten "weiß" dann, wo es hingeht.
Wenn nur jeweils der nächste Knoten bekannt ist/sein kann (und das ist bei ausgedehnten Anlagen mit Brandabschnitten o.ä. sinnvoll), dann muss der MFR das Routing übernehmen und das nächste Ziel eintragen (unter uns: das ist ja die zentrale Aufgabe eines MFR!). Je nach Art der Programmierung kann er das machen, während sich die Palette zum nächsten Knoten bewegt oder eben erst, wenn die Palette am nächsten Knoten angekommen ist.
Jeder Förderplatz braucht dabei eine anlagenweit eindeutige Kennzeichnung. Am besten einfach durchnummerieren.
In der Routingtabelle steht z.B:
Wie man jetzt die Routingtabelle gestaltet ist egal. Es muss dem Ziel nur eine Richtung für den Förderer zugeordnet sein.
eigentlich ist das ja nichts anderes, wie in der Netzwerktechnik. Jeder Knoten bzw. Entscheidungspunkt ist ein Router, in dem eine Routingtabelle hinterlegt ist.
Je nach MFR und Ausdehnung der Anlage kann es sinnvoll sein, in der Routingtabelle alle möglichen Ziele oder nur die nächsten möglichen Knoten (Router) zu hinterlegen.
Wenn alle möglichen Ziele hinterlegt sind (kleine Anlagen), kann der MFR direkt das Endziel vorgeben und jeder Knoten "weiß" dann, wo es hingeht.
Wenn nur jeweils der nächste Knoten bekannt ist/sein kann (und das ist bei ausgedehnten Anlagen mit Brandabschnitten o.ä. sinnvoll), dann muss der MFR das Routing übernehmen und das nächste Ziel eintragen (unter uns: das ist ja die zentrale Aufgabe eines MFR!). Je nach Art der Programmierung kann er das machen, während sich die Palette zum nächsten Knoten bewegt oder eben erst, wenn die Palette am nächsten Knoten angekommen ist.
Jeder Förderplatz braucht dabei eine anlagenweit eindeutige Kennzeichnung. Am besten einfach durchnummerieren.
In der Routingtabelle steht z.B:
| ZIEL | RICHTUNG |
| 23 | 1 |
| 35 | 1 |
| 43 | 2 |
| 56 | 3 |
Wie man jetzt die Routingtabelle gestaltet ist egal. Es muss dem Ziel nur eine Richtung für den Förderer zugeordnet sein.
- Beiträge
- 11.649
- Reaktionspunkte
- 3.892
Ist das wirklich eine gute Idee?
Wenn eine Fördertechnik so konzipiert ist, dass mehrere Wege zum Ziel führen können, dann hat das meist einen Grund.
Sei es nun Kapazität und / oder Ausfallsicherheit.
Tritt nun auf dem Weg der Palette zum Ziel ein Problem auf, dann ist die Route u.U. nicht mehr möglich und ich schieß mich selber ins Knie.
Eine Palette ist eben doch etwas anderes als ein TCP/IP-Paket.
- Beiträge
- 22.195
- Reaktionspunkte
- 7.379
Fördertechnik mit vielen Dreh- Eckumsetzern und vor allem Kreuzungen sind deutlich komplexer zu programmieren als viele es annehmen.
Ich habe es früher immer so gemacht, dass jede Palette einen Datensatz mitgeliefert bekommt, der von Transportband zu Transportband mitwandert. An Kreuzungspunkten habe ich dann anhand des Ziel ausgewertet, wohin es weitergeht. Das hat dann auch den Vorteil, wenn es an einer Kreuzung zwei Möglichkeiten gibt um zum Ziel zu kommen ich aber weiß, dass Strecke A überlastet / gewartet / defekt ist, dann konnte ich flexibel entscheiden die Strecke B zu nutzen. So konnte man auch die Auslastung der einzelnen Strecken etwas beeinflussen, indem ein paar Paletten z.B. den etwas längeren Weg genommen haben, dafür aber den kürzeren Weg entlastet haben.
Was natürlich auch zu bedenken ist sind:
-Laufzeitüberwachungen
-Palette wird von Hand entfernt ( weil umgekippt oder sonst was )
-Handbetrieb
-Palette wird von Hand aufgesetzt ( vorher umgekippt und nun wieder aufgesetzt.... )
-Sichere Datenverfolgung ( verliert man z.B. wegen Handbetrieb oder weil die Palette hängen blieb den Datensatz, was dann..... )
-Wohin soll die Palette fahren, falls das Ziel nicht bekannt ist ( Datensatz verloren, warum auch immer... )
Ich habe es früher immer so gemacht, dass jede Palette einen Datensatz mitgeliefert bekommt, der von Transportband zu Transportband mitwandert. An Kreuzungspunkten habe ich dann anhand des Ziel ausgewertet, wohin es weitergeht. Das hat dann auch den Vorteil, wenn es an einer Kreuzung zwei Möglichkeiten gibt um zum Ziel zu kommen ich aber weiß, dass Strecke A überlastet / gewartet / defekt ist, dann konnte ich flexibel entscheiden die Strecke B zu nutzen. So konnte man auch die Auslastung der einzelnen Strecken etwas beeinflussen, indem ein paar Paletten z.B. den etwas längeren Weg genommen haben, dafür aber den kürzeren Weg entlastet haben.
Was natürlich auch zu bedenken ist sind:
-Laufzeitüberwachungen
-Palette wird von Hand entfernt ( weil umgekippt oder sonst was )
-Handbetrieb
-Palette wird von Hand aufgesetzt ( vorher umgekippt und nun wieder aufgesetzt.... )
-Sichere Datenverfolgung ( verliert man z.B. wegen Handbetrieb oder weil die Palette hängen blieb den Datensatz, was dann..... )
-Wohin soll die Palette fahren, falls das Ziel nicht bekannt ist ( Datensatz verloren, warum auch immer... )
MFreiberger
Level-3
- Beiträge
- 2.875
- Reaktionspunkte
- 763
-> Hier kostenlos registrieren
Das ist ja in der Tat so. Der Aufbau einer Fördertechnik ist bekannt. Es gibt nichts, was ungeplant hinzukommt.Ist das wirklich eine gute Idee?
Wenn eine Fördertechnik so konzipiert ist, dass mehrere Wege zum Ziel führen können, dann hat das meist einen Grund.
Sei es nun Kapazität und / oder Ausfallsicherheit.
Tritt nun auf dem Weg der Palette zum Ziel ein Problem auf, dann ist die Route u.U. nicht mehr möglich und ich schieß mich selber ins Knie.
Eine Palette ist eben doch etwas anderes als ein TCP/IP-Paket.
Von daher ist es auch üblicherweise so, dass die Wege bekannt sind und nicht dynamisch berechnet werden.
Bei Palettenanlagen (wie in dem Beispiel vom TS), gibt es auch wenig Alternativrouten (Vielleicht noch Abkürzungen in einem Loop). In Behälteranlagen sieht dass dann etwas anders aus. Aber wie gesagt: die Wegeberechnung übernimmt der MFR. Dazu ist er da.
Und die Routen werden fest geplant; deren Umsetzung ist ein fast zu vernachlässigender Aufwand im Gegensatz zu der Installation der Fördertechnik und Maschineninbetriebnahme.
winnman
Level-3
- Beiträge
- 2.237
- Reaktionspunkte
- 407
Kann man da nicht einfach das System in Koordinaten abbilden (x und y)
Dann hat jede Station und jede Kreuzung eine eindeutige Koordinate.
An der Kreuzung (bzw kurz davor) dann prüfen welche 3 Wege frei sind.
Anhand der Koordinaten lässt sich doch jetzt leicht entscheiden wo es Richtung Ziel geht
Dann hat jede Station und jede Kreuzung eine eindeutige Koordinate.
An der Kreuzung (bzw kurz davor) dann prüfen welche 3 Wege frei sind.
Anhand der Koordinaten lässt sich doch jetzt leicht entscheiden wo es Richtung Ziel geht
- Beiträge
- 11.649
- Reaktionspunkte
- 3.892
Das nichts hinzukommt ist klar
Allerdings kann während der Transportzeit der Palette ungeplant was wegkommen (Defekt, Störung, ...).
Hast du nun Paletten mit vorgegebener Route entsteht ein Problem.
Sucht das System an jeder Kreuzung / Knoten neu, bleibt man flexibler.
Rechenleistung ist ja heute eigentlich kein Problem mehr.
- Beiträge
- 22.070
- Reaktionspunkte
- 6.861
-> Hier kostenlos registrieren
Das ist doch ein Grund dafür, eben nicht schon beim Start die komplette Route zu suchen und festzulegen. Die Regeln für Alternativen müssen so oder so verarbeitet werden, egal ob der komplette Weg beim Start berechnet wird oder erst unterwegs an den Alternativ-Knoten. Macht man es erst unterwegs während der Fahrt, dann kann man noch auf dynamische Änderungen der Bedingungen reagieren. Macht man es vorher, dann kann der vorberechnete Weg unmöglich werden. Wenn dann in der Not ein neuer Weg berechnet wird, dann war die ganze schöne Berechnung des kompletten Wegs vor dem Start für die Katz - kann man also gleich ganz weglassen und immer erst entscheiden, wenn die Palette irgendwo ankommt wo entschieden werden muß. Und da muß auch nicht der komplette Rest-Weg gesucht werden, sondern nur der Weg zur nächsten Alternative, die in der Richtung zum Ziel liegt.
Harald
So ist es umgesetzt. Es wird irgendwann mühsam dies vorzuberechnen wenn die Anlagen größer werden.
Einem Algorithmus wäre es egal wie groß die Anlage ist.
Natürlich müssen wir die Zykluszeit im Auge behalten.
Bei uns übernimmt die Wegfindungsaufgabe an jeder Entscheidungsstelle der MFR. Das hat den Vorteil, dass es auch egal ist, ob beim Fördern jetzt ein SPS-Bereich in einen neuen gewechselt wird. Im Schnitt steht eine Palette dadurch ca. 400ms auf einem Entscheidungsplatz, bevor es weiter geht. Dafür ist zu jederzeit die maximale Flexibilität gegeben, was belegte Routen/Störungen und auch mögliche Auftragsänderungen angeht gegeben. Der Auftrag ist dann in jedem Fall immer nur Quelle X zu neuem Ziel Y, wobei Y die nächste Entscheidungsstelle ist. Im MFR sind die Routen bereits vorgeplant, werden aber bei geänderten Bedingungen aktualisiert.
Ein solches System sinnvoll auf einer SPS (vor allem mit mehreren SPSen) realisieren zu wollen, ist auf jeden Fall deutlich aufwändiger. Hier muss sich lediglich um die sinnvolle Anbindung SPS/MFR gekümmert werden, damit der MFR immer alle nötigen Informationen hat und den Routenfindungsalgorithmus im Hintergrund über eine DB oder ähnliches durchführen lassen kann.
Ein solches System sinnvoll auf einer SPS (vor allem mit mehreren SPSen) realisieren zu wollen, ist auf jeden Fall deutlich aufwändiger. Hier muss sich lediglich um die sinnvolle Anbindung SPS/MFR gekümmert werden, damit der MFR immer alle nötigen Informationen hat und den Routenfindungsalgorithmus im Hintergrund über eine DB oder ähnliches durchführen lassen kann.
- Beiträge
- 22.070
- Reaktionspunkte
- 6.861
-> Hier kostenlos registrieren
Man sollte nicht alle möglichen beliebig aufwändigen Berechnungen und Datenverarbeitungen in der SPS realisieren. Die ist dafür nicht gedacht und auch nicht gut geeignet.
Harald
Harald
Ich kenne dort zwei verschiedene Systeme, welche bei uns zum Einsatz kommen.
Variante 1:
Entscheidungsstellen = RFID-Schreib-Lesegeräte
Werkstückträger = Informationen wie z.B. Ziel enthalten
Anlage ist sinnvoll in Segmente und somit auch Nummernbereiche bzw. Zielnummern aufgeteilt.
Somit braucht man an z.B. Entscheidungsstellen erstmal nur schauen
Ziel (>= 1 und < 100) = links abbiegen
Ziel (>= 100 und < 200) = rechts abbiegen
....
Sobald die Werkstückträger dann in die Bereiche gefahren sind und es dort auch mehrere Entscheidungsstellen gibt, muss natürlich etwas kleiner aufgelöst werden, Bsp.:
Ziel (>= 1 und <10) = links
......
Aber das ist dann stark davon abhängig, wie viele Kreuzungen etc. es dann noch in den Zielsegmenten gibt. Somit muss erstmal nicht an jeder Entscheidungsstelle eine komplette Liste durchsucht werden.
Variante 2:
Entscheidungsstellen = RFID-Schreib-Lesegeräte mit eindeutiger Kennung
Werkstückträger = UUID des Tags
Anlage ist sinnvoll in Segmente und somit auch Nummernbereiche bzw. Zielnummern aufgeteilt.
Auf Leitrechnerebene gibt es dann natürlich eine komplette Datenbank etc. und unter anderem wird dort eine Routingtabelle gepflegt.
Dort enthalten sind die Ziele der Anlagen (Spalten) und die Entscheidungsstellen (Zeilen).
Für die Richtungen sind Nummer festgelegt
1 = Haupttransportrichtung
2 = rechts von Haupttransportrichtung
3 = entgegen der Haupttransportrichtung
4 = links von Haupttransportrichtung
..
Die Tabelle muss natürlich einmal (oder bei Erweiterung) gepflegt werden. Dort muss an jeder Entscheidungsstelle betrachtet werden, wie ein Werkstrückträger mit entsprechendem Ziel auch zu seinem Ziel gelangt, anhand des Layouts, Bsp.:
In der Datenbank sind dann informationen verknüpft wie:
UUID = Identifizierung Werkstückträger (gibt es natürlich nur 1 mal im System)
Informationen über das Werkstück auf dem Werkstückträger wie z.B. Ziel
An jeder Entscheidungsstelle wird dann am Leitrechner eine Richtungsanfrage gemacht:
Anfrage:
Kennung Entscheidungsstelle
UUID Werkstückträgers
Antwort:
Richtung die gefördert werden soll (Informationen aus der Datenbank über das Ziel des Werkstückträgers und der Routingtabelle)
So eine Routingtabelle könnten man sich natürlich auch Zentral in einem DB ablegen und das auf SPS-Seite pflegen und jede Entscheidungsstelle rennt einfach durch das 2-Dimensionale Array und sucht sich seine Richtung. Da muss natürlich die Zykluszeit betrachtet werden, wenn z.B. 45 Entscheidungsstellen gleichzeitig ein Werkstückträger haben und durch das Array laufen.
An Entscheidungsstellen wo man eventuell mehrere Möglichkeiten hat den Werkstückträger ans Ziel zu bringen muss man halt gesondert einfach Ausnahmen programmieren, um das Routing zu überstimmen.
Normal gibt es in so einem Layout einen Hauptmaterialfluss (=Haupttransportrichtung). Sollten die Hauptstrecken z.B. voll sein oder gesperrt oder was auch immer, muss man dann über andere Auswertungen (z.B. nach einer bestimmten Wartezeit, über Erkennung anderer Auslastungen etc.) dann einfach eine andere Richtung starten.
Auch kann das gewollt sein um z.B. ein Zwangsrotieren oder ein Kreisen zu erzwingen, bis sich irgendwo ein Stau aufgelöst hat etc., damit der Rückstau nicht noch andere Bereiche lahm legt.
Aber das muss natürlich nicht an jeder Entscheidungsstelle gemacht werden. Normal sollten solche Stellen schon in der Layoutplanung und Simulation mit betrachtet werden, wodurch dann solche "Sonderfälle" nur an einer überschaubaren Anzahl an Entscheidungsstellen ausprogrammiert werden müssen.
-chris
Variante 1:
Entscheidungsstellen = RFID-Schreib-Lesegeräte
Werkstückträger = Informationen wie z.B. Ziel enthalten
Anlage ist sinnvoll in Segmente und somit auch Nummernbereiche bzw. Zielnummern aufgeteilt.
Somit braucht man an z.B. Entscheidungsstellen erstmal nur schauen
Ziel (>= 1 und < 100) = links abbiegen
Ziel (>= 100 und < 200) = rechts abbiegen
....
Sobald die Werkstückträger dann in die Bereiche gefahren sind und es dort auch mehrere Entscheidungsstellen gibt, muss natürlich etwas kleiner aufgelöst werden, Bsp.:
Ziel (>= 1 und <10) = links
......
Aber das ist dann stark davon abhängig, wie viele Kreuzungen etc. es dann noch in den Zielsegmenten gibt. Somit muss erstmal nicht an jeder Entscheidungsstelle eine komplette Liste durchsucht werden.
Variante 2:
Entscheidungsstellen = RFID-Schreib-Lesegeräte mit eindeutiger Kennung
Werkstückträger = UUID des Tags
Anlage ist sinnvoll in Segmente und somit auch Nummernbereiche bzw. Zielnummern aufgeteilt.
Auf Leitrechnerebene gibt es dann natürlich eine komplette Datenbank etc. und unter anderem wird dort eine Routingtabelle gepflegt.
Dort enthalten sind die Ziele der Anlagen (Spalten) und die Entscheidungsstellen (Zeilen).
Für die Richtungen sind Nummer festgelegt
1 = Haupttransportrichtung
2 = rechts von Haupttransportrichtung
3 = entgegen der Haupttransportrichtung
4 = links von Haupttransportrichtung
..
Die Tabelle muss natürlich einmal (oder bei Erweiterung) gepflegt werden. Dort muss an jeder Entscheidungsstelle betrachtet werden, wie ein Werkstrückträger mit entsprechendem Ziel auch zu seinem Ziel gelangt, anhand des Layouts, Bsp.:
| Ziel 100 = Anlage 1 | Ziel 200 = Anlage 2 | Ziel 300 = Anlage 3 | Ziel 400 = Anlage 4 | Ziel 500 = Anlage 5 | |
| Entscheidungsstelle 1 | 1 | 4 | 2 | 4 | 2 |
| Entscheidungsstelle 2 | 4 | 1 | 3 | 2 | 1 |
| Entscheidungsstelle 3 | 2 | 4 | 1 | 3 | 2 |
In der Datenbank sind dann informationen verknüpft wie:
UUID = Identifizierung Werkstückträger (gibt es natürlich nur 1 mal im System)
Informationen über das Werkstück auf dem Werkstückträger wie z.B. Ziel
An jeder Entscheidungsstelle wird dann am Leitrechner eine Richtungsanfrage gemacht:
Anfrage:
Kennung Entscheidungsstelle
UUID Werkstückträgers
Antwort:
Richtung die gefördert werden soll (Informationen aus der Datenbank über das Ziel des Werkstückträgers und der Routingtabelle)
So eine Routingtabelle könnten man sich natürlich auch Zentral in einem DB ablegen und das auf SPS-Seite pflegen und jede Entscheidungsstelle rennt einfach durch das 2-Dimensionale Array und sucht sich seine Richtung. Da muss natürlich die Zykluszeit betrachtet werden, wenn z.B. 45 Entscheidungsstellen gleichzeitig ein Werkstückträger haben und durch das Array laufen.
An Entscheidungsstellen wo man eventuell mehrere Möglichkeiten hat den Werkstückträger ans Ziel zu bringen muss man halt gesondert einfach Ausnahmen programmieren, um das Routing zu überstimmen.
Normal gibt es in so einem Layout einen Hauptmaterialfluss (=Haupttransportrichtung). Sollten die Hauptstrecken z.B. voll sein oder gesperrt oder was auch immer, muss man dann über andere Auswertungen (z.B. nach einer bestimmten Wartezeit, über Erkennung anderer Auslastungen etc.) dann einfach eine andere Richtung starten.
Auch kann das gewollt sein um z.B. ein Zwangsrotieren oder ein Kreisen zu erzwingen, bis sich irgendwo ein Stau aufgelöst hat etc., damit der Rückstau nicht noch andere Bereiche lahm legt.
Aber das muss natürlich nicht an jeder Entscheidungsstelle gemacht werden. Normal sollten solche Stellen schon in der Layoutplanung und Simulation mit betrachtet werden, wodurch dann solche "Sonderfälle" nur an einer überschaubaren Anzahl an Entscheidungsstellen ausprogrammiert werden müssen.
-chris
