@Amirco: Interface ist nur das Englisch Wort für Schnittstelle.
Eine Schnittstelle (Im Computerbereich) ist grob gesagt eine gemeinsame "Sprache" Die 2 ansonsten völlig verschiedene Computer-/Softwaresysteme auf beiden seiten verstehen. Das wird häufig über XML-/Textdateien o.ä. gelöst.
Hier wird eine vorhandene DLL-Datei zur Kommunikation mit dem TS genutzt (weiter ausholen möchte ich jetzt nicht 
).
Grüße
-setter-
Ok.
@Dayjay Ich wollte heute mal den Versuch starten. Leider lief der TSConductorUI nicht auf Anhieb. Es kam eine Fehlermeldung vom MS .NET Framework "Die Eingabezeichenfolge hat das falsche Format.". Das .NET 3.5 hatte ich vorab unter Win7 64bit aktiviert. Wenn ich auf "Weiter" klickte, startete zwar das Programm, aber es funktionierte nicht. Die Felder der Einstellungen waren leer. 
Dann habe ich ins Programmverzeichnis geschaut und eine settings.ini, lt. Deiner Homepage, angelegt. Nun startet das Programm und man kann sich mit Hercules (als TCP-Client) verbinden. Leider lässt mein System kein überlagertes Fenster von Hercules beim TrainSimulator zu, aber ich bekomme meine Antworten und kann Werte setzen. Das ist doch mal ein Anfang. 
Jetzt kommt der schwierige Part. Ein Programm schreiben, was Eingabebefehle von Joystickachsen als TCP Nachrichten übermittelt. 
Interessante Sache - Vor allem wenn man Smartphones oder Tablets zur Steuerung des TS verwenden will. Lassen sich sicher gute Apps (Fahrhilfen) mit der Funktion erstellen 
Interessante Sache - Vor allem wenn man Smartphones oder Tablets zur Steuerung des TS verwenden will. Lassen sich sicher gute Apps (Fahrhilfen) mit der Funktion erstellen
Siehe mein Beitrag vom 12. März 2016: hier 
Ich probier da mal was aus. Mal schauen ob man die Befehle auch über eine HTML5 App ausführen kann (muss ich natürlich eben mal schnell schreiben xD ).
Nach einigen Stunden Arbeit kommt die Ernüchterung. Nicht jede Lok reagiert auf SetControllerValue() beim Fahrtregler. Egal ob ich den Regulator oder den SimpleThrottle anspreche, die Werte werden vom TS nicht übernommen. Auslesen geht. Das Setzten der Fahrtrichung geht auch. Getestet an der UP SW10 und UP ES44DC.
EDIT: @Dayjay im Installationsverzeichnis wird leider keine Logdatei abgelegt.
Die Felder der Einstellungen waren leer.
Das ist komisch. Erstellt denn die "Zurücksetzen" Funktionen eine ini bzw. wenn du die Einstellungen bearbeitest? Auch das du kein Log hast ist komisch, eventuell ein Berechtigungsproblem. Läuft der TSC mit Adminrechten bzw. hast du Adminrechte?
@Dayjay Auch mit Adminrechten bekomme ich kein Log im Programmverzeichnis. Ich habe mich jetzt mit dem Hercules Tool als TCP Server beholfen. Dein Server funktioniert ansonsten ja reibungslos. 
Programmiertechnisch stoße ich, als Gelegenheitsprogrammierer mit AutoIt, an meine Grenzen. Eine Abfrage, dass mein Tool nur einen TCP-Befehl sendet, wenn auch die Joystickachse bewegt wurde, bekomme ich nicht hin. Somit sendet mein Client dauernd den selben Befehl. Es gibt auch noch weitere kleine Fehler 
Ich überlege schon, wie ich Dich als Programmierer für meinen Client begeistern kann? 
Danke, ich werde wohl darauf zurückkommen.
Das mit dem Speichern des letzten Joystickwertes hatte ich eingebaut. Nur habe ich heute erst einen kleinen Fehler entdeckt, welcher diese Abfrage aus hebelte. Jetzt werden wesentlich weniger TCP-Befehle verschickt, aber immer noch ein paar zu viel. Die Kontrolle anhand des letzten, über TCP gesendeten, Befehls will mir nicht gelingen.
Nach einem kleinen Beta-Test (siehe hier) geht es weiter. Die BR 101 ist wiederum eine Lok, welche nicht sauber auf "VirtualBrake" oder "TrainBrakeControl" reagiert. Bei ersterem bremst zwar der Zug, aber der Bremshebel bewegt sich nicht.
Ich tue mich schwer mit den folgenden Formulierungen (von der TSConductor Webseite):
License Copyright © ... - All Rights Reserved
sowie der Tatsache, dass sich der Autor massiv bei frueheren quelloffenen Projekten informiert hat, diese aber fuer meinen Geschmack viel zu wenig wuerdigt. Die gesamte Mechanik der Kommunikation mit raildriver.dll wurde aber im letzten Jahr von anderen Leuten erarbeitet, inklusive Details zu internen Kontrollvariablen wie Zugposition etc. TSConductor ist ein netter aufgebohrter C# Wrapper um diese fruehren Projekte, aber es gibt fuer Leute, die lieber gemeinsam und freizuegig mit freien Tools arbeiten, auch weniger "proprietäre und geheime" Alternativen mit publiziertem Quellcode, z.B.
Rob Mitchelmore (wird immerhin in den Acknowledgements erwaehnt, ohne zu sagen, dass all das auf seinen Ideen basiert, bis hin zur Realisierung eines Servers in C#!)
Blog Eintrag zu RDIp
C# Quellcode zu RDIp und RDIp-server
wer lieber Python mag, kann zu py-raildriver greifen -- ein entsprechender Server ist in python mit 20-50 mehr Zeilen geschrieben...
PY-Raildriver mit Quellcode
Die gesamte Mechanik der Kommunikation mit raildriver.dll wurde aber im letzten Jahr von anderen Leuten erarbeitet, inklusive Details zu internen Kontrollvariablen wie Zugposition etc.
Von anderen Leuten? Die standen alle auf der alten Engine-Driver Webseite und die Artikel waren afaik alle von Matt Peddlesden.
aber es gibt fuer Leute, die lieber gemeinsam an Dingen arbeiten, auch weniger "vertrauliche und geheime" Alternativen mit publiziertem Quellcode, z.B.
Ich denke doch darüber nach den Quellcode zu veröffentlichen. Meine Güte...
Rob Mitchelmore (wird immerhin in den Acknowledgements erwaehnt, ohne zu sagen, dass all das auf seinen Ideen basiert)
Habe ich erwähnt weil seine Blogeinträge mir geholfen zu verstehen wie die .dll funktioniert. Ideen für einen TCP Server gab es aber schon länger und öfter.
Zitat: "Habe ich erwähnt weil seine Blogeinträge mir geholfen zu verstehen wie die .dll funktioniert."
...und weil Du seinen Raildriver.cs von besagter github Seite als Basis fuer Deine eigene Erweiterung benutzt hast (inkl. 1:1-Kopie bei den enums und der Art wie man die externen dll-Funktionen zulinkt). Ich bin mir sicher, dass Du viel Arbeit in TSConductor gesteckt hast und steckst, aber trotzdem: wie die Amerikaner so schoen sagen: give credit where credit is due! Was fuer ein Zacken fiele Dir denn aus der Krone zu schreiben, "basiered auf Ideen von RDIp oder so aehnlich?"
Richtige Entscheidung!
Danke für deine Arbeit. Ich denke, TSConcductor könnte mir sehr nützlich sein.
Leider muss ich sagen, dass TSConductor für mich nicht funkoniert. Ich denke, dass es ist, weil mein Computer amerikanischen Regionaleinstellungen hat.
.NET hat eine nützliche / lästige 'Eigenschaft', dass es die Computereinstellungen verwendet, zwischen , und . entscheiden.
System.FormatException: Input string was not in a correct format.
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at System.Convert.ToInt32(String value)
at TSConductorUI.MainForm.LoadIniFile()
at TSConductorUI.MainForm.MainForm_Load(Object sender, EventArgs e)
Dieses Beispiel macht mir Sorgen, auch:
<? Xml version = "1.0" encoding = "UTF-8"?>
<List>
<Controller>
<ID> 18 </ ID>
<Aktuell> 17,60397 </ Aktuelles>
</ Controller>
</ List>
1. alle anderen Programmiersprachen außer .NET erwarten string mit . für string -> float Umwandlung.
2. wird es noch 17,60397 auf meinem PC sein, oder 17.60397?