' schrieb:Es ist doch so, wenn ich sage lese 3 Byte und Serial-Port ist konfiguriert auf Baudrate,8Bit, usw. dann sorgt doch der darunterliegende Treiber (VISA,OS/Kernel) dafür, das die Daten nochmals angefordert werden
Was heißt "nochmals angefordert"?
Es handelt ich hier - wahrscheinlich - nur um den ganz ordinären RS232-Treiber (ob der vom Betriebssystem gemacht wird oder von einem Softwareteil von NI ist dabei egal). Dieser Treiber ließt die Daten aus dem Hardwarepuffer aus (und schreibt ggf. da hinein). Die gelesenen Daten werden zwischengelagert. Kommt nun jemand her und verlangt 3 Zeichen, werden die aus dem Zwischenspeicher herausgeholt und weitergegeben. Ob das richtige Daten sind (Bitkombination) oder ob da eines fehlt (z.B. das M-Byte) weiß der Treiber nicht. Zum M-Byte wird ein Zeichen erst in der Applikation, nicht im Treiber. Der Treiber erkennt nur die von dir angesprochenden Parityerror etc. Wenn also jemand 3 Zeichen verlangt, gibt der Treiber drei weiter oder wartet, bis er selbst drei hat. Eine Anforderung nach draußen an irgendwen, jetzt drei Zeichen zu senden, das macht der Treiber nicht. Ein solches Verhalten würde eine/einige Stufen (OSI-7-Schichtenmodell) höher liegen.
Zitat:Ich habe schon viele Serielle Komunikationen gemacht, aber solche Fehler habe ich noch nie festgestellt.
Naja, 112KB ist nicht wenig. Da muss das Kabel schon entsprechend gut abgeschirmt sein. Und auch die Treiberschaltungen (Hardware) sollten noch gut sein (was bei den Onboard-Schnittstellen nicht immer der Fall ist).
[*grübel*]
Aber so viele fehlende Daten wie hier sollten nicht auftreten. Bei einem meiner Prüfstände mit zwölf seriellen Schnittstellen mit jeweils 112kB treten so gut wie keine Fehler auf. Möglicherweise sollte Achim mal die Anzahl der Stoppbits überprüfen.
Zitat:Kann es sein, dass das gar keine richtige serielle Kommunikation ist.
Eine richtige würde ich schon sagen. Bei einer Adaption von RS485 (Endgerät) auf RS232 (PC) alleine mit Verdrahtung könnte ich mir aber diese Fehleranzahl vorstellen.