Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

QT: Serialport verschluckt Daten

Werbeanzeige

kylecorver

Frischling

  • »kylecorver« ist der Autor dieses Themas

Beiträge: 57

  • Private Nachricht senden

11

05.10.2015, 15:58

Zitat von »Koschi«

Nur um sicher zu gehen das wir nicht an einander vorbei reden, damit die daten Richtig übertragen/empfangen werden, reicht es nicht aus nur die Übertragungs rate in deinem Programm zu ändern, die Baudrate muss auch auf dem Chip geändert werden.

Wie gesagt ich würde es mal mit einem Terminal-Programm probieren ob das Resultat das selbe ist am Laptop.
Ja das ist schon klar. Ich hab jetzt lang rum probiert, aber ich komm mit der Win-Konsole bzw. der Powershell einfach nich klar =/

Zitat von »TrommlBomml«

Da du vermutlich eine USB-Serial Adapter benutzt weiß ich, dass die Teilweise ziemlich zickig sind. Sind die Treiber dafür auf Laptop/PC identisch konfiguriert?
Also speziell konfiguriert bzw. Treiber installiert habe ich nicht. Beides Windows-Standardtreiber. Kann da ein Unterschied sein zwischen Win8 und Win10? Der Treiber ist (wohl) uralt, da sollten beide den gleichen haben.

Oder kann es alternativ sein, dass mein Code zum Auslesen einfach kac** ist?
Dahingehend auch nochmal meine Frage bezüglich der Formatierung: Der Code ist jeweils in einer Zeile ... das war keine Absicht so ^^

TrommlBomml

Community-Fossil

Beiträge: 2 117

Wohnort: Berlin

Beruf: Software-Entwickler

  • Private Nachricht senden

12

05.10.2015, 16:09

Ich weiß nur aus Erfahrung, dass wir für unsere Serielle Kommunikation mit einem Gerät über einen USB-Adapter genau vom Hersteller ein konkretes Modell empfohlen bekommen haben, um verlässlich Daten zu bekommen. Und ja, der Treiber kann eine Rolle spielen, wenn sonst der Code vernünftig funktioniert.

Als Referenz kannst du auf deinem Zielsystem mit Windows 10 mit C# den Code nachbauen. Da gibt es eine Serialport-Klasse, die ist sehr einfach zu bedienen. Wenn dasselbe Ergebnis kommt, könnte es der Treiber sein.

Koschi

Alter Hase

Beiträge: 657

  • Private Nachricht senden

13

05.10.2015, 16:21

Zitat von »kylecorver«

aber ich komm mit der Win-Konsole bzw. der Powershell einfach nich klar =/

Einfach mal ein Terminal-Programm runterladen aus dem Netz mit Grafischer Oberfläche z.B. der Hier Sollte eigentlich nicht schwer sein über dieses Programm auf dein OBD zu zugreifen und mit diesem zu Komunizieren.

Zitat von »TrommlBomml«

Als Referenz kannst du auf deinem Zielsystem mit Windows 10 mit C# den Code nachbauen. Da gibt es eine Serialport-Klasse, die ist sehr einfach zu bedienen. Wenn dasselbe Ergebnis kommt, könnte es der Treiber sein.


Wie gesagt bevor du jetzt den Code nochmal neu machst würde ich es mit dem Terminal Programm versuchen, kann aus meiner Erfahrung allerdings die Zickigen USB-Serial Adapter nicht bestätigen.
Wer aufhört besser werden zu wollen hört auf gut zu sein!

aktuelles Projekt:Rickety Racquet

kylecorver

Frischling

  • »kylecorver« ist der Autor dieses Themas

Beiträge: 57

  • Private Nachricht senden

14

05.10.2015, 16:49

Ok nochmal danke für die Tipps. Ich habe jetzt 3 Sachen ausprobiert:

1. Das ganze in C# gemacht mittels System.IO.Ports.SerialPort und auf dem PC ausgeführt.

C#-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12

SerialPort oPort = new SerialPort("COM3");

oPort.BaudRate = 38400;
oPort.Parity = Parity.None;
oPort.DataBits = 8;
oPort.StopBits = StopBits.One;

string sCmd = Console.ReadLine();
oPort.Write(sCmd + '\r');
System.Threading.Thread.Sleep(1000);
string sMsg = oPort.ReadExisting();
Console.WriteLine(sMsg);


Das Ergebnis: Lustigerweise fehlt auch hierbei der Anfang der Antwort. Das Problem, das ich eigentlich nur auf dem Laptop hatte, habe ich so auch auf dem PC?!?!?!?

Dann danke Koschi für den Link zu dem Programm. Dies habe ich sowohl auf Laptop als auch auf dem PC ausprobiert.
Das Ergebnis hierbei: Auf beiden Geräten kommt wird die komplette Nachricht korrekt empfangen. Es fehlen keine Bytes oder ähnliches am Anfang.

Dementsprechend würde ich ein Problem mit den Treibern ausschließen, richtig?

Also bleibt nur noch der Code übrig ... :o

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »kylecorver« (05.10.2015, 18:32)

Koschi

Alter Hase

Beiträge: 657

  • Private Nachricht senden

15

05.10.2015, 18:19

Zitat von »kylecorver«

Dementsprechend würde ich ein Problem mit den Treibern ausschließen, richtig?

Würde auch sagen kein Treiber Problem.

Als nächstes solltest du mal checken ob dein Programm folgendes erfüllt

Zitat von »http://elmelectronics.com/DSheets/ELM327DS.pdf«

Don’t forget to also
set your connection for 8 data bits, no parity bits, and 1
stop bit, and to set it for the proper ‘line end’ mode.


Edit: soweit ich das deinem Code entnehmen konnte tut er das.
Edit2: Übrigens den Code einfügen wenn du auf "Quellcode" den Reiter oben Links eingestellt hast.
Wer aufhört besser werden zu wollen hört auf gut zu sein!

aktuelles Projekt:Rickety Racquet

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Koschi« (05.10.2015, 18:25)

kylecorver

Frischling

  • »kylecorver« ist der Autor dieses Themas

Beiträge: 57

  • Private Nachricht senden

16

05.10.2015, 18:37

Merci für den Tipp.

Hab meinen Code oben editiert, dass die Initialisierung ebenfalls dabei ist. Das Line-End schicke ich beim Senden manuell mit mittels +'\r', was offenbar auch richtig interpretiert wird.
Was ich versucht habe ist, das Attribut System.IO.Ports.SerialPort.NewLine meines Ports zu setzen. Dazu heißt es in der Beschreibung:

Zitat

Ruft den Wert ab, mit dem das Ende eines Aufrufs der ReadLine-Methode und der WriteLine-Methode interpretiert wird, oder legt diesen fest.


Der Befehl beim Senden wird richtig interpretiert, beim Empfangen muss ich jedoch mehrere Zeilen auslesen, von denen die ersten 2-3 leer sind. Sobald jedoch die Zeile mit Daten ankommt wird diese auch korrekt gelesen. :o =/

Koschi

Alter Hase

Beiträge: 657

  • Private Nachricht senden

17

05.10.2015, 19:07

Hast du schon mal mit dem FlowControl von QT rumgespielt?

Folgender Artikel beschreibt das ganze recht gut was da im einzelnen passiert.
Wer aufhört besser werden zu wollen hört auf gut zu sein!

aktuelles Projekt:Rickety Racquet

kylecorver

Frischling

  • »kylecorver« ist der Autor dieses Themas

Beiträge: 57

  • Private Nachricht senden

18

13.10.2015, 17:23

Hey also mal vielen Dank für die Hilfe :)
Für manuelle Eingaben funktioniert das Programm nun.

Ich habe mich dazu entschlossen das ganze in C# zu machen. Es gibt nun einen separaten, asynchronen Thread zum Einlesen und Verarbeiten der Empfangenen Daten, welches mittels WriteLine() bzw. ReadLine des SerialPorts realisiert ist.

Nun bin ich jedoch auf ein weiteres Problem gestoßen: Bei manuellen Eingaben über die Konsole o.ä. Klappt das ganze wunderbar: Ergebnis wird empfangen, geparst und konvertiert. Nun will ich das ganze natürlich nicht manuelle machen sondern automatisch auswerten lassen. Dazu schicke ich eine Reihe von Anfragen über USB und empfange im anderen Thread die Ergebnisse. Baue ich hierbei kein Sleep() von mindestens 50ms in den Schreib-Thread ein, so erhalte ich komplett konfuse Ergebnisse: Die eigentlichen Daten sind zwar wohl richtig, die "Pakete", die ich per Readline() empfange sind jedoch konfus. Beispiel:

Richtiges Ergebnis wäre:
41 0C 00 1C\r
41 1E 00\r
>NO DATA

Was ankommt:
41 0C
00 1C
\r41 1E
00\r
>NO
DATA

Ich habe leider keine Ahnung, woran das nun schon wieder liegt. Mit dem Sleep Befehl passt das Ergebnis, wenn ich dauerhaft Daten reinschreibe nicht :(
FlowControl habe ich alle Optionen durchprobiert, das macht auch keinen Unterschied =/

Koschi

Alter Hase

Beiträge: 657

  • Private Nachricht senden

19

13.10.2015, 18:55

So wie es aussieht kommen die Daten in Richtiger Reihenfolge, das Endline Zeichen ist anscheinend '\r'
Die komplete Zeile könntest dir ja dann selber zusammen fügen.

Ich vermute mal das das Senden der Daten unterbrochen wird wenn andere Pakete empfangen werden, in der Zwischenzeit werden die Daten vom PC "abgeholt/eingelesen".
Dann wird wieder gesendet und das Ergebnis hast du vorliegen, aber wie gesagt, du könntest dir deine Zeile selber zusammen bauen.
Wer aufhört besser werden zu wollen hört auf gut zu sein!

aktuelles Projekt:Rickety Racquet

kylecorver

Frischling

  • »kylecorver« ist der Autor dieses Themas

Beiträge: 57

  • Private Nachricht senden

20

13.10.2015, 19:54

Dafür habe ich eigentlich extra die Methoden ReadLine() und WriteLine() im Zusammenhang mit dem NewLine-Attribut des SerialPorts benutzt. Hier mal Ausschnitte vom Code:

C#-Quelltext

 
1

static volatile SerialPort moPort;


Initialisierung:

C#-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11

moPort = new SerialPort("COM3");

moPort.BaudRate = 38400;
moPort.Parity = Parity.None;
moPort.DataBits = 8;
moPort.StopBits = StopBits.One;
moPort.NewLine = "\r";
moPort.Handshake = Handshake.RequestToSend;
moPort.ReadTimeout = 5000;

moPort.Open();


Write:

C#-Quelltext

 
1
2
3
4
5
6
7
8

for (; ; )
{
    foreach (string sPID in Car.getAvailablePIDs())
    {
        moPort.WriteLine("01 " + sPID);
        Thread.Sleep(50);
    }
}


Read-Thread:

C#-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12

for (; ; )
{
                string sResult;
                try
                {
                    sResult = moPort.ReadLine();
                }
                catch (TimeoutException)
                {
                    return;
                }
}


Die beiden Methoden WriteLine() und ReadLine() greifen beim Schreiben/Lesen auf das NewLine Attribut zu. Doku: https://msdn.microsoft.com/de-de/library…(v=vs.110).aspx

Werbeanzeige

Ähnliche Themen