PureBoard

Verfasst: **04.03.2016 20:07**

Schönen guten Abend.

Zur Information, damit ein kleiner Einblick da ist wodrum es ungefähr geht ein Link zu meinem anderen Thread: http://purebasic.fr/german/viewtopic.php?f=16&t=29477

Dort geht es um die Kommunikation zu einem Simulator über einen Virtuellen Port

Ich habe bis jetzt damit weiter gearbeitet und dank der Hilfe aus dem Forum auch ohne Probleme.

Da ich nun endlich meine Kabel zugesendet bekommen habe (ELM327 v1.5 / OBD2 Diagnose), konnte ich nun mein Programm unter realen Bedingungen testen. Zu Testzwecken habe ich über ein bereits funktionierendes Diagnose Programm genommen um die Funktionalität des Kabels zu überprüfen, und es läuft tadellos. Danach habe ich über Putty/Termite bzw. Tera Term, also über einen Terminal versucht, die Daten die ich sonst über mein Programm an das Steugerät sende, zu verschicken. Ebenfalls mit vollen Erfolg, aber auch erst als ich die Baudrate auf 38400 gestellt habe.

Ich muss folgende Optionen benutzen:

Baudrate: 38400
Datenbits: 8
Stopbits: 1
Parität: Keine
Flow Control: Keine

Jedoch bekomme ich entweder von Purebasic nur an Daten zurück was ich selber gesendet habe, oder irgendein kompletten Müll in irgendwelchen Zeichen die nicht "erkannt" werden.

Der Code ist immernoch ganz normal:

Code: Alles auswählen

OpenSerialPort(0, "COM3", 38400, #PB_SerialPort_NoParity, 8, 1, #PB_SerialPort_NoHandshake, 1024, 1024)
 
   WriteSerialPortString(0,"0100"+#CRLF$)
    Delay(100)
     While AvailableSerialPortInput(0)>0
       If ReadSerialPortData(0,@Byte,1)    
         text.s=text.s+Chr(Byte)
       EndIf
     Wend
   Debug text

Ich hab erst gedach das ich vielleicht vorher ein bestimmte Protokoll einstellen und senden muss, da ich beim Zugriff über einen Terminal wie Putty aber auch nicht mehr eingeben brauch wie das, was ich senden will, gehe ich davon aus das irgendwie generell ein Fehler beim Senden besteht...

Muss ja ein Grund haben das es über Putty die Daten sendet die ich haben will aber über Purebasic nicht.

Mit freundlichen Grüßen
HHYayo

__________________________________________________
Link angepasst
04.03.2016
RSBasic

Verfasst: **04.03.2016 20:30**

Hallo HHYayo,

ich hab mir jetzt nicht den ganzen anderen Thread durchgelesen, aber meine Erfahrung hat gezeigt, dass das Arbeiten mit COM-Schnittstellen manchmal ein wenig tricky ist.

Wenn Du wirre Zeichen erhälst kann es an einer falschen Bautrate, falschem Parity oder auch falschen Handshake liegen.
Manchmal hilft es aber auch, das Kabel einfach nochmal heraus zu ziehen, den COM-Partner auszuschalten, das Kabel wieder anzuschließen, sicher stellen, dass Dein Programm bereit für die Kommunikation ist und dann den COM-Partner neu zu starten.

Falls das auch nicht hilft, hab ich Dir mal hier ein paar Ausschnitte zusammen gestellt, wie ich bei uns mit verschiedenen Waagen kommuniziere.
Mit dieser Methode klappt das bei uns nun zuverlässig. Vieles ist nur Drumherumgeplänkel für Debug-Zwecke etc., aber das Wichtigste dürftest Du erkennen können.

Der Code ist so nicht lauffähig, aber vielleicht bekommst Du ja da ein paar Ideen die Du bei Dir noch ändern könntest:

Code: Alles auswählen

Global	DebugMode = #False
Global	AktSchritt.f = 1
;Global	DebugMode = #True

#ComPort_Waage	= 3
#ComPort_Timer = 123

If DebugMode
	CreateDirectory("C:\Temp")
	OpenFile(222,"C:\Temp\ComPort.LOG", #PB_File_Append)
EndIf

#WaagenTyp_KPZ		= 1
#WaagenTyp_BOSCHE	= 2

#Wiegung_Mindestgewicht = 0.05

#DataBase_Main = 0

Global AktuellesGewicht.f = 0
Global AktuellerTARA.f
Global COM_PortName.s	= "COM1"
Global COM_Baud			= 9600
Global COM_Parity		= #PB_SerialPort_NoParity
Global COM_Bits			= 8
Global COM_Stop			= 1
Global COM_LenInputBuffer.l	= 200
Global COM_InputBuffer.s		= Space(COM_LenInputBuffer)
Global COM_BytesReceived.l
Global COM_ActLineText.s
Global COM_ActGewicht.f
Global COM_ActLineNumber.l
Global COM_LastLineNumber.l

; Global COM_WaagenTyp	= #WaagenTyp_KPZ
; Global COM_HShake		= #PB_SerialPort_NoHandshake

Global COM_WaagenTyp	= #WaagenTyp_BOSCHE
Global COM_HShake		= #PB_SerialPort_XonXoffHandshake

Global WiegungStabil = #True

If DebugMode
	OpenConsole()
	; PrintN("Bitte Handshaking auswählen:")
	; PrintN("--------------------------------------------")
	; PrintN(Str(#PB_SerialPort_NoHandshake)+" - #PB_SerialPort_NoHandshake")
	; PrintN(Str(#PB_SerialPort_RtsHandshake)+" - #PB_SerialPort_RtsHandshake")
	; PrintN(Str(#PB_SerialPort_RtsCtsHandshake)+" - #PB_SerialPort_RtsCtsHandshake")
	; PrintN(Str(#PB_SerialPort_XonXoffHandshake)+" - #PB_SerialPort_XonXoffHandshake")
	; PrintN("")
	; COM_HShake = Val(Input())
EndIf

Procedure	DebugN(Value.f)
	Debug Value.f
	If DebugMode
		PrintN(StrF(Value))
	EndIf
EndProcedure

Procedure	DebugS(Value.s)
	Debug Value.s
	If DebugMode
		PrintN(Value)
		WriteStringN(222, FormatDate("%hh:%ii:%ss - ", Date()) + Value)
	EndIf
EndProcedure

Global COMPort_OK = #True
If Not OpenSerialPort(#ComPort_Waage, COM_PortName, COM_Baud, COM_Parity, COM_Bits, COM_Stop, COM_HShake, 1024, 1024)
	MessageRequester("FEHLER !!!", "Der Zugriff auf die serielle Schnittstelle '"+COM_PortName+"' ist fehlgeschlagen !!!"+#CR$+#CR$+"Es können somit keine Daten von der Seriellen-Schnittstelle abgerufen werden.", #PB_MessageRequester_Ok)
	COMPort_OK = #False
EndIf

If DebugMode
	
	DebugS("COM-Port gefunden: "+Str(COMPort_OK))
	
	Select COM_HShake
		Case #PB_SerialPort_NoHandshake
			DebugS("Handshaking: #PB_SerialPort_NoHandshake")
		Case #PB_SerialPort_RtsHandshake
			DebugS("Handshaking: #PB_SerialPort_RtsHandshake")
		Case #PB_SerialPort_RtsCtsHandshake
			DebugS("Handshaking: #PB_SerialPort_RtsCtsHandshake")
		Case #PB_SerialPort_XonXoffHandshake
			DebugS("Handshaking: #PB_SerialPort_XonXoffHandshake")
		Default
			DebugS("Unbekanntes Handshaking: "+Str(COM_HShake))
	EndSelect
	
EndIf

; --- Wenn COM-Port geöffnet werden konnte, dann iniziiere den Timer zur Auslesen des COM-Ports

If COMPort_OK
	AddWindowTimer(#Window_Main, #ComPort_Timer, 100)
EndIf


; --- Event Loop mit permanenter Abfrage des Seriellen Ports


Repeat		;{ ----- Haupt Event-Schleife
	
	Define event = WaitWindowEvent()
	Select event
			
		Case #PB_Event_Timer
			
			If EventTimer() = #ComPort_Timer
				
				; ---- ALLE Daten aus dem Serial-Port auslesen  (solange bis er leer ist) ---
				
				If AvailableSerialPortInput(#ComPort_Waage)  Or AktuellesGewicht < 1
					
					COM_ActLineText = ""
					
					While AvailableSerialPortInput(#ComPort_Waage)
						
						If AvailableSerialPortInput(#ComPort_Waage) < COM_LenInputBuffer
							COM_BytesReceived = ReadSerialPortData(#ComPort_Waage, @COM_InputBuffer, AvailableSerialPortInput(#ComPort_Waage))
						Else
							COM_BytesReceived = ReadSerialPortData(#ComPort_Waage, @COM_InputBuffer, COM_LenInputBuffer)
						EndIf
						COM_ActLineText + PeekS(@COM_InputBuffer, COM_BytesReceived)
					Wend
					
					COM_ActLineText = "US,GS,    28.4KG"+#CRLF$+""+#CRLF$+"  28.8KG"+#CRLF$+"ST,GS,    28.8KG"
					
					Select COM_WaagenTyp
							
						Case #WaagenTyp_KPZ		; --- Datenauswertung für eine K-PZ Waage ---
							
							Define ActCOMLine.s = COM_ActLineText
							
							While Len(ActCOMLine)
								
								COM_ActLineText = StringField(ActCOMLine, 1, #CRLF$)
								ActCOMLine = Mid(ActCOMLine, Len(COM_ActLineText)+3)
								
								If Len(COM_ActLineText) > 9
									
									COM_ActLineNumber		= Val(Left(COM_ActLineText,4))
									
									If COM_ActLineNumber > 0 And COM_ActLineNumber <> COM_LastLineNumber								
										COM_ActGewicht	= ValF(Trim(Mid(COM_ActLineText,5)))
										COM_LastLineNumber = COM_ActLineNumber
										AktuellesGewicht = COM_ActGewicht
										Setze_Aktuelles_Gewicht(AktuellesGewicht)
										; Beep_(2000,200)
									Else
										If FindString(COM_ActLineText,"S/N") : COM_LastLineNumber = 0 : EndIf
									EndIf
								EndIf
								
								DebugS(Str(Len(COM_ActLineText))+"  '"+COM_ActLineText+"'   - "+Str(COM_LastLineNumber))
								
							Wend
							
							
						Case #WaagenTyp_BOSCHE		; --- Datenauswertung für eine BOSCHE Waage ---
							
							Define ActCOMLine.s = COM_ActLineText
							
							While Len(ActCOMLine)
							  
							  COM_ActLineText = StringField(ActCOMLine, 1, #CRLF$)
							  ActCOMLine = Mid(ActCOMLine, Len(COM_ActLineText)+3)
							  
							  If Left(COM_ActLineText,3) = "ST," Or Left(COM_ActLineText,3) = "US,"
							    
							    WiegungStabil = #False	:	If StringField(COM_ActLineText,1,",") = "ST" : WiegungStabil = #True : EndIf
							    
							    COM_ActLineText = Trim(StringField(COM_ActLineText,3,","))		; Gewicht herausfiltern, z.B.:  "28.8KG"
							    
							    If Right(COM_ActLineText,2) = "KG"
							      
							      AktuellesGewicht = ValD(COM_ActLineText)
							      
							      Setze_Aktuelles_Gewicht(AktuellesGewicht)
							      
							      DebugS("Neues Gewicht: " + Str(Len(COM_ActLineText))+"  '"+COM_ActLineText+"'   - "+Str(COM_LastLineNumber)+"  -  Akt. Gewicht: "+StrD(AktuellesGewicht,2))
							      
							    Else
							      DebugS("ST/US, aber KG falsch: " + Str(Len(COM_ActLineText))+"  '"+COM_ActLineText+"'   - "+Str(COM_LastLineNumber)+"  -  Akt. Gewicht: "+StrD(AktuellesGewicht,2))
							    EndIf
							  EndIf
							  ;Delay(1000)
							  
							Wend
							
					EndSelect
					
					DebugS(Str(Len(COM_ActLineText))+"  '"+COM_ActLineText+"'   - "+Str(COM_LastLineNumber)+"  -  Akt. Gewicht: "+StrD(AktuellesGewicht,2))

				EndIf
				
			EndIf
	EndSelect
	
Until Window_Main_Events(event) = #False		;}

Grüße und viel Glück,
PL.

Verfasst: **04.03.2016 21:10**

PureLust hat geschrieben:Hallo HHYayo,

ich hab mir jetzt nicht den ganzen anderen Thread durchgelesen, aber meine Erfahrung hat gezeigt, dass das Arbeiten mit COM-Schnittstellen manchmal ein wenig tricky ist.

Wenn Du wirre Zeichen erhälst kann es an einer falschen Bautrate, falschem Parity oder auch falschen Handshake liegen.
Manchmal hilft es aber auch, das Kabel einfach nochmal heraus zu ziehen, den COM-Partner auszuschalten, das Kabel wieder anzuschließen, sicher stellen, dass Dein Programm bereit für die Kommunikation ist und dann den COM-Partner neu zu starten.

Falls das auch nicht hilft, hab ich Dir mal hier ein paar Ausschnitte zusammen gestellt, wie ich bei uns mit verschiedenen Waagen kommuniziere.
Mit dieser Methode klappt das bei uns nun zuverlässig. Vieles ist nur Drumherumgeplänkel für Debug-Zwecke etc., aber das Wichtigste dürftest Du erkennen können.

Der Code ist so nicht lauffähig, aber vielleicht bekommst Du ja da ein paar Ideen die Du bei Dir noch ändern könntest

Ich muss mich bei dir für den Code bedanken!

Alleine wege den Fehlerhandling wird der für mich nützlich sein, da sind definitiv einige Sachen bei die ich gebrauchen könnte. Gerade wenn es denn doch komplexer wird.

Ich habe versucht die Protokolle zu ändern, irgendwann habe ich gemerkt das ich beim Senden von "AT SP 4" (Entsprechernd vom Protokoll des Autos) vollkommen normale Werte erhalte. So bin ich auf den Fehler gekommen, wieso ich lediglich nur den Wert erhale den ich selber absende...

100ms waren einfach zu kurz, die ich gegeben hatte um Daten zu senden und zu empfangen

Zwischen 150ms und 200ms erhalte ich den kompletten Datensatz (Dabei konnte ich mich auch grob dran erinnern das ich gelesen hatte bei mp3car, dass 200ms akzeptabel sind).

Darauf muss man auch erstmal kommen, da der Simulator natürlich mit der gegebenen Zeit klar kam.

Mit freundlichen Grüßen
HHYayo

Verfasst: **04.03.2016 22:04**

Bitte nicht immer ganze Codes in Zitaten mitschleppen, das macht das Lesen solcher Threads unnötig anstrengend.

Mir scheint Du kommst aus der Mikrocontroler-Ecke?
Du benutzt nach wie vor diesen völlig unbrauchbaren Code, sorry, ist aber so.

Du musst bedenken, dass Windows im Gegensatz zu einem Mikrocontroler ein Multitasking System ist.
Es kann sein, dass Du nebenher einen Film mit 8GB entpackst und/oder dein Antivir eine verdächtige Datei scannt, entsprechend wenige Resourcen werden dann Deinem Programm zugewiesen und schwupps, genügt nicht mal mehr ein Delay(200) (und nein, ein Delay(200) bedeutet auch nicht, dass das Programm genau 200ms wartet).
Windows stellt extra einen Puffer bereit, du holst die Daten dort einfach ab, wenn sie da sind (oder auch später) und nicht stur nach irgendeinem Delay.

Verfasst: **04.03.2016 22:33**

HeX0R hat geschrieben:Bitte nicht immer ganze Codes in Zitaten mitschleppen, das macht das Lesen solcher Threads unnötig anstrengend.

Mir scheint Du kommst aus der Mikrocontroler-Ecke?
Du benutzt nach wie vor diesen völlig unbrauchbaren Code, sorry, ist aber so.

Du musst bedenken, dass Windows im Gegensatz zu einem Mikrocontroler ein Multitasking System ist.
Es kann sein, dass Du nebenher einen Film mit 8GB entpackst und/oder dein Antivir eine verdächtige Datei scannt, entsprechend wenige Resourcen werden dann Deinem Programm zugewiesen und schwupps, genügt nicht mal mehr ein Delay(200) (und nein, ein Delay(200) bedeutet auch nicht, dass das Programm genau 200ms wartet).
Windows stellt extra einen Puffer bereit, du holst die Daten dort einfach ab, wenn sie da sind (oder auch später) und nicht stur nach irgendeinem Delay.

Ich beschäftige mich eher mit der Leistungsoptimierung von Fahrzeugen, mit Mikrocontroler habe ich noch nie was zu tun gehabt (Ich weiß aber worauf du hinaus willt).

Ich hatte deinen Code übernommen gehabt falls du darauf hinaus willst, da ich ja selber erwähnt hatte das ich große Probleme hatte auch ein Auge auf die Auslastung bzw. der Effizienz des Programmes zu werfen, was man alleine an meiner Dateikonstruktion sehen konnte um die letzten Bytes zu filtern, statt eine einzige Zeile Code zu nutzen.

Derzeitig funktioniert so nun alles!

Mit freundlichen Grüßen
HHYayo

Verfasst: **04.03.2016 23:04**

HHYayo hat geschrieben:Ich hatte deinen Code übernommen gehabt falls du darauf hinaus willst, [...]

Nein, nein, das war nicht meine Absicht.
Ehrlich gesagt denke ich eh nicht, dass der Code auf Anhieb funktioniert.
Meine Erfahrung hat gezeigt, dass Programme, die per RS232 auf externe Hardware zugreifen erst durch jede Menge Trial&Error zielführend sind

Aber zumindest hätte ich erwartet, dass Du Dir Teile davon näher betrachtest und entsprechend verwendest.
Probleme wird es noch genug geben, dann sollte aber wenigstens die Datenübermittlung stabil ausprogrammiert sein.

Wo hast Du denn OBD Protokollinfos her?
[Edit]
O.k. vergiss die Frage, findet man ja doch so einiges im Netz... interessant

Ich habe hier auch noch einen OBD2 Adapter, der arbeitet allerdings per Bluetooth.

Verfasst: **06.03.2016 19:23**

HeX0R hat geschrieben:
HHYayo hat geschrieben:Ich hatte deinen Code übernommen gehabt falls du darauf hinaus willst, [...]
Nein, nein, das war nicht meine Absicht.
Ehrlich gesagt denke ich eh nicht, dass der Code auf Anhieb funktioniert.
Meine Erfahrung hat gezeigt, dass Programme, die per RS232 auf externe Hardware zugreifen erst durch jede Menge Trial&Error zielführend sind

Aber zumindest hätte ich erwartet, dass Du Dir Teile davon näher betrachtest und entsprechend verwendest.
Probleme wird es noch genug geben, dann sollte aber wenigstens die Datenübermittlung stabil ausprogrammiert sein.

Wo hast Du denn OBD Protokollinfos her?
[Edit]
O.k. vergiss die Frage, findet man ja doch so einiges im Netz... interessant

Ich habe hier auch noch einen OBD2 Adapter, der arbeitet allerdings per Bluetooth.

Dein Code hat auf Anhieb funktioniert!

Ich habe diesen nur kurzzeitig hier nicht verwendet, weil ich erstmal schauen wollte ob ich überhaupt eine anständige Verbindung aufgebaut bekomme und Daten senden und empfangen kann.

Die Informationen zu den Protokollen habe ich aus einer ziemlich umfangreichen .PDF, also eine Manual die von den Herstellern des ELM327 Adapters selbst zum Download freigegeben wurden. Dort wird so ziemlich alles von A-Z aufgelistet, natürlich auch bereits bekannte Dinge wie die ganzen PID's und die entsprechende Verwendung.

Für die Bluethooth Variante habe ich mich bewusst nicht entschieden, da viele Fahrzeuge in Gegensatz zu der USB-Version nicht kompatibel zu sein scheinen. Bisher habe ich auch keine Probleme sonst gehabt, weder mit CAN-BUS noch mit KWP.

Nachtrag:

Ich habe derzeitig noch ein anderes Problem im Bezug auf das Empfangen der Daten vom Steuergerät. Ich habe es ja wie schon bereits erwähnt geschafft die Werte richtig zu empfangen. Nun habe ich versucht diese Werte entsprechend zu vearbeiten, leider schaffe ich es nicht mir entsprechend die Bytes anzeigen zu lassen die ich möchte. Über den Simulator scheint die Ausgabe immer dieselbe zu sein, doch bei dem echten Steuergerät bekomme ich zwar auch diese Daten, jedoch angehangen an die Daten zuvor. Das heißt das Filtern mit Right und StringField funktioniert nicht mehr, da der Index sich stetig verändert. Auch das Filtern des Puffers funktioniert nicht mehr, da sich meine gewünschten Werte nicht mehr an derselben Stelle befinden.

Das Problem ist also das der Buffer "Byte" nicht einzig und allein den Neuen, sondern auch den alten Inhalt ausgibt:

010D
41 01 00 00

>010D
41 01 00 00

>010D
41 01 00 00

>010D
41 01 00 00

>

...

Wie bekomme ich nun hin das ich wieder nur noch die neuen Werte aus dem Buffer des Serial Ports erhalte ?

Sprich nur:

010D
41 01 00 00

>

Mit freundlichen Grüßen
HHYayo

Verfasst: **06.03.2016 19:41**

Das liegt nicht am RS232 Puffer, sondern am Code.
Wie sieht der denn mittlerweile aus?

Verfasst: **06.03.2016 19:47**

HHYayo hat geschrieben:Wie bekomme ich nun hin das ich wieder nur noch die neuen Werte aus dem Buffer des Serial Ports erhalte ?

Code: Alles auswählen

; ----- Test-Text erzeugen ...

Text$ = "010D"+#CR$+"41 01 00 00"+#CR$+#CR$+">"
Text$ + "010D"+#CR$+"41 01 00 01"+#CR$+#CR$+">"
Text$ + "010D"+#CR$+"41 01 00 02"+#CR$+#CR$+">"
Text$ + "010D"+#CR$+"41 01 00 03"+#CR$+#CR$+">"

; ----- Letzten Eintrag aus aktuellem Text heraus filtern

If Right(Text$,1) = ">" : Text$ = Left(Text$, Len(Text$)-1) : EndIf
LastText$ = StringField(">"+Text$, CountString(Text$, ">")+2, ">")
Debug LastText$

Verfasst: **06.03.2016 22:16**

PureLust hat geschrieben:

HHYayo hat geschrieben:Wie bekomme ich nun hin das ich wieder nur noch die neuen Werte aus dem Buffer des Serial Ports erhalte ?

Code: Alles auswählen

; ----- Test-Text erzeugen ...

Text$ = "010D"+#CR$+"41 01 00 00"+#CR$+#CR$+">"
Text$ + "010D"+#CR$+"41 01 00 01"+#CR$+#CR$+">"
Text$ + "010D"+#CR$+"41 01 00 02"+#CR$+#CR$+">"
Text$ + "010D"+#CR$+"41 01 00 03"+#CR$+#CR$+">"

; ----- Letzten Eintrag aus aktuellem Text heraus filtern

If Right(Text$,1) = ">" : Text$ = Left(Text$, Len(Text$)-1) : EndIf
LastText$ = StringField(">"+Text$, CountString(Text$, ">")+2, ">")
Debug LastText$

Scheint zu funktionieren, LastText$ gibt denn folgendes aus:

010D
41 01 00 03

wodurch ich denn durch folgende Ergänzung meine "gewünschten" Wert 03 erhalte:

Code: Alles auswählen

 
LastText$+#CR$
Val("$"+Right(LastText$,5))

Gerade am laufenden Fahrzeug getestet und funktioniert, muss nur mal schauen ob ich das ganze alles noch ein wenig schneller gestalten kann. Im Stand müsste entsprechend der Wert 00 sein, da die Geschwindigkeit natürlich auch 0 ist. Wenn ich jetzt jedoch die Zeit auf 200ms runterstelle, kommt er auf die Idee mir den Wert 269 auszugeben, was garnicht möglich ist da eigentlich der maximalwert FF oder umgerechnet 255 sein kann. Sobald ich dies wieder auf 350-400ms stelle bleibt er bei 0 bzw. passt sich der Geschwindigkeit an.

Reicht die Baudrate von 38400 nicht aus, oder kommt das Steuergerät einfach nicht hinterher bei so vielen Anfragen alle 200ms ?

Mit freundlichen Grüßen
HHYayo

PureBoard

Daten von einen Motorsteuergerät empfangen (Serial Port)

Daten von einen Motorsteuergerät empfangen (Serial Port)

Re: Daten von einen Motorsteuergerät empfangen (Serial Port)

Re: Daten von einen Motorsteuergerät empfangen (Serial Port)

Re: Daten von einen Motorsteuergerät empfangen (Serial Port)

Re: Daten von einen Motorsteuergerät empfangen (Serial Port)

Re: Daten von einen Motorsteuergerät empfangen (Serial Port)

Re: Daten von einen Motorsteuergerät empfangen (Serial Port)

Re: Daten von einen Motorsteuergerät empfangen (Serial Port)

Re: Daten von einen Motorsteuergerät empfangen (Serial Port)

Re: Daten von einen Motorsteuergerät empfangen (Serial Port)