---

Hallo!

Mein Problem: Ich muss eine Bestellung der Materialien anhand Bestellpunk-Loßgrößen-Verfahren realisieren. Das bedeutet, sobald Anzahl der Elemente im Puffer auf x (x=10) sinkt, wird y (y=15) nachbestellt. Bedarf der Materialien z (z = 40) ist für einen Auftrag bekannt.

Dafür habe ich folgendes zusammengestellt:

Quelle -> Puffer -> Einzelstation ->Senke

Eingangssteuerung des Puffers:
<<<<<<<<<<<<<<<<<<<<<<<<
is
sourceObj22 bject;
do

sourceObj22 := ".Modelle.Netzwerk.Quelle";

repeat
      if Puffer.AnzahlBEs = 10 then
if sourceObj22 /=void then
    sourceObj22.Anzahl :=  15;
    Variable := Variable + 1;
  end;
      end;
until Puffer.statAnzahlEin <= 40;
end;
<<<<<<<<<<<<<<<<<<<<
Variable zählt Anzahl der Bestellungen.

Zeitpunkt der Nachbestellung brauche ich nicht.
Das Modell bestellt nur ein Mal nach, muss aber mit diesen Werten 2 Mal nachbestellen.

Habt Ihr eine Idee, wo ich den Fehler gemacht habe?

Tausend Dank für jede Hilfe.

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

---

Moin,

was Du beschrieben hast könntest Du mit

Code:

---

is
do
-- an der Quelle einstellen
quelle.anzahl := 15;
quelle.Erzeugungszeit := "Anzahl einstellbar";

if puffer.anzahlBes <= 10 + 1 then
-- bestellen
Variable := Variable + 1;
Quelle.Abstand.setzeParam("konst", 0);
end;
puffer.inhalt.umsetzen;
end;

---

als Ausgangssteuerung des Puffers erreichen (ohne anhalten bei 40 Ausgängen). Wenn Du allerdings Verzögerungen zwischen Bestellung und dem Eintreffen im Puffer hast wird dies nicht mehr ausreichen, denn es wird nur der Pufferzustand geprüft und die schon nachbestellte Menge nicht mit einbezogen.
Vielleicht schaust Du Dir mal die Kanban Bausteine an, die können sowas.

Gruß
P.

------------------
Two hours of trial and error can save ten minutes of manual reading!

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

---

Hallo P.,

DANKE SCHÖN!!! Ich habe die Begrenzung auf 40 doch eingeführt und es funktioniert. Mit Kanban-Bausteinen werde ich jetzt ausprobieren.

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

---

Hallo P.,
ich habe mit Kanban noch nie gearbeitet, deswegen klappt es momemnat auch nicht oben beschriebenen Verhalten zu simulieren. Ich muss tatsächlich die Verzögerung zwischen der Bestellungen einbauen.

Ich habe KanbanQuelle, KanbanPuffer, einzelstation und die Senke genommen. Teile kommen von dem KanbanPuffer nicht weiter. Ich ouffer habe ich angestellt: min - 10, max - 40, anfang - 11.

Was muss ich machen,
1.damit die Teile zu der Einzelstation wandern
Danke schön,
N.

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

---

Moin,

vielleicht muss ich mit dem Hinweis auf die Kanban Bausteine etwas zurückrudern. Man kann das zwar abbilden (Du brauchst eine KanbanSingleProc/KanbanEinzelstation) aber das führt zu Diskussionen weil Bestellpunkt-Losgrößen-Verfahren doch etwas anderes ist als Kanban.

Was man an der Inhalt-Tabelle des Kanban-Puffers allerdings schön sehen kann ist die Spalte 'requestetParts'. Diese wird bei einer Bestellung erhöht und bei Eintreten im Puffer vermindert. So kann man immer ausrechnen wie viele teile man Bestellen darf ohne die Puffergröße zu überschreiten. Eine solche Variable müsstest Du am Puffer führen und in den Ein- und Ausgangssteuerungen entsprechend erhöhen/mindern (beachte evt. vorinitialisierte Pufferbestände oder die ersten Lieferung der Quelle die evt. automatisch beim Simulationsstart erfolgt).

Gruß
P.

------------------
Two hours of trial and error can save ten minutes of manual reading!

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

---

Hallo,

die Anzahl der Teile rechne ich am Anfang aus, weil der Anwender gibt mir die Höhe des Bedarfs (Stückzahl) im Dialogfenster an und den Verbrauch pro Stück kenne. Ich berechne die optimale Bestellmenge und ich weiss auch wieviel mal bestellt werden muss.

Das Problem ist, dass zwischen den Bestellungen eine gewisse Zeitspanne berücksichtigt werden muss: Wenn die Meldebestand 10 erreicht ist, muss nachbestellt werden, aber die Teile dürfen erst eine gewisse Zeit später den Puffer betretten. Das was Du vorgeschlagen hast, funktioniert super, aber ich schaffe es nicht eine Verzögerung zu realisieren. Ich habe schon versucht, die Ereignisverwalterzeit zu merken und zu dieser Zeit die Verzögerung zu addieren und erst dann nachzubestellen. Funktioniert irgenwie nicht.
Hast Du eine Idee?
Gruß,
N.

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

---

Moin,

hier einige Möglichkeiten

• ein Förderband vorschalten
  
• eine Parallelstation vorschalten, die die Lieferzeit als Bearbeitungszeit hat.
  
• Du kannst die Bestellung in eine eigene Methode kapseln deren Aufruf Du mit 'methaufr' suspendierst.
  
• ...
  

Gruß
P.

------------------
Two hours of trial and error can save ten minutes of manual reading!

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

---

Unbenannt.JPG

Hallo P.,

ich habe folgendes gemacht (siehe Bild):
Quelle1 ist für die mögliche Restbestäde an Material.

Parallelstation habe ich auch drin. Sie bekommt aber immer Teile von der Quelle.

Ich habe keine Ahnung, wie ich jetzt dem Modell beibringen soll, dass die "Variable" richtig zählt und es bestellt wird, nur dann wenn es gebraucht wird und nicht immer. Ich habe z.B. Am Anfang in INIT-Methode Quelle.Anzahl = 0 gesetzt. Es geht nur für die erste Bestellung korrekt, weitere werden nicht nach dem erreichen des Puffersinhaltes=10 bestellt, sondern sofort, wenn die Paralelstation leer wird.

Gruß,
N.

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

---

forum.jpg

Moin,

so klappts bei mir.

Allerdings glaube ich, dass Du wenn Du aus Deinem Ansatz etwas größeres bauen möchtest (Stichwort Restmaterial verwenden), Dir erstmal ein Gesamtkonzept (Zielgrößen) entwickeln solltest, denn der Ansatz mit den für den Auftrag benötigten 40 Bes scheint mir so nicht besonders gelungen. Z.B. hätte ich diese aus einem Puffer genommen und danach meine Fertigung/Bestellung angestoßen.

LG
P.

------------------
Two hours of trial and error can save ten minutes of manual reading!

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

---

Hallo P.,
wenn ich richtig verstanden habe, zählt die Methode CtIn_Buffer die Eingegangene BEs in requeested:
requeested := requeested + 1;
und die Methode ist in der Eingagngsteuerung des Puffers eingetragen.
Gruß,
N.

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

---

Hallo P.,

VIELEN DANK!!!

meine vorherige Anmerkung war echt unüberlegt.

Bis jetzt kriege ich nicht heraus, was cIn_Buffer-Methode macht. Könntest Du bitte sagen? Du hast Sie nicht mitgeschickt und ich versuche es ohne Erfolg rauszukriegen.

Gruß,
N.

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

---

Hallo P.,
ich habe gemerkt, dass bei mir allgemein nur 1 Mal nachbestellt wird. Egal welche Daten ich für die Initialisierung des puffers nehme (5,12,...). Die Bediengung mit < 40 wird ignoriert. Ist bei Dir das auch so?

Gruß,
N.

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

---

Hallo P.,
CtIn_Buffer-Methode beinhaltet:
requeested := 0;
oder?
Vielen Dank!
Gruß,
N.

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

---

Moin,

schau nochmal hin, so kompliziert ist es nicht. Weiter oben habe ich schon geschrieben:

Zitat:

---

Was man an der Inhalt-Tabelle des Kanban-Puffers allerdings schön sehen kann ist die Spalte 'requestetParts'. Diese wird bei einer Bestellung erhöht und bei Eintreten im Puffer vermindert.

---

In der Puffer Ausgangssteuerung bestellen wir mit quelle.abstand.setzePara..etc. der Abstand '0' löst also ein (1) Mal die Erzeugung der Bes aus (die Anzahl haben wir ja vorher eingestellt). Dies wird bei jedem Be Austritt aus dem Puffer aufgerufen. Ohne Berücksichtigung der bestellten Menge würden wir also bei 10 Ausgängen 150 Bes bestellen, das möchten wir nicht.
Deshalb merken wir uns wieviel wir bestellt haben in 'requested' und zählen die Menge zu dem aktuellen Pufferbestand dazu (als würde die Bestellung sofort geliefert) und bestellen so nur soviel neu, wie auch wirklich gebraucht wird. Bei jedem Puffereingang eines Bes (Lieferung der Bestellung) mindern wir 'requestet' um eins.

in CtIn_Buffer steht lediglich requested := requested -1;

Gruß
P.

------------------
Two hours of trial and error can save ten minutes of manual reading!

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

---

Hallo P.,

TAUSEND DANK!!!

Gruß,
N.

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