---

LoadSequence.txt

Hallo alle zusammen,
ich habe ein Problem beim losweisen Umlagern von einem Puffer in den nächsten.
Das Modell sieht folgendermaßen aus: Es existieren 2 Maschinenlinien.
Auf jeder Linie laufen (im Moment) 3 Produkte (Be.Name = Part_A, Part_B, Part_C). Bei Linie 1 (LS) startet die Produktion mit einem „neuen“ Produkt und endet in einem dem Produkt zugeordneten Puffer.
Linie 2 (BS) entnimmt Produkte aus dem jeweiligen Puffer und lagert sie im Lospuffer der Linie 2 ein.
Beide Linien produzieren durch eine Meldebestandssteuerung.
In beiden Linien werden Lose produziert (Losgröße := MaxBestand – IstBestand) sobald der Meldebestand unterschritten wird.
Die Funktion welche von einem Puffer in den nächsten Umlagern soll hängt unten an. Das Problem ist, daß LsBuffer.MU(i) ein VOID zurückgibt, obwohl der Puffer noch nicht leer ist. Das Problem tritt nicht sofort sondern erst nach einer gewissen Laufzeit auf. Ich habe beobachtet, daß genau bei halbem Pufferbestand ein VOID zurückkommt. Also zum Beispiel: Los = 150, Puffer = 200, LsBuffer.MU(100) = VOID.
Weiß jemand woran das liegen tut?
Komischerweise wird in der davor aufgerufenen Debugschleife kein VOID zurückgegeben.

Vielen Dank für eure Hilfe,
RostigerNagel

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

---

Hi,

schick mal das Modell (wenn mit einer kommerziellen Lizenz erstellt) oder einen aussagekräftigen Screenshot .

Gruss

------------------
Der Simulator

---

Umlagern2.spp.jpg

Modell hängt an.

Das Problem tritt nach ca. 1 Tag Simulationszeit auf.
Erkennbar an den Konsolenausgaben:

Inhalt bufferTable2 : .MUs.HB_MUs.PCB102Part_CVOID on : .Models.Werkbank.Factory.MotherFrameBS
-- = 102 Stück von Part_C
Problem after : 80 of : 102
-- 79 Stück konnten umgelagert werden (Differenz wegen dem Inkrement von i)
numMUs : 78
-- Abfrage nach Verlassen der FOR SChleife. Deckt sich auch mit der Anzeige im Weiteren Verlauf.

Vielen Dank!
/RostigerNagel

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

---

Hi,
Du hast in der Schleife nicht die Dynamik bedacht.
Bei jeder Umlagerung eines Mu´s rücken die Mu´s in dem Puffer auf
D.h. spätestens nach der Hälfte greifst Du mit Deinem index "i" auf einen leeren Platz zu obwohl der Puffer noch halb gefüllt ist.
Wenn Du immer den 1.  (s.u.) oder letzten Platz abfragst, funktioniert es soweit in Deinem Fall.

for i := 1 to sequence[2,1] loop -- Number
IF LsBuffer.MU(1) /= VOID
THEN
LsBuffer.MU(1).move(LotBuffer); -- Move the MU from the ExitBuffer to the LotBuffer

ELSE
--debug; -- Not enough MUs on ExitBuffer
print "Problem after : ", i, " of : ",sequence[2,1];
print "numMUs : ",LsBuffer.numMU;
EXITLOOP;
END; -- of IF

next;

Gruss

------------------
Der Simulator

---

Danke,
werde es umgehend testen.
Allerdings dachte ich, dass genau der Fall VOID eintritt falls ich immer auf auf den gleichen Platz im Puffer zugreife [Puffer.MU(1)].
Mal eine allgemeine Verständisfrage:

eM-Plant arbeitet ereignisorientiert, sprich das Auslagern aus dem Puffer ist ein Ereignis. Da der Puffer selbst keine Bearbeitungszeit hat werden die nachfolgenden BEs sofort um eins vorgerückt.

Bisher dachte ich, dass der Aufruf einer Methode/Schleife ein Ereignis darstellt welches zuerst komplett abgearbeitet wird, ehe etwas anderes passiert.

dankbar,
/RostigerNagel

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

---

Korrekt !

aus diesem Grunde habe ich auch "... funktioniert es soweit in Deinem Fall" geschrieben.

Gruss

------------------
Der Simulator

[Diese Nachricht wurde von Simulator am 27. Mrz. 2006 editiert.]

---

Hallo Simulator,

1000Dank.

Das Problem ist damit gelöst.

/RostigerNagel

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

---

ReleaseOrderMth.txt

Hallo Simulator und alle anderen,
jetzt bin ich doch etwas verwirrt.
Eine Methode in meinem Modell soll eine ähnliche Aufgabe wie die hier diskutierte erledigen. Alle 24h soll der Kundenauftrag aus dem Lagerpuffer entnommen werden. Die Methode welche das Umlagern übernimmt wird dazu alle 24h von einem Generator getriggert.

Allerdings klappt das Umlagern nur per

Puffer.Be(i).umlagern(Senke);
mit i als Laufvariable einer FOR Schleife

und nicht
Puffer.Be(1).umlagern(Senke);

Weder Puffer noch Senke haben irgeneine Bearbeitungszeit. Die "i" Methode funktioniert, die "1" Methode gibt ein FALSE zurück. Also warum kann  "1" nicht auf die Senke umlagern und mit "i" klappts???

Der Quelltext der Methode hängt an. Ich hoffe es wird durch die Kommentierung ersichtlich.

/RostigerNagel

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

---

umlager3.spp.jpg

Hi,

es ist schwer ohne Modell hierauf eine Erklärung zu finden zumal es in dem Testmodell so funktioniert.

Wenn Du ein abgespecktes Modell hast, kann ich es mir mal anschauen.

Gruss

------------------
Der Simulator

---

TestAbrufNetzwerk.spp.jpg

Beispielnetzwerk hängt an.
Ich habe gerade nochmal getestet.
Mit i funktioniert es, mit 1 nicht.

Vielen Dank für Deine Hilfe!

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

---

Eine Frage hätte ich noch....

Ich möchte einer Einzelstation, abhängig vom zu bearbeitenden Teil, eine Bearbeitungszeit zuweisen.

Mit
Syntax:  <Pfad>.BearbeitungsZeit; 

geht das ja... Allerdings ist dieses Attribut vom Typ "Zeit".
Gibt es auch eine Möglichkeit eine Verteilung mit Parametern zuzuweisen?
Z.B.: Erlang, 2, 1:57.8, 0:37.3, 0:30, 3:00

Oder müsste ich in einer Methode beim Eintreffen eines BEs eine z.B. Erlang verteilte Zeit errechnen und dann mit <Pfad>.BearbeitungsZeit der Station zuweisen?

Danke,
/RostigerNagel

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

---

Hi,

geht beides.

Du kannst die Erlang-Verteilung direkt bei der Bearbeitungszeit auswählen( "Erlang" wählen) und dann die Parameter in dem Bearbeitungszeit-Feld eintragen.

Oder "Formel" wählen und Erlang-Verteilung bzw. eine selbstgeschriebene Methode mit entsprechendem Rückgabewert eingeben.

Was Du nicht machen solltest, ist die Bearbeitungszeit ueber eine Methode in der Eingangssteuerung festlegen, da sie dann erst beim nachfolgenden Bearbeitungszyklus verwendet wird.

Gruss

------------------
Der Simulator

---

TestAbrufNetzwerk.spp.jpg

Hi,

also bei mir verhält sich die Methode korrekt.

D.h. das 1. Teil wird umgelagert auf die jeweilige Senke und das nachfolgende Teil nicht, da die Senke noch blockiert ist!

Das Verhalten  ist mit "i" und "1" gleich

Du arbeitest mit 7.5.2
Es gibt zwischenzeitlich das 7.5.4 Patch.

Wenn Du  nicht auf eine Senke sondern auf Puffer umlagerst funktioniert es immer. (s. Anhang)

Gruss

------------------
Der Simulator

---

Also das von mir gewünschte Verhalten (eine Anzahl BEs zu einem Zeitpunkt in eine Senke umlagern) ist ein Bug?
Sprich ich müsste erst die BEs aus dem Puffer in einen anderen Puffer umlagern von wo aus sie dann in die Senke abfliessen können?

Die Verteilung direkt im Baustein auswählen und Parameter angeben geht leider nicht, da unterschiedliche BEs unterschiedliche Zeiten mitbringen... Ich habe es noch nicht ausprobiert, aber könnte ich über "Formel" eine Methode nutzen und da drin dann z.b.

IF BE.name = Teil1
THEN
return Verteilung1
ELSE
return Verteilung2
END

(mit richtiger syntax versteht sich)

Danke.

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

---

Hi,

zu 1.

nein, ein Bug ist es meines Erachtens nicht!
das interne Umlagern der Be´s im Puffer hat eine höhere Priorität, als das externe Umlagern der Senke.

Du kannst aber vor dem Umlagern abfragen, ob die Senke leer ist.
z.B. durch      waituntil senke.leer prio 1;
dann funktioniert es genauso wie beim Puffer.

Gruss

zu 2.

ja, so sollte es gehen.

Gruss

------------------
Der Simulator

[Diese Nachricht wurde von Simulator am 30. Mrz. 2006 editiert.]

---

Hallo,

die Puffer waren eine gute Idee.
Die Bearbeitungszeit per Formel und Methode nat. auch.

Allerdings hat die Sache noch einen kleinen Schönheitsfehler.

Wie unter Methode beschrieben funktioniert alles ohne Probleme. Nur wie kann ich jetzt noch "elegant" eine obere und untere Schranke setzen, damit da nichts ausufert?
Per
SingleProc.BearbeitungsZeit.setzeTypUndAttr("Normal", "1,30,10,1,100");
setzt die Zeit leider erst wie du gesagt hast für das darauf folgenden BE.

Methode:

:time
is

do
IF @.name = "Part_A"
THEN
return z_normal(1,60,10);
ELSE
return z_normal(1,120,10);
END;

end;

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

---

Ich habs jetzt mal mit einer repeat until schleife hingepfuscht:
Ist das vertretbar?

a:time;
do

IF @.name = "Part_A"
THEN
REPEAT
a := z_normal(1,60,10);
UNTIL a > 30 AND a < 90;
return a;
ELSE
REPEAT
a := z_normal(1,120,10);
UNTIL 60 > 30 AND a < 180;
return a;
END;

end;

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