---

Hallo Zusammen!

Ich habe eine Methode1, die wie folgt aussieht:

Code:

---

is
do
wait 3000;
Methode2;
end;

---

Jetzt möchte ich aber falls die Methode1 innerhalb dieser 3000 Sekunden erneut aufgerufen wird, dass der Befehl wait von neuem anfängt und den vorhergehenden Aufgeruf "vergisst".

Meine Beobachtung war jedoch, das er dann einfach ein zweites wait startet.
Gibt es für so eine Sache einen alternativen Befehl oder kann ich den wait dahingehend verändern?
Ich hoffe nämlich, dass ich nicht mit der Zeit aus dem Ereignisverwalter arbeiten muss.

Danke

chris

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

---

beschreib doch mal, was Du genau vor hast.

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

---

Hallo Zusammen und im speziellen an Der Simulant!

Ich möchte gerne einen Stau- bzw. Mangelschalten zusammenbauen. Nachdem das im Prinzip fast das gleiche ist möchte ich den Stauschalter als Beispiel nehmen.

Auf einer staufähigen Förderstrecke soll ein „Sensor“ erkennen, wenn ein BE vor ihm stehen bleibt. Vorbeifahrende BE sollen ihn nicht interessieren (Außer sie fahren sehr sehr langsam vorbei).

Da ich die Länge meins Objektes und aufgrund meiner Anlage auch die Geschwindigkeit kenne, hätte ich folgende Idee:
Ich setze einen Sensor auf den Bug meines Objektes. Dieser setzt mir eine Variabel (True/False) als Merker und startet mir einen Countdown.
Der Countdown dauert (theoretisch) die Länge meines BEs / Geschwindigkeit des Pulkes.

Kommt innerhalb dieser Zeit mein Heck vorbei, wird dies über einen zweiten Sensor an der gleichen Stelle erkannt und bricht den Countdown ab.

Passiert innerhalb dieser Zeit das Heck nicht den zweiten Sensor weiß ich das ein BE vor meinem Sensor zum stehen gekommen ist und kann eine Staumeldung abgeben.

Meine Überlegung war, dass wenn ich eine Methode ein zweites Mal starte, dass ein wait-Befehl aus dem ersten Aufruf seine Gültigkeit verliert. Dem scheint nicht so zu sein.

Für einen Mangelschalter würde ich von dem Heck einen Countdown auslösen lassen und mir vom Bug des nachfolgenden BEs beenden lassen. Bei nicht eintreffen dann eine Mangelmeldung rausgeben.

Freue mich über Ideen/Verbesserungsvorschläge bwz. wenn ich auf dem Holzweg bin um eine Landkarte zum rechten Weg finden. 

Danke

chris

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

---

????
Das Beispiel http://ww3.cad.de/foren/ubb/Forum262/HTML/000822.shtml#000001
hast Du Dir schon angeschaut und verstanden, oder ?

delta =0  -> Stau (lokal)
delta >0 -> Mangel (lokal)

OK !!!

Ueber die inhaltsliste kannst vermutlich auch die Abstände zwischen den bes bestimmen.

Schau Dir mal waituntil ..... prio.. in der Hilfe an

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

---

Hallo Der Simulant und auch an alle anderen fleißigen Leser!

Ich hab mir dein Beispiel angeschaut (und bin der Meinung es auch verstanden zu haben).
Damit ich mir auch sich bin: Du berechnest die Zeit, die zwischen dem Heck von BE1 und dem Bug von BE2 vergeht. Richtig?
Das sehe ich als Ansatz für einen Mangelschalter. Es stimmt auch, dass DELTA > 0 bei einem Mangel ist. (Jetzt kommt aber ein Aber).

Aber die Meldung

Code:

---

print status,chr(9),delta;

---

erscheint erst dann, wenn wieder ein neues BE nachkommt, sprich wenn der Mangel mehr oder weniger schon vorbei ist.

Darum wollte ich ein wait 123; aufrufen was von dem Bug des nachfolgenden BE unterbrochen werden sollte. Ist dies nicht der Fall soll dann eine Reaktion erfolgen.

Wenn ich dein Prinzip auf einen Stauschalter anwende, also die Zeit zwischen Bug und Heck desgeleichen BEs bestimme, bekomme ich erst dann die Meldung „Stau“ wenn dieser sich bereits auflöst. Da ich ja das Heck brauch um das DELTA auszurechnen. Hier würde ich wieder ein wait aufrufen, was dann vom Heck unterbrochen wird, wenn dieser innerhalb der Waitzeit ankommt. Ansonsten mit einem Methodenaufruf reagieren.

War dir dies so bewusst? Oder stehe ich noch immer auf einem Holzweg?

Dein Vorschlag mit dem waituntil … prio… hatte ich schon verworfen, da ich in der Hilfe unter dem Schlagwort "Methode suspendieren“ gelesen habe, dass mit einem waituntil nur eine Methode unterbrochen aber nicht abgebrochen wird. Somit würde meine Wartenzeit wieder weiterlaufen.

Dein Vorschlag mit der Inhaltsliste zu arbeiten hatte ich auch schon. Nur halte ich bei meiner Simulation dies nicht  für anwendbar, da ich eine Flaschenabfüllanlage simuliere und mehrere 100.000 BEs/h  gleichzeitig handel muss. Somit ist meine Simulation ohnehin schon relativ langsam. Nachdem ich solche Stau- und Mangelschalter auch in größerer Meine einbauen werde sehe ich da mit den Inhaltslisten größere Probleme. Oder sehe ich das falsch und brauche für eine Inhaltliste kaum Rechenleistung?

Würde mich über weitere Anregungen freuen.

Danke Chris

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

---

   

Zitat:

---

erscheint erst dann, wenn wieder ein neues BE nachkommt, sprich wenn der Mangel mehr oder weniger schon vorbei ist.

---

na und, dafür habe ich ja den Status und Zeitstempel (ende0) berücksichtigt. Du kannst also zu jedem Zeitpunkt den Zustand abfragen und nicht erst wenn das folgende Be die Sensor-Methode aufruft !

Gleiches gilt fuer den Stau-Zustand !

   

Zitat:

---

Dein Vorschlag mit dem waituntil … prio… hatte ich schon verworfen, da ich in der Hilfe unter dem Schlagwort "Methode suspendieren“ gelesen habe, dass mit einem waituntil nur eine Methode unterbrochen aber nicht abgebrochen wird. Somit würde meine Wartenzeit wieder weiterlaufen.

---

Quatsch !

Die Methode wird solange suspendiert, bis sie ein "True"-Ereignis erhält. Danach kannst Du selbst in der Methode entscheiden ueber einen sofortigen Abbruch = (return)  oder nicht !

Zitat:

---

Oder sehe ich das falsch und brauche für eine Inhaltliste kaum Rechenleistung?

---

Kannst es ja mal mit dem Profiler messen !

------------------
Der Simulator
WSL, Bruxelles

[Diese Nachricht wurde von Simulator am 07. Jan. 2008 editiert.]

---

Sorry! Ich nochmal.

Hätte da noch ein paar Fragen.

Zitat:

---

na und, dafür habe ich ja den Status und Zeitstempel (ende0) berücksichtigt. Du kannst also zu jedem Zeitpunkt den Zustand abfragen und nicht erst wenn das folgende Be die Sensor-Methode aufruft !

Gleiches gilt fuer den Stau-Zustand !

---

Für diesen Fall müsste ich wieder eine Mehtode von außen Aufrufen die diese zwei Zustände weiterverarbeitet. Ich hatte das bei einer anderen Gelgenheit mal mit einem Trigger realisiert. Das Ergebnis war, das mein System dann sehr langsam war.
Darum wollte ich es so lösen, dass diese Methode nur bei Stau/Mangel eine weitere aufruft.

Zitat:

---

Quatsch !

Die Methode wird solange suspendiert, bis sie ein "True"-Ereignis erhält. Danach kannst Du selbst in der Methode entscheiden ueber einen sofortigen Abbruch = (return)  oder nicht !

---

Das mit dem return verstehe ich nicht. Hab leider auch keine Bsp. gefunden. Könntest du mir bitte dazu noch einen Kommentar geben?

Und danke für den Tip mit dem Profiler.

Danke Chris

PS: Gibt es aus deiner Sicht ein gutes Buch/Homepage. Bzw. ein alternatives Forum für den Einstieg?

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

---

    

Zitat:

---

....die diese zwei Zustände weiterverarbeitet. Ich hatte das bei einer anderen Gelgenheit mal mit einem Trigger realisiert

---

wie das ?

    

Zitat:

---

Das mit dem return verstehe ich nicht. Hab leider auch keine Bsp. gefunden. Könntest du mir bitte dazu noch einen Kommentar geben?

---

das Bsp.:

is
do
repeat
waituntil zeit > ereignisverwalter.zeit or einzelstation.anzahlein> 5 prio 1;
if einzelstation.anzahlein> 5 then
print 6;
else
end;
until false;
end;

Zu Beginn der Simulation Die Methode wird 1 X ueber methaufr (s. Hilfe) aufgerufen z.B. in "init".

Alternative waere ohne "repeat...until"

Hast Du Dir eigentlich mal ueberlegt, dass man den Stau/Mangel-Zustand ggf. ueber die  Attribute "voll" bzw. "belegt"  feststellen kann ?

Schau Dir auch mal die abfragbaren Statistiken "wartend" /"blockiert" an. 

    

Zitat:

---

Gibt es aus deiner Sicht ein gutes Buch/Homepage. Bzw. ein alternatives Forum für den Einstieg?

---

Nun dieses Forum ist zwischenzeitlich auf ein absolutes Einsteigerniveau heruntergerichtet worden. Ein Forum mit einem noch niedrigeren level wirst Du wohl nicht finden.

Kannst ja mal Deine Fragen bei www.xing.de  /(Gruppe = Digitale Fabrik)  anbringen.

Hast Du schon an eine Schulung gedacht ?

------------------
Der Simulator
WSL, Bruxelles

[Diese Nachricht wurde von Simulator am 26. Jan. 2008 editiert.]

---

Hallo Tuhpon,

ich muss gestehen ich hab mir deinen Dialog mit Simulator nicht komplet durchgelesen...

Methode1:

Code:

---

is
do
  Variable := Ereignisverwalter.Zeit + 3000;
  wait 3000;
  Methode2;
end;

---

Methode2:

Code:

---

is
do
  if Ereignisverwalter.Zeit = Variable then
    ...
  end;
end;

---

Also ich finde das mit dem Ereignisverwalter nicht so schlimm.....

Ich würde mir eher Gedanken machen ob ich dies Simulationszeitfressende "wait" benutzen würde

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

---

Was bezweckst Du mit der nochmaligen Abfrage der Variable in Methode2 ???

Im Übrigen - wie kommst Du dazu zu behaupten, dass "wait" ein Simulationszeitfresser sei?

Das ist nichtssagend und verleitet wohlmöglich noch die Leser, diese Funktion nicht zu nutzen !!  

------------------
Der Simulator
WSL, Bruxelles

[Diese Nachricht wurde von Simulator am 19. Jan. 2008 editiert.]

---

Tuhpon:

Zitat:

---

Jetzt möchte ich aber falls die Methode1 innerhalb dieser 3000 Sekunden erneut aufgerufen wird, dass der Befehl wait von neuem anfängt und den vorhergehenden Aufgeruf "vergisst".

---

@Simulator

zum zeitpunkt t=0 wird Methode1 gestartet => zum zeitpunkt t=3000 wird Methode2 gestartet. Die Variable wird auf t=3000 gesetzt.

zum zeitpunkt t=234 wird Methode1 erneut gestartet => zum zeitpunkt t=3234 wird auch Methode 2 gestartet. Die Variable wird auf t=3234 gesetzt.

zum zeitpunkt t=3000 wird Methode2 gestartet da wir dies ja zum zeitpunkt t=0 in auftrag gegeben haben, allerdings wird der unter "..." stehende Quelltext nicht ausgeführt da 3000 nicht gleich 3234 ist.

zum zeitpunkt t=3234 wird Methode 2 erneut gestartet, und nun wird auch der "..." Quelltext ausgeführt da t=Variable ist.

Ich bin mir sicher das, wenn du noch mal ein klein bisschen weniger emotional den Code durchliest, dir auch auffällt das er sinn macht.

was die Geschichte mit "wait" angeht:

Ich hab nur das wiedergegeben was mir bei einer Schulung beigebracht wurde. Um hier nichts falschen stehen zu lassen habe ich eine Anfrage an die eM-Plant Entwicklung gestellt und werde sobald ich Antwort habe diese hier posten. (Falls du selbst dort arbeitest, was deine Identifikation mit dem Tool erklären würde, darfst du gerne persönlich auf meine Anfrage antworten.)

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

---

 

Zitat:

---

"wait" sollte nicht kritisch sein

---

"wait until" sinngemäß: sollte bei rein beobachtbaren Ereignissen auch nicht kritisch sein - ist aber mit Formeln oder nicht beobachtbaren Geschichten wie variablen mit Vorsicht zu genießen

[Diese Nachricht wurde von kleinUNDhilflos am 25. Jan. 2008 editiert.]

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

---

Wenn nach "if Ereignisverwalter.Zeit = Variable then"
eine Zeitverzögerung eintritt (z.B. durch ein "waituntil..."),so können mehrere "Methode2"-Methoden gleichzeitig ausgeführt werden. 

Methodenaufrufe sollten deshalb kanalisiert werden, um sicherzustellen, dass die Methode2 vollständig abgearbeitet wurde vor einem erneuten Aufruf.

Zitat:

---

"wait until" sinngemäß: sollte bei rein beobachtbaren Ereignissen auch nicht kritisch sein - ist aber mit Formeln oder nicht beobachtbaren Geschichten wie variablen mit Vorsicht zu genießen

---

"waituntil" funktioniert m.E. nur in Verbindung mit beobachtbaren Ereignissen.

Variablen-Objekte sind beobachtbar !

@ 

Zitat:

---

(Falls du selbst dort arbeitest, was deine Identifikation mit dem Tool erklären würde...)

---

Nein, ich bin ein ganz normaler 0815-Anwender und arbeite fuer einen  italienischen Konzern.

Mit (zwischenzeitlich) Siemens habe ich weder direkt noch indirekt zu tun!

------------------
Der Simulator
WSL, Bruxelles

[Diese Nachricht wurde von Simulator am 27. Jan. 2008 editiert.]

---

Man muss zwischen wait und waituntil unterscheiden. Die wait-Anweisung reiht einfach nur ein Ereignis im Ereignisverwalter ein und ist daher überhaupt nicht zeitkritisch. (Dasselbe gilt übrigens auch für MethAufr). Beim waituntil kommt es darauf an, wie oft sich der überwachte Ausdruck ändert. Der Ausdruck "Ereignisverwalter.Zeit" ändert sich logischerweise ständig. Eine einzelne suspendierte Methode sollte aber trotzdem kein Problem darstellen. Wenn aber hunderte Methoden gleichzeitig suspendiert sind, wird es u.U. zäh.

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