Peace!

Wir sitzen schon den ganzen Tag vor den schönen Petrinetzen in RENEW (haben uns die von der TGI Seite geladen). Leider haben wir bisher noch überhaupt nichts hinbekommen. Uns fehlt so zu sagen der komplette Ansatz, auch die GUI hat uns bisher nicht weiter geholfen. Wir haben an so ziemlich allen Kanten rumprobiert, haben sie gewichtet oder eben nicht mehr gewichtet, doch leider gab es selten Veränderungen. Was sind die Kanten ohne Pfeile? Wir schaffen es auch nicht, aus der GUI einen Request zu senden (No binding for transition). Wir haben natürlich auch das probiert im Elevator zu implementieren.
Wir schaffen es über die GUI ein Objekt der Klasse Elevator zu erzeugen.
Danke![/php]

Also erstmal muss man bei Renew darauf achten nicht die Elemente zu benutzen, die keine Funktion haben (die Kreise und Rechtecke ohne Buchstaben drin). Also allgemein nur die Elemente aus der unteren Reihe. Als nächstes sollte man bei der Simulation eines Netzes mal mit Rechtsklick auf einer Markierung klicken um die tatsächlichen Marken zu sehen und nicht nur die Anzahl der Marken.

Zu den Kanten:
Kante mit einer Pfeilspitze: normale Kante
Kante ohne Pfeilspitze: Testkante (d. h. eine Transition ist aktiviert, wenn die zu der Testkante gehörende Stelle die Marke entsprechend der Kantenbeschriftung enthält. Die Marke wird aber nicht entfernt)
Kante mit mehreren Pfeilspitzen: Flexible Kante. Mit dieser Kante kann man über eine Kante mehrere Marken laufen lassen. Sollte man aber für FGI2 eigentlich nicht brauchen

Wenns trotzdem noch probleme gibt, einfach nochmal fragen. Dann aber konkreter!

Edit: Man sollte auch beachten, dass Renew standardmäßig den "Java Net Compiler" als Formalismus eingestellt hat. Der verhält sich nicht genau so, wie man das vielleicht von einem P/T-Netz erwarten würde.

Der Java Net Compiler ist für die Lösung der FGI2-Aufgabe der richtige, da die Java-Netze eine Weiterentwicklung gefärbter Netze sind und die Aufgabe ein gefärbtes Netz verlangt.

Das Debugging von Netzen ist besonders dann schwierig, wenn eine Transition einfach nicht schalten will.  Als erfahrener Renew-Nutzer mache in in solchen Situationen folgendes:

1. Die Anzeige der Markierung von (kursiv dargestellten) Kardinalitäten auf individuelle Marken umstellen:  Alles markieren (Strg+A), Menü Net->Marking->Tokens.  Wenn man das im Netzmuster (weißer Fensterhintergrund) macht, wird die Einstellung mit dem Netz gespeichert, wirkt aber erst ab dem nächsten Simulationsstart.  Wenn man das im Simulationsfenster (bläulicher Fensterhintergrund) macht, wirkt es sofort, ist aber bei Simulationsende vergessen. Für einzelne Stellen kann man den Modus auch per Rechtsklick auf die Markierungsanzeige umschalten.
2. Zu der Markierung schalten, in der die fragliche(n) Transition(en) eigentlich schalten sollte(n), d.h. in der in allen Eingangsstellen aller am Schaltvorgang beteiligten Transitionen die meiner Meinung nach richtigen Marken liegen.  An einem Schaltvorgang sind genau dann mehrere Transitionen beteiligt, wenn synchrone Kanäle (Anschriften mit Doppelpunkt) im Spiel sind.
Auf das Beispiel mit der Fahrstuhlanforderung bezogen:  In der GUI muss die Elevator-Marke in der grünen Stelle unter der Treppenhausgrafik liegen.  Ein Klick auf diese Marke öffnet das eigentliche Elevator-Netz mit Markierung.  Zu mindestens einer der Transitionen mit der Anschrift ":req(i)" müssen in allen Eingangsstellen sinnvolle Marken vorhanden sein.  "Sinnvoll" hängt natürlich von der Modellierung ab, also beispielsweise ein Wert für die aktuelle Etage des Fahrstuhls, um ihn mit der Etage der Anfrage vergleichen zu können.
3. Selber die gewünschte Variablenbelegung durchrechnen: Jede im Umfeld der Transition(en) verwendete Variable muss so belegt werden, dass ihr Wert zu den Marken in allen Eingangsstellen passt.  Hierbei ist auf folgende Details zu achten:
• Renew kann keine Variablenbelegung frei erfinden, d.h. zu jeder belegten Variable muss es mindestens eine Eingangs-, Reservierungs- oder Testkante oder einen Kanalparameter geben, über den Renew diese Belegung ermitteln kann (Ausgangskanten und Guards helfen nicht bei der Belegungsfindung).
• Vertipper in Variablennamen sind eine gemeine Variante dieses Problems und verhindern in der Regel eine erfolgreiche Belegungsfindung.
• Kanten ohne Beschriftung können ausschließlich schwarze Marken (dargestellt als "[]") konsumieren oder erzeugen.  Wenn in der benachbarten Stelle eine gefärbte Marke liegt (z.B. eine Zahl), kann die Transition nicht schalten.
4. Wenn nach eigenem Durchrechnen die Transition eigentlich schalten müsste, dann liegt möglicherweise ein nicht sofort sichtbarer Fehler in der Zeichnung vor.  Gute Kandidaten sind:
• Unbeabsichtigte, zusätzliche Kanten- und Transitionsanschriften, die beispielsweise durch ungewollten Rechtsklick entstanden sein können.  Ein Doppelklick auf die Transition bzw. Kante wählt alle zugeordneten Anschriften aus, so dass man prüfen kann, ob da zuviel ausgewählt wird.  Falls solche Anschriften einander verdecken, hilft ein "Layout Check" (im Menü Net zu finden), Überlappungen aufzuspüren.
• Funktionslose Grafikelemente oder Anschriften, die anstelle der semantisch relevanten Netzelemente gezeichnet wurden.  Falls man so etwas vermutet, hilft nur löschen und neu zeichnen der fraglichen Elemente (mit den richtigen Werkzeugen).  Semantikfrei sind (wie von doodle bereits erwähnt) alle Werkzeuge der längeren (üblicherweise oberen) Werkzeugleiste, das schließt auch das "Connected Text Tool" mit ein (A mit kleinem Pfeil nach links oben).

Also ich bin gerade soweit, dass ich den Elevator erzeugen kann und dieser kann schonmal hochfahren, die Richtung ändern und wieder nach unten fahren. Ich kann die Transitionen entweder selber durchschalten mit "Simulation step", oder ich mach "Run Simulation", dann fährt er unendlich oft hoch und runter.
Mit den Requests schaff ich es aber noch nicht. Mir ist nicht ganz klar, wie die Anfragen in das Netz gelangen. Warum ist z.B. bei dem oben freistehenden Netz nur "5;4;3" als Request im Platz.
Außerdem würde mich noch interessieren wie das mit den Testkanten genau funktioniert. Bei der Transition "stop" führt ja eine zum Kabinen-Level, ist es richtig, dass ich z.B mit "x = l" als Kantenbeschriftung prüfen kann, ob die Anfrage gleich dem Stockwerk entspricht? Mir kam es so vor, als wenn "<" oder ">" Abfragen nicht funktioniert hätten.
Das ":changeto(x)" muss bestimmt auch in das Netz eingebaut werden, oder? Da fehlt mir irgendwie der Ansatz.
Ich hab bestimmt noch mehr Fragen, aber ich glaube das reicht erstmal :)
Danke.

Mit den Requests schaff ich es aber noch nicht. Mir ist nicht ganz klar, wie die Anfragen in das Netz gelangen. Warum ist z.B. bei dem oben freistehenden Netz nur "5;4;3" als Request im Platz.

Ist nur eine Beispielmakierung, fuer Requests fuer die Stockwerke 5 , 4 und 3.

Außerdem würde mich noch interessieren wie das mit den Testkanten genau funktioniert. Bei der Transition "stop" führt ja eine zum Kabinen-Level, ist es richtig, dass ich z.B mit "x = l" als Kantenbeschriftung prüfen kann, ob die Anfrage gleich dem Stockwerk entspricht?

Nicht als Kantenbeschriftung, sondern als Guard fuer die Transition.

Kann mir mal jemand erklären, wie ich nun die Verbindung zwischen der GUI und meinem Aufzug herstelle? Ich verstehe nicht, was mit "Uplinks für Synchrone Kanäle :req(i) und :changeto(i) an den geeigneten Transitionen des Elevator-Netzes anbringen" gemeint ist…

Kann mir mal jemand erklären, wie ich nun die Verbindung zwischen der GUI und meinem Aufzug herstelle? Ich verstehe nicht, was mit "Uplinks für Synchrone Kanäle :req(i) und :changeto(i) an den geeigneten Transitionen des Elevator-Netzes anbringen" gemeint ist…

Wie schon weiter im Text steht musst du immer beide Netze geöffnet haben (Elevator + GUI). Im Elevator siehst du als Vorgabe an einigen Stellen ja schon req(x). Du musst keine spezielle Verbindung herstellen. Wenn du die Methoden richtig benennst und die Transitionen alle Bedingungen erfüllen ist es so, dass die entsprechende Transition im Netz ausgeführt wird (da wo dann :req(x) steht), wenn du in der GUI auf die entsprechenden Stockwerke klickst (Die Stockwerke in der GUI übergeben der Methode einfach nur spezifische Werte).

Wieso ist es eigentlich Teil einer Aufgabe ein blödes Tool bedienen zu müssen? Wieso kann man ohne diese Aufgabe unmöglich 50% des Blattes schaffen? Wieso ist diese eine Aufgabe, die über 50% des Blattes ausmacht, so gestellt, dass man alle Punkte vergessen kann sobald man die erste Teilaufgabe nicht hinbekommt?

Ich finde das ist ganz großer Mist.

Wenn du die Methoden richtig benennst und die Transitionen alle Bedingungen erfüllen ist es so, dass die entsprechende Transition im Netz ausgeführt wird (da wo dann :req(x) steht), wenn du in der GUI auf die entsprechenden Stockwerke klickst (Die Stockwerke in der GUI übergeben der Methode einfach nur spezifische Werte).

Wenn ich die Simulation starte, liegt in dem Platz zwischen C1 und L1 eine Marke, die aber schon statisch da ist.
Dann klicke ich mit der rechten Maustaste z.B. auf die Transition R3 und im Hauptfenster steht lediglich der Text "TransitiTransition cpn-aufzug-gui[211].R3 fired." Die Marke bleibt aber in dem Platz zwischen C1 und L1 liegen.
Mein modifiziertes Skelett ändert aber seine Stockwerke und nimmt beliebige Request-Folgen an. Was sollte denn in der GUI passieren?

Kann man bei Renew nicht "Step back" machen?
Fände das sehr hilfreich beim debuggen.
Versuche gerade einen Fehler zu reproduzieren der bei der ersten Simulation auftrat, aber jetzt seit 30 Simulationen nie wieder.
Wie soll ich herausfinden was da schief lief????

Edith:

Wie kanns überhaupt sein, dass beim ersten, oder den ersten 2 Simulationen ein nicht gewollter Verlauf auftritt, danach aber immer alles funktioniert wie es soll?
Ich bekomme das einfach nicht reproduziert :-(.
Bei meinem Glück tritt das dann bei der Abgabe auf, ich bekomme keine Punkte obwohl es bei mir 5000x funktioniert hat.

Edith #2:

was ist falsch an guard( … & d == "up") ?
Lösche ich den Teil "& d == "up" wieder schaltet die Transition…

Mein modifiziertes Skelett ändert aber seine Stockwerke und nimmt beliebige Request-Folgen an. Was sollte denn in der GUI passieren?

Hört sich schon fast richtig an.
In der GUI soll passieren: Man sendet ein Request für ein Stockwerk, sagen wir mal man befindet sich in 1 und sendet einen Request für 3, dann soll man natürlich in den 3. Stock fahren und in der GUI sollte man dann rechts bei der "update logic" sehen, dass die Kabine auch in das gewünschte Stockwerk (3) gefahren ist.
Der Ablauf sieht also ungefähr so aus: Du startest die Simulation, sendest über die GUI Requests für Stockwerke, in dem Netz werden die nötigen Transitionen dafür ausgeführt und, da man an entsprechenden Stellen das :changeto eingebaut hat, aktualisiert sich auch in der GUI die "update logic", sodass man dort sehen kann, dass man sich auch wirklich in dem Stockwerk befindet.

Edith #2:

was ist falsch an guard( … & d == "up") ?
Lösche ich den Teil "& d == "up" wieder schaltet die Transition…

Was daran falsch ist kann ich dir auch nicht genau sagen, aber bei mir funktioniert es, wenn ich an der Testkante direkt "up" bzw "down" ranschreibe und ihr nicht einen namen gebe und dann mit entsprechendem guard(…) prüfe…

Edith #2:

was ist falsch an guard( … & d == "up") ?
Lösche ich den Teil "& d == "up" wieder schaltet die Transition…

Was daran falsch ist kann ich dir auch nicht genau sagen, aber bei mir funktioniert es, wenn ich an der Testkante direkt "up" bzw "down" ranschreibe und ihr nicht einen namen gebe und dann mit entsprechendem guard(…) prüfe…

Vielen Dank! Da hab ich wohl vor lauter Wald die Bäume nicht mehr gesehen..

Hört sich schon fast richtig an.
In der GUI soll passieren: Man sendet ein Request für ein Stockwerk, sagen wir mal man befindet sich in 1 und sendet einen Request für 3, dann soll man natürlich in den 3. Stock fahren und in der GUI sollte man dann rechts bei der "update logic" sehen, dass die Kabine auch in das gewünschte Stockwerk (3) gefahren ist.
Der Ablauf sieht also ungefähr so aus: Du startest die Simulation, sendest über die GUI Requests für Stockwerke, in dem Netz werden die nötigen Transitionen dafür ausgeführt und, da man an entsprechenden Stellen das :changeto eingebaut hat, aktualisiert sich auch in der GUI die "update logic", sodass man dort sehen kann, dass man sich auch wirklich in dem Stockwerk befindet.

Aha, ich muss doch noch was in meinem Elevator ändern, damit die GUI läuft. Indem ich das changeto(Stockwerk) bei den up- und down-Transitionen eingefügt habe läuft das nun :)
Danke!!

Mag noch mal wer für ganz doofe sagen was mit den Testkanten gemeint ist?
Ich sitze schon stundenlang dran und ich bekomme nichts geschaltet wenn da Testkanten dran sind..

Ich komme mit der Bedienung noch nicht so klar von renew…
Ich habe keine Vorlage benutzt sondern ein neues Netz gebaut.

Nur weiss ich nicht wie ich es bei einem gefärbten Netz mache wie ich guards benutze usw.
Also nehmen wir mal an ich wollte ein Netz bauen, dass einfach eine Zahl runterzählt bis 0, so ähnlich wie Präsenz 5.5 nur ganz simpel halt.

Ich mache einen neuen Platz, ziehe von da aus nach rechts, eine neue Transition entsteht. Ziehe von da aus zurück, ein neuer Pfeil zu p1. Die Namen denk ich mal mit Name Tool eingeben ("p1","t1").
2 mal rechtsklick auf p1 und 8 eingeben (z.B), 2 mal rechtsklick auf den Pfeil zu t1 und m eingeben, 2 mal rechtsklick auf den anderen und m-1 eingeben, 2 mal rechtsklick auf t1 und :s(m>0).

So hatte ich es mir gedacht… aber wenn ich die Simulation starte passiert nichts.

Wie würde ich das konstruieren in renew?

Mag noch mal wer für ganz doofe sagen was mit den Testkanten gemeint ist?
Ich sitze schon stundenlang dran und ich bekomme nichts geschaltet wenn da Testkanten dran sind..

Eine Testkante ist fast das gleiche, wie so eine <–>. Einziger (oder einzig relevanter?) Unterschied ist, dass WÄHREND die Transition schaltet…
* bei der Testkante die Marke noch auf dem Platz liegt
* bei der <–> die Marke nicht mehr da liegt (nach dem Schalten aber wieder)

Mag noch mal wer für ganz doofe sagen was mit den Testkanten gemeint ist?
Ich sitze schon stundenlang dran und ich bekomme nichts geschaltet wenn da Testkanten dran sind..

Ich finde "Testkanten" ist kein gutes Wort dafür. Diese Kanten geben der Transition die Information, was gerade in den Plätzen anliegt und lassen sich als Bedingung bei den Guards verwenden. Anders als bei den gerichteten Kanten bleiben die Zustände der Plätze aber erhalten.

Vielen dank, jetzt macht das gleich viel viel mehr Sinn.

Kann sich noch wer daran erinnern, das in der Vorlesung gesagt worden ist wir würden das Programm nicht brauchen? ):

Edith #2:

was ist falsch an guard( … & d == "up") ?
Lösche ich den Teil "& d == "up" wieder schaltet die Transition…

Was daran falsch ist kann ich dir auch nicht genau sagen, aber bei mir funktioniert es, wenn ich an der Testkante direkt "up" bzw "down" ranschreibe und ihr nicht einen namen gebe und dann mit entsprechendem guard(…) prüfe…

ich hatte das selbe problem und jetzt funktioniert es mit a.equals("up")

Noch mal ganz doof..
Wie bekomm ich z.B. up geschaltet?
Das ganze hängt ja nur mit den Testkanten zusammen. Ich dachte wenn die Bedingungen an up stimmen müsste es doch schalten oder?
Oder wie bekomm ich es dazu etwas zutun?

damit up schaltet, muss die richtung auch "up" sein, es müssen req aboves vorhanden sein und das stockwerk in dem man sich befindet, darf gerade keinen request haben.

… 2 mal rechtsklick auf t1 und :s(m>0).

So hatte ich es mir gedacht… aber wenn ich die Simulation starte passiert nichts.

Die Transitionsanschrift ":s(m>0)" legt de facto die Transition lahm.  Renew interpretiert den Doppelpunkt als Kanal-Uplink, d.h. diese Transition könnte nur in Synchronisation mit einer anderen mit passendem Downlink (Kanalname "s", Parametertyp boolean) schalten.  Eine solche hast Du aber vermutlich nicht gezeichnet.

Ich nehme mal an, dass (m>0) ein Guard sein soll.  Die richtige Syntax dafür lautet "guard (m > 0)" (ohne Anführungszeichen).

Edith #2:

was ist falsch an guard( … & d == "up") ?
Lösche ich den Teil "& d == "up" wieder schaltet die Transition…

Was daran falsch ist kann ich dir auch nicht genau sagen, aber bei mir funktioniert es, wenn ich an der Testkante direkt "up" bzw "down" ranschreibe und ihr nicht einen namen gebe und dann mit entsprechendem guard(…) prüfe…

ich hatte das selbe problem und jetzt funktioniert es mit a.equals("up")

d == "up" ist falsch, da es – wie in Java üblich –  auf Objektidentität statt auf Inhaltsgleichheit prüft.  Deswegen ist "up".equals(d) der richtige Ersatz.  Oder man nutzt die Tatsache, dass Renew bei der Markensuche ebenfalls .equals() verwendet.  Daher funktioniert das "pattern matching" mit der Zeichenkette "up" an der Testkante.