Hallo Zusammen, bin gerade dabei, in einem Steuergerät XCP on TCP/IP zu implementieren bzw. in Betrieb zu nehmen. Das verfügbare Mess- und Calibriersystem ETAS INCA funktioniert aber nur eingeschränkt damit. Bei der Datenerfassung über XCP DAQ verliert es immer wieder DTOs weil angeblich der Counter nicht richtig ist. Mit Wireshark kann ich nachweisen, dass mein SG alle Nachrichten korrekt verschickt. Jetzt frage ich mich, ob ETAS oder ich die XCP-Spec falsch interpretiert. Dort steht: "To make optimal use of UDP/IP, multiple XCP Frames may be combined into a single UDP/IP frame, but an XCP Frame may not cross a UDP/IP frame boundary. The same XCP Frame format is used for the stream oriented protocol TCP/IP to simplify decoding the original XCP messages." Bei UDP kann demnach eine XCP-Nachricht nicht über eine UDP nachricht hinausgehen. Soweit logisch. Da TCP das Konzept der Nachricht eigentlich nicht kennt, würde ich nicht davon ausgehen, dass diese Einschränkung auch für die segmentierten Pakete bei TCP gilt. INCA meckert aber, wenn genau das passiert... Was meint Ihr?
Keiner? Kann man sich auf techischer Ebene irgendwie darauf verlassen, wie die Segmentierung erfolgt?
Interessant, ich meine dass selbe Problem auch bei meiner Toolchain beobachtet zu haben. Die Steuergeräteseite (TCP/IP + XCP) habe ich dabei implementiert, auf PC Seite läuft Vector CANape. Ab und zu taucht die Meldung auf dass DTOs verloren gegangen sind. Mangels Zeitgründen und weil es recht selten auftritt habe ich das Problem aber nie näher analysiert. Wenn ich deine Beschreibung richtig verstehe, so tritt das Problem immer dann auf, wenn du einen XCP Frame auf zwei TCP/IP Pakete aufteilst?
Bei mir ist es in der Tat so, dass auf einem PC ein TCP-Server läuft, der den Datenstrom vom SG verpackt und dann über WLAN weitergibt. Deshalb habe ich ohne größere Aufwände auch keine Möglichkeit weiter unten einzugreifen. INCA beschwert sich dann, das der Paket-Zähler nicht wie erwartet ist. Das passiert immer, wenn ein XCP-Paket die Grenzen eines TCP-Segments überschreitet. Das nächste ausgewertete XCP-Paket ist dann eines, was im übernächsten TCP-Segment liegt. D.h. INCA verwirft u.U. viele Bytes an Daten und mehrere XCP-Pakete aus dem Segment, das nicht mit einem XCP-Paket beginnt. Hab das probehalber mal auf UDP umgestellt, und da geht's besser. Allerdings ist UDP über WLAN auch nicht die reine Freude :(
Hmm du könntest versuchen deinen Server dazu zu bringen, für jeden XCP-Frame ein eigenes TCP/IP Paket zu verschicken. Also quasi hart das Versenden des TCP/IP Pakets zu triggern, sobald du einen XCP Frame dort reingelegt hast. Damit wird deine Ethernet Verbindung natürlich ineffizienter da viele kleinere TCP/IP Pakete verschickt werden, aber auf der anderen Seite sollte dein Problem zumindest behoben sein.
Wie mach ich das zuverlässig und mit vertretbarem Aufwand? Hab danach auch schon gesucht, aber die mehrheitliche Meinung war, dass man so ein Verhalten über Sockets nicht hinbekommt (und tiefer möchte ich eigentlich nicht gehen). Daher auch der Versuch mit UDP, wo man die einzelnen Telegramme verschicken kann. Allerdings gehen die über WLAN ab und an verloren :(
Das kann ich Dir leider auch nicht sagen. Wenn du jetzt ebenfalls den lwip Stack einsetzen würdest könnte ich Dir den Befehl dafür raussuchen, aber von Socketshabe ich keinen Plan. Schau doch mal ob etwas zum Nagle algorithmus findest, ich meine das ist der Teil der für das Bilden der Pakete zuständig ist (genau weiß ich das nciht mehr, ist schon ne Weile her). Wenn du den deaktivierst müsste theoretisch jeder Frame mit einem eigenen TCP/IP Paket verschickt werden.
Nachtrag: Grad mal nach nach "Nagle Algorithmus deaktivieren" gesucht: http://support.microsoft.com/kb/138831/de Das könnte tatsächlich helfen :-)
Nabend. bei TCP sollte doch ein Paketverlust doch eigentlich vom Protokoll her nicht möglich sein! Sollte sich mein gedächtniss mich nicht täuschen. UDP ist datenverlust möglich. und ggf auch gewünscht und tolleriert. Dafür schneller weil weniger overhead. Einsatz z.B. Audio und Video Streaming. Der stream darf nicht stocken, ein verlust einiger pakete ist tollerierbar. ggf kann der codec das wieder ausgleichen.
Hallo alle zusammen, ich arbeite momentan an einer XCP on Ethernet Verbindung und hab es geschafft mit CanApe und der Netzwerkkarte direkt den Slave anzusprechen. Nun würde es mich interessieren, ob dies auch mit INCA möglich ist, d.h INCA und der Netzwerkkarte direkt ohne zusätzliche ETAS Hardware über XCP on TCP/IP mit dem XCP Slave kommunizieren zu lassen? Ich hab auf der ETAS homepage gelesen, dass ich das XCP-IP integration package dazu benötige, jedoch nirgends Informationen für zusätzliche hardware gefunden. Kann mir dabei jemand helfen? Vielen Dank im Vorraus
Nachtrag: zu dem Thema mit den fehlenden DTO Packeten kann ich sagen, dass dies bei INCA auch mit XCP on CAN der Fall sein kann, wenn der RESUME mode im Slave aktiviert ist, d.h. durch INCA mit der Fast Measurement Methode getriggert wird. Ich glaube INCA hat da Probleme mit dem Timming. Ich hab den CAN bus analyziert, alle DTOs werden vom Slave gesendet, bloß INCA verliert anscheinend welche bei der Erfassung. Das interessante ist, dass das nur im RESUME mode der Fall ist. Bei der normalen dynamischen DAQ Konfiguration funktioniert alles einwandfrei. Arbeite mit INCA 7.0 HF 18
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.