DSD2010 kein 'goto X' drehung - gelöst
-
Sven
- Administrator
- Beiträge: 980
- Registriert: Mo 7. Mär 2011, 15:13
- Kontaktdaten:
Re: DSD2010 kein 'goto X' drehung - gelöst
Hallo Stephan,
ich habe mir heute mal die RS232 Signale und die dsd.exe auf das Timing hin angesehen.
Eigentlich sollte alles sehr entspannt sein. Wenn ich das Problem richtig verstehe, dann ist das Auslesen von den Daten problematisch. Nicht aber die zyklische Statusmeldung (also die Aktualisierung des Status der Drehscheibe, hierfür sendet die Grubenplatine zyklisch Informationen mit 9600 Baud mit harmlosen 15 Bytes in 160ms)
Wenn man jetzt anfängt, Daten auszulesen, dann beginnt das "Frage- und Antwort" Spiel:
1) die EXE fragt ein EEprom Wert aus der Grube ab.
2) Grube antwortet, das dauert hier ca. 30-60ms nach Abfrage (1)
3) EXE fragt den nächsten Wert ab, ca. 30-40ms nach Empfang von der Grube (2)
Ich weiß jetzt nicht ob Du das bei Dir mal mit einem Oszi aufzeichnen kannst...
Sven
ich habe mir heute mal die RS232 Signale und die dsd.exe auf das Timing hin angesehen.
Eigentlich sollte alles sehr entspannt sein. Wenn ich das Problem richtig verstehe, dann ist das Auslesen von den Daten problematisch. Nicht aber die zyklische Statusmeldung (also die Aktualisierung des Status der Drehscheibe, hierfür sendet die Grubenplatine zyklisch Informationen mit 9600 Baud mit harmlosen 15 Bytes in 160ms)
Wenn man jetzt anfängt, Daten auszulesen, dann beginnt das "Frage- und Antwort" Spiel:
1) die EXE fragt ein EEprom Wert aus der Grube ab.
2) Grube antwortet, das dauert hier ca. 30-60ms nach Abfrage (1)
3) EXE fragt den nächsten Wert ab, ca. 30-40ms nach Empfang von der Grube (2)
Ich weiß jetzt nicht ob Du das bei Dir mal mit einem Oszi aufzeichnen kannst...
Sven
-
ttbahner
- Beiträge: 4
- Registriert: Mi 28. Dez 2022, 13:23
Re: DSD2010 kein 'goto X' drehung - gelöst
Hallo Sven,
vielen Dank für die Antwort. Ich habe diese leider erst jetzt gesehen, sonst hätte ich schon früher geantwortet. Wie schon beim letzten Mal geschrieben, ist das Problem für mich ja kein wirkliches Problem, weil ich die Drehscheibe normalerweise mit der ECoS über DCC bzw. aus Rocrail steuere und das problemlos funktioniert. Evtl. wäre es deshalb auch sinnvoll meine Frage sowie deine und meine heutige Antwort in einen eigenen Thread "DSD2010 unter Linux" zu verschieben.
Ich habe heute noch einmal kurz getestet. Seit meiner Frage liegen ja schon einige Updates von Manjaro Linux und Wine dazwischen. Entsprechend funktionierte heute erst einmal überhaupt nichts mehr richtig. Beim Start der Software kommen schon Fehlermeldungen, dass keine Antwort empfangen wurde. Nach einigen Sekunden und der Frage nach dem Abbruch des Einlesens wird die Software dann aber bedienbar und die Drehscheibe lässt sich zumindest damit steuern. Mit Version 4.5 hatte ich aber auch dann einige Mal fehlerhafte Rückmeldungen. Während der Drehung und auch im Stand springt die Positionsanzeige und/oder die Farbe der Statusanzeigen (Rückmelder etc.), z.T. mit total sinnlosen Werten (z.B. kam mal als Position der Wert 66). Nach Update auf Version 4.6 ist zumindest das Problem nicht mehr aufgetaucht (keine Ahnung ob Zufall oder wegen der neuen Software), Lesefehler beim Start oder beim Lesen vom EEPROM gibt es aber trotzdem. Z.B. funktioniert des Lesen des EEPROMs Grube für die ersten ca. 16 Adressen normal und ab dann kommen nur noch Lesefehler und auch nach einem Abbruch des Auslesens funktioniert erst einmal ein paar Sekunden überhaupt nichts mehr.
Mit dem Oszi messen kann ich prinzipiell machen. Ich glaube allerdings, dass es aufgrund der damit maximal möglichen Länge der Aufzeichnung nicht wirklich verwertbare Informationen gibt (physisch ist das Signal ja ok, es funktioniert ja mit der gleichen Hardware aus Windows oder aus einer Windows-VM unter Linux). Weil es mich wirklich interessiert, werde ich in den nächsten Wochen aber mal mit meinem Logic Analyzer (Kingst LA2016) nachmessen. Ich muss mir nur erst einmal einen Adapter für die Messung direkt an der RS232 basteln, weil ich nicht an der Platine Kabel anlöten möchte. Mit dem Logic-Analyzer sollten sich bei den Frequenzen des UARTs eigentlich mehrere Sekunden der Kommunikation problemlos aufzeichnen und in Ruhe auswerten lassen.
Meine Vermutung ist, dass via Wine-Emulation der UART so ungünstig geschrieben und/oder gelesen wird, dass bei der Übertragung in einzelnen Messages zu große Pausen zwischen den einzelnen Bytes entstehen und dadurch die PC-Software oder vielleicht sogar die Drehscheibe aus dem Takt kommt.
Wenn ich neue Erkenntnisse habe, werde ich es hier schreiben.
Viele Grüße
Stephan
vielen Dank für die Antwort. Ich habe diese leider erst jetzt gesehen, sonst hätte ich schon früher geantwortet. Wie schon beim letzten Mal geschrieben, ist das Problem für mich ja kein wirkliches Problem, weil ich die Drehscheibe normalerweise mit der ECoS über DCC bzw. aus Rocrail steuere und das problemlos funktioniert. Evtl. wäre es deshalb auch sinnvoll meine Frage sowie deine und meine heutige Antwort in einen eigenen Thread "DSD2010 unter Linux" zu verschieben.
Ich habe heute noch einmal kurz getestet. Seit meiner Frage liegen ja schon einige Updates von Manjaro Linux und Wine dazwischen. Entsprechend funktionierte heute erst einmal überhaupt nichts mehr richtig. Beim Start der Software kommen schon Fehlermeldungen, dass keine Antwort empfangen wurde. Nach einigen Sekunden und der Frage nach dem Abbruch des Einlesens wird die Software dann aber bedienbar und die Drehscheibe lässt sich zumindest damit steuern. Mit Version 4.5 hatte ich aber auch dann einige Mal fehlerhafte Rückmeldungen. Während der Drehung und auch im Stand springt die Positionsanzeige und/oder die Farbe der Statusanzeigen (Rückmelder etc.), z.T. mit total sinnlosen Werten (z.B. kam mal als Position der Wert 66). Nach Update auf Version 4.6 ist zumindest das Problem nicht mehr aufgetaucht (keine Ahnung ob Zufall oder wegen der neuen Software), Lesefehler beim Start oder beim Lesen vom EEPROM gibt es aber trotzdem. Z.B. funktioniert des Lesen des EEPROMs Grube für die ersten ca. 16 Adressen normal und ab dann kommen nur noch Lesefehler und auch nach einem Abbruch des Auslesens funktioniert erst einmal ein paar Sekunden überhaupt nichts mehr.
Mit dem Oszi messen kann ich prinzipiell machen. Ich glaube allerdings, dass es aufgrund der damit maximal möglichen Länge der Aufzeichnung nicht wirklich verwertbare Informationen gibt (physisch ist das Signal ja ok, es funktioniert ja mit der gleichen Hardware aus Windows oder aus einer Windows-VM unter Linux). Weil es mich wirklich interessiert, werde ich in den nächsten Wochen aber mal mit meinem Logic Analyzer (Kingst LA2016) nachmessen. Ich muss mir nur erst einmal einen Adapter für die Messung direkt an der RS232 basteln, weil ich nicht an der Platine Kabel anlöten möchte. Mit dem Logic-Analyzer sollten sich bei den Frequenzen des UARTs eigentlich mehrere Sekunden der Kommunikation problemlos aufzeichnen und in Ruhe auswerten lassen.
Meine Vermutung ist, dass via Wine-Emulation der UART so ungünstig geschrieben und/oder gelesen wird, dass bei der Übertragung in einzelnen Messages zu große Pausen zwischen den einzelnen Bytes entstehen und dadurch die PC-Software oder vielleicht sogar die Drehscheibe aus dem Takt kommt.
Wenn ich neue Erkenntnisse habe, werde ich es hier schreiben.
Viele Grüße
Stephan