---

Screenshot_Modellaufbau.pdf

Hallo Leute,

ich bin ein absoluter Neuling in Sachen Plant Simulation und soll im Rahmen meiner Bachelorarbeit ein zugegebenermaßen relativ umfangreiches Lager mit allen logistischen Abläufen simulieren. Dank diesem Forum und einem Buch habe ich schon ein Modell auf die Beine gestellt. Es gibt aber noch ein Problem...
Wie man in dem angehängten Screenshot erkennen kann, habe ich auf dem ganzen Weg viele Sensoren zur Positionserkennung gepflastert. Quelle (=Zielort für nicht beladene Kräne) und Zielort (=Zielort für beladene Kräne) der Fahrzeuge (Kräne) werden aus automatisch generierten Aufträgen gezogen. Das klappt auch wunderbar. Bei beiden Kränen ist es so, dass sobald sie einen Auftrag bekommen, dass sie die entsprechende "Quelle" anfahren. Sobald sie aber ein BE aufgenommen haben, fahren sie den Zielort, der ebenfalls aus den Aufträgen entnommen wurde, nicht an. Sie fangen dann an zwischen zwei Sensoren "rumzuzappeln", so als ob der eine Sensor den Befehl "fahre vorwärts" und der nächste Sensor den Befehl "fahre rückwärts" ausgibt. Aus diesem Grund habe ich in jeden Fall (hauptsächlich If-Verzweigungen) einer jeden Methode eine Print-Anweisung mit dem Namen der Methode und der Fallnummer (fortlaufende Nummer) eingefügt. Sobald ich die Simulation starte, wird dann in der Konsole die Reihenfolge der Methoden bzw. der Fälle in den Methoden angezeigt, die vom Programm aufgerufen werden. Die Konsole zeigt mir an, dass der linke Kran (Kran84) sich bei Fall 14 der Methode "FahrsteuerungKran84" aufhängt. Der rechte Kran (Kran83) hängt sich hingegen bei dem Fall 21 der Methode "FahrsteuerungKran83" auf. Die beiden Fälle werden in einer Tour in der Konsole ausgegeben und die Fahrzeuge zappeln fröhlich zwischen zwei Sensoren hin und her und fahren nicht zum Wunschort.

FahrsteuerungKran84: Fall 14:

elseif ZielortKRA84<SensorID AND @.belegt AND ZielortKRA84=45  then
  print "FahrsteuerungKran84: Fall 14";
  @.Zielsensor:=SensorID;
  @.geschwindigkeit:=0;
  @.rückwärts:=true;
  @.geschwindigkeit:=1;
  HolePriorität84;
  HolePriorität83;
  ErmittlungKollisionsgefahr;

FahrsteuerungKran83: Fall 21:

elseif ZielortKRA83>SensorID AND @.belegt AND ZielortKRA83=308  then
  print "FahrsteuerungKran83: Fall 21";
  @.Zielsensor:=SensorID;
  @.geschwindigkeit:=0;
  @.rückwärts:=false;
  @.geschwindigkeit:=1;
  HolePriorität84;
  HolePriorität83;
  ErmittlungKollisionsgefahr;

ErmittlungKollisionsgefahr, HolePriorität84 und HolePriorität83 sind Methoden, die den Wert einiger globaler Variablen ändern. Die können für das Problem nicht verantwortlich sein.

Jedes Mal, wenn der Kran 84 einen Sensor berührt, wird die FahrsteuerungKran84 ausgeführt und jedes Mal, wenn der Kran 83 einen Sensor berührt, wird die FahrsteuerungKran83 ausgeführt. Die Fahrsteuerungen dienen dazu, die Kräne gemäß der Quellen und Zielorte zu den richtigen Sensoren zu führen und die Kräne, sobald sie die Sensoren erreicht haben, zum Aufnehmen oder Ablegen von BEs zu bewegen. Interessant könnte vielleicht noch sein, dass ich die Sensoren für den Kran 84 und für den Kran83 jeweils übereinander gelegt habe, sodass die Sensoren der beiden Kräne die gleichen Positionen haben. Aber kann mir irgendwie nicht vorstellen, dass das das Problem sein könnte.

Warum zappeln die Kräne zwischen zwei Sensoren, sobald sie ein BE aufgenommen haben? Dürfen die Kräne vielleicht nur einmal den Befehl @.rückwärts:= true bekommen? Das kann aber eigentlich nicht sein, weil die Kräne auch zur richtigen Quelle fahren und dafür habe ich ähnliche Codes.

Den Code hier habe ich aus der FahrsteuerungKran83:

elseif QuelleKRA83>SensorID AND @.leer AND QuelleKRA83=46 then
  print "FahrsteuerungKran83: Fall 3";
  @.Zielsensor:=SensorID;
  @.geschwindigkeit:=0;
  @.rückwärts:=false;
  @.geschwindigkeit:=1;
  HolePriorität84;
  HolePriorität83;
  ErmittlungKollisionsgefahr;

Das klappt wunderbar. Nur wenn die Kräne ein BE aufgenommen haben, machen sie, was sie wollen...!

Brauche dringend Hilfe, weil mir die Zeit langsam davon rennt!!!

Beste Grüße
Neuling X

------------------
Unmögliches wird schnell erledigt. Wunder dauern etwas länger!

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

---

Moin,
für Fehlersuche ist print "FahrsteuerungKran83: Fall 21"; zu wenig, gib die Steuerungsvariablen vor und nach einer Änderung in Console aus. Es geht auch mit einem Generator, welcher in regelmäsigen Abständen dir die Steuerungsvariablen ausgibt. und Debugger einsetzen!!!

Zitat:

---

ErmittlungKollisionsgefahr, HolePriorität84 und HolePriorität83 sind Methoden, die den Wert einiger globaler Variablen ändern. Die können für das Problem nicht verantwortlich sein.

---

das geht immer nach dem Ausschlussverfahren. Grenze den Fehler weiter ein. Nur beurteilen kann ich so dies nicht.

Zitat:

---

Interessant könnte vielleicht noch sein, dass ich die Sensoren für den Kran 84 und für den Kran83 jeweils übereinander gelegt habe, sodass die Sensoren der beiden Kräne die gleichen Positionen haben. Aber kann mir irgendwie nicht vorstellen, dass das das Problem sein könnte.

---

Ja, wenn die Übereinander liegen, und unterschiedliche Methoden ansprechen, sollten die Sensoren sich nicht behindern.

Zitat:

---

Dürfen die Kräne vielleicht nur einmal den Befehl @.rückwärts:= true bekommen?

---

Rückwärt ist ein Zustand. Ob du den 100mal auf true setzt. ändert nichts, das er auf true steht.

Zitat:

---

Warum zappeln die Kräne zwischen zwei Sensoren, sobald sie ein BE aufgenommen haben?

---

Keine Ahnung. Das Modell kenne ich ja nicht. Es muss zwischen diesen zwei Sensoren die Steuerungsrichtung ändern. Aber ausschliessen kann ist nichts.
Wo ist dein Ziel? Nicht das du das Abladen vergessen hast?

Tipp: Code vereinfachen-->z.B.: dies gillt für jeden elseif-Block, also auslagern nach If-Schleife

Code:

---

HolePriorität84;
  HolePriorität83;
  ErmittlungKollisionsgefahr;

---

vg
nadin

------------------
„Die einfachste Art an korrekte Informationen zu gelangen ist, etwas Falsches in ein Forum zu posten und auf die Korrektur zu warten.“ Matthew Austern

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

---

Hallo nadin1223,

ja der Tipp ist auf jeden Fall gut, aber das Problem tritt schon gleich zu Beginn der Simulation auf. An dieser Stelle werden noch gar keine nennenswerten Parameter geändert. Es kann auch keine andere Methode einen gegensätzlichen Befehl ausgeben, weil noch gar keine andere Methode aufgerufen wird, die so etwas machen könnte.

Mir fällt ein, dass ich noch ergänzen muss, dass die Codes in Fall 14 und Fall 21 bereits funktioniert haben. Zu Beginn der Entwurfsphase des Modells hatte ich ursprünglich nur einen Kran in meinem Modell. Der hat ohne Probleme die Teile aufgenommen und zu den entsprechenden Zielorten transportiert. Seitdem ich den zweiten Kran in das Modell eingefügt habe, klappt es nicht mehr. Es sind natürlich noch einige Methoden seitdem hinzugekommen, aber die werden zu Beginn noch gar nicht aufgerufen.

Das macht für mich einfach keinen Sinn. Kann man ein Simulationsmodell durch den Einsatz zu vieler Sensoren überlasten, sodass es zu unerklärlichen Fehlhandlungen kommt? 

------------------
Unmögliches wird schnell erledigt. Wunder dauern etwas länger!

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

---

Zitat:

---

An dieser Stelle werden noch gar keine nennenswerten Parameter geändert.

---

Gut dann bleibt wenig Code zum Durchsuchen übrig.

Zitat:

---

[...]bereits funktioniert haben. Zu Beginn [...]einen Kran in meinem Modell. [...]Seitdem ich den zweiten Kran in das Modell eingefügt habe, klappt es nicht mehr.

---

Prüfe nach, ob deine Steuerung den richtigen Kran anspricht.
Prüfe nach, was an einem der Sensoren für einen Kran passiert. Entspricht die Aufrufreihenfolge und Parameter deiner Erwartung?
Las einen Kran laufen. Schau ob die Auslagerung geht.

Code:

---

Es sind natürlich noch einige Methoden seitdem hinzugekommen, aber die werden zu Beginn noch gar nicht aufgerufen.

---

Tja, hoffe du weißt noch, was du so alles geändert hattest,damit falls nötig mit früherer Version neu anzufangen.   

Code:

---

Kann man ein Simulationsmodell durch den Einsatz zu vieler Sensoren überlasten, sodass es zu unerklärlichen Fehlhandlungen kommt?

---

Hilft dir auch nicht weiter. Falls dies ein Bug ist, dann kannst du es nur als Bug belegen, wenn Du diesen Bug identifizierst und wiederholt gewollt in vereinfachten Modell auftreten lässt. (Auch ein Bug ist reproduzierbar.) Somit ist es irrelevant ob du nach deinem Fehler oder Bug suchst. Solange du es nicht gefunden hast ist das Vorgehen gleich. --> HIER <--.

Aus meiner Erfahrung ist mir bis jetzt im EM noch kein Bug untergekommen. Auch ist dein Vorgehen zur Abbildung eines automatischen Lager gängig und wird häufig praktiziert. Somit glaube ich nicht, dass ein Bug vorliegt bzw. die Anzahl der Sensoren einen Bug verursacht. Ausgeschlossen ist natürlich nichts. 

vg
Nadin

------------------
„Die einfachste Art an korrekte Informationen zu gelangen ist, etwas Falsches in ein Forum zu posten und auf die Korrektur zu warten.“ Matthew Austern

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

---

Hallo,

das Problem ist behoben! Das Problem lag wie schon vermutet nicht in den Programmierungen..

Für die Leute, die eventuell das gleiche Problem haben, kann ich die Ursache des Problems gerne einmal erklären...

Ich hatte mir in den Kopf gesetzt, dass die Sensoren, die bei mir die Fahrzeugsteuerungen für die Kräne aufrufen (die Sensoren mit geraden IDs rufen die Fahrzeugsteuerung des Krans 84 auf und die Sensoren mit den ungeraden IDs rufen die Fahrsteuerung des Krans 83 auf) automatisch  fahrzeuggebunden sind, weil sie eben mit den Fahrzeugsteuerungen gekoppelt sind... totaler Quatsch! Dadurch dass die Sensoren für den Kran 83 und den Kran 84 schön übereinander liegen, hat der Kran 83 jedes mal automatisch die Fahrsteuerung des Krans 84 mit ausgelöst und umgekehrt. Das führte zu totalem Unsinn. Das erklärt auch, warum die Codes bei der Simulation eines Krans funktionierten.

Im Nachhinein sehr logisch!    

Lösen kann man das Problem, indem man beiden Kränen ein benutzerdefiniertes Attribut hinzufügt und dieses bei Aufruf der Fahrsteuerungen abfragt. Dann kann die Fahrsteuerung ruhig jedes Mal vom falschen Kran aufgerufen werden. Da der Kran nicht über das entsprechende benutzerdefinierte Attribut verfügt, richtet die Fahrsteuerung keinen Schaden an.

Ich habe jetzt aber noch ein anderes Problem. Und zwar erstelle ich per Methode auf der linken Hallenseite zwei Trailer (als normale Fahrzeuge modelliert), die zu gegebener Zeit rückwärts in die Halle fahren sollen. Mein Problem ist, dass der Trailer1 am Ende des Weges erzeugt wird und dort einfach stehen bleibt. Der Trailer 2 wird eine Zeit später erzeugt und fährt dann, wie gewünscht, rückwärts zum Sensor. Die Codes für die beiden Trailer sind absolut identisch. Wie kann das sein?

Bei beiden Trailern ist ein Haken bei "rückwärts" gesetzt. Der Weg, auf dem die Trailer erzeugt werden, ist 9 m lang und die Trailer werden auch bei 9 m erzeugt. Aber selbst wenn ich den Trailer 1 bei 6 m erzeuge, bleibt er einfach stehen. Ich habe es schon mit Fahrbefehlen versucht, obwohl Fahrzeuge ja bei Erstellung sofort losfahren. Das hat aber nichts gebracht.

Der Trailer ist eine Zeit lang mal rückwärts gefahren. Aus irgendeinem Grund macht er es nicht mehr. Hatte Jemand schon einmal ein solches Problem? Ich wäre dankbar für Hilfe. Das macht für mich wieder einmal absolut keinen Sinn.

Beste Grüße
Neuling X

------------------
Unmögliches wird schnell erledigt. Wunder dauern etwas länger!

[Diese Nachricht wurde von Neuling X am 25. Okt. 2016 editiert.]

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

---

na hat doch nur 5 Tage gedauert. Herzlichen Glückwunsch  

Zitat:

---

Mein Problem ist, dass der Trailer1 am Ende des Weges erzeugt wird und dort einfach stehen bleibt. Der Trailer 2 wird eine Zeit später erzeugt und fährt dann, wie gewünscht, rückwärts zum Sensor. Die Codes für die beiden Trailer sind absolut identisch. Wie kann das sein?

---

Was macht Trailer 1 ohne Trailer 2?
Was macht der Trailer 2 wenn du diesen für Trailer 1 erzeugst?
Teile das System wieder in Stepps und untersuche die Zustandsveränderung. Am Besten alles in Console ausgeben, was das Fahrzeug stoppen kann.

------------------
„Die einfachste Art an korrekte Informationen zu gelangen ist, etwas Falsches in ein Forum zu posten und auf die Korrektur zu warten.“ Matthew Austern

[Diese Nachricht wurde von nadin1223 am 26. Okt. 2016 editiert.]

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