tim-fischertechnik

Hallo liebe Community, nach mehreren Versuchen und bestimmt 10 Modifieren konnte ich den Mast verjüngen. Allerdings störte mich die hohe Polygon-Anzahl. Dank der Hilfe von Brummi konnte ich nun einen Polygon ärmeren Gittermast modellieren. Das Modell habe ich erneut aktualisiert. Dem Modell habe ich eine zweite, Polygon ärmere Version hinzugefügt. Ich hoffe, dass der Unterschied zur Version mit weniger Polygonen in Ordnung ist und nicht so sehr ins Gewicht fällt. Liebe Grüße Tim

Hallo zusammen, heute gibt es einen kleinen Vorgeschmack zu einer alten historischen Rundleuchte. Diese findet man im Vorbild häufiger an alten Betriebsstellen und da diese Art von Rundleuchten an einem Gittermast im Katalog noch nicht vorhanden ist, habe ich dieses Modell gebastelt. Das Modell kann als Entwurf unter der Content-ID: 98A99802-A27A-4B0B-BCF6-223812F5FDBE begutachtet werden. Modell als Signal [Signalbegriff: 0 - Licht aus / Signalbegriff: 1 - Licht an] angedeuteter Seilzug mit Umlenkrollen und Handkurbel Ich überlege mir noch, ob ich die Handkurbel mit samt Seilzug noch animiere. Die Leuchte stammt noch aus der Zeit, wo man Petroleumlampen verwendet hatte. Damit man diese besser warten konnte, hatte man die Lampe mit einem Seilzug versehen, um diese absenken zu können. Leider weiß ich nur nicht, an welcher Stelle genau die Lampe vom Träger getrennt ist. Ich vermute folgenden Aufbau: Falls jemand Hinweise hinsichtlich der genauen Funktionsweise von Gittermastleuchten mit Seilzügen hat, freue ich mich sehr. Soll ich die beiden Versionen in der untenstehenden PDF-Datei auch noch bauen? Vorschläge -zusätzliche Versionen für Rundleuchte_Gittermastleuchte.pdf Viele Grüße Tim

Hallo @Markus4.1, benenne mal bitte in all deinen Gleiskontakten am Bahnsteigende die Variable "linke Bahnsteigseite" in "Ausstieg in Fahrtrichtung links" um. Ich Dussel hatte vergessen, dich nochmal explizit darauf hinzuweisen, dass ich ab Version 2 des dritten Lösungsvorschlages diese Variable umbenannt hatte. Im Ereignis "Bahnsteigs - Gleiskontakt betreten --> relative Fahrtrichtung bestimmen/ Fahrtrichtungsumkehr" solltest du alles bis zum Kommentar "Fahrtrichtungsumkehr herauslöschen. Dieser Teil der manuellen relativen Fahrtrichtungsbestimmung wird nicht mehr benötigt, da im anderen Ereignis "Bahnsteigs - Gleiskontakt wird betreten bei der Einfahrt --> Türen öffnen" dies schon von dem Lua-Skript-Baustein übernommen wird, der die relative Fahrtrichtung vollautomatisch bestimmt. Dann müsste alles richtig funktionieren. Viele Grüße Tim

Ja, mein Lua-Skript aus Version 4b ist sogar in der Lage, die Position/Richtung sowohl von Loks als auch von Wagen in einem Zugverbund zu bestimmen und zwar vollautomatisch. Der Erstentwurf funktionierte zuerst nur bei Zügen mit maximal zwei Loks richtig. Diese durften auch nur an den Zugenden platziert sein. In meinem modifizierten Skript werden beliebig viele Züge [Auslöser] berücksichtig, die sich auch an beliebig vielen Stellen, also auch mittig im Zug, befinden können. Die Bilder dienten zur Veranschaulichung der manuellen Konfiguration für die Version 4a und da die anderen beiden Fälle dem Standardverhalten entsprachen, habe ich sie nicht nochmal aufgeführt. Mir war es immer zu mühselig, die Ausrichtung von jedem einzelnen Wagon zu prüfen und dann händisch in Form von Variablen einzutragen. Man kann also Wagen einfach auf die Platte ziehen und muss sich keine Gedanken über eine richtige Ausrichtung machen. Lediglich die beiden Animationsnamen der Türen für links/rechts müssen in einer Tabelle eingetragen werden. Bei meinem Skript nehme ich mir die Kupplungsbelegungen zur Hilfe, um die relative Ausrichtung im ersten Schritt zu bestimmen. Du hattest ja auch schon ein paar erste Tests mit Kupplungsbelegungen gemacht. Ist schon eine tolle Sache! Im zweiten Schritt wird die Ausrichtung/Position auf die Fahrtrichtung gemünzt. Wenn die Ausrichtung eines Wagons identisch zur Ausrichtung der auslösenden Lok ist, wird die Fahrtrichtung des Auslösers übernommen, andernfalls umgekehrt. Beim Stöbern einiger Beiträge bin ich auf diesen Beitrag gestoßen. Interessant ... Ich muss schmunzeln, da die Türsteuerung über fast gleiche Grundkonzepte verfügt. Beispielsweise bestimmst du die Türseite auch über die Fahrtrichtung oder du hast ja auch eine Fahrtrichtungsumkehr, indem du die Zug Geschwindigkeit mit der Zug Ausfahrtrichtung multiplizierst. Natürlich hat da jeder seine eigene Struktur. Ob man jetzt die Ausstiegseite "BahnsteigSeite==links/rechts" [Hawkeye] oder "Ausstieg in Fahrtrichtung rechts == "true/false" [Tim] nennt, ist völlig egal. Vielleicht kannst du ja etwas von der automatischen Fahrtrichtungsbestimmung adaptieren und ich schaue mal, ob ich noch ein Gimmick von dir verwenden kann. Beim Erstellen meines Tutorials wollte ich es vermeiden, Lua einzusetzen und stattdessen den Schwerpunkt auf die grafische EV legen. Und ich muss sagen, ich bin kläglich gescheitert. An zwei Stellen in der EV bin ich um Lua nicht herumgekommen. Es ist also eine ganz schöne Herausforderung, einen Kompromiss zwischen komplexen realistischen Betriebssituationen, die sich nur gut über Lua abbilden lassen und Verständlichkeit auf der anderen Seite mittels überschaubarer grafischer EV, zu finden. Viele Grüße Tim

Hallo @neuLich, du hattest in einer deiner Beispielanlagen gezeigt, wie man eine Spitzenbeleuchtung entsprechend der Fahrtrichtung für genau eine Zuggattung umsetzen kann. Ich habe mich dem Wunsch angenommen und eine generische Spitzenbeleuchtung für alle Zuggattungen entworfen. Funktionsbeschreibung: Die meisten Aktionen habe ich mit Kommentaren versehen. Dennoch möchte ich hier kurz darauf eingehen, wie das allgemeine Prinzip hinter der Spitzenbeleuchtung funktioniert. Wann müssen überhaupt die Spitzen- und Schlusslichter eines Zuges wechseln? Eigentlich nur dort, wo der Zug seine Fahrtrichtung umgekehrt, also in Kopfbahnhöfen. Deswegen prüfe ich zuerst, ob der Zug die Fahrtrichtung wechselt (Variable Fahrtrichtungsumkehr == True). Grafik 3/14: EV für Spitzenlichtbeleuchtung Dann werden alle vier Lichter (Spitzenlichter/ Schlusslichter, je vorne/ hinten) für jeden Wagon innerhalb des Zugverbunds ausgeschaltet. Zuvor wird geprüft, ob der Texteintrag und die Tabelle überhaupt existiert. Nicht jede Lok/ Wagon muss zwangsläufig zwei Spitzenlichter haben. Da kann dann mal das hintere Spitzenlicht fehlen. Nach einer kurzen Verzögerung von 0,5 Sekunden werden die Lichten unter bestimmten Kriterien eingeschaltet. Ein Licht wird nur eingeschaltet, wenn die Kupplung auf derselbe Seite wie das Licht frei ist, d.h. nicht mit anderen Wagen gekuppelt. Die Fahrtrichtung entscheidet über die Farbe (weißes Spitzenlicht oder rotes Schlusslicht). Wagen, die mitten im Zugverbund eingereiht sind: Beide Kupplungen sind belegt, weswegen überhaupt kein Licht eingeschaltet wird. Wagen am Zugende: Hierbei ist eine Kupplung frei und ein Licht wird eingeschaltet. Loks ohne Wagen: Hierbei sind beide Kupplungen frei. Folglich werden zwei Lichter eingeschaltet. Ein konkretes Beispiel: Grafik 3/15: Beispiel hintere rote Schlusslicht wird eingeschaltet Die Diesellok DB 212 fährt mit drei Umbauwagen mit negativer Geschwindigkeit (hintere Kupplung zeigt Richtung Prellbock) in das Stumpfgleis ein. Hierbei ist die hintere Kupplung frei und die hiergezeigte Bedingung ist erfüllt. Das weiße Spitzenlicht wird zuvor in dem oben beschriebenen Teil ausgeschaltet und nach einer kurzen Verzögerung leuchtet das rote Schlusslichte auf. Konfigurierung: Grafik 3/16: Konfigurierung der Namen für Spitzen- und Schlusslicht Anbei die 5. Version: 3. Lösungsvorschlag - Version 5.mbp fertig. Das Tutorial ist zu Ende. Viele Grüße Tim

Danke Götz, das hilft mir weiter. Nun weiß ich beruhigt, woran es lag. Die Variable "positive Fahrtrichtungsumkehr" wird ja vom Lua-Skript bereitgestellt und dann in der grafischen EV ausgelesen. Meine Tests mit der EV-Protokollierung ergaben, dass die Fahrtrichtung schon ausgelesen wurde, ehe sie durch das Lua-Skript verändert wurde. Das ergab dann natürlich immer eine fehlerhafte Fahrtrichtung. Jetzt habe ich natürlich den Lua-Skript-Baustein ganz nach oben über die eh schon vorhandene Verzögerung gezogen. Das fehlerhafte Verhalten lässt sich also in der beigeführten Anlage nicht mehr nachvollziehen, weil ich es zuvor schon behoben hatte. Viele Grüße Tim

Ja, sowohl Version 4a als auch Version 4b behandeln die Türsteuerung. Es geht hierbei konkret darum, dass die beiden Loks eines Zuges auch in die entgegengesetzte Richtung mit ihrer "Schnauze" zeigen können und es dann nicht zu Fehlern kommen sollte. Die Version 4a setzt diese Fehlerbehebung komplett grafisch um, während die Version 4b diese mittels Lua-Skript umsetzt und darüber hinaus hoffentlich viel anwendungsfreundlicher ist. Hierbei muss keine händische Konfiguration vorgenommen werden. Alles läuft automatisch ab. relative Fahrtrichtung bestimmen - Lua-Skript-Baustein: Grafik 3/13: Lua-Skript-Baustein / Reihenfolge der Aktionen - sequenzielle Abfolge Der Lua-Skript Baustein, der hier im obigen Bild zu sehen ist, übernimmt dieselbe Aufgabe wie die EV-Erweiterung im vorherigen Beitrag. Mit dem Baustein wird nämlich die relative Fahrtrichtung eines kompletten Zuges automatisch bestimmt. Der Vorteil dabei ist, dass: die Objektvariablen "andererTriebkopf" bzw. "andere Triebkopf" nicht mehr benötigt werden. man die Konfigurierung der Ausrichtung mittels des Schlagworts "gedreht" nicht mehr händisch vornehmen muss. Dies geschieht jetzt automatisch in Form der Variablen "Ausrichtung". man sich Frust und Ärger vermeidet, wenn die händische Konfigurierung nicht so richtig funktionieren will. Für alle Interessierten gibt es einen Vorher-nachher-Vergleich meines Lua-Skripts. Erstentwurf: Allein die Bestimmung der relativen Fahrtrichtung beinhaltet in etwa 105-Lua-Codezeilen. Der größte Teil an Kommentaren ist davon ausgenommen. verbesserte Version: function orientationOfNextWagon(_wagon, _nextWagon) -- Funktion prüft, ob der nächste Wagon im Zugverbund im Bezug auf den aktuellen Wagon in die gleiche oder entgegengesetzte Richtung zeigt if _nextWagon.couplers[0].connectedCoupler ~= nil then -- vK ist gekuppelt if _nextWagon.couplers[0].connectedCoupler.vehicle == _wagon then return 1 end end if _nextWagon.couplers[1].connectedCoupler ~= nil then -- hK ist gekuppelt if _nextWagon.couplers[1].connectedCoupler.vehicle == _wagon then return 0 end end end local t = layout:getVehicleGroup(vehicle) -- Zugverbund vK = t[1].couplers[0].connectedCoupler -- vordere Kupplung hK = t[1].couplers[1].connectedCoupler -- hintere Kupplung if vK ~= nil then t[1].variables["Ausrichtung"] = 0 --> vordere Kupplung [1. Wagon im Zugverbund] belegt else t[1].variables["Ausrichtung"] = 1 --> hintere Kupplung [1. Wagon im Zugverbund] belegt end for i, wagon in ipairs(t) do if i >= #t then print("ABBRUCH DER SCHLEIFE: Ab "..#t..". Position ("..t[#t].name..") sind keine zu bestimmenden Wagen vorhanden") break end nextWagon = t[i+1] nextWagon.variables["Ausrichtung"] = orientationOfNextWagon(wagon, nextWagon) end if vehicle.currentSpeed > 0 then -- Geschwindigkeitsbestimmung des Auslösers [Triebfahrzeug] posGeschwindigkeit = true else posGeschwindigkeit = false end for k, v in ipairs(t) do -- Fahrtrichtung für alle Wagen im Zugvebund bestimmen (Fahrtrichtung bezieht sich auf dei Fahrtrichtung des Auslösers!) if v.variables["Ausrichtung"] == vehicle.variables["Ausrichtung"] then v.variables["positive Fahrtrichtung"] = posGeschwindigkeit -- übernehme Fahrtrichtung bei gleicher Ausrichtung else v.variables["positive Fahrtrichtung"] = not posGeschwindigkeit -- drehe Fahrtrichtung um bei entgegengesetzter Ausrichtung end end Hier seht ihr meinen modifizierten Code, der aus insgesamt 46 Zeilen besteht. Ich habe nur eine Bitte. Versucht erst gar nicht, den Code zu verstehen, wenn ihr nicht Lua lernen wollt! Wichtig ist eigentlich nur, was so ein Baustein ausspuckt! Der Lua-Skript-Baustein funktioniert wie eine Schnittstelle und überträgt in diesem Falle eine Variable "positive Fahrtrichtung". Auf diese Variable kann nämlich später die grafische EV zurückgreifen. Ich freue mich wie immer über Anregungen unserer Lua-Experten, wenn man den Code noch schlanker machen könnte. Dann habe ich eine Frage an euch. Welche der Versionen sagt euch mehr zu? Die mit oder ohne dem Lua-Skript-Baustein? Markus hatte ja geschrieben, dass derzeit seine Türsteuerung nicht funktioniert, was vermutlich an der äußert komplizierten Konfigurierung (Version 4a ohne Lua-Skript-Baustein) liegt. ... und eine Frage an @Goetz. In der obigen Grafik habe ich eine Randbemerkung geschrieben. An der markierten Stelle wollte ich eigentlich zuerst den Skript-Baustein einfügen, doch dann traten undefinierte Zustände auf. Der ICE zum Beispiel öffnete bei jeder zweiten Runde die Türen auf der falschen Seite. Nun habe ich das natürlich verbessert, sodass sich die Türen auf der richtigen Seite öffnen. Abhilfe schafft dann immer eine nachgestellte Verzögerung. Gibt es eine Faustregel, wann man eine Verzögerung nach einem Lua Skript benötigt und wann nicht? Nach meinem Verständnis werden ja alle Ereignisse von oben nach unten (sequenziell) abgearbeitet. Anbei die Version 4b: 3. Lösungsvorschlag - Version 4b.mbp Viele Grüße Tim

Hallo zusammen, im Folgenden möchte ich euch Lösungsvorschläge für dieses Problem aufzeigen. Dazu werde ich im ersten Beitrag eine Lösung ohne Lua und im zweiten eine Lösung mit Lua präsentieren. relative Fahrtrichtung bestimmen - Lösung ohne Lua: Grafik 3/10: Erweiterung für relative Fahrtrichtungsbestimmung Beschreibung der EV: Zuerst wird in der mehrfachen Bedingung geprüft, ob: im Auslöser eine Objektvariable mit dem Namen "anderer Triebkopf" existiert. der andere Triebkopf als Wert in dieser Objektvariablen eingetragen ist. Das Objekt soll ja nicht leer sein. im Gleiskontakt die Variable Fahrtrichtungsumkehr wirklich true ist. Wenn alle dieser 3-Bedingungen erfüllt sind (UND-Logik), wird geschaut, ob der gegenüberliegende Triebkopf gleich oder umgekehrt zum Auslöser positioniert ist. Schlagwort "gedreht" vorhanden: → Der andere Triebkopf (nicht der Auslöser) zeigt in die entgegengesetzte Richtung wie das auslösende Triebfahrzeug. Bei einer Fahrtrichtungsumkehr in Kopfbahnhöfen etc. muss die die Ausrichtung (in Form des Schlagworts: "gedreht) aller Wagen umgekehrt werden, da jetzt nun die andere Lok wieder aus dem Bahnhof fährt, und zwar mit entgegengesetzter Geschwindigkeit wie die auslösende Lok zuvor. Grafik 3/11: entgegengesetzte Ausrichtung zweier Loks Schlagwort "gedreht" fehlend: → Der andere Triebkopf (nicht der Auslöser) zeigt in die gleiche Richtung wie das auslösende Triebfahrzeug. Alles bleibt wie beim Alten. Die auslösende Lok fährt in die gleiche Fahrtrichtung weiter weswegen die Ausrichtung aller Wagen beibehalten wird und nichts Weiteres in der EV unternommen werden muss. Wie die Ausrichtung im Zugverbund umgekehrt wird! Für jeden Wagon (auch Lok) wird die Ausrichtung umgekehrt: Wenn zuvor das Schlagwort "gedreht" in einem Wagon vorhanden war, wird es gelöscht. Wenn das Schlagwort "gedreht" zuvor gefehlt hat, wird es nun vergeben. Konfiguration des Schlagworts "gedreht": Wenn man einen neuen Zug anlegt, geht man am besten anhand folgender Schritte vor. Grafik 3/12: Konfigurierung Schlagwort gedreht Suche im Zugverbund eine Lok aus, die später losfahren soll. Wenn die vordere Kupplung dieser Lok in Fahrtrichtung zeigt, dann lösche das Schlagwort "gedreht", falls schon vergeben. Wenn die hintere Kupplung dieser Lok in Fahrtrichtung zeigt, dann vergebe das Schlagwort "gedreht". Prüfe bei allen übrigen Wagen, ob diese in die gleiche oder in die entgegengesetzte Richtung wie die ausgewählte Lok zeigen. gleiche Ausrichtung: Schlagwort löschen entgegengesetzte Richtung: Schlagwort vergeben Diesmal stelle ich neben der großen Beispielanlage auch eine kleine Mini-Demo ein, die sich auf das Wesentliche beschränkt. Die EV-Ergänzung aus der Mini-Demo wurde auf die größere Beispielanlage eins zu eins übertragen : MINI-Demo für 3. Lösungsvorschlag - Version 4a.mbp 3. Lösungsvorschlag - Version 4a.mbp Viele Grüße Tim Fortsetzung folgt in Kürze

Hallo @Roter Brummer, Ist das Einfahren des letzten Wagons in das blaue Depot in der hier gezeigten Anlage (veröffentlicht als Entwurf: 16B3A6D4-B039-42C5-A9A1-3889D1DEBDF3) besser? Ich habe folgende Änderungen vorgenommen: Die Kupplungen werden im Ereignis "Einfahrt Depot blau" nicht mehr aktiviert, sondern deaktiviert. Dafür werden die Kupplungen aktiviert, wenn der GK "Gleiskontakt Zugende" betreten wird. Wenn der Zug zu lange ist (besteht zufällig aus vielen längeren Wagons), werden Wagons über das "Zugende" hinaus nicht angekuppelt. Zusätzlich wird hier die automatische Verzögerung ausschließlich bei Wagen deaktiviert, sodass diese nicht mehr sanft, sondern zügig ankuppeln. Ich bin auch ratlos, warum der letzte Wagen so "ruppig" abgebremst wird und dann ziemlich allein gelassen wird. Aber so funktioniert es wenigstens. Liebe Grüße Tim

Hallo @rothie65, soweit wie ich erkennen kann, benutzt du die Version V3. Dabei kann es öfters zu Internetproblemen kommen, weil eine bestimmte Datei veraltet ist, wie in einem Beitrag von Neo beschrieben. Dort wird geraten, eine Datei "ServiceAPI.zip"als Zip zu downloaden und die alte Datei durch die neue zu ersetzen. Vielleicht ist das ein Versuch wert. Viele Grüße Tim

Hallo @Trainfan, eigentlich wollte ich dir eine persönliche Nachricht (PN) schreiben. Aus irgendeinem Grund kannst du keine PN empfangen. Daher hier meine gekürzte/zensierte Fassung. Wenn das mit der PN nicht klappt, kannst du natürlich weiterhin über das Forum schreiben oder wende dich bei Problemen am besten an Neo. Viele Grüße Tim

Hallo zusammen, in diesem Beitrag zeige ich euch einen Lösungsweg für den oben genannten Fehler auf. Ich habe die EV an einigen Stellen aufgeräumt. Dabei sind folgende Änderungen vorgenommen worden: Die Bezeichnung einiger Ereignisse wurde zum besseren Verständnis geringfügig erweitert. Die Variable "Austieg in Fahrtrichtung links" wurde in "Ausstieg in Fahrtrichtung" korrigiert. Die Ermittlung der Ausstiegseite in Form der Variable "Ausstieg in Fahrtrichtung links" erfolgt nicht mehr über zwei Zuweisungen, sondern einer. Zuvor wurde die Aussiegseite vom Gleiskontakt auf das auslösende Fahrzeug übertragen und im Anschluss wurde im Ereignis: "Bahnsteigs-Gleiskontakt wird betreten bei der Einfahrt --> Türen öffnen" als Auslöser das Fahrzeug verwendet, um die richtige Türseite zu ermitteln. Nun wird in diesem Ereignis direkt auf den Gleiskontakt als Auslöser zugegriffen. Die Zuweisung des Zugs und des Bahnsteig-Gleiskontakts zum Signal wurde in das Ereignis: "Bahnsteigs-Gleiskontakt betreten --> relative Fahrtrichtung bestimmen/ Fahrtrichtungsumkehr" verschoben. Die Überarbeitung der Fahrtrichtungsumkehr, die ich im Folgenden vorstellen werden. Um die Änderungen zwischen dieser und der vorherigen Version nachvollzuziehen, empfehle ich die beiden EV-Einträge miteinander zu vergleichen. Wie mit der neuen Fahrtrichtungsumkehr auch Züge mit nur einer Lok richtig umkehren: Grafik 3/8: EV für die Fahrtrichtungsumkehr Überall dort, wo eine Aktion nummeriert wurde, befindet sich ein Lua-Skript. Leider sind wir an dieser Stelle an einem Punkt angekommen, wo sich der Einsatz von Lua nur schwer vermeiden lässt, weil sich nur durch Lua der EV-Umfang begrenzen lässt. Ich werde dann immer den passenden Code hier einstellen. Für die Ermittlung des gegenüberliegenden Triebkopfs am anderen Zugende wird nicht mehr die Variable "andere Triebkopf" benötigt, sondern die Bestimmung erfolgt automatisch mithilfe des ersten Lua-Skripts. -- Lua Skript Nr. 1 local t = layout:getVehicleGroup(vehicle,1) -- 1 bedeutet: filtere alle Fahrzeuge in einem Zug mit einem Antrieb -- ermittle gegenüberliegenden Triebkopf im Zugverbund if t[1] == vehicle then andererTriebkopf = t[#t] -- letzte Element/ letzter Wagon else andererTriebkopf = t[1] -- erste Element/ erster Wagon end Dabei werden zunächst alle Fahrzeuge mit einem Antrieb aus dem Zugverbund einer Tabelle t zugeordnet. Wenn das erste Element/ erster Wagon der Tabelle t[1] gleichzeitig das auslösende Fahrzeug (vehicle) ist, wird das letzte Element/ letzter Wagon t[#t] aus der Tabelle der Variablen andererTriebkopf zugeordnet, andernfalls das erste Element. Die Raute # in Lua ermittelt immer die Anzahl an Elementen einer Tabelle. Somit kann mit t[#t] immer auf das letzte Elemente einer Tabelle zugegriffen werden, egal wie viele Elemente die Tabelle besitzt. Mithilfe der Bedingung Fahrzeug steht auf einem Gleiskontakt wird ermittelt, ob der Auslöser den Zug zieht oder schiebt. Ein Auslöser zieht immer einen Zug, wenn das Fahrzeug [Auslöser] gleichzeitig auf dem Gleiskontakt [Auslöser] steht und ein Auslöser schiebt einen Zug, wenn er selbst nicht auf dem Gleiskontakt steht. Wenn also der Auslöser den Zug schiebt und die Variable "Fahrtrichtungsumkehr" wahr ist, dann wird der Antrieb des Auslösers deaktiviert und dafür der Antrieb des gegenüberliegenden Antriebs aktiviert. (Der Auslöser zeigt in diesem Fall ja in Richtung Prellbock und soll bei der Abfahrt nicht angetrieben werden). -- Lua Skript Nr. 2 print("Auslöser ("..vehicle.name..") zieht Zug") Hier wird das auslösende Fahrzeug, welches den Zug zieht, in der EV-Protokollierung ausgegeben. -- Lua Skript Nr. 3 local v = andererTriebkopf -- gegenüberliegende Triebkopf if v:hasEngine() then v.engine.active = true -- aktiviere Antrieb vom gegenüberliegenden Triebkopf end Das Skript wurde fast vollständig aus der Aktion "Antrieb ausschalten/einschalten" durch Umwandeln extrahiert. Die einzige Veränderung besteht in der ersten Zeile, bei der die Variable andererTriebkopf der Variable v zugeordnet wurde. Die Variable andererTriebkopf kennen wir ja schon vom ersten Skript. Wenn der Auslöser den Zug schiebt, wird der Antrieb vom gegenüberliegenden Triebkopf zuerst deaktiviert und im Anschluss daran der Auslöser zur Sicherheit nochmal aktiviert. Die Skripte 4 und 5 ähneln den beiden vorherigen sehr. -- Lua Skript Nr. 4 print("Auslöser ("..vehicle.name..") schiebt Zug") -- lediglich andere Bezeichnung 'schiebt' -- Lua Skript Nr. 5 local v = andererTriebkopf if v:hasEngine() then v.engine.active = false -- deaktiviere Antrieb vom gegenüberliegenden Triebkopf end False deaktiviert in diesem Fall den Antrieb. Grafik 3/9: EV-Fahrtrichtungsumkehr für das Anfahren Im Ereignis "Wenn das KS Hauptsignal schaltet --> Türen schließen" werden ausschließlich nur alle Fahrzeuge mit aktiven Antrieb in einer Wiederholung angesprochen! Das habe ich so bewusst gewählt, da ich ja zuvor die Antriebe deaktiviere und aktiviere und somit sicherstelle, dass immer nur ein Antrieb aktiviert ist. Wenn der Zug beispielsweiße in einem Kopfbahnhof die Fahrtrichtung umkehren soll (Fahrtrichtungsumkehr = True), dann wird allen Fahrzeugen mit aktivem Antrieb eine negative Geschwindigkeit relativ zur Fahrtrichtung vergeben, andernfalls eine positive Geschwindigkeit. Anbei die dritte Version: 3. Lösungsvorschlag - Version 3.mbp Viel Spaß damit. Viele Grüße Tim

Ja, dem schließe ich mich auch an und freue mich schon auf das Modell. (Wer schaut schon schräg von dieser Perspektive? Da kann man doch gar nicht richtig die Skala erkennen ). Viele Grüße Tim

Edit: einziger Kritikpunkt/Verbesserungsvorschlag Von der Draufsicht aus gesehen hat eine Polygonfläche (Viereckfläche bestehend aus zwei/mehreren Dreiecken) einen Knick, sodass ein Dreieck sichtbar wird. (ziemlich vernachlässigbar/fällt kaum auf) Liebe Grüße Tim

Geschwindigkeitsprüfung (bei allen Variationen schlägt der Regler bis zum eingestellten Geschwindigkeitsbereich [auch negativer Bereich] richtig bis zum Anschlag aus und verharrt bei Überschreitung) bestanden! Die Kanten sind viel weicher und sehen dadurch realistischer aus. Die Buchsen haben mehr Tiefenschärfe Das neue Modell ist polygonarmer. Benutzerfreundlicher durch die variablen Geschwindigkeitsbereiche (Variationen). Meiner Meinung nach ist das neue Modell auf jeden Fall eine Bereicherung für den Katalog und übertrifft das alte Modell / kann das alte Modell ersetzen. Viele Grüße Tim

Hallo @Markus Meier, sind wir Modellbauer irgendjemand Rechenschaft schuldig, wann wir Auskunft über den Fortschritt von Modellen geben? Wir Modellbauer geben unser Bestes aber wie schon an vielen Stellen im Forum beschrieben, haben wir (nicht nur die Modellbauer) neben der Beschäftigung hier im MBS auch noch Familie, einen Job oder gehen zur Schule. Und das Projekt selbst kann sich ziemlich in die Länge ziehen. Das Modellieren an sich ist oft nicht am zeitintensivsten, jedoch das Aufsuchen von geeigneten Zeichnungen und Bildmaterial. In Projekten stößt man auf Unzulänglichkeiten, die man am Anfang nicht so in der Form bedacht hatte. (z.B.: komplizierte geometrische Stirnfronten an Triebköpfen, Änderungswünsche von Usern etc.). Bei mir dauert das Texturieren von Modellen fast genauso lang wie das Modellieren von Modellen. Ich bitte dich daher um Geduld! Reinhard wird hier schon ein Update geben, aber dann, wenn es ihm passt. Ich pflichte dir bei, dass klassisches Rollmaterial zum Beispiel Dieseltriebzüge wie die BR 614 nice to have sind. Aber wenn du unbedingt diese Modelle haben möchtest, könntest du selbst Eigeninitiative ergreifen oder den Modellbauern behilflich sein, indem du Geduld mitbringst und geeignete Zeichnungen zusendest. Ich würde gern auch einen Dieseltriebzug als Modell bauen, aber ich habe aufgrund der Schule schlicht nicht die Zeit für solche komplexen Modelle! Daher nenne ich jetzt auch nicht den Namen meines Favoriten. So baue ich eben "einfachere" Modelle der Bahnübergangstechnik und Beschilderungen. Siehe bitte auch hier: Modellwünsch Thomas Lokomotiven für V6 - Modellwünsche - 3D-Modellbahn Studio leicht genervte Grüße Tim

Hallo @Markus4.1, du hattest mich gefragt, ob es möglich ist, eine ganze Platte in seiner Höhe zu variieren, weil du noch einen weiteren Bahnhof "CityPark" anschließen möchtest, der aber im Bezug zum HBF etwas höher liegt. Ich nehme diesen Post zum Anlass, eine kleine spezifische Anleitung zum Verschieben von Platten zu erstellen (ich hoffe das ist so in Ordnung). Erst einmal muss ich dich loben, dass du die Objekte verschiedenen Ebenen zugeordnet hast. Das ist genau richtig so und du verschaffst dir eine enorme Arbeitserleichterung später beim Verschieben der Platten, da die Objekte vereinfacht gesagt durch Ausblenden von einzelnen Ebenen geschickt gruppiert werden können. Wie man eine bestehende Platte mit Inhalt in ihrer Höhe verschiebt (Mist ich habe vergessen, die Ebene am Anfang höher zu setzen): Im Folgenden werde ich anhand dieser Anlage (C8AF82DE-77C6-4374-A606-21AFE2B84927) von Markus die Platte, auf der sich die Drehscheibe befindet, höher setzten. Die Platte, auf der sich der HBF befindet bleibt unverändert. Vorrausetzung für das Verschieben einer Platte ist, dass du sämtliche Objekte einer, besser mehreren aussagekräftigen Ebenen zugeordnet hast! Wenn du nur eine Ebene für Gleise angelegt hast aber zwei Platten verwendest, musst du zwei Gleisebenen (z.B.: Ebene - Gleise HBF und Ebene - Gleise Betriebswerk) anlegen, weil du ja nur eine der Ebenen verschiebst. Die gleiche Prozedur gilt für alle andere Arten an Ebenen genauso. Blende alle Ebenen aus (durchgestrichenes Augensymbol), die du nicht auf deiner Platte haben/ gruppieren willst. Wenn eine Ebene nicht sichtbar ist, wird sie nicht ausgewählt! Achte beim Ausblenden von Ebenen auf besondere Objekte wie Bodenplattem, die standardmäßig fixiert/gesperrt sind und nur durch einen Doppelklick sonst anwählbar wären. Klicke auf die Pinnadel, um diese zu entsperren. Halte die linke Maustaste gedrückt und ziehe das Auswahlfenster über den gesamten Bereich der Platte. Dazu schaltet man am besten in die 2D-Ansicht. Gruppiere deine ausgewählten Objekte mit Strg + G und vergebe der Gruppe einen aussagekräftigen Namen. Verschiebe deine Gruppe in z-Richtung auf die gewünschte Höhe. Wenn du genau arbeiten möchtest, kannst du die Höhe in den Eigenschaften aufaddieren/berechnen lassen. Löse die Gruppierung mit Strg + U auf, um die einzelnen Objekte wieder bearbeiten zu können. Fertig! Wie man Ebenen gleich am Anfang höher legt : Lege eine neue Ebene an und weise ihr eine bestimmte Höhe zu. (siehe Wiki: Arbeiten mit Ebenen/Layern - Planung - 3D-Modellbahn Studio) Wähle eine Bodenplatte aus, um Gleise etc. auf die Platte zu ziehen und stelle sicher, dass du die richtige Ebene aktiviert hast, bei der die Höhenbeschränkung aktiviert ist. Aktiviere die automatische Höhenanpassung, damit sich Objekte entlang der Bodenplatte (verwende dazu die Option - Gelände) oder über anderen Objekten (verwende dazu die Option - Stapel) ausrichten. Erst wenn du mit der Höhe zufrieden bist, legst du weitere Ebenen mit derselben Höhenbeschränkung fest. (ggf. ist die Höhenbeschränkung unterschiedlich) Fertig! Liebe Grüße Tim

Wichtig ist, dass man in den Exporteinstellungen unter Inlcude das Kästchen "+ Y Up" setzt. Wenn man dies vergisst, werden die Achsen beim Export vertauscht. Die z-Achse in Blender entspricht dann nicht mehr der z-Achse im Studio. Hier noch weitere Einstellungen und eine Erklärung wofür das gut ist: speichert die letzten Exporteinstellungen ab, damit man diese nicht immer neu festlegen muss damit selektiert man nur Objekte mit der linken Maustaste oder mit der Tastenkombination "A" um alle Objekte auszuwählen. Das kann äußert praktisch sein, wenn man noch Hilfsmittel wie Zeichnungen als Objekte im Projekt hat und diese nicht mitexportieren will. die besagte Korrektur der Achsen In Blender gibt es sogenannte Modifier mit denen du Objekte manipulieren kannst. Beispielsweiße gibt es einen Mirror-Modifier zum Spiegeln. Damit diese beim Export und nicht nur in Blender angewendet werden, muss man das Kästchen (Punkt 4) aktivieren, wenn man von diesen Feature Gebrauch nimmt. Edit: Eigentlich sollte es nur ein Post geben und ich bin auf die Taste zum Abschicken des Posts aus Versehen gekommen. Jetzt weiß ich, dass es so eine Taste gibt. Liebe Grüße, Tim

Hallo @Sassa, Den X-Datei-Exporter benötigst du gar nicht mehr, weil es ein viel geeigneteres Format zum Exportieren von Modellen gibt, nämlich das glb/glTF-Format. Das ist bereits schon ab Blender 2.8 vorinstalliert. Deswegen brauchst du bei deiner Version kein extra Addon installieren (siehe auch Wiki: Vorbereitungen - Modellbau - 3D-Modellbahn Studio). Wenn du ein fertiges Modell exportierst, gehst du zu File > Export > glTF 2.0 (.glb/glTF).

Ja gerne. Auf die Schnelle habe ich eine kleine Kurzanleitung als PDF-Dokument erstellt. Wenn ich mich nicht täusche, verwendest du SketchUp und nicht Blender? In SketchUp weiß ich leider nicht, ob schon standardmäßig ein Tool für AO installiert ist und soweit ich weiß, gibt es keine kostenlose Addons dafür, was nicht so schön ist, da der Modellbau hier eigentlich kostenlos sein sollte. (Das ergab eine ganz kurze Recherche dazu). Kurzanleitung_Wie man eine Ambient Occlusion umsetzt_tim-fischertechnik.pdf Liebe Grüße Tim

Modell - Ne 7 Schneepflugtafel Hallo zusammen, auch wenn wir längst noch keinen Winter haben, habe ich ein Modell gebaut, das gut zu dieser Zeit passt. Bei der Schneepflugtafel handelt es sich um ein Nebenbahnsignal (Ne-Signal), das angibt, ob ein Schneepflug angehoben oder gesenkt werden muss, da es auf dem Bahndamm Hindernisse wie Bahnübergänge, Brücken, etc. gibt. Bedeutung der Signalbegriffe: Ne 7 a (eine nach oben zeigende Pfeilspitze "^"): Schneepflug heben Ne 7 b (eine nach unten zeigende Pfeilspitze "V"): Schneepflug senken Dem Modell habe ich einen Ambient Occlusion-Anteil (ein Art Schattenwurf, der die Ecken und Kanten farblich durch Verdunklung hervorhebt) verpasst. Ich hoffe, dass euch dieser Effekt gefällt und nicht zu extrem ist, da ich das ja auch zum ersten Mal mache. Das Modell beinhaltet 6 Versionen. Zwei davon sind Aufsätze, die mit Kontaktpunkten ausgestattet sind, um sie auf der Rückseite zu befestigen. Dann sind am Mast zwei Tafeln statt einer Tafel angebracht. Nach welchen Regeln diese Aufstellung erfolgt, kann hier nochmal gesondert nachgelesen werden: TF-Ausbildung.de - Ne-Signale / Ne 7. Die Kontaktpunkte sind so ausgelegt, dass immer nur 2 Modelle aufeinanderpassen, bei denen die Pfeilspitzen in die entgegengesetzte Richtung zeigen und die unterschiedlichen Typs, einmal Aufsatz, einmal normaler Mast sind. Somit beinhalten alle Variationen bis auf die Variation "Weiße Schneepflugtafel heben" und "Gelbe Schneepflugtafel heben" einen Kontaktpunkt. Das Modell steht als Entwurf unter 52E5A08A-AAA7-4106-B87D-D5A8518566A0 zum Testen bereit. Die Beschreibung ergänze ich demnächst. Gerne freue ich mich über Anregungen und Kritik zum Beispiel, wie benutzerfreundlich und fehlerfrei das Aufstecken der Aufsätze ist. Viele Grüße Tim

Im ersten Schritt wird die relative Fahrtrichtung ermittelt. Was ist aber damit gemeint? Die relative Fahrtrichtung bezieht sich immer relativ zur Fahrtrichtung des auslösenden Fahrzeugs, daher die Bezeichnung relativ. Wenn der Wagen in dieselbe Richtung wie der Auslöser zeigt (die vordere Kupplung des Wagens zeigt in dieselbe Richtung wie die vordere Kupplung des Auslösers/ die hintere Kupplung des Wagens zeigt in dieselbe Richtung wie die hintere Kupplung des Auslösers) dann wir die absolute Fahrtrichtung des Auslösers übernommen. Zeigen die Kupplungen von Wagen und Auslöser in entgegengesetzte Richtung wird die Fahrtrichtung umgekehrt. Grafik 3/4: Wie wird die relative Fahrtrichtung bestimmt Die relative Fahrtrichtung wird in einem neuen Ereignis „GK Bahnsteig betreten --> relative Fahrtrichtung bestimmen“ ermittelt. Das Schlagwort „Merker neg. Geschw.“ verkörpert die absolute Geschwindigkeit des Auslösers. Schlagwort vorhanden → negative absolute Geschwindigkeit Schlagwort fehlend → positive absolute Geschwindigkeit Mit dem Schlagwort „gedreht“ beschreibt man wie der Wagen im Bezug zum Auslöser ausgerichtet ist. Schlagwort vorhanden → Wagen zeigt in entgegengesetzte Richtung Schlagwort fehlend → Wagen zeigt in gleiche Richtung. Im nächsten Schritt wird der boolesche Wert der Variablen in Fahrtrichtung links vom Gleiskontakt auf das auslösende Fahrzeug übertragen: True → Ausstieg in Fahrtrichtung links False → Ausstieg in Fahrtrichtung rechts Grafik 3/5: Türseitensteuerung über relative Fahrtrichtung Wenn die beiden booleschen Variablen „Ausstieg in Fahrtrichtung links“ und „positive Fahrtrichtung“ identisch sind (false == false oder true == true) dann wird die linke Tür geöffnet, andernfalls die rechte Tür. Der Vorteil gegenüber dem 2. Lösungsvorschlag besteht hierin, dass wir die Skript Bedingung wieder durch eine grafische Bedingung ersetzen können, was die Übersichtlichkeit erhöht. Die beiden untenstehenden Bilder geben einen Einblick, wie sich die Variablen für die absolute Fahrtrichtung (Merker neg. Geschw.) und relative Fahrtrichtung (positive Fahrtrichtung) bei unterschiedlicher Einfahrt verhalten. Der Umbauwagen W1 wurde im Bezug zur Diesellok um 180° gedreht. Grafik 3/6: DB 212 fährt mit negativer Geschwindigkeit ein Die Diesellok schiebt den Zug und fährt mit absolut negativer Fahrtrichtung in den Bahnhof ein. Grafik 3/7: DB 212 fährt mit positiver Geschwindigkeit ein Die Diesellok zieht den Zug und fährt mit absolut positiver Fahrtrichtung in den Bahnhof ein. Anbei die zweite Version: 3. Lösungsvorschlag - Version 2.mbp Um keinen Hehl daraus zu machen. Die Anlage ist noch immer nicht fehlerfrei. Die Verbesserungen hebe ich mir dann für den nächsten Beitrag auf. Bei lokbespannten Zügen (z.B.: DB 212 mit drei Umbauwagen) wirft die EV einen Fehler im Ereignis „Wenn das KS Hauptsignal schaltet“ bei der Fahrtrichtungsumkehr aus, weil sie bisher nur Züge mit zwei Auslösern anstatt einem Auslöser mit berücksichtig. Bei Zügen mit zwei Auslösern, die in die entgegengesetzte Richtung zeigen wie der ICE, öffnen/schließen sich die Türen nicht immer auf der richtigen Seite. PS: Ich soll euch ganz liebe Grüße von Markus ausrichten. Er hatte mehrere Trauerfälle und war längere Zeit nicht mehr im Forum. Viele Grüße Tim

Neues Konzept: Türseite mittels relativer Fahrtrichtung bestimmen: Wenn wir einige Beiträge zurückblicken, sehen wir, wie die Fahrtrichtung über ein einziges Schlagwort ermittelt wurde. Was ist aber wenn wir keine Triebzüge auf unserer Anlage einsetzen wollen, sondern nur einfache lokbespannte Züge mit einer Lok oder beide Triebköpfe in die gleiche statt in die entgegengesetzte Richtung zeigen? Dann haben wir ein Problem, da nicht alle Türen auf der richtigen Seite mehr öffnen! Probiert im ersten Lösungsvorschlag einmal aus, den vorderen ICE-Triebkopf in Richtung Bahnsteig um 180° zu drehen (die Vorbildlichkeit ist an dieser Stelle egal) oder einen Triebkopf aus dem Zug herauszunehmen. Grafik 3/2: Türen am Triebkopf B öffnen auf der falschen Seite In dieser Situation wurde der Triebkopf B um 180° gedreht. Da der Triebkopf B nicht über das Schlagwort andere Türseite verfügt, fährt der Zug mit der normalen Fahrtrichtung ein, wie der obigen Grafik zu entnehmen ist. Folglich stimmt bei allen Wagen außer dem Triebkopf B die Türseite, weil nur dieser umgedreht wurde. Grafik 3/3: alle Türen öffnen auf der falschen Seite. Hier wurde der Triebkopf B aus dem Zugverbund entfernt. Da der Triebkopf A über das Schlagwort andere Türseite verfügt, müsste der Zug mit der umgekehrten Fahrtrichtung einfahren. Tatsächlich fährt er aber mit normaler Fahrtrichtung ein nur eben, dass der Triebkopf A eine negative statt der sonst üblichen positiven Geschwindigkeit aufweist. Deswegen öffnen sich alle Türen auf der falschen Seite. Wir sehen also, dass die bisherige Fahrtrichtungsbestimmung nur dann funktioniert, wenn der Auslöser mit positiver Geschwindigkeit auf den Gleiskontakt zufährt. Dabei zeigt die Zugspitze des ICE-Triebkopfs stets in Richtung Gleiskontakt. Würde sie in die andere Richtung zeigen, ist die Geschwindigkeit des Auslösers negativ. Damit beide Triebköpfe eines ICEs immer mit positiver Geschwindigkeit einfahren, müssen diese zwangsläufig in die entgegengesetzte Richtung zeigen. Jedoch möchte man vielleicht auch Züge einsetzten, bei denen die beiden Lokomotiven (Auslöser) in die gleiche Richtung zeigen. Wir müssen also die Fahrtrichtungsbestimmung vom Schlagwort „andere Türseite“ entkoppeln und stattdessen die Fahrtrichtung über die Geschwindigkeit des Auslösers ermitteln, um diese konzeptionelle Schwäche zu überwinden.

3. Lösungsvorschlag - Türsteuerung mittels Wiederholung "Für alle Fahrzeuge in einem Zug/Fahrzeugverbund" (Liste) Hallo ihr Lieben, nun widmen wir uns dem dritten und damit letzten Lösungsvorschlag. Oft kommt man an einem Punkt, wo man im Nachhinein die EV hätte viel einfacher gestalten können und die EV konzeptionelle Schwächen aufweist. Das ist jedoch nicht weiter tragisch, da wir ja in diesem Tutorial verschiedene Lösungswege miteinander vergleichen. Denn nur so kann man lernen, warum der eine Lösungsweg für den einen Zweck besser geeignet ist und für einen anderen Zweck eben nicht. Wiederholung "Für alle Fahrzeuge in einem Zug/Fahrzeugverbund: Beim 2. Lösungsvorschlag werden alle Wagen über eine Liste namens Zugverbund angesprochen. Der Nachteil dabei ist, dass man alle Wagen in diesem Zugverbund händisch in die Liste kopieren muss und diese Liste wiederum für zwei Auslöser anlegen muss, da ein ICE aus zwei Triebköpfen [Auslöser] besteht. Gibt es nicht eine Möglichkeit den Zugverbund automatisch zu bestimmen, um den Aufwand zu reduzieren? Da kommt die Wiederholung "Für alle Fahrzeuge in einem Zug/Fahrzeugverbund" ins Spiel. Wenn ein Zug einen Gleiskontakt betritt oder verlässt, dann erstellt das Studio automatisch eine Art Liste aller Fahrzeuge eines Zugs. Diese Methode hat zweierlei Vorteile: Man erspart sich den Aufwand, alle Wagen händisch in eine Liste zu kopieren (für jeden Zug :-) ). Man unterläuft nicht der Gefahr, eine fehlerhafte Liste anzulegen, indem man vergisst, Wagen anzulegen oder indem man Wagen anlegt, die gar nicht zum Zugverbund gehören. Grafik 3/1: Wiederholung für alle Fahrzeuge in einem Zug Die Wiederholung "Für alle Fahrzeuge in einem Zug/Fahrzeugverbund" bietet einen Filter mit vier Auswahlmöglichkeiten. Da wir alle Fahrzeuge in dem Zug unabhängig davon, ob diese einen Antrieb besitzen, ansprechen wollen, wählen wir die erste Option [0 - Alle] aus. Im Gegensatz zum 2. Lösungsvorschlag öffnen sich die Türen eines Wagens nur dann, wenn dieser im Zugverbund eingereiht ist. Wenn ihr einen Wagen aus dem Zugverbund herausnehmt, öffnen sich die Türen im 3. Lösungsvorschlag nicht. Im 2. Lösungsvorschlag hingegen schon. 3. Lösungsvorschlag - Version 1.mbp

Hallo liebe 3D-Modellbaucommunity, als nächstes Modell würde ich gerne ein Photovoltaikmodell erstellen. Solche Modelle sind eher ungewöhnlich. Von daher möchte ich euch fragen, ob überhaupt Interesse an einem solchen Modell besteht. Hier seht ihr eine Art Vorstudie, wie das Modell grob aussehen wird. Die Multitextur kann recht klein ausfallen, weil sie recht gut kachelbar ist. Die Module wird es in mindestens drei Variationen mit unterschiedlichen Mustern geben. Ich könnte mir auch vorstellen, dass ich an die Solarmodule Träger befestige, damit diese wie in einem Solarpark aufgestellt werden können. Praktischerweise lässt die geometrische Form Splines zu, sodass man die Module bequem in einer Flucht ausrichten könnte, vorausgesetzt, dass es nicht zu viele Polygone beim Trägergerüst werden. Gerne freue ich mich über Anregen, Wünsche und Kritik. Unter F0DCED0F-BFE5-4B82-B7DD-01A69A9215A2 (Entwurf) könntet ihr das Solarmodul schonmal begutachten. Herzliche Grüße Tim