---

Hallo,
ich sitze schon eine ganze Weile über ein paar Aufgaben, die mit dem Programm ED 7 zu lösen sind. In diesem Forum habe ich auch schon viele hilfreiche Tipps gefunden. Jetzt stehe ich wieder vor einer Herausforderung, und finde keine Lösung. Vielleicht kann mir ja ein etwas versierterer Anwender eine Hilfestellung leisten.

Ich habe einen Multi-Server mit drei Eingängen. Über diese Eingänge kommen Atome mit den Attributwerten 1, 2 und 3 in den Server. Über Eingang 1 kommen nur die Atome mit dem Attributwert 3, während die Atome mit dem Attributwert 2 über die Eingänge 1 und 2 in den Server gelangen. Die Atome mit dem Attributwert 3 kommen über alle drei Eingänge in den Server. Jetzt versuche ich, da ich nur 4* Attributwert 1 oder 2* Attributwert 2 oder 1* Attributwert 1 mit diesem Server bearbeiten kann, die verschiedenen InpuChannels zu sperren, damit lediglich die gleichen oder keine Atome mehr in den Server gelangen können.

Trigger on Entry:
if(
att([Klasse],i)=1,do(CloseIc(1,c),CloseIc(2,c)),
  if(
  att([Klasse],i)=2,do(CloseIc(1,c),CloseIc(3,c)),
  closeinput(c)
  )
)

Trigger on Exit:
if(Input(c)=Output(c),
do(
  if(
  att([Klasse],i)=1,and(openic(1,c),openic(2,c)),
    if(
    att([Klasse],i)=2,and(openic(1,c),openic(3,c)),
    openinput(c)
    )
  )
)
)

Beim Trigger on Entry wird lediglich der letzte Befehl ausgeführt, und es wird beim Eingang eines Atoms mit dem Attributwert 3 die Servereingänge komplett gesperrt.

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

---

Hallo Nightfire,

Du kannst Dein Vorhaben nicht (bzw. nur teilweise) mit dem Trigger on Entry steuern. Welche Kanäle von dem Mulitserver geöffnet werden wird in der Inputstrategie (siehe Eingabemaske von Multiserver) festgelegt. die Inputstrategie wird nach dem Trigger on entry ausgeführt, überschreibt also Deine Festlegungen (mit Ausnahme des Befehls Closeinput(c), der ja nicht auf die Kanäle zugreift, sondern sozusagen einen "Rolladen" noch vor allen Kanälen schließt. Wahrscheinlich meintest Du eh closeallic(c), das ist der Befehl, der alle Kanäle schließt).
Fraglich ist jedoch, ob Du Deine Aufgabe alleine mit dem Öffnen und Schließen der Eingangskanäle lösen kannst. Das geht nur dann, wenn du weißt, welche Produkte von welchen Eingangskanälen kommen. Dem ist aber offensichtlich nicht immer so, wie ich die Aufgabe verstanden habe. Du mussst also noch vorher verhindern, daß von dem Vorgängeratom ein falsches Produkt losgeschickt werden kann.
Dazu würde ich für den Mulitserver eine Variable (z.B akt_klass) einführen, die den Wert 0 hat, wenn der Server leer ist und sonst den Wert der Klasse aufweist, die gerade bearbeitet wird. Er wird in Trigger on Entry (hier richtig) mit der Anweisung c.akt_klass:=att([Klasse],i) gesetzt, bzw. - wenn der Server leer ist - bei Trigger on Exit auf 0 gesetzt. Die Vorgängeratome können dann in der Sendto-Anweisung abfragen, ob der Mulitserver überhaupt die richtige aktuelle Klasse hat.

Ich wünsche Dir noch einen schönen Sonntag

Gruß, Georg

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

---

Hallo Georg,

danke erstmal für deine schnelle Antwort. Mein Modell umfasst drei solcher Server, von denen zwei den o. g. Restriktionen unterliegen. Alle drei Server werden aus einem weiteren Server bedient, bei dem die Verteilung geregelt ist. Da ich mich mit ED noch nicht so gut auskenne, weiß ich leider nicht, wie ich diese Abfrage noch in meine SenTo-Anweisung einbauen kann.

SendTo:
if((att([Klasse],rank(1,c)))=1, indexmax(7,*(ocready(count,c),random(100000))),(if(att([Klasse],rank(1,c))=2, indexmax(4,*(ocready(count,c),random(100000))) , indexmax(2,*(ocready(count,c),random(100000))))))

Dir auch noch einen schönen Sonntag.

Gruß
Markus

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

---

Hallo Markus,
ich verstehe Deinen Sendto-Befehl nicht und weiß nicht, was Du damit bezwecken willst.
Die Sendto-Anweisung wird bei jedem OC-Ready-Impuls ausgeführt, also dann, wenn entweder der Server fertig mit seiner Arbeit ist und / oder das nachfolgeende Atom seinen zugehörigen Eingangskanal offen hat bzw. öffnet. Falls also über die Sendtoanweisung ein nachfolgendes Atom gefunden wird, soll dieser Ausgangskanal gewählt werden, wenn keines zur Verfügung steht, soll die Anweisung ins Leere laufen, also den Kanal wählen, der mit keinem Element verbunden ist. Sie wird ja jedesmal neu ausgeführt, wenn ein nachfolgendes Atom seine Pforten wieder öffnet.

Die Quick and Dirty-Lösung:

Gib dem vorhergehenden Server einen Ausgang mehr als notwendig. Dieser (letzte) Ausgang ist mit keinem Element verbunden (wichtig!)
Setze in den Sendtobefehlt die folgende Anweisung (ist mit Kommentaren versehen):

nroc(c)-
indexmatch(
  nroc(c)-1,
  1,
  and(
  AtomExists(first(c)),    {Stellt sicher, daß überhaupt ein Atom zum Versenden da ist}
  ocready(nroc(c)-count,c), {Stellt sicher, das der angesprochene Kanal überhaupt übergeben kann, also Ausgang und (!)) Eingang offen sind}
  or(  {In der Or-Schleife wird der aktuelle Wert der Variablen in dem Mulitserver abgefragt}
    label([akt_klass],out(nroc(c)-count,c))=0, 
    label([akt_klass],out(nroc(c)-count,c))=att([Klasse],first(c))
   
  )
 
  )
)

{Wenn kein Ausgang gefunden wird, liefert indexmatch den Wert 0. Der Wert der Sendtoanweisung ergibt also nroc(c) - und der letzte Kanal ist mit keinem Atom verbunden

Die Anweisung fängt mit dem vorletzten Ausgang an zu suchen und geht bis zu dem Asugang Nr. 1. Dieser Ausgang ist also bevorzugt!

}

Natürlich gäbe es noch viele andere gute Lösungen. In komplexen Modellen würde man das auch so nicht lösen, sondern würde den konkreten Ausgang über ein Steuerungselement ermitteln - eben so, wie es in der Realtität auch gemacht werden würde. Das Steuerungselement wäre dort eine übergordnete Materialflusssteuerung oder eben ein Mensch, der das entscheiden kann.

Gruß, Georg

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

---

Hallo Georg,

deine Hilfen waren bisher Spitze, aber es klappt nicht so, wie es eigentlich sollte. Deine Hinweise funktionieren auf jeden Fall besser als meine Ideen. Zum Szenario:
Ein Server verteilt Atome mit den Attributwerten [Klasse] 1, 2, 3 an drei Multiserver. Der erste Multiserver kann 2* die Klasse 1 bearbeiten, der zweite und der dritte Multiserver können jeweils 4* die Klasse 1, 2* die Klasse 2 und 1* die Klasse 3 bearbeiten.

Mit meiner Sendto-Anweisung hatte ich erreicht, dass die Betreffenden Atome an die richtigen Server weitergeleitet wurden. Dann habe ich versucht, sobald ein Atom in einem Multiserver angekommen war, die Eingänge zu sperren, die von den Atomen mit den anderen Klassen genutzt werden. So habe ich z. B. den Eingang für die Klasse 2 auf den ersten und zweiten Channel eines Multiserver gelegt. Mit dem ersten Klasse 2 Atom sollten der Channel 1 und 3 gesperrt werden, so dass nur noch ein Klasse 2 Atom in den Server kommt. Aber meine Überlegung ist hier nicht ganz richtig.

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

---

Wie kann ich bei dem Multiserver festlegen, dass er nur 2 Atome mit dem Attribut 2 oder 1 Atom mit Attribut 3 bearbeiten kann. Bei Attribut 1 stellt das ja mit deiner Verteilung kein Problem dar, da Atome mit dem Attribut 1 die volle Kapazität in anspruch nehmen können.

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

---

Hallo,

ich habe mein Programm jetzt soweit fertig. Das einzige was noch nicht funktioniert ist, dass ich ein Atom als Eingang habe, in dem keine Produkte anstehen dürfen. Also das Atom sollte nur durchleiten, und nicht die Möglichkeit besitzen ein Produkte über längere Zeit zu beinhalten. Eine Warteschlange befindet sich vor dem Eingang. Gibt es hierzu eine Möglichkeit?

Andernfalls müsste das Attribut des Produktes vor dem Eingang mit den Attributen der Server verglichen werden, die sich hinter dem Eingang befinden. Dann dürfte das Produkt nur weitergeleitet werden, wenn der Server mit dem gleichen Attribut frei ist.

Für Hilfe wäre ich, wie immer, sehr dankbar.

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