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?
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.
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
