Fahrzeugantrieb-dll

Das Unterforum für Diskussionen rund um die Technik, Bedienung, Konfiguration usw. Das ist auch die erste Anlaufstelle für Bastler mit Fragen zu den Editoren.
Nachricht
Autor
HaraldB
Beiträge: 48
Registriert: 01.10.2020 22:10:15

Re: Fahrzeugantrieb-dll

#21 Beitrag von HaraldB »

lipkegu hat geschrieben: 29.08.2023 15:34:50 Ich denke mal das könnte man allgemein lösen, indem man aktuelle aufgeschaltete Fahrstellung der Hebel, mit den Hebeln syncronisiert.
Das ist m.E. die Fehlannahme. Der Autopilot stellt keine Hebel, er legt keine Fahrstufen ein und bedient nicht die Bremsen. Oberstrom, A-Kammer-Druck oder Kurzzeitleistung sind ihm völlig egal.
Vergleichbar mit einem gefühllosen Modellbahner, der seinen Zug von Hand über das Gleis zieht.
lipkegu hat geschrieben: 29.08.2023 15:34:50 Ich denke mal das könnte man allgemein lösen, indem man aktuelle aufgeschaltete Fahrstellung der Hebel, mit den Hebeln syncronisiert.
Wenn Jedes Tfz, solch dynamisches Antriebsmodel hat, dann wäre es ja problemlos möglich, das anzugleichen.
Die allgemeinen Antriebsmodelle gibt es ja schon, intern im Simulator und die sind auch ziemlich dynamisch. Und "problemlos" wäre (und ist) angesichts der individuellen (also vielen unterschiedlichen) Antriebsmodelle und Führerstände kaum irgendwas. Als Beispiel könnten hier die Diskussionen um die Abstimmungsfeinheiten im Antrieb der Ludmillas oder des Bremsverhaltens der Varianten vom 420 dienen. Die Antriebs-DLLs sollen solche Spezialfälle umsetzbar machen, ohne den Arbeitsaufwand am Sim zusätzlich erheblich und grenzenlos zu erhöhen

Und dann hat hat Thomas U. ja völlig recht. Selbst wenn man "problemlos" die kontinuierliche Steuerung von Zugkraft oder Beschleunigung des AP in passende, zulässige Schalterstellungen eines passenden Führerstands "umrechnen" könnte, wäre der Nutzwert ehrlich gering, weil auf der echten Lok am echten Zug auf der echten Strecke bei echtem Nebel sowieso alles dann doch entscheidend anders ist.

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33348
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Fahrzeugantrieb-dll

#22 Beitrag von Carsten Hölscher »

Bitte das kleine Paket neu runterladen, wenn man meine Demo-dlls ohne Absturz nutzen möchte.

Carsten

Benutzeravatar
F. Schn.
Beiträge: 6564
Registriert: 24.10.2011 18:58:26

Re: Fahrzeugantrieb-dll

#23 Beitrag von F. Schn. »

Kannst du im Quellcode anstatt PChar PWideChar schreiben? Das ist zwar das gleiche, aber ich war da kurz auf Glatteis weil ich gedanklich bei PAnsiChar war.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33348
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Fahrzeugantrieb-dll

#24 Beitrag von Carsten Hölscher »

Wo genau?
Carsten

Benutzeravatar
F. Schn.
Beiträge: 6564
Registriert: 24.10.2011 18:58:26

Re: Fahrzeugantrieb-dll

#25 Beitrag von F. Schn. »

Allen voran in der dllHauptunit.pas:21 => function VariantenName(index:integer):PChar; stdcall;
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33348
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Fahrzeugantrieb-dll

#26 Beitrag von Carsten Hölscher »

Wollt nur mal horchen, ob es aus Nutzersicht schon irgendwelche Meinungen gibt zu dem Thema.

Carsten

Benutzeravatar
F. Schn.
Beiträge: 6564
Registriert: 24.10.2011 18:58:26

Re: Fahrzeugantrieb-dll

#27 Beitrag von F. Schn. »

Möchte jetzt diese Woche die ersten zwei Spielereien incl. der zugehörigen Zusatzwünsche veröffentlichen. Wollte ich eigentlich schon letzte Woche, aber dann kam was dazwischen.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat

Benutzeravatar
JuRa
Beiträge: 271
Registriert: 27.02.2018 09:04:33
Aktuelle Projekte: Stecke Plockhorst - Peine
Objekte Epoche III
Wohnort: Edemissen
Kontaktdaten:

Re: Fahrzeugantrieb-dll

#28 Beitrag von JuRa »

Nachdem ich einiges getestet und probiert habe, versuche ich die Logik der Dampflok-Führerstands-dll zu übertragen.
Im Moment fehlt mir die Zeit, um wirklich voran zu kommen.

Da ich als alter SPS-Programmierer mit der Objekt-Orientierten Syntax ein wenig hadere, fällt mir das ganze wirklich nicht leicht.
Ich hoffe, globale Variablen sind in der dll nicht ganz verpönt.

Bin mal gespannt auf die Beispiele

Gruß
Jürgen

jonathanp
Beiträge: 282
Registriert: 01.06.2015 14:11:25
Aktuelle Projekte: http://www.zusidatenbank.de/
Wohnort: BW Schöneweide

Re: Fahrzeugantrieb-dll

#29 Beitrag von jonathanp »

F. Schn. hat geschrieben: 10.09.2023 17:07:10 Kannst du im Quellcode anstatt PChar PWideChar schreiben? Das ist zwar das gleiche, aber ich war da kurz auf Glatteis weil ich gedanklich bei PAnsiChar war.
Ich würde dies unterstützen.
Das Problem ist, dass PChar bis Dephi 2009 gleichbedeutend mit PAnsiChar/char* war, danach war es aber ein PWideChar/wchar_t*. In FreePascal scheint es immer noch PAnsiChar zu meinen. Um die Schnittstelle zu verwenden, muss man also wissen, mit welcher Delphi-Version Zusi kompiliert wurde.
Autor - Zusi 3 C++ Client, zusidatenbank.de - Das Zusi3 Addon-Datenbank

Benutzeravatar
F. Schn.
Beiträge: 6564
Registriert: 24.10.2011 18:58:26

Re: Fahrzeugantrieb-dll

#30 Beitrag von F. Schn. »

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
(nicht mehr lauffähig)

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. :tup

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.
Zuletzt geändert von F. Schn. am 19.01.2024 18:37:39, insgesamt 3-mal geändert.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat

Benutzeravatar
Leif K.
Beiträge: 342
Registriert: 30.04.2023 10:33:53
Aktuelle Projekte: Fahrplaneditor lernen und verstehen
Wohnort: KKUZ (kennt das noch jemand?), am Wochenende EDG

Re: Fahrzeugantrieb-dll

#31 Beitrag von Leif K. »

Aber Hallo, mit so einem schnellen Output hätte ich ja im Leben nicht gerechnet. Das muss ich mir morgen mal genau anschauen, großes Kompliment schon mal anhand der Beschreibung. :tup

Für die 112.1 / 143 müsste ich übrigens bei Bedarf auch noch Unterlagen haben, sowohl vor als auch nach der Wende.
„Die Neugier steht immer an erster Stelle des Problems, das gelöst werden soll.“ (Galileo Galilei). Oder schlichter gesagt: Bei ehrlicher Neugier gibt es keine dummen Fragen.

Danke & Beste Grüße, Leif

Wolfgang E.
Beiträge: 550
Registriert: 28.10.2021 12:16:41
Aktuelle Projekte: https://github.com/machinae-vectoriae-ductor/
Wohnort: Köln
Kontaktdaten:

Re: Fahrzeugantrieb-dll

#32 Beitrag von Wolfgang E. »

Schön, dass Du den ersten Aufschlag gemacht hast.
Würdest Du auch Deine Quelltexte als Beispiel für andere Implementierungen zur Verfügung stellen?

Viele Grüße
Wolfgang

Benutzeravatar
Johannes
Beiträge: 3195
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Fahrzeugantrieb-dll

#33 Beitrag von Johannes »

JuRa hat geschrieben: 23.09.2023 09:16:44 Ich hoffe, globale Variablen sind in der dll nicht ganz verpönt.
Du musst eben beachten, dass die DLL nur einmal geladen wird, aber mehrere Fahrzeuge damit gesteuert werden können.

Noch eine Frage: Ist es beabsichtigt, dass es die Funktion "VarianteAktivieren" für das Anlegen eines neuen Antriebs gibt, aber keine Funktion zum "Deaktivieren" (Freigeben)? Sieht mir nach einem Speicherleck aus, wenn man z.B. einen neuen Fahrplan startet.

Benutzeravatar
F. Schn.
Beiträge: 6564
Registriert: 24.10.2011 18:58:26

Re: Fahrzeugantrieb-dll

#34 Beitrag von F. Schn. »

JuRa hat geschrieben: 23.09.2023 09:16:44 Da ich als alter SPS-Programmierer mit der Objekt-Orientierten Syntax ein wenig hadere, fällt mir das ganze wirklich nicht leicht.
Ich hoffe, globale Variablen sind in der dll nicht ganz verpönt.
Also globale Variablen machen bei einer Antriebs-DLL wenig Sinn, weil du möglicherweise mit deiner DLL verschiedene Lokomotiven steuern möchtest.

Du kannst aber Alternativ auch mit nur einer einzigen Klasse auskommen, und alles in diese einzige Klasse packen. (Das Gegenmodell wäre, Dinge wie den Fahrschalter "modular" in unterschiedlichen Klassen aufbauen.) Das wäre dann aber nicht statisch, sondern trotzdem Instanzvariablen und Instanzmethoden. Vom Programmieren her fühlt sich so etwas dann genauso an, wie wenn du eine Nicht-Objektorientierte Programmiersprache in der Hand hättest.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat

Benutzeravatar
Leif K.
Beiträge: 342
Registriert: 30.04.2023 10:33:53
Aktuelle Projekte: Fahrplaneditor lernen und verstehen
Wohnort: KKUZ (kennt das noch jemand?), am Wochenende EDG

Re: Fahrzeugantrieb-dll

#35 Beitrag von Leif K. »

Guten Abend F.Schn.,

Nochmals auch von mir vielen Dank für Deine ersten Eperimental-DLLs. Ein erstes Feedback aus der Anwendung:

BR 111, getestet mit RE 59118 im Fahrplan Augsburg-Mertingen 2018: Die Fahrstufenanzeige blieb bei mir konstant auf 00, egal ob in Auf-Ab- oder in Z-Steuerung gefahren wurde. Ansonsten ist die neue Z-Steuerung ein spürbarer Fortschritt.

BR 141, getestet mit SE 3808 im Fahrplan Weserbergland 1996: Hier konnte ich eben noch nicht intensiv testen, nur zwei Anfahrten erstmal. Mir kam es vor, als würde ich gar kein Schaltgeräusch hören, das muss ich aber am anderen Rechner nochmal mit anderen Soundeinstellungen verifizieren.

In beiden Fällen wurde in Buchfahrplanfenster kein Bfpl angezeigt. Die Zugdaten waren aber sichtbar, EBuLa auf der 111 hat auch funktioniert.

Ist nur ein Ergebnis eines absoluten Schnelltests und kein Gemecker. Ich finde es weiterhin toll, dass Du diesen Ansatz weiterverfolgst. Morgen versuche ich, etwas intensiver zu testen.

Beste Grüße
Leif
„Die Neugier steht immer an erster Stelle des Problems, das gelöst werden soll.“ (Galileo Galilei). Oder schlichter gesagt: Bei ehrlicher Neugier gibt es keine dummen Fragen.

Danke & Beste Grüße, Leif

Benutzeravatar
F. Schn.
Beiträge: 6564
Registriert: 24.10.2011 18:58:26

Re: Fahrzeugantrieb-dll

#36 Beitrag von F. Schn. »

Okay, ich darf keine Debug-Variante der CoreEntryPoint.64.dll mitliefern, weil er sonnst auf Nicht-Debug-Rechnern den Import-Verweis nicht findet. Ich melde mich, wenn ich alles wieder so weit habe. Danke an den #zusi-IRC für die Hilfe.

PS: Der Schnelltest sollte damit aber nicht Aussagekräftig sein.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat

Benutzeravatar
Leif K.
Beiträge: 342
Registriert: 30.04.2023 10:33:53
Aktuelle Projekte: Fahrplaneditor lernen und verstehen
Wohnort: KKUZ (kennt das noch jemand?), am Wochenende EDG

Re: Fahrzeugantrieb-dll

#37 Beitrag von Leif K. »

Entschuldigung, aber den letzten Satz verstehe ich grammatikalisch nicht ganz. Heißt das im Klartext, ich sollte mit weiteren Tests warten, bis Du die CoreEntryPoint.64.dll auf eine non-debug-Version gefixt hast?

Auf jeden Fall aber schon einmal herzlichen Dank für die schnelle Antwort und an alle Kollegen aus dem Chat für die Problemanalyse und Lösungsfindung. Viel Erfolg bei der Implementierung :tup
„Die Neugier steht immer an erster Stelle des Problems, das gelöst werden soll.“ (Galileo Galilei). Oder schlichter gesagt: Bei ehrlicher Neugier gibt es keine dummen Fragen.

Danke & Beste Grüße, Leif

Benutzeravatar
JuRa
Beiträge: 271
Registriert: 27.02.2018 09:04:33
Aktuelle Projekte: Stecke Plockhorst - Peine
Objekte Epoche III
Wohnort: Edemissen
Kontaktdaten:

Re: Fahrzeugantrieb-dll

#38 Beitrag von JuRa »

Johannes hat geschrieben: 25.09.2023 08:05:39 Du musst eben beachten, dass die DLL nur einmal geladen wird, aber mehrere Fahrzeuge damit gesteuert werden können.
F. Schn. hat geschrieben: 25.09.2023 17:35:23 Also globale Variablen machen bei einer Antriebs-DLL wenig Sinn, weil du möglicherweise mit deiner DLL verschiedene Lokomotiven steuern möchtest.

Du kannst aber Alternativ auch mit nur einer einzigen Klasse auskommen, und alles in diese einzige Klasse packen. (Das Gegenmodell wäre, Dinge wie den Fahrschalter "modular" in unterschiedlichen Klassen aufbauen.) Das wäre dann aber nicht statisch, sondern trotzdem Instanzvariablen und Instanzmethoden. Vom Programmieren her fühlt sich so etwas dann genauso an, wie wenn du eine Nicht-Objektorientierte Programmiersprache in der Hand hättest.
Danke für eurer Hinweise und Tipps. Hatte das so gar nicht auf dem Schirm.

Gruß
Jürgen

Benutzeravatar
F. Schn.
Beiträge: 6564
Registriert: 24.10.2011 18:58:26

Re: Fahrzeugantrieb-dll

#39 Beitrag von F. Schn. »

So, funktioniert wieder, korrigierter Download-Link siehe oben.

(Den Sourcecode würde ich ehrlich gesagt erst mal zurück stellen, bis das Provisorium mit dem Stack aufgelöst ist.)
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat

Benutzeravatar
Leif K.
Beiträge: 342
Registriert: 30.04.2023 10:33:53
Aktuelle Projekte: Fahrplaneditor lernen und verstehen
Wohnort: KKUZ (kennt das noch jemand?), am Wochenende EDG

Re: Fahrzeugantrieb-dll

#40 Beitrag von Leif K. »

Danke vielmals! Einspielen werde ich heute Abend noch schaffen, Testen wohl eher in den nächsten Tagen.

Schönen Abend & Viele Grüße
Leif
„Die Neugier steht immer an erster Stelle des Problems, das gelöst werden soll.“ (Galileo Galilei). Oder schlichter gesagt: Bei ehrlicher Neugier gibt es keine dummen Fragen.

Danke & Beste Grüße, Leif

Antworten