So, anbei meine zwei Test-DLLs: Die eine fügt der 141 einen Zufallsabhängigen Knall hinzu, die andere repariert die Zugkraftsteuerung der 111. Aus technischen Gründen gibt es beide DLLs nur in der 64-Bit-Varriante, mehr dazu im folgenden.
.Net-Technik
Die DLLs müssen leider auch Daten aus dem Programme-Ordner updaten. Die Ursache ist folgende: Die Einstiegspunkte in .Net Core sind nach wie vor nicht so einfach, wie damals zu .Net Framework-Zeiten. Es geht aber. Trotzdem hat sich immer wieder herausgestellt, der beste Weg das zu lösen, ist, eine Zentral abgelegte Infrastruktur aufzubauen. Das sind die DLLs der ZusiBfpl.dll. Ähnliche Probleme hatte ich schon bei der Fahrpult-DLL. Jetzt hat sich bei der Fahrzeugantriebs-DLL herausgestellt, dass ich noch mehr zentrale Infrastruktur in Form von Interface-Definitionen brauche, die ich in diesem Fall auch nicht dezentral ablegen kann. Das führt im Endeffekt dazu, dass der Fahrzeugantrieb die ZusiBfpl.dll nutzt. Lange Rede kurzer Sinn: ich muss hier also wohl sinnvollerweise irgendwo zentral mehrere .Net-DLLs ablegen. @Carsten: Das muss ich wohl noch mal bilateral mit dir besprechen. Derzeit ist es halt der .timetable-Ordner. @Für alle, die die DLLs testen wollen: Ihr müsst halt die mitgelieferten DLLs in den Programme-Ordner kopieren. Die alten DLLs vor dem überschreiben natürlich sichern.
Wunsch Nr 1: TMehrfachtraktionsdaten
TMehrfachtraktionsdaten ist eine Struktur. Wie
im anderen Thema besprochen, ist das unter 64 bit recht kompatibel. Unter 32 bit kann man aber Felder nicht mehr so einfach ändern. Ich würde daher darum bitten, TMehrfachtraktionsdaten kurzfristig noch auf const var zu ändern, um auch in Zukunft die DLL noch halbwegs einfach ändern zu können.
Gleichzeitig würde ich noch folgende 2 Änderungen an der Struktur vorschlagen:
* Individuell und FdtIntern an das Ende der Struktur TProtokollFst umsortieren
* Einen Member Size:size_t einbauen. Dieser Member sollte vor der Übergabe an die DLL auf sizeof(TMehrfachtraktionsdaten/TProtokollFst) gesetzt werden und würde gemäß dem erwähnten Thema auch für mehr Kompatiblität sorgen. Sinnvollerweise wäre das auch der 1. Member.
Wunsch Nr 2: Bessere Interaktion mit Nachbarantrieben
Ich habe ja versucht, der 141 ein Zufallsabhängiges Knallen zu verpassen. Jetzt müsste ich an für sich den gesamten Reihenschlussantrieb neu Implementieren, nur um dieses eine Knallen hinzuzufügen. Ich weiß nicht, aber ich halte das ehrlicherweise für nicht sehr sinnig. Daher habe ich versucht, den klassischen Reihensschlussantrieb von meiner DLL aus zu steuern. Das ging aber nur Teilweise: Ich kann dem Reihenschlussantrieb zwar die Informationen geben, die ich brauche, aber wie Wolfgang festgestellt hat, ist das Auslesen der Werte des klassischen Reihenschlussantriebes recht kompliziert.
Ich würde mir daher folgendes Wünschen:
Erweiterung der Fahrzeugantriebs-DLL um eine Methode procedure AndererAntrieb(Instanz:Pointer, AndereInstanz:Pointer)
Diese "andere Instanz" dient dazu, dass man sie an die z3strbie.64.dll übergeben kann.
In der z3strbie.64.dll würde ich mir dann gerne eine Erweiterung um eine Methode function LeseAntriebskraft(Instanz:Pointer):single; stdcall; sowie vor allem jetzt in meinen Fällen Fahrstufe und Oberstrom wünschen.
Ich habe ja schon in anderen Themen geschrieben, dass ich es auch für sinnvoll halte, Triebwagen mit DLLs auszurüsten, bei denen man im Prinzip nur den Fahrzeugbus neu schreibt. Auch dort wäre es eher fraglich, ob man dort wirklich nur wegen des Fahrzeugbus den ganzen Antrieb neu schreiben will. Und die 111 ist genauso: Ich habe hier jetzt nur die Z-Kraftsteuerung neu geschrieben. Man könnte jetzt auch das komplette Antriebsüberwachungsgerät schreiben. Aber deswegen den Motor neu Implementieren? Ich weiß nicht so recht.
Wie habe ich das jetzt gemacht? Naja, ich habe mir den Pointer auf die anderen Antriebe halt vom Stack geholt. Was dann auch der Grund ist, weswegen es derzeit nur unter x64 geht: Ich müsste einen Assembler-Code für die Delphi-Fastcall-Calling-Convention unter x86 scheiben. Geht, und ich glaube, ich könnte inzwischen auch sagen, wie der grob aussehen sollte. Aber generell ist halt das keine sinnvolle Vorgehensweise, das ist ja denke ich klar.
Ausnahmebehandlung
Noch der kurze Hinweis an die Nutzer: Ich muss mir noch Gedanken darüber machen, wie ich verhindere, dass .Net versucht, .Net-Ausnahmen an Zusi weiter zu geben. Wenn also Zugriffsverletzungen auftreten, liegt das mit hoher Wahrscheinlichkeit daran. Ist aber noch mein Thema.
Download
https://www.pkeus.de/~philipp/Zusi/3/Zu ... 11-141.zip
Grundsätzlich macht das mit den Antrieben aber schon Spaß.
Zwar ist das Testen nicht ganz so einfach, aber es ist schon recht viel möglich.
Mein Plan wäre, die Erweiterungen der 111 und 141 ggf. zu verbessern und dann in den Bestand zu bekommen und mich dann Wendezug-, Vielfachsteuerungs- und Fahrzeugbussystemen sowie dem Steuergerät der 143 zu widmen. Voraussetzung wäre aber, dass ich da nicht auf den Hack angewiesen bin.
