---

Hallo!

Ich glaube nicht das sich viele mit der Fabriksimulationssoftware QUEST auskennen. Ich hoffe aber mal das sich das ändern wird, daher stehe ich für fragen gerne zu verfügung! Ich bin kein Experte doch ein paar funktionen bekomme ich hin.
Z.B. die Funktion AGV (Automated Guided Vehicles)!

Gruss DrMabuse07 

------------------
Ein erfolgreicher Mann hat alles, nur keine Zeit

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

---

Ich möchte mich Dr.Mabuse anschliessen.
Wir arbeiten hier am European Delmia Training Center in Siegen und geben auch Schulungen, als Experte würde ich mich trotzdem nicht bezeichnen: Ich bin immer wieder überrascht, was QUEST einem für merkwürdige Beschränkungen auferlegt. Falls jemand fragen hat: Stehe gern zur Verfügung.

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

---

Ich arbeite mich gerade beruflich in Quest ein. Würde mich also über Tipps von jeder Seite freuen, auch was Seiten im Internet angeht, die sich mit Quest beschäftigen. Sobald ich's mal kann, geb ich auch gerne meine Tipps und Erfahrungen weiter.

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

---

Ich hätte da gleich mal ne Frage:
In QUEST kann man Klassen- und Element-Verbindungen verwenden. Wenn man in einer Klasse mehrere Elemente hat, dann bietet sich die Klassenverbindung an, damit man nicht alle Elemente einzeln verknüpfen muss. Damit man noch Einfluss auf das Routing der Parts hat, gibt es dafür die Part-Input-Logik in der Ziel-Klasse. Nun das Problem: Der Rückgabewert dieser Logik ist ein Element. Ich denke mal, es soll das Element sein, zu dem die Vorgänger-Klasse das Part routen soll. Aber egal was ich an Logik einbaue, das Vorgänger-Element routet immer zum ersten Element der Ziel-Klasse, sofern dort Platz ist. Hat jemand dazu schon Erfahrungen gesammelt?

Gruß, Horst.

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

---

hallo horst,

ich kann dir nicht ganz folgen bzw. habe dein problem nicht ganz verstanden, es wäre gut wenn du mir anhand eines beispiels dein problem erklären würdest.

ich habe folgendes verstanden: du hast ein element das mehrere outputs hat und er geht zyklisch, bei der abgabe vor. du möchtest dies aber nicht so haben?
meinst du das?

gruss

gökhan

------------------
"es ist unklug, nur auf die moral zu hören, und es ist unmoralisch, unklug zu sein"

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

---

Hallo Gökhan und sorry für die späte Reaktion.

Beispiel:

Man hat eine Maschineklasse A. In dieser Maschinenklasse gibt es 5 Maschinen, also A1, A2, ... A5. Diese Maschinen geben ihre Parts (Produkte) an die Maschinenklasse B, die ebenfalls 5 Elemente umfasst (B1 bis B5), weiter. Nun kann man die Verknüpfung dieser 10 Maschinen in QUEST entweder als Element- oder als Class-Connection ausführen. In der Element-Connection muss man jede Maschine mit jeder möglichen Folgemaschine verbinden. Das bedeutet A1 mit B1, A1 mit B2, A1 mit B3, ... bis A5 mit B5. Wenn man jedoch eine Class-Connection verwendet, muss man nur A mit B verbinden.
Damit man aber Einfluss auf das Routing hat, gibt es bei der Element-Connection die Part-Routing-Logic. Diese gilt aber so nichtunbedingt für eine Class-Connecttion. Dafür gibt es eigentlich die Part-Input-Logic. Jetzt hätte ich eigentlich erwartet, dass man in der Part-Input-Logic als Rückgabewert ein Element ausgibt und das Teil dann zu diesem Element geroutet wird. Aber das klappt so nicht. Daher meine Frage, ob jemand schon Erfahrungen mit der Part-Input-Logic gesammelt hat. Die Quest-Doku gibt ja, wie an vielen anderen Stellen, dazu leider nicht viel her.

Gruß, Horst.

[Diese Nachricht wurde von Horst2000 am 04. Nov. 2004 editiert.]

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

---

hallo horst,

na da bin ich auch überfragt, ich kann mir ehrlich nicht vorstellen das was du möchtest über diese art verbindung möglich ist.
ich steuere die abgabe eines objektes über die "inputs" und "outputs" eines elements. z.B. require part thru 3 oder require part thru output 3....

gruss

------------------
"es ist unklug, nur auf die moral zu hören, und es ist unmoralisch, unklug zu sein"

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

---

Hallo,
wenn man ein Modell hat, bei dem man die Anzahl der Maschinen variieren will, z.B. mal 5 Maschinen, mal 10 Maschinen, etc., dann braucht man sich bei einer Klassenverbindung nicht um die Verbindungen zu den Vorgänger- und Nachfolgerelementen, bzw. -Klassen zu machen. Man ändert einfach die Anzahl der Elemente in der Klasse und plaziert die zusätzlichen Elemente im Modell. Die Verbindungen sind auf Klassenebene angelegt. Die Part-Input-Logik routet standardmässig auf die Next-Free Maschine. Deneben gib es dann noch cyclic. Alles andere muss man per SCL kodieren. Und da fehlt mir dann der Zusammenhang zwischen Part-Input-Logic (eine Routine mit Rückgabewert vom Typ Element) und dem Part-Routing. Die SCL-Programmierung stellt an sich kein Problem dar.

Gruß, Horst.

[Diese Nachricht wurde von Horst2000 am 05. Nov. 2004 editiert.]

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

---

hallo,

ich werde mir das mal nächste woche anschauen, du hast recht,  normalerweise sollte es bei der class-verbindung auch funktionieren.
ich schreibe dir dann ob es funktioniert hat oder nicht!

gruss

------------------
"es ist unklug, nur auf die moral zu hören, und es ist unmoralisch, unklug zu sein"

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