Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich versuche mit LabVIEW mit dem OBD Chip über die serielle Schnittstelle zu kommunizieren.
Mit Hyperterminal gibt es keine Probleme, also auf des Kommando atz (reset) meldet sich der Chip mit seiner Firmwareversion.
Wenn ich das vom LabVIEW mach bekome ich nur Müll, da gibt es bestimmt noch irgendwelche Zeichen die ein Hyperterminal sendet, oder nicht?
Und es wird auch seltsam, wenn ich die Übertragungsrate nach oben setze auf 38400 (das habe ich im Hyperterminal eingestellt) bekomme ich nur das Echo.
20.01.2010, 07:35 (Dieser Beitrag wurde zuletzt bearbeitet: 20.01.2010 08:20 von Y-P.)
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
Kommunikation über RS232 mit ELM327
Hast Du auch das Trennzeichen verwendet, das Dein Gerät möchte, also z.B. ein Carriage Return,...?
Du kannst ja mal genau schauen, was Dein Hyperterminal sendet (HEX-mäßig), dann siehst Du anhand einer ASCII-Tabelle gleich, was für ein Trennzeichen Du hast und ob Du Deinen Befehl überhaupt richtig schickst.
Gruß Markus
EDIT: Ich ändere Dir mal den Thementitel von RS323 in RS232. Das tut mir in den Augen weh.
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
Es ist definitiv ein CR.
Ich habe für Testzwecke 2 PCs miteinander verbunden, und das was ich vom Vi sende ist exakt das selbe was der Hyperterminal sendet.
Es muss also daran liegen wie die Antwort gelesen wird, aber warum bekomme ich dann das Echo als Antwort?
Ich habe auch versucht die Zeichen einzeln zu verschicken (der HypTerm machts auch so) aber das Ergebnis ist auch gleich, es liegt also ganz sicher nicht am Senden.
Danke,
ich habe jetzt auch schon mal ein Teilerfolg und zwar durch eine Schleife die die Daten ausliest.
Allerdings bekomme ich nur einen Teil der Antwort, egal was ich einstelle, ich bekomme nie den gesamten String.
Die Anzahl der Bytes die das System ausspuckt ist ja auch Mist, da steht 5 und es sind doch 12 + CR.
Wenn ich an den Parametern drehe Anzahl For Loops und Anzahl Bytes beim Serial Reed, bekomme ich immer einen Bereich aus den String, entweder den vorderen Teil oder mittleren oder das Ende, aber maximal 4 Bytes.
Wie muss es richtig ausgelesen werden und wie soll man das verstehen was da passiert?
Wenn du den TerminationChar im VISA Config aktiviert hast, dann brauchst du den beim Senden einen Befehls nicht selber zum zu sendenden String hinzufügen. Das macht VISA für dich.
Wenn die Antworten ebenfalls immer mit einem <CR> abgeschlossen sind, dann kannst du beim READ-Befehl bei Read-Count auch einfach eine sehr große Zahl anschließen (z.B. 1000), VISA-Read liest dann einen String ein, bis es den TerminationChar entdeckt.
Weitere Tests: Wenn der Bytes at Port 5 liefert, wieso liest du dann 4 Zeichen ein? Und wenn du aktuell mehrere Lesevorgänge in eine Schleife gepackt hast, dann lass dir alle ausgelesenen String in einem Array anzeigen, nicht nur den letzten. Du weißt aktuell gar nicht, was bei den ersten Lesevorgängen raus gekommen ist.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Das mit dem Array war ne gute Idee, ich sehe auf jeden Fall mehr, aber es fehlen trotzdem einige Buchstaben und das Echo sollte eigentlich auch nicht da sein.
Wenn ich den CR (den ich manuell noch dazugebastelt habe) beim senden weglasse, dann passiert garnichts, dass vi läuft ohne anzuhalten (irgendwo in einer Endlossleife)
und ich bekomme gar keine Ergebnisse, also muss woll das Senden ein Problem haben.
20.01.2010, 14:09 (Dieser Beitrag wurde zuletzt bearbeitet: 20.01.2010 14:30 von pgl_bear.)
ach so und wenn ich die 4 (Anzahl Bytes zu lesen) auf 20, 30 oder mehr setze dann ist das Array komplett leer.
Das ELM habe ich auch gefunden, es ist in der Zelle über 327 aber mir einem CR davor, deshalb sieht man es nicht.
Wie auch immer, da sind zu viele CR dazwischen, es muss wahrscheinlich ein Überbleibsel vom Senden sein
und so oder so ist es keine Lösung, weil atz nur ein Befehl ist und ich muss alle Befehle mit unterschiedlichen Antworten behandeln können
21.01.2010, 06:30 (Dieser Beitrag wurde zuletzt bearbeitet: 21.01.2010 06:47 von pgl_bear.)
ich komme der Lösung langsam näher, ich habe mir einen Portmonitor installiert damit ich sehe was da passiert.
Nach dem Senden des Befehls kommt die ganze Antwort sofort zurück nur das auslesen des Buffert im LabVIEW ist problematisch der zurückkommende String sieht etwa so aus:
<das Echo>0D 0A<die eigentliche Info>0D 0A 0D 0A 3E
ich lese jetzt in einer while schleife Byteweise aus und wollt die Schleife verlassen wenn sie am 3E angekommen ist, aber das funktioniert irgendwie nicht,
die ganzen 0D und 0A bringen das VISA Read durcheinander,
ich dachte dass ich einfach auf das zweite 0D warte, aber wie sage ich der while Schleife dass sie das zweite Zeichen nehmen soll und nicht das erste?
Wenn ich die while Schleife auf das erste 0D verlasse funktioniert es - nur dann fehlen mir die Daten,
wenn ich 0D 0A zum verlassen der Schleife angebe - Endlosschleife ....... Warum das?
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
Kommunikation über RS232 mit ELM327
Mach' mal was Jens schon gesagt hat und lass' das Carriage Return an Deinem Befehl oder das Carriage Return an Deinem Konfigurationseingang weg.
Doppelt macht keinen Sinn und kann zu Problemen führen. Wenn das nicht hilft, dann sag' nochmal genau, was nicht passt.
Gruß Markus
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------