---

Hallo Forum,

ich (Studentin) bin dabei für meine Diplomarbeit eine Anlage zu simulieren. Diese besteht aus mehreren Einzelstationen die alle über Förderstrecken / Flusssteuerungen miteinander verbunden sind. Insgesamt sind es ca. 400 Elemente. Die einzige Programmierung die ich für jede der Flusssteuerungen vorgenommen habe, sieht folgendermaßen aus:

(r:integer):integer
is
do
-- @ ist das BE
if @.name ="blau" then
if F_nicht_angetrieben12.AnzahlBEs = F_nicht_angetrieben12.Kapazitaet then
return 1;
else
return 2;
end;
else
return 1;
end;
end;

Davon gibt es 25 Methoden die genauso aufgebaut sind, nur werden unterschiedliche Strecken betrachtet. Für jede Flusssteuerung eine.

Generiert die Quelle alle 30 s ein Teil dann läuft die Simulation mehrere Wochen. Soll sie allerdings alle 15 s ein Teil generieren ist nach 3:12:19.9848 Stunden Schluss. Der Grund dafür ist nicht zu erkennen. Es werden keinerlei Fehlermeldungen oder ähnliches ausgegeben.Bis dahin sind 22.998.067 Events gezählt worden. An der Rechnerauslastung kann es nicht liegen. Auf verschiedenen Rechnern mit unterschiedlichen Auslastungen stoppt die Simulation immer nach der gleichen Zeit. Hat Plant Simulation einen limitierenden Faktor den ich nicht kenne ? Hat jemand von euch vielleicht eine Idee woran das ansonsten noch liegen könnte ? 

Ich arbeite mit einer Educational License Version 8.2

Danke

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Marie,
solche Probleme treten in der Regel auf, wenn ein Umlagern auf einen nachgelagerten Baustein fehlschlägt. Das BE bleibt dann an der Stelle liegen, wo das Umlagern fehlgeschlagen ist. Eine Fehlermeldung gibt PS da nicht aus, aber du kannst dir eine erzeugen (siehe Beispielmethode.

Anstatt der Flusssteuerung kannst du auch eine solche Ausgangssteuerung verwenden (wenn ich denn den Fehler richtig erraten habe).

Code:

---

is
    obj : object;
do
    i:= --Anweisung für den Nachfolger
    station:=?.nf(i);
    waituntil station.voll=false prio 1;
    if not @.umlagern(station) then
          debug;
    end;
end;

---

------------------
Grüße,
tsx 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Eingangssteuerung.jpg

Hallo tsx,

ich glaube inzwischen herausgefunden zu haben, dass es nicht an den Flusssteuerungen liegt. An einigen Stellen laufen bei mir Förderstrecken zusammen. Ich habe sie einfach, wie im Anhang zu sehen, modelliert. Das geht wahrscheinlich nicht so. Angenommen bei Förderstrecke1 ist der Ausgang gesperrt und Förderstrecke1 wäre dran das BE an Förderstrecke weiterzugeben. Dann kann Förderstrecke2 nicht weitergeben und alles hängt sich auf... Für den Eingang von Förderstrecken gibt es keine Auswahlmöglichkeiten, also weiß ich nicht nach welchem System Plant die Reihenfolge bestimmt. Ich müßte wohl eine Eingangssteuerung programmieren, die zwischen Förderstrecke1 und Förderstrecke2 wählt, abhängig davon welche Strecke gesperrt ist oder gibt es noch eine einfachere elegante Möglichkeit ?

Schon einmal vielen Dank für die erste Antwort !

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Für den Eingang von Förderstrecken gibt es keine Auswahlmöglichkeiten, also weiß ich nicht nach welchem System Plant die Reihenfolge bestimmt.

---

Plant Simulation macht first-come, first-served.

Zitat:

---

Ich müßte wohl eine Eingangssteuerung programmieren, die zwischen Förderstrecke1 und Förderstrecke2 wählt, abhängig davon welche Strecke gesperrt ist oder gibt es noch eine einfachere elegante Möglichkeit ?

---

Sowas würde ich auch mit der Ziehen-Steuerung machen. Mir ist nur noch nicht ganz klar, warum du den Ausgang der Förderstrecke sperrst und dann keine Funktion zum Entsperren hast 

------------------
Grüße,
tsx 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Beispiel.zip

Hallo tsx,

ganz so ist es auch nicht. Die Strecke wird schon wieder freigegeben. Ich hab mal ein kleines Beispielmodell gebaut bei dem das Phänomen auch auftritt. Wenn die Strecken vor den Einzelstationen blockiert sind, gehen die BEs in den Umlauf und versuchen ihr Glück dann später nochmal. Vielleicht liegt es auch überhaupt nicht an der Zusammenführung von den zwei Strecken sondern an noch etwas ganz anderem. 

Vielleicht hast du eine Idee ?

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Marie,
leider kann ich das Modell nicht öffnen. Ich denke aber, dass ein Screenshot reichen sollte um das Problem zu erkennen 

------------------
Grüße,
tsx 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Bild_zum_Beispiel.jpg

Hallo tsx,

hab nicht an die Lizenzgeschichte mit den unterschiedlichen Versionen gedacht. Hab einen Screenshot von der vollen Anlage gemacht, damit man weiß was ich tun will. Blaue BEs werden an der ersten Flusssteuerung ausgeschleust. Rote an der Zweiten. Wenn die Kapazitäten voll sind, geht es in den Umlauf.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Bild_zum_Beispiel_2.jpg

Das mit der Einzelstation war nur ein Test. Funktioniert allerdings auch nicht. Eigentlich sieht das Ganze so aus !

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

So wie ich das sehe, blockiert die Strecke, weil die Förderstrecken für die rot und blauen Teile voll sind und aber immer mehr Teile in der Förderkreislauf reingedrückt werden. Kommt nun eine ungünstige Kombination, bleibt die ganze Strecke stehen, weil kein Teil auf ein nachgelagertes Band umgelagert werden kann.

Lösungsmöglichkeit: Ausgangssteuerung des Bandes nach der Quelle

Code:

---

waituntil (Band1.anzahlbes + .... + ) <  (maximale Kapazität der 4 inneren Bänder - 1) prio 1;
@.umlagern

---

------------------
Grüße,
tsx 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo tsx,

in dem Modell vom Bild funktioniert deine Methode. Jedenfalls ist es 100 Tage gelaufen ohne abzubrechen. Das würde ich für stabil halten.  In meinem großen Modell funktioniert es so leider nicht. Wenn ich den Umlauf nicht wieder mit dem Anfang verbinde, sondern die Teile alle in eine Senke laufen lassen, dann läuft es auch einwandfrei. Sobald die allerdings wieder eingeschleust werden sollen, bricht es irgendwann ab. Deine Methode zögert den Zeitpunkt zwar hinaus, aber nach spätestens 11 Stunden ist Schluss. Das hat dann auch nichts mit dem Füllgrad zu tun. Es bricht auch ab, wenn nur ein paar Teile im Umlauf sind. So ein Umlauf ist doch eigentlich kein Hexenwerk. Das müsste doch irgendwie zu machen sein.

Ratlose Grüße !

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Was ist denn im richtigen Modell anders? Noch mehr Methoden oder eine geringere Kapazität der Bänder?

------------------
Grüße,
tsx 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo tsx,

ich hab den Fehler gefunden. Irgendwo hatte sich noch eine Förderstrecke versteckt, die nicht staufähig war. Die hat das ganze dann irgendwann zum anhalten gebracht. Jetzt klappt es auch mit deiner Methode. DANKE

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Na gut, dass wir die Geschichte endlich zum Laufen gebracht haben 

------------------
Grüße,
tsx 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ja das freut mich auch. Wenn man bei Diplomarbeiten eine Widmung schreiben würde, würde ich dich mitaufnehmen  !

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Macht man das nicht vor der Einleitung? 

------------------
Grüße,
tsx 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Nur bei Dissertationen! Und so weit wird es wahrscheinlich nicht kommen.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo tsx,

jetzt habe ich noch eine Frage. Wenn ich wissen möchte, ob auf den inneren Strecken + Umlauf ein bestimmtes BE vorhanden ist oder auch nicht, wie stelle ich das an ? Ist es vorhanden soll solange gewartet werden bis eben kein BE dieser Sorte mehr vorhanden ist.
Ich habe es für eine Förderstrecke versucht mit:

is

test:table;

do

test.create;
Förderstrecke.Inhaltsliste(test);
if test.finden({1,*},.BEs.Blau)then

......

end; 

Ich weiß nicht genau wie ich eine bestimmte Sorte BEs für den Wert der finden Methode angeben muss. So funktioniert es jedenfalls nicht. Genauso wenig wie "Blau" oder so ".BEs.Blau". Ist ja eigentlich auch logisch weil in der Inhaltsliste sowas wie : *.BEs.Blau:123 steht. Aber kann ich das trotzdem irgendwie abfragen auch wenn ich die Nummer des BEs nicht weiß ? Ja und dazu wie ich das waituntil bis keine Blauen BEs mehr vorhanden sind bauen soll, sind mir bis jetzt auch nur nicht funktionsfähige Ideen gekommen.

LG Marie

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Marie 

Viele Wege führen nach Rom, z.B. dieser:

Code:

---

is
    i:integer;
    vorhanden:boolean;
do
    for i:=1 to Förderstrecke.anzahlbes loop
          if Förderstrecke.be(i).name="blau" then
              --gefunden
              vorhanden:=true;
              exitloop
          end;
    next;

    if vorhanden then
          --Anweisung
    else
          -- BE nicht auf der Strecke
    end;
end;

---

------------------
Grüße,
tsx 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Vielen Dank,

nach ein wenig dran- und abstricken der Methode funktioniert das genauso wie ich mir das vorgestellt habe.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Wenn ich das Ganze allerdings nicht von einer Ein- bzw. Ausgangssteuerung aufrufen will, sondern diese Methode aus einer anderen Methode heraus, bringe ich nur Endlosschleifen zu Stande. Weder mit while oder repeat funktioniert das. Ich würde das gerne machen, weil ansonsten die Simulation irgendwann sehr langsam wird, weil die Strecken die gesamte Zeit überwacht werden. Sie müssten aber nur zu einem bestimmten Zeitpunkt überwacht werden. Solange bis ich die Rückmeldung kriege, das kein blaues Teil mehr im Umlauf ist. Geht das überhaupt? Ich hatte da eine Idee mit Goto, aber das gibt es in SimTalk ja nur für Werker und nicht zum Springen in Methoden.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Die Methode sollte genauso funktionieren, wenn du sie aus einer anderen Methode heraus startest.

Mit for-Schleifen bekommst du i.d.R. keine Endlosschleife hin. Bei Repeat-Schleifen erreichst du das Abbruchkriterium nicht, das lässt sich aber mit etwas debuggen nachvollziehen und abstellen. Ohne den Methodenquelltext kann ich dir da aber nicht viel weiterhelfen..

------------------
Grüße,
tsx 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Das Problem ist, dass die For-Schleife zu früh abbricht. Nochmal eine kurze Erklärung was das ganze soll. Also ich habe diesen Umlauf wie auf dem Bild. Nach einer bestimmten Anzahl von Schichten möchte ich Rüsten. Das Rüsten darf aber erst gestartet werden, wenn im Umlauf kein blaues Teil mehr ist, da dann eine neue Variante grün gefertigt werden soll.

Methode für das Rüsten die nach x Anzahl von Schichten augerufen wird:

Code:

---

is
do
  repeat
    Methode_Überwachen;
  until Ruesten_Umlauf_1 = true;

  Einzelstation.RuestZeit := 900;
  Einzelstation.ruestenFuer(BEs.grün);
end;

---

Methode_Überwachen : die den Wert Ruesten_Umlauf_1 zurück geben soll. Ruesten_Umlauf_1 ist eine globale Variable.

Code:

---

is
  i:integer;
  vorhanden:boolean;
do
  for i:=1 to Förderstrecke1.anzahlbes loop
      if Förderstrecke1.be(i).name = "blau" then
          vorhanden:=true;
          exitloop
      end;
  next;

  for i:=1 to Förderstrecke2.anzahlbes loop
      if Förderstrecke2.be(i).name= "blau" then
        vorhanden:=true;
        exitloop
      end;
  next;

  for i:=1 to Förderstrecke3.anzahlbes loop
      if Förderstrecke3.be(i).name= "blau" then
        vorhanden:=true;
        exitloop
      end;
  next;

  if vorhanden then
      Ruesten_Umlauf_1:=false;
  else
      Ruesten_Umlauf_1:=true;
  end;

end;

---

Ich hoffe ich habe beim Kürzen jetzt nichts unterschlagen. Solange die Methode_Überwachen von einer Ausgangssteuerung aufgerufen wird, funktioniert es. Frisst nur Ressourcen, da ich von diesen Überwachungsmethoden 7 Stück habe die 150 Strecken zu überwachen haben. Nur mit dem repeat until klappt das nicht!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

das Thema mit dem Rüsten hatte ich vor kurzem auch bei einem Modell von mir.

Ich fand es einfacher beim Erzeugen der BEs die Typen in einer Variable zu zählen.
In der Quelle wird hochgezählt und bei einem Bestimmten Bearbeitungspunkt bzw in der Senke wieder abgezogen. Damit brauchst du nicht jede Förderstrecke einzeln abfragen und kannst auf die ganze FOR Schleife verzichten.

Das bietet den Vorteil, dass duch auch jederzeit weisst wieviel WIP du von jeder Variante im System hast.

Gruß Stefan

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Stefan,

ich muss genau wissen wo sich das Teil befindet. Irgendwo im System reicht leider nicht aus.

Gruß Marie

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Marie,
ich hab deine Methode nur kurz überflogen.

Problem wird sein, dass die Repeat-Schleife die Methode_Überwachen kontinuierlich aufruft, aber zwischen den Aufruf keine Zeit vergangen ist (bei der Ausführung einer Methode vergeht keine Zeit, auch nicht in einer Schleife).

Pragmatische Lösung:

Code:

---

is
do
  repeat
    wait 20 --20 Simulationssekunden warten
    Methode_Überwachen;
  until Ruesten_Umlauf_1 = true;

  Einzelstation.RuestZeit := 900;
  Einzelstation.ruestenFuer(BEs.grün);
end;

---

------------------
Grüße,
tsx   

[Diese Nachricht wurde von tsx am 17. Jun. 2010 editiert.]

[Diese Nachricht wurde von tsx am 17. Jun. 2010 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Manchmal hat man einfach ein Brett vorm Kopf. Ich hatte schon vermutet, dass es eine Endlosschleife wird, weil sich die BEs nicht weiter bewegen. Dass man das aber einfach über ein wait austricksen kann, darauf bin ich noch nicht gekommen. Eigentlich logisch. Vielen Dank fürs entfernen des Brettes !

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP