Problem mit serieller Schnittstelle - Datenverlust

[Martin Eckel]

Hallo,

ich habe hier ein Projekt, welche relativ große Datenmengen über die
serielle Schnittstelle empfängt.

Dazu benutze ich System.IO.Ports - leider kommt es ab und an zu
Datenverlusten.
Seltsamerweise sind diese Datenverluste abhängig von den Daten - die
Datenmenge ist immer gleich, das ist kein Problem. Aber bei bestimmten
Meßsignalen fehlen einfach einige Bytes.

Zum Auslesen benutze ich SerialPort.Read in ein Byte-Array, so sollte es
nach meinem Verständnis kein Problem mit Codierungseinstellungen geben.
DiscardNull steht auch auf False.


Wenn ich die serielle Schnittstelle wie unter VB6 direkt mittels API
ansteuere, so habe ich dieses Problem nicht. Leider kommt es aber bei
der direkten API-Ansteuerung zu Instabilitäten beim Programmablauf, was
mir nicht wirklich klar ist.


Mein Entwicklungssystem ist VS2008.

Jemand eine Idee, wo meine Bytes verlustig gehen?

Gruß,
Martin

[Armin Zingler]

Post by Martin Eckel
Hallo,
ich habe hier ein Projekt, welche relativ große Datenmengen über die
serielle Schnittstelle empfängt.
Dazu benutze ich System.IO.Ports - leider kommt es ab und an zu
Datenverlusten.
Seltsamerweise sind diese Datenverluste abhängig von den Daten - die
Datenmenge ist immer gleich, das ist kein Problem. Aber bei bestimmten
Meßsignalen fehlen einfach einige Bytes.
Zum Auslesen benutze ich SerialPort.Read in ein Byte-Array, so sollte es
nach meinem Verständnis kein Problem mit Codierungseinstellungen geben.
DiscardNull steht auch auf False.
Wenn ich die serielle Schnittstelle wie unter VB6 direkt mittels API
ansteuere, so habe ich dieses Problem nicht. Leider kommt es aber bei
der direkten API-Ansteuerung zu Instabilitäten beim Programmablauf, was
mir nicht wirklich klar ist.
Mein Entwicklungssystem ist VS2008.
Jemand eine Idee, wo meine Bytes verlustig gehen?

Ohne etwas Code zu sehen, wie die Daten empfangen und weiterverarbeitet
werden und woran du erkennst, dass Daten fehlen ist das schwer zu sagen.


Armin

[Martin Eckel]

Post by Armin Zingler
Ohne etwas Code zu sehen, wie die Daten empfangen und weiterverarbeitet
werden und woran du erkennst, dass Daten fehlen ist das schwer zu sagen.

Die Weiterverarbeitung ist völlig identisch beim Zugriff über NET und API.

Erkennen daß Daten fehlen tu ich daran, daß es zu wenige sind.

Ganz einfach, beim API-Zugriff mach ich ein ReadFile mit OVERLAPPED-IO,
bis alle Daten angekommen sind.

Beim Zugriff über NET lese ich über SerialPort.Read immer alle
vorhandenen Daten aus und zwar gleich an die richtige Stelle des
Byte-Array, so daß ich am Ende alle Daten im Byte-Array habe.
Aber es fehlen halt manchmal welche.

Aber auch wenn ich den Port-Empfangsbuffer so groß mache, daß alle Daten
rein passen, und warte, bis alle Daten im Buffer sind und sie erst dann
auslese, so kommen im Zweifelsfall nicht alle Daten an.

Die ganze Geschichte ist 100pro Daten abhängig - bei bestimmten Daten
gehen absolut sicher welche verloren über NET (aber nicht über API), bei
anderen Daten (gleiche Datenanzahl) gehts 100pro glatt.

Da es sich jedoch um Meßwerte handelt, welche nicht jedesmal absolut
gleich sind, kann ich so ohne weiteres gar nicht sagen, welche Werte fehlen.


Irgendwo gibt es definitiv einen Unterschied, wie die Daten über NET
oder über API kommen. Und der Datenverlust hat mit Sicherheit nichts mit
überlaufenden Buffern o.ä. zu tun (ich habe das schon tagelang getestet).

Ich habe mir schon die Augen viereckig gelesen, ob die Daten beim
Zugriff über NET noch irgendwie verarbeitet werden (vielleicht gibts ja
irgendeine Code-Folge, die irgendwas bedeutet??) aber ich habe nichts
gefunden.

Ich kann aber Montag gern noch mal ein Code-Fragment reinstellen.


Gruß,
Martin

[Peter Götz]

Hallo Martin,

Post by Martin Eckel
Die Weiterverarbeitung ist völlig identisch beim Zugriff
über NET und API.
Erkennen daß Daten fehlen tu ich daran, daß es zu
wenige sind.
Ganz einfach, beim API-Zugriff mach ich ein ReadFile mit
OVERLAPPED-IO, bis alle Daten angekommen sind.
Beim Zugriff über NET lese ich über SerialPort.Read immer
alle vorhandenen Daten aus

Alle vorhandenen Daten müssen nicht unbeding alle Daten sein.
Wan das Ereignis DataReceived ausgelöst wird ist abhängig
von SerialPort.ReceivedBytesThreshold.
Wie hast Du .ReceivedBytesThreshold eingestellt?

Post by Martin Eckel
und zwar gleich an die richtige Stelle des Byte-Array, so daß
ich am Ende alle Daten im Byte-Array habe.

Meinst Du damit etwas in der Art:

dim NumBytes as Integer
dim bArray(999) as Byte
dim Offset as integer = ...
dim Count as integer = ...

NumBytes = SerialPort.Read(bArray, Offset, Count)

Oder liest Du byteweise per SerialPort.ReadByte?

Post by Martin Eckel
Aber es fehlen halt manchmal welche.
Aber auch wenn ich den Port-Empfangsbuffer so groß
mache, daß alle Daten rein passen,

Weisst Du denn im Voraus, wieviele Bytes zu
erwarten sind?
Oder welches Endekriterium gibt es sonst?

Post by Martin Eckel
und warte, bis alle Daten im Buffer sind und sie erst dann
auslese, so kommen im Zweifelsfall nicht alle Daten an.

Wie schon gesagt, ohne zu wissen, wie die Eigenschaften
Deines Serialport-Objektes konkret eingestellt sind und
welche Lesemethode Du verwendest, kann man nur spekulieren.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Martin Eckel]

Post by Peter Götz
dim NumBytes as Integer
dim bArray(999) as Byte
dim Offset as integer = ...
dim Count as integer = ...
NumBytes = SerialPort.Read(bArray, Offset, Count)

Genau so siehts aus.

Post by Peter Götz
Weisst Du denn im Voraus, wieviele Bytes zu
erwarten sind?

Ja, ich weiß vorher wieviele es sind. Es sind immer gleich viele. Sie
kommen immer gleich schnell. Und da es mit bestimmten Daten 100pro
funktioniert, kann es nicht an Geschwindigkeit oder Buffergröße liegen.
Es liegt mit absoluter Sicherheit an den Daten selber.

Post by Peter Götz
Wie schon gesagt, ohne zu wissen, wie die Eigenschaften
Deines Serialport-Objektes konkret eingestellt sind und
welche Lesemethode Du verwendest, kann man nur spekulieren.

Ich werde Montag, wenn ich wieder am Arbeitsplatz bin, ein genaues
Code-Fragment mitbringen ;-)

Gruß,
Martin

[Peter Götz]

Hallo Martin,

Post by Martin Eckel

Post by Peter Götz
dim NumBytes as Integer
dim bArray(999) as Byte
dim Offset as integer = ...
dim Count as integer = ...
NumBytes = SerialPort.Read(bArray, Offset, Count)

Genau so siehts aus.

Und ist dann NumBytes = Count?

Post by Martin Eckel

Post by Peter Götz
Weisst Du denn im Voraus, wieviele Bytes zu
erwarten sind?

Ja, ich weiß vorher wieviele es sind. Es sind immer gleich
viele. Sie kommen immer gleich schnell.

Was meinst Du mit "gleich schnell".
Woher willst Du wissen wie schnell, bzw. zu welchem
Zeitpunkt die Gegenstelle Daten sendet?

Post by Martin Eckel
Und da es mit bestimmten Daten 100pro funktioniert, kann
es nicht an Geschwindigkeit oder Buffergröße liegen.
Es liegt mit absoluter Sicherheit an den Daten selber.

Das glaube ich eher nicht. Ich habe hier eine ganze Reihe
von industriellen Anwendung (u.a. Messdatenerfassung)
mit dem SerialPort-Objekt und hatte bisher noch nie ein
wie von Dir beschriebenes Problem damit.

Mir ist immer noch nicht ganz klar, ob und welche Art
von Übertragungsprotokoll Du verwendest. Ebenso sehe
ich bisher nicht, wie und wann (nach welchem Ereignis /
Kriterium) Du beginnst, Daten aus dem Empfangspuffer
zu lesen.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Martin Eckel]

Post by Peter Götz
Was meinst Du mit "gleich schnell".
Woher willst Du wissen wie schnell, bzw. zu welchem
Zeitpunkt die Gegenstelle Daten sendet?

Das weiß ich, weil ich die Firmware der Gegenstelle selber geschrieben
habe. Deshalb weiß ich auch genau, daß immer die selbe Menge an Daten
kommt (nochmal gegengeprüft mit HTerm).

Post by Peter Götz
Mir ist immer noch nicht ganz klar, ob und welche Art
von Übertragungsprotokoll Du verwendest. Ebenso sehe
ich bisher nicht, wie und wann (nach welchem Ereignis /
Kriterium) Du beginnst, Daten aus dem Empfangspuffer
zu lesen.

Wie bei der Antwort zu Armin Zingler schon geschrieben:

Selbst wenn ich SerialPort.ReadBufferSize so groß mache, daß alle Daten
dort hineinpassen und dann nichts anderes mache, als zu warten bis
SerialPort.BytesToRead die gewünschte Menge an Daten im Buffer anzeigt,
so passiert genau das selbe.

Mit den einen Daten klappt es immer, im Buffer sind soviele Zeichen wie
erwartet und mit den anderen Daten klappt es nie, es sind immer zu
wenige Zeichen.


Mittels API gehts jedoch in beiden Fällen 100prozentig. Irgendwo geht in
den Tiefen des NETs was verloren.

Ein Übertragungsprotokoll existiert bislang nicht wirklich, es werden
einfach nur die Rohdaten gesendet. Das wird natürlich noch auf
gesicherte Übertragung umgestellt und ich bin gespannt, was dann passiert:

1. Fehlerhafte Blöcke werden erkannt und wiederholt, dann gehts weiter.

oder:

2. Ein und derselbe Block ist immer wieder fehlerhaft, weil es ja mit
den Daten zusammenhängt. Deshalb wird er bei diesem Block hängenbleiben.


Aber auch wenn die gesicherte Übertragung eine Umgehung dieses Problems
möglich machen sollte, so würde ich doch gerne wissen, WARUM zum Geier
das auftritt.

Gruß,
Martin

[Martin Eckel]

Hallo,

um es nochmal deutlich zu machen:

Es handelt sich um ein Meßgerät, welches Meßdaten zum PC überträgt. Mit
Prüfling A wurden schon -zig Messungen durchgeführt. Immer kommt die
richtige Anzahl von Daten an.

Wird mit Prüfling B die selbe Messung durchgeführt (gleiche Datenrate,
gleiche Datenmenge, nur halt andere Daten), kommen auf einmal zu wenige
Daten an. Und zwar landen bereits zu wenige Daten im ReadBuffer, also
gehen sie schon verloren, bevor mein Programm sie verarbeitet.

Das läßt sich 100mal wiederholen.

Wird der Datenempfang auf API Handling umgestellt, gibts auch mit
Prüfling B kein Problem. Von daher kann ich ein Problem auf der Seite
des Meßgerätes ausschliessen.

Also irgendwo im NET gehen Bytes verloren. Aber halt nur unter
bestimmten Bedingungen.

Gruß,
Martin

[Armin Zingler]

Post by Martin Eckel
Also irgendwo im NET gehen Bytes verloren. Aber halt nur unter
bestimmten Bedingungen.

Fehlen die Daten innerhalb des Byte-Arrays, das du einliest oder
zwischen den Arrays?


Armin

[Peter Götz]

Hallo Martin,

Post by Martin Eckel
Selbst wenn ich SerialPort.ReadBufferSize so groß mache,
daß alle Daten dort hineinpassen und dann nichts anderes
mache, als zu warten bis SerialPort.BytesToRead die
gewünschte Menge an Daten im Buffer anzeigt, so passiert
genau das selbe.

Das verstehe ich immer noch nicht.
Angenommen Du erwartest 2000 Byte und SerialPort.BytesToRead
liefert den Wert 2000.
Sind dann im Empfangspuffer weniger als diese 2000 Byte?
Ich kann mir nicht so recht vorstellen wie das gehen sollte.

Post by Martin Eckel
Mit den einen Daten klappt es immer, im Buffer sind soviele
Zeichen wie erwartet und mit den anderen Daten klappt es nie,
es sind immer zu wenige Zeichen.

Obwohl .BytesToRead die richtige, erwartete Anzahl von Bytes
zeigt?
Mir fällt gerade auf, dass Du im vorigen Satz "Zeichen" erwähnst.
Meinst Du wirklich "Zeichen" oder doch eher "Bytes"?

Post by Martin Eckel
Mittels API gehts jedoch in beiden Fällen 100prozentig. Irgendwo
geht in den Tiefen des NETs was verloren.

Wie schon erwähnt habe ich bei mehreren Anwendungen, bei
denen mit dem SerialPort-Objekt gearbeitet wird, weder bei
byteweiser noch bei textorientierter Arbeitsweise einen solchen
Effekt feststellen können. Akt. habe ich hier gerade eine
Anwendung in Arbeit, die aus unterschiedlichen E-Proms
(2, 4, 8 u. 16 kB) kommende Daten über SerialPort liest
und prüft.

Post by Martin Eckel
Ein Übertragungsprotokoll existiert bislang nicht wirklich,
es werden einfach nur die Rohdaten gesendet.
Das wird natürlich noch auf gesicherte Übertragung umgestellt
1. Fehlerhafte Blöcke werden erkannt und wiederholt,
dann gehts weiter.

Ja, so sollte es eigentlich sein.

Post by Martin Eckel
2. Ein und derselbe Block ist immer wieder fehlerhaft, weil
es ja mit den Daten zusammenhängt. Deshalb wird er bei
diesem Block hängenbleiben.

In diesem Fall sollte ein Wiederholzähler mitlaufen, der bei
Erreichen eines bestimmten Maximalwertes eine entsprechende
Fehlerbehandlung u. Fehlermeldung initiiert.

Post by Martin Eckel
Aber auch wenn die gesicherte Übertragung eine Umgehung
dieses Problems möglich machen sollte, so würde ich doch
gerne wissen, WARUM zum Geier das auftritt.

Übertragungsfehler treten je nach Übertragungsgeschwindigkeit
und Leitungsgüte bei einer DfÜ via V24 / RS232 immer mal
auf, was eben durch eine gesicherte Übertragungsprozedur
aufgefangen werden kann.
Dass ein Übertragungsfehler im selben Datenblock immer an
der selben Stelle auftritt, ist eher unwahrscheinlich. Wenn so
etwas auftritt, würde ich eher einen Fehler auf der Hardware-
seite bzw. der zugehörigen Firmware vermuten.

Kannst Du denn feststellen, welche Daten (Bytes oder Byte-
kombinationen) verfälscht oder unterdrückt werden?

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Martin Eckel]

Post by Peter Götz
Das verstehe ich immer noch nicht.
Angenommen Du erwartest 2000 Byte und SerialPort.BytesToRead
liefert den Wert 2000.

Nein, SerialPort.BytesToRead liefert in dem entsprechendem Fall weniger
als 2000 - obwohl definitiv 2000 gesendet wurden, überprüft einmal mit
API oder auch direkt mit HTerm.

Post by Peter Götz
Mir fällt gerade auf, dass Du im vorigen Satz "Zeichen" erwähnst.
Meinst Du wirklich "Zeichen" oder doch eher "Bytes"?

Natürlich meine ich Bytes...

Post by Peter Götz

Post by Martin Eckel
2. Ein und derselbe Block ist immer wieder fehlerhaft, weil
es ja mit den Daten zusammenhängt. Deshalb wird er bei
diesem Block hängenbleiben.

In diesem Fall sollte ein Wiederholzähler mitlaufen, der bei
Erreichen eines bestimmten Maximalwertes eine entsprechende
Fehlerbehandlung u. Fehlermeldung initiiert.

Ja, wenn der Fehler wirklich deterministisch bestimmten Daten zuordnebar
ist, dann würde so ein Block im Endeffekt nicht übertragbar sein, da
immer wieder derselbe Fehler auftritt (über NET).

Post by Peter Götz
Übertragungsfehler treten je nach Übertragungsgeschwindigkeit
und Leitungsgüte bei einer DfÜ via V24 / RS232 immer mal
auf, was eben durch eine gesicherte Übertragungsprozedur
aufgefangen werden kann.

Ja, aber ein echter Übertragungsfehler würde ja beim API-Handling auch
auftreten.

Post by Peter Götz
Dass ein Übertragungsfehler im selben Datenblock immer an
der selben Stelle auftritt, ist eher unwahrscheinlich. Wenn so
etwas auftritt, würde ich eher einen Fehler auf der Hardware-
seite bzw. der zugehörigen Firmware vermuten.

Wie gesagt, bei Empfang über API oder per HTerm kommt IMMER die
gewünschte Anzahl an Bytes an - also kann hier eigentlich kein Fehler in
der Firmware sein - was meinst Du, wie ich schon an meinem Verstand
gezweifelt habe...

Post by Peter Götz
Kannst Du denn feststellen, welche Daten (Bytes oder Byte-
kombinationen) verfälscht oder unterdrückt werden?

Leider habe ich in der Hardware nicht genügend Speicher, um alle Daten
zwischenzuspeichern - sonst würde ich zweimal hintereinander dieselben
Daten übertragen, einmal über NET empfangen, eimal über API - vielleicht
würde man da eine Gesetzmäßigkeit feststellen, was verloren geht.

Wenn ich die selbe Messung nochmal durchführe, kommt natürlich
prinzipiell das selbe raus (und der Datenverlust tritt auch wieder auf),
aber die Meßdaten sind natürlich nicht absolut identisch.

Gruß,
Martin

[Peter Götz]

Hallo Martin,

Post by Martin Eckel
Nein, SerialPort.BytesToRead liefert in dem entsprechendem
Fall weniger als 2000 - obwohl definitiv 2000 gesendet wurden,
überprüft einmal mit API oder auch direkt mit HTerm.

Stellt sich wieder die Frage nach

SerialPort.ReceivedBytesThreshold

a) Welche Datenmenge (Anzahl Bytes) erwartest Du konkret?

b) Wie ist SerialPort.ReceivedBytesThreshold eingestellt?

c) Welchen Wert liefert SerialPort.BytesToRead?

d) Wie sind SerialPort

.BaudRate
.DataBits
.StopBits

eingestellt?


Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Martin Eckel]

Post by Peter Götz
a) Welche Datenmenge (Anzahl Bytes) erwartest Du konkret?

Das dürften so 90.000 sein.

Post by Peter Götz
b) Wie ist SerialPort.ReceivedBytesThreshold eingestellt?

Wozu ist das wichtig, wenn ich nicht ereignisgesteuert abhole, sondern
polle?

Post by Peter Götz
c) Welchen Wert liefert SerialPort.BytesToRead?

So 50-60 Bytes zu wenig wenn ich mich recht erinnere (auf jeden Fall
nicht konstant).

Post by Peter Götz
d) Wie sind SerialPort
.BaudRate

3000000 (nicht wundern, ist ein spezieller USB/Seriell Adapter)

Post by Peter Götz
.DataBits

8

Post by Peter Götz
.StopBits

1



Was alles nichts daran ändert, daß irgendwo ein Unterschied zwischen NET
und API ist.

Montag werde ich mal definitive Code-Schnipsel testen und dann hier
vorstellen - wie es mit NET manchmal nicht geht und mit API immer.

Gruß,
Martin

[Peter Götz]

Hallo Martin,

Post by Martin Eckel

Post by Peter Götz
a) Welche Datenmenge (Anzahl Bytes) erwartest Du konkret?

Das dürften so 90.000 sein.

"So 90.0000" hört sich aber nicht nach einer wirklich
exakt definierten Datenmenge an, die im Zusammenhang
mit SerialPort.ReceivedBytesThreshold schon von
Interesse wäre.

Post by Martin Eckel

Post by Peter Götz
b) Wie ist SerialPort.ReceivedBytesThreshold eingestellt?

Wozu ist das wichtig,

Weil Du nur über diese Einstellung eine wirkliche
Kontrolle über Deinen Empfangspuffer bekommst.

Post by Martin Eckel
wenn ich nicht ereignisgesteuert abhole,
sondern polle?

... und genau das dürfte die Ursache für Dein Problem
sein. Polling auf den Datenpuffer des SerialPort-
Objektes ist eher ein Lotteriespiel.
Warum willst Du nicht die für dieses Objekt vorgesehene
Ereignissteuerung nutzen?

Post by Martin Eckel

Post by Peter Götz
c) Welchen Wert liefert SerialPort.BytesToRead?

So 50-60 Bytes zu wenig wenn ich mich recht erinnere
(auf jeden Fall nicht konstant).

Post by Peter Götz
d) Wie sind SerialPort
.BaudRate

3000000 (nicht wundern, ist ein spezieller USB/Seriell
Adapter)

Was ist das denn konkret für ein Adapter (Hersteller/Typ)?

Je nach Leitungslänge und Leitungsgüte dürften dabei
mit hoher Wahrscheinlichkeit reichlich Datenübertraguns-
fehler anfallen.
Warum arbeitest Du nicht mit einer für die V24 / RS232
angepassten, deutlich niedrigeren Übertragungsgeschwindigkeit?
Deine Datenmenge von ca. 90.000 Byte ist ja nicht wirklich
sehr gross.

Post by Martin Eckel

Post by Peter Götz
.DataBits

8

Post by Peter Götz
.StopBits

1
Was alles nichts daran ändert, daß irgendwo ein Unterschied
zwischen NET und API ist.

Ich denke mal, Du vergleichst da Äpfel mit Birnen.

In jedem Fall würde ich Dir dringend empfehlen, die für das
Serialport-Objekt vorgesehene Ereignissteuerung via
DataReceived zu nutzen.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Martin Eckel]

Post by Peter Götz
"So 90.0000" hört sich aber nicht nach einer wirklich
exakt definierten Datenmenge an, die im Zusammenhang

Ich habs halt nicht im Kopf, die Anzahl ist auf jeden Fall immer gleich

Post by Peter Götz
... und genau das dürfte die Ursache für Dein Problem
sein. Polling auf den Datenpuffer des SerialPort-
Objektes ist eher ein Lotteriespiel.

Warum? Wenn der Buffer groß genug ist, um ALLE Daten aufzunehmen, darf
doch auch ein Polling in keinem Fall schiefgehen.
Vor allem nicht in Abhängigkeit der Daten (und dabei bleibe ich).

Post by Peter Götz

Post by Martin Eckel

Post by Peter Götz
.BaudRate

3000000 (nicht wundern, ist ein spezieller USB/Seriell
Adapter)

Was ist das denn konkret für ein Adapter (Hersteller/Typ)?
Je nach Leitungslänge und Leitungsgüte dürften dabei
mit hoher Wahrscheinlichkeit reichlich Datenübertraguns-
fehler anfallen.

Die Länge der seriellen Datenleitungen beträgt nur wenige mm, vom
USB/Seriell Wandler zum Microcontroller.
Es könnte tatsächlich sein, daß in Abhängigkeit der Daten hier
Übertragungsfehler auftreten (ich hab mal so eine Sauerrei gehabt, das
bei einem 5 Meter USB-Kabel die Übertragung komplett hängen blieb, wenn
die Daten alle um Null waren). Ich kann gerne mal die Datenrate senken
und vergleichen, das wäre tatsächlich noch eine Idee.

Dennoch bekomme ich über API immer die richtige Anzahl an Daten (und
dabei bleibe ich auch).

Post by Peter Götz
Warum arbeitest Du nicht mit einer für die V24 / RS232
angepassten, deutlich niedrigeren Übertragungsgeschwindigkeit?
Deine Datenmenge von ca. 90.000 Byte ist ja nicht wirklich
sehr gross.

Es können später auch noch mehr Daten werden. Auf 1500000 müßte ich aber
gehen können.

Post by Peter Götz

Post by Martin Eckel
Was alles nichts daran ändert, daß irgendwo ein Unterschied
zwischen NET und API ist.

Ich denke mal, Du vergleichst da Äpfel mit Birnen.

Warum?

Fakt ist: Mit NET-Handling gehen unter bestimmten Umständen Daten
verloren, mit anderen Daten passiert das nicht.
Fakt ist: Mit API-Handling kommen immer alle Daten an.

Da bleibt bei mir immer noch ein sehr großes Fragezeichen.

Post by Peter Götz
In jedem Fall würde ich Dir dringend empfehlen, die für das
Serialport-Objekt vorgesehene Ereignissteuerung via
DataReceived zu nutzen.

Kann ich gerne mal versuchen. Und ich werde mir einen
Serial-Port-Sniffer installieren.

Gruß,
Martin

[Joachim Fuchs]

Hallo Martin,

Post by Martin Eckel

Post by Peter Götz
... und genau das dürfte die Ursache für Dein Problem
sein. Polling auf den Datenpuffer des SerialPort-
Objektes ist eher ein Lotteriespiel.

Warum? Wenn der Buffer groß genug ist, um ALLE Daten aufzunehmen, darf
doch auch ein Polling in keinem Fall schiefgehen.
Vor allem nicht in Abhängigkeit der Daten (und dabei bleibe ich).

Post by Peter Götz
In jedem Fall würde ich Dir dringend empfehlen, die für das
Serialport-Objekt vorgesehene Ereignissteuerung via
DataReceived zu nutzen.

davon kann ich nur dringend abraten. Der Umgang mit den Events der
Komponente ist extrem schwierig und fehleranfällig. Wie bereits viele
Programmierer feststellen mussten, funktioniert diese Variante nur sehr
bedingt. Da die Events nicht mit dem GUI-Thread synchronisiert sind, muss
man sich ohnehin mit Multithreading auskennen, um sie richtig einzusetzen.
Liest man dann beispielsweise im DataReceived-Ereignis ein Byte zuviel,
kommt alles außer Tritt.

Wesentlich sicherer ist es, einen dedizierten Thread anzulegen (z. B.
Backgroundworker), der in einer Endlosschleife z. B. über einen StreamReader
oder einen BinaryReader von der Schnittstelle liest, die Daten
kontinuierlich aufbereitet und über eine Queue an andere Programmteile
weitergibt. Bei dieser Variante lassen sich auch leicht andere Codierungen
mit unterschiedlichen Byte-Längen (z. B. UTF8) dekodieren, was bei der
Ereignisgesteuerten Variante recht kompliziert wird.

Mögliche Fehlerquelle bei der threadbasierten Endlosschleife:
- Überlauf des Zwischenpuffers, wenn der Thread nicht oft genug die Daten
abholen kann
- Falsch eingestellte Schnittstellenparameter (Baudrate, Anzahl Stoppbits,
Parity, Handshake) Hier könnte auch der Unterschied zur API-Variante liegen.
Vielleicht wird XON/XOFF verwendet und die Bitkombinationen kommen in den
Daten vor?

Vielleicht lässt aber die Komponente auch nicht die krumme Baudrate zu,
sondern stellt automatisch einen (ähnlichen) Standardwert ein. Das könnte
dazu führen, dass bestimmte Bitkombinationen zufällig richtig gelesen
werden, andere aber nicht.

Viele Grüße
Joachim

[Karsten Sosna]

Post by Joachim Fuchs

Post by Martin Eckel

Post by Peter Götz
... und genau das dürfte die Ursache für Dein Problem
sein. Polling auf den Datenpuffer des SerialPort-
Objektes ist eher ein Lotteriespiel.

Warum? Wenn der Buffer groß genug ist, um ALLE Daten aufzunehmen, darf
doch auch ein Polling in keinem Fall schiefgehen.
Vor allem nicht in Abhängigkeit der Daten (und dabei bleibe ich).

Post by Peter Götz
In jedem Fall würde ich Dir dringend empfehlen, die für das
Serialport-Objekt vorgesehene Ereignissteuerung via
DataReceived zu nutzen.

davon kann ich nur dringend abraten.

Hallo Joachim,
und hier protestiere ich mit Nachdruck.

Post by Joachim Fuchs
Der Umgang mit den Events der Komponente ist extrem schwierig und
fehleranfällig.

Schwierig steht außer Frage, aber das sie fehleranfällig ist konnte ich noch
nie feststellen. Fehler entstanden nur durch logische Fehler deswegen auch
schwierig.

Post by Joachim Fuchs
Wie bereits viele Programmierer feststellen mussten, funktioniert diese
Variante nur sehr bedingt. Da die Events nicht mit dem GUI-Thread
synchronisiert sind, muss man sich ohnehin mit Multithreading auskennen,
um sie richtig einzusetzen. Liest man dann beispielsweise im
DataReceived-Ereignis ein Byte zuviel, kommt alles außer Tritt.

Und genau dafür gibt es Protokolle, die auf der Senderseite und Empfänger
unbedingt eingehalten werden müssen. Jeder der diese ignoriert und davon
ausgeht dass es ohne diese funktioniert hat an dieser Stelle schon verloren.
Genau das tut der OP:

"Das weiß ich, weil ich die Firmware der Gegenstelle selber geschrieben
habe. Deshalb weiß ich auch genau, daß immer die selbe Menge an Daten kommt"

"Ein Übertragungsprotokoll existiert bislang nicht wirklich, es werden
einfach nur die Rohdaten gesendet. Das wird natürlich noch auf gesicherte
Übertragung umgestellt und ich bin gespannt, was dann passiert:"

Die serielle Schnittstelle ist grundsätzlich mit einer asynchronen
Datenübertragung belastet, eine Synchronisation kann nur über das Protokoll
stattfinden und tut es i.d.R. auch.

Post by Joachim Fuchs
Wesentlich sicherer ist es, einen dedizierten Thread anzulegen (z. B.
Backgroundworker), der in einer Endlosschleife z. B. über einen
StreamReader oder einen BinaryReader von der Schnittstelle liest, die
Daten kontinuierlich aufbereitet und über eine Queue an andere
Programmteile weitergibt. Bei dieser Variante lassen sich auch leicht
andere Codierungen mit unterschiedlichen Byte-Längen (z. B. UTF8)
dekodieren, was bei der Ereignisgesteuerten Variante recht kompliziert
wird.

Hast Du es vielleich nicht gelesen?

"Natürlich meine ich Bytes..."

Post by Joachim Fuchs
- Überlauf des Zwischenpuffers, wenn der Thread nicht oft genug die Daten
abholen kann

Mir ist es noch nicht einmal untergekommen das der Puffer überläuft, wären
auch ein Wunder, da die Puffer nach dem FIFO-Prinzip arbeiten. Gibt es
keinen Platz mehr werden nicht abgeholte Bytes aus dem Puffer geschoben.
Damit entsteht zwangsläufig ein Datenverlust. Und genau das passiert wenn
man versucht zu pollen und die Ereignissteuerung ignoriert.

Post by Joachim Fuchs
- Falsch eingestellte Schnittstellenparameter (Baudrate, Anzahl Stoppbits,
Parity, Handshake) Hier könnte auch der Unterschied zur API-Variante
liegen. Vielleicht wird XON/XOFF verwendet und die Bitkombinationen kommen
in den Daten vor?

Wäre möglich, jedoch wäre die Datenübertagung prinzipiell gestört, was
bedeutet das die empfangen Daten grundsätzlich "Schrott" sind.

Post by Joachim Fuchs
Vielleicht lässt aber die Komponente auch nicht die krumme Baudrate zu,
sondern stellt automatisch einen (ähnlichen) Standardwert ein. Das könnte
dazu führen, dass bestimmte Bitkombinationen zufällig richtig gelesen
werden, andere aber nicht.

Nun zumal habe ich noch nie gesehen das ein Gerät mit:

"3000000 (nicht wundern, ist ein spezieller USB/Seriell Adapter)"

läuft, der nächstliegende Wert wären 3.4MBit. Kein Schnittstellenbaustein,
der Autodetecion-Eigenschaften wird sich auf so einen merkwürdigen Wert
einlassen.
Nun alles in Allem gehe ich mal davon aus der OP wirklich keine Ahnung von
der Materie hat. Nur ein paar Auszüge:
==================

Post by Joachim Fuchs
a) Welche Datenmenge (Anzahl Bytes) erwartest Du konkret?

Das dürften so 90.000 sein.

Post by Joachim Fuchs
b) Wie ist SerialPort.ReceivedBytesThreshold eingestellt?

Wozu ist das wichtig, wenn ich nicht ereignisgesteuert abhole, sondern
polle?

Post by Joachim Fuchs
c) Welchen Wert liefert SerialPort.BytesToRead?

So 50-60 Bytes zu wenig wenn ich mich recht erinnere (auf jeden Fall
nicht konstant).

Montag werde ich mal definitive Code-Schnipsel testen und dann hier
vorstellen - wie es mit NET manchmal nicht geht und mit API immer.
==================
Welche API meint Er eigentlich? War da nicht im Eigangangs-Posting zulesen?
"Wenn ich die serielle Schnittstelle wie unter VB6 direkt mittels API ..."

Also an dieser Stelle hakt es schon. Selbst unter VB6 benötigt man keine API
da es ja das MSComm-Control gibt. Und wenn ich schon eine API benutzt warum
benutze ich diese dann nicht unter VB.Net, den die Aussage steht hier:
"Dazu benutze ich System.IO.Ports"

Oder
===================

Post by Joachim Fuchs
"So 90.0000" hört sich aber nicht nach einer wirklich
exakt definierten Datenmenge an, die im Zusammenhang

Ich habs halt nicht im Kopf, die Anzahl ist auf jeden Fall immer gleich
===================
Hatte Er nicht geschrieben:
"Das weiß ich, weil ich die Firmware der Gegenstelle selber geschrieben
habe. Deshalb weiß ich auch genau, daß immer die selbe Menge an Daten kommt
(nochmal gegengeprüft mit HTerm)."

Also wenn ich so etwas kodiere weiß ich hundertprozentig noch nach 2 Jahren
wieviel Daten dort übertragen. Und wenn ich die "Firmware" geschrieben
hätte, habe ich auch diese Software und Dokumentation irgendwo auf dem
Server liegen und könnte jederzeit nachschauen, wieviel es Bytes es wirklich
sind.
Noch etwas ist sehr merkwürdig, was mir noch nie untergekommen ist:
=============

Post by Joachim Fuchs
Warum arbeitest Du nicht mit einer für die V24 / RS232
angepassten, deutlich niedrigeren Übertragungsgeschwindigkeit?
Deine Datenmenge von ca. 90.000 Byte ist ja nicht wirklich
sehr gross.

Es können später auch noch mehr Daten werden. Auf 1500000 müßte ich aber
gehen können.
==============
ca.1.5 MegaByte und ohne Protokoll bei vermutlichen 3.4MBit/s????
Oder
"Die Länge der seriellen Datenleitungen beträgt nur wenige mm, vom
USB/Seriell Wandler zum Microcontroller"

Als wenn mich das interessiert. Und die Verbindung ist davor 5m lang ohne
Schirmung?

Er hat defintiv keine Ahnung was Er dort wirklich tut. Weder auf der
Software- noch Hardware-Seite.
Ich programmiere bestimmt schon seit über 25 Jahren, darunter waren auch
etliche Schnittstellen-Projekte(egal ob es eine RS232, V24 oder irgendwelche
Bussyteme). Aus einem habe ich auf jeden Fall gelernt, Spezifikationen
einhalten!

P.S.: Entschuldigung für das etwas konfuse Posting.
--
Gruß Scotty

[Martin Eckel]

Also solangsam geht mir der Hut hier hoch.

Post by Karsten Sosna
unbedingt eingehalten werden müssen. Jeder der diese ignoriert und davon
ausgeht dass es ohne diese funktioniert hat an dieser Stelle schon verloren.

SELBSTVERSTÄNDLICH wird noch auf gesicherte Übertragung umgeschwenkt.
Nur wenn bereits bei der ungesicherten Übertragung ein systematischer
Fehler auftritt, dann sollte man vielleicht herausfinden, warum!

Post by Karsten Sosna
Gibt es
keinen Platz mehr werden nicht abgeholte Bytes aus dem Puffer geschoben.
Damit entsteht zwangsläufig ein Datenverlust. Und genau das passiert wenn
man versucht zu pollen und die Ereignissteuerung ignoriert.

Und das DARF nicht passieren, wenn der Eingangsbuffer groß genug ist, um
alle Daten zu emfangen.

Post by Karsten Sosna
"3000000 (nicht wundern, ist ein spezieller USB/Seriell Adapter)"

Ist ja schön, dieser Baustein läuft aufgrund spezieller Anforderungen
mit einem etwas ungeraden Takt und dadurch kommen wir auch auf 3MBit.

Post by Karsten Sosna
Welche API meint Er eigentlich? War da nicht im Eigangangs-Posting zulesen?
"Wenn ich die serielle Schnittstelle wie unter VB6 direkt mittels API ..."
Also an dieser Stelle hakt es schon. Selbst unter VB6 benötigt man keine API
da es ja das MSComm-Control gibt.

Wenn Du mir empfiehlst, das MSComm-Control unter VB6 zu benutzen, dann
muß ich davon ausgehen, daß Dir damit die Erfahrung fehlt. Aufgrund der
Probleme und Fehler des Controls habe ich damals direkt die API benutzt.

Post by Karsten Sosna
Und wenn ich schon eine API benutzt warum
"Dazu benutze ich System.IO.Ports"

Die API funktioniert unter NET zwar, jedoch führte sie aus mir noch
nicht erkennbaren Gründen zu Instabilitäten. Und im Prinzip hätte ich eh
alles lieber auf der NET-Schiene.

Post by Karsten Sosna
Also wenn ich so etwas kodiere weiß ich hundertprozentig noch nach 2 Jahren
wieviel Daten dort übertragen. Und wenn ich die "Firmware" geschrieben
hätte, habe ich auch diese Software und Dokumentation irgendwo auf dem
Server liegen und könnte jederzeit nachschauen, wieviel es Bytes es wirklich
sind.

Ich bin derzeit nicht an meinem Arbeitsplatz und im Kopf habe ich die
Menge nunmal nicht - ist auch nicht wirklich wichtig. Morgen kann ich
meinen Sourcecode wieder anschauen.

Post by Karsten Sosna
Als wenn mich das interessiert. Und die Verbindung ist davor 5m lang ohne
Schirmung?

Die Verbindung davor ist USB. Das Gerät wird mittels USB angebunden, der
USB/Seriell Wandler sitzt im Gerät und das Gerät wird auf softwareseite
als virtueller COM-Port eingebunden.

Post by Karsten Sosna
Er hat defintiv keine Ahnung was Er dort wirklich tut. Weder auf der
Software- noch Hardware-Seite.

Mit Sicherheit weiß ich, was ich tue.

Post by Karsten Sosna
Bussyteme). Aus einem habe ich auf jeden Fall gelernt, Spezifikationen
einhalten!

Spezifikation hin- oder her. Wenn ich ein und dasselbe mache, einmal
über NET und einmal über API, dann gibts bei NET manchmal ein Problem.
Und bei API nie. Und die ganze Chose hängt von den Daten ab.

Und mir hat noch keiner einen einzigen Anhaltspunkt geben können, woran
das liegen kann (bis auf XON/XOFF, aber daran glaube ich nicht wirklich
- mal schauen).


Aber ich werde schon noch herausfinden, woran das liegt. Bisher hab ich
noch jeden noch so seltsamen Fehler gefunden - und nicht immer lags am
Programmierer.


Gruß,
Martin

[Peter Götz]

Hallo Joachim,

Post by Joachim Fuchs

Post by Peter Götz
In jedem Fall würde ich Dir dringend empfehlen, die
für das Serialport-Objekt vorgesehene Ereignissteuerung
via DataReceived zu nutzen.

davon kann ich nur dringend abraten.

Da möchte ich aber schon ganz entschieden widersprechen.

Post by Joachim Fuchs
Der Umgang mit den Events der Komponente ist extrem
schwierig und fehleranfällig.

Schwierig ist ein recht subjektiver Begriff, fehleranfällig trifft
hier ganz sicher nicht zu.

Post by Joachim Fuchs
Wie bereits viele Programmierer feststellen mussten,
funktioniert diese Variante nur sehr bedingt.

Alle hier in den NGs auftauchenden Fragen zu Problemen mit
seriellen Schnittstellen (V24 / RS323) lassen immer das gleiche
Muster erkennen:
Es wird eben keine saubere Ereignissteuerung genutzt und/oder
es gibt kein vernünftiges, sicheres Übertragungsprotokoll. Beides
gehört zusammen und nur so lassen sich auch sichere Verbindungen
realisieren.

Ich habe eine ganze Reihe von Anwendungen im industriellen
Umfeld im Einsatz, bei denen unterschiedlichste Daten und
auch in grossen Mengen (z.B. industrielle Messautomaten)
übertragen werden. Es gab dabei seit Jahren kein Problem
mit der Dfü via V24 / RS232.

Post by Joachim Fuchs
Da die Events nicht mit dem GUI-Thread synchronisiert sind,
muss man sich ohnehin mit Multithreading auskennen, um sie
richtig einzusetzen.

Natürlich sollte man eine Technik, die man verwenden will,
kennen und beherrschen. Dazu gehört nicht nur der sichere
Umgang mit Multithreading, sondern eben auch das notwendige
technische Wissen um serielle Datenübertragung.

Post by Joachim Fuchs
Liest man dann beispielsweise im DataReceived-Ereignis ein
Byte zuviel, kommt alles außer Tritt.

Ich sehe nicht so recht, wie man bei Nutzung eines vernünftigen
Übertragungsprotokolls und sauberer Ereignissteuerung
irgendwelche Bytes zuviel oder zuwenig lesen soll.

Post by Joachim Fuchs
Wesentlich sicherer ist es, einen dedizierten Thread anzulegen
(z. B. Backgroundworker), der in einer Endlosschleife z. B. über
einen StreamReader oder einen BinaryReader von der
Schnittstelle liest, die Daten kontinuierlich aufbereitet und über
eine Queue an andere Programmteile weitergibt.

Genau das ist es, was ich als Lotteriespiel bezeichne.
Mit reinem Polling, ohne definiertes Übertragungsprotokoll
gibt es keine sichere Datenübertragung.

Post by Joachim Fuchs
Bei dieser Variante lassen sich auch leicht andere Codierungen
mit unterschiedlichen Byte-Längen (z. B. UTF8) dekodieren,
was bei der Ereignisgesteuerten Variante recht kompliziert wird.

Bei der Datenübertragung via RS232 / V24 gibt es entweder 7 oder
8 Bits pro Byte und bei rein byteorientierter Arbeitsweise sind
Codierungen wie UTF8 und andere für den reinen Übertragungsweg
völlig ohne Bedeutung.

Post by Joachim Fuchs
- Überlauf des Zwischenpuffers, wenn der Thread nicht oft
genug die Daten abholen kann

Alleine schon das ein ausreichender Grund nicht mit simplem
Polling zu arbeiten.

Post by Joachim Fuchs
- Falsch eingestellte Schnittstellenparameter (Baudrate,
Anzahl Stoppbits, Parity, Handshake)

Das sind Fehler, die der Programmierer macht, aber keine
Fehler, welche durch die Technik bedingt sind.

Post by Joachim Fuchs
Hier könnte auch der Unterschied zur API-Variante liegen.
Vielleicht wird XON/XOFF verwendet und die Bitkombinationen
kommen in den Daten vor?

Ich habe in dieser Diskussion bisher nichts von XON/XOFF
gelesen. Ansonsten hätte ich das für die Übertragung von
Messdaten, um die es ja offensichtlich geht, als ungeeignet
eingestuft.

Post by Joachim Fuchs
Vielleicht lässt aber die Komponente auch nicht die krumme
Baudrate zu, sondern stellt automatisch einen (ähnlichen)
Standardwert ein.

Bei USB-Serial-Wandlern kann dies durchaus der Fall sein,
weil der zugehörige Treiber möglicherweise eben nur ein
bestimmtes Raster von Übertragungsraten bereitstellt.
Deshalb ja auch meine "hartnäckige" Nachfrage nach der
konkreten Baudrate.

Post by Joachim Fuchs
Das könnte dazu führen, dass bestimmte Bitkombinationen
zufällig richtig gelesen werden, andere aber nicht.

Solche "zufälligen" Datenverfälschungen können und werden
aber auch durch Störungen auf dem Leitungsweg (elektr. /
magnetisch) verursacht und genau deshalb braucht man
ein sicheres Übertragungsprotokoll zusammen mit einer
durchdachten Ereignissteuerung.

Eine ganz andere Frage wäre noch, ob für eine Übertragungs-
rate von 3.000.000 Baud oder sogar noch mehr eine
Übertragung via RS232 / V24 das geeignete Verfahren ist.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Martin Eckel]

Hallo,

bei allen Diskussionen um die Ereignissteuerung bleibe ich dabei, daß es
ein unhaltbarer Zustand ist, wenn der Empfangsbuffer groß genug ist, um
alle ankommenden Daten zu empfangen und dennoch Daten verloren gehen.
Und dies ist hier der Fall, und auch nur, wenn man das SerialPort-Objekt
benutzt.

Ich habe jetzt herausgefunden, unter welchen Bedingungen dieses Problem
auftritt - und warum dieses Problem anscheinend bisher niemand anderem
aufgefallen ist.

Das SerialPort-Objekt ist anscheinend (zumindest bei mir) nicht in der
Lage, Daten mit mehr als 115200bps sicher zu verarbeiten - und zwar
seltsamerweise datenabhängig - wer weiß, was NET da noch im Hintergrund
macht.
Die wirkliche Baudrate des Anschlusses ist hierbei uninteressant, es
kommt nur auf die tatsächliche Datenrate an.
Da wahrscheinlich kaum jemand einen seriellen Port hat, welcher mehr als
115200bps kann geschweige denn ihn auf dieser Rate betreibt, ist das
wahrscheinlich auch nie aufgefallen.


Heute habe ich zuerst die Datenrate meines USB/Seriell-Ports von 3000000
auf 460800 bps verringert. Erwartungsgemäß machte das keinen Unterschied.
XON/XOFF war auch nicht aktiv ;-)

Um mal nachprüfbare Ergebnisse zu haben, habe ich mir zwei Datensätze
gespeichert - einer der per NET problemlos war und einen, welcher bei
NET zu Datenverlust führte, aber per API auch problemlos war.

Da ich in meinem Gerät nicht genügend Speicherplatz habe, um den ganzen
Datensatz zwischenzuspeichern, habe ich mein Gerät kurzerhand in eine
Art Loop-Back-Device umprogrammiert.
Dieses Gerät hat zwei Schnittstellen, eine Standard-RS232 (bis
921600bps) und die USB-Schnittstelle, welche onboard in serielle
Übertragung gewandelt wird, mit bis zu 3MBit/s direkt auf den
Microcontroller geht und Windows-seitig als virtueller COM-Port
eingebunden wird.

Alles, was per echter RS232 reinkam, wurde sofort mit 460800bps an den
USB/seriell Wandler zurückgeschickt und wanderte dann wieder per USB an
den PC.

Seltsamerweise lief dort auch der problematische Datensatz problemlos
durch - was mir einiges an Kopfzerbrechen bereitete, bis mir auffiel,
daß ich natürlich nur mit 115200bps reingesendet hatte (mehr kann der
Standard-PC nunmal nicht), im Realfall die Daten jedoch mit netto ca.
180000bps von meinem Gerät kommen.

Nun habe ich aber noch einen anderen PC hier, welcher eine extra
Schnittstellenkarte bis 921600bps drin hat. Hier stellte sich sofort dar:

Der problematische Datensatz mit 230400bps weggesendet, über NET wieder
empfangen - immer Datenverlust (im übrigen noch mehr Verluste, als im
Realfall mit netto 180000bps).
Der unproblematische Datensatz geht auch mit 230400bps problemlos durch.

Bei Empfang über API gibt es in keinem Fall Datenverluste.

Das ganze habe ich X-Mal durchgetestet. Diese Situation ist gleichbleibend.



Also soweit es sich hier darstellt, ist das SerialPort-Objekt definitiv
nicht für Übertragungen mit mehr als 115200bps geeignet - dabei hat der
USB-Seriell Wandler sogar einen FIFO von 320 Bytes.
Aber über API gehts ja auch problemlos...



Wenn das jemand gegenchecken möchte (und kann, schliesslich braucht man
mindestens zwei serielle Schnittstellen welche mindestens 230400bps
können - oder man macht sich einen Loop-Back-Stecker?), so kann ich ihm
gerne den problematischen und den unproblematischen Datensatz zuschicken
(je ca. 130kb).

Würde mich echt interessieren, was dabei rauskommt.

Gruß,
Martin

[Peter Götz]

Hallo Martin,

Post by Martin Eckel
bei allen Diskussionen um die Ereignissteuerung bleibe
ich dabei, daß es ein unhaltbarer Zustand ist, wenn der
Empfangsbuffer groß genug ist, um alle ankommenden

Daten zu empfangen und dennoch Daten verloren gehen.

Post by Martin Eckel
Und dies ist hier der Fall, und auch nur, wenn man das
SerialPort-Objekt benutzt.

Die Grösse des Empfangspuffers alleine gwährleistet keine
sichere Datenübertragung. Die für SerialPort eingestellte
Baudrate muss ebenfalls zu dem für das Senden der Daten
verwendeten Schritttakt passen.
Hinzu kommt, dass nicht jede V24 / RS232 jede beliebige
Taktfrequenz resp. Baudrate unterstützt. In der OH zum
SerialPort-Objekt heisst es dazu:

Die Baudrate muss vom seriellen Treiber des Benutzers
unterstützt werden. Der Standardwert ist 9600 Bits pro
Sekunde (bps).

Ich habe mir mal die Spezifikationen aller von mir bisher
im prakt. Einsatz getesteten V24-Schnittstelenkarten bzw.
USB-seriell-Adapter (ca. 30 verschiedene Typen) angesehen.
Darunter ist keine einzige, die 3.000.000 bps unterstützt.

Post by Martin Eckel
Ich habe jetzt herausgefunden, unter welchen Bedingungen
dieses Problem auftritt - und warum dieses Problem
anscheinend bisher niemand anderem aufgefallen ist.
Das SerialPort-Objekt ist anscheinend (zumindest bei mir)
nicht in der Lage, Daten mit mehr als 115200bps sicher zu
verarbeiten - und zwar seltsamerweise datenabhängig - wer
weiß, was NET da noch im Hintergrund macht.

Die Datenabhängigkeit erklärt sich daraus, dass es je nach
konkreten Daten mal zu mehr oder weniger Flusswechseln
auf der Leitung und damit zu unterschiedlich hoher Störanfälligkeit
kommt.

Post by Martin Eckel
Die wirkliche Baudrate des Anschlusses ist hierbei uninteressant,
es kommt nur auf die tatsächliche Datenrate an.

Was meinst Du mit "wirklicher Baudrate" und "tatsächlicher Datenrate"?

Die tatsächliche Taktung der Daten müssen mit der für SP
eingestellten Baudrate übereinstimmen oder anders ausgedrückt,
Sendeschritttakt auf der Senderseite und Empfangsschritttakt
auf der Empfangsseite müssen synchron sein.

Post by Martin Eckel
Da wahrscheinlich kaum jemand einen seriellen Port hat, welcher
mehr als 115200bps kann geschweige denn ihn auf dieser Rate
betreibt, ist das wahrscheinlich auch nie aufgefallen.

s.oben:
Ich habe bisher keine Spezifikation für eine V24- oder RS232-
Schnittstellenkarte gesehen, die 3.000.000 bps bereitstellt.

Post by Martin Eckel
Heute habe ich zuerst die Datenrate meines USB/Seriell-Ports
von 3000000 auf 460800 bps verringert.

Auch das ist ein Wert, den keine mir bekannte RS232 oder V24
Schnittstellenkarte bereitstellt.

Post by Martin Eckel
Erwartungsgemäß machte das keinen Unterschied.
XON/XOFF war auch nicht aktiv ;-)
Um mal nachprüfbare Ergebnisse zu haben, habe ich mir zwei
Datensätze gespeichert - einer der per NET problemlos war und
einen, welcher bei NET zu Datenverlust führte, aber per API auch
problemlos war.
Da ich in meinem Gerät nicht genügend Speicherplatz habe, um
den ganzen Datensatz zwischenzuspeichern, habe ich mein Gerät
kurzerhand in eine Art Loop-Back-Device umprogrammiert.
Dieses Gerät hat zwei Schnittstellen, eine Standard-RS232 (bis
921600bps)

Da würde mich mal die originale Spezifikation des Herstellers
interessieren.
Welches Gerät von welchem Hersteller ist das?

Post by Martin Eckel
und die USB-Schnittstelle,

Wenn Dein Gerät eine USB-Schnittstelle hat, dann verstehe ich
nicht, warum Du für relativ hohe Übertragungsgeschwindigkeiten
nicht eben die dafür ohnehin besser geeignete USB-Schnittstelle
verwendest.

Post by Martin Eckel
welche onboard in serielle Übertragung gewandelt wird,

Egal ob RS232 oder USB, die Übertragung der Daten
erfolgt in beiden Fällen seriell.

Post by Martin Eckel
mit bis zu 3MBit/s direkt auf den Microcontroller geht und
Windows-seitig als virtueller COM-Port eingebunden wird.

Bis hierher verstehe ich nicht wirklich, wie diese Hardware
konkret aussieht, sprich wann bzw. wo USB und wann bzw.
wo RS323 zum Einsatz kommt.

Post by Martin Eckel
Alles, was per echter RS232 reinkam,

Was meinst Du mit "echter RS232" und was kam wo
rein?

Post by Martin Eckel
wurde sofort mit 460800bps an den USB/seriell Wandler
zurückgeschickt und wanderte dann wieder per USB an
den PC.

Wie schon erwähnt, habe ich dieses "Gemisch" von USB
und RS232 Schnittstellen (noch) nicht verstanden.

Post by Martin Eckel
Seltsamerweise lief dort auch der problematische Datensatz
problemlos durch - was mir einiges an Kopfzerbrechen bereitete,
bis mir auffiel, daß ich natürlich nur mit 115200bps reingesendet
hatte (mehr kann der Standard-PC nunmal nicht),

Die Mehrzahl der angebotenen RS232 bzw. V24 Schnittstellen
stellen Übertragungsraten bis 115200 bps bereit. Schnittstellen-
karten, welche höhere Übertragungsraten bereitstellen werden
weit seltener angeboten und haben meist auch entsprechende
Preise.

Post by Martin Eckel
im Realfall die Daten jedoch mit netto ca.
180000bps von meinem Gerät kommen.

Wenn die Daten mit 180.000 pbs getaktet sind, dann wird es auf
der Empfangsseite bei einer Einstellung von 115.200 bps schwierig
bis unmöglich sein, den Empfangsschritttakt entsprechend zu
synchronisieren.

Post by Martin Eckel
Nun habe ich aber noch einen anderen PC hier, welcher eine extra
Schnittstellenkarte bis 921600bps drin hat.

Von welchem Hersteller ist diese Karte und welche
Typenbezeichnung hat diese?

Post by Martin Eckel
Der problematische Datensatz mit 230400bps weggesendet, über
NET wieder empfangen - immer Datenverlust (im übrigen noch mehr
Verluste, als im Realfall mit netto 180000bps).

Wenn Sendeschritttakt und Empfangsschrittakt nicht synchron sind,
bzw. nicht synchronisiert werden können, dann gibt es auch keine
sichere Übertragung.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Martin Eckel]

Hallo,

drücke ich mich wirklich so unverständlich aus?

Naja, kommt wahrscheinlich davon, wenn man nicht von Anfang an das
komplette Bild vermittelt - wobei ich nach wie vor der Meinung bin, daß
das nicht nötig ist, weil die Hardware nichts mit dem Problem zu tun
hat.

Aber damit jetzt ein für alle Mal alle Unklarheiten beseitigt sind:

Es handelt sich um ein Meßgerät, von meiner Firma entwickelt und gebaut.

Dieses Meßgerät hat eine RS232 und eine USB-Schnittstelle.

Die CPU dieses Gerätes hat zwei UARTs on chip. An dem einen UART hängt
(natürlich über Pegelwandler, -buffer) die externe RS232. Die
Pegelwandler schaffen maximal 1MBit/s, so daß ich auf dieser RS232 nicht
nur bis 115200, sondern auch 230400, 460800 und 921600 unterstützen kann
(und prinzipiell noch diverse dazwischen, da der Teiler für den
UART-Takt von einem viel höheren Takt ausgeht). 115200 ist auch nicht
mehr für alle Meßaufgaben ausreichend. Aber der RS232-Port steht
zumindest als Notfall-Option bereit, falls ein Firmware-Update schief
geht um mittels Bootblock eine neue Firmware reinzuladen.

Da ich keine besonderen Funktionen des USB-Ports brauche, sondern
einfach nur die höhere Bandbreite benötige (und weiterhin neue PCs
teilweise keine RS232 mehr haben), sitzt in dem Gerät ein FT2232D USB /
UART Wandler. Dieser hängt am zweiten seriellen Port der CPU mit bis zu
3MBit/s an ultrakurzen Verbindungswegen (und ja, der FT2232D unterstützt
das bei TTL-Pegel - und die CPU auch).

Von FTDI gibt es dann einen fertigen Windows-Treiber, der den Anschluß
via USB in einen virtuellen COM-Port umwandelt.
Die Baudrate, welche man für diesen virtuellen COM-Port einstellt,
bestimmt mit welcher Baudrate die Daten vom FT2232D zur CPU im Gerät
wandern.

Man kann das Gerät also entweder per RS232 oder per USB anschliessen,
für die Software auf dem PC sind beides COM-Ports, der über USB ist halt
ein bißchen schneller ;-)

Und genau bei der Geschwindigkeit über 115200 bps fangen die Probleme
mit dem SerialPort-Objekt an.

Post by Peter Götz

Post by Martin Eckel
Das SerialPort-Objekt ist anscheinend (zumindest bei mir)
nicht in der Lage, Daten mit mehr als 115200bps sicher zu
verarbeiten - und zwar seltsamerweise datenabhängig - wer
weiß, was NET da noch im Hintergrund macht.

Die Datenabhängigkeit erklärt sich daraus, dass es je nach
konkreten Daten mal zu mehr oder weniger Flusswechseln
auf der Leitung und damit zu unterschiedlich hoher Störanfälligkeit
kommt.

NEIN - denn wenn ich die Daten mittels Windows-API abhole, passieren
diese Fehler nicht!

Post by Peter Götz
Was meinst Du mit "wirklicher Baudrate" und "tatsächlicher Datenrate"?

Was hindert mich daran, wenn die Schnittstelle auf 1MBit/s steht, Pausen
zwischen den einzelnen Bytes zu machen?
Dafür ist die RS232 schliesslich asynchron.
Ein 56k-Modem wird auch mit 115200bps angeschlossen, bietet aber nur
56000 tatsächliche Datenrate (Kompression mal ausgenommen).

Post by Peter Götz

Post by Martin Eckel
Heute habe ich zuerst die Datenrate meines USB/Seriell-Ports
von 3000000 auf 460800 bps verringert.

Auch das ist ein Wert, den keine mir bekannte RS232 oder V24
Schnittstellenkarte bereitstellt.

Der FT2232D kann das...
Ich weiß schon, wovon ich rede!

Post by Peter Götz
Da würde mich mal die originale Spezifikation des Herstellers
interessieren.
Welches Gerät von welchem Hersteller ist das?

Mein Gerät :-)

Post by Peter Götz
Wenn Dein Gerät eine USB-Schnittstelle hat, dann verstehe ich
nicht, warum Du für relativ hohe Übertragungsgeschwindigkeiten
nicht eben die dafür ohnehin besser geeignete USB-Schnittstelle
verwendest.

Tu ich ja, s.o.

Post by Peter Götz
Bis hierher verstehe ich nicht wirklich, wie diese Hardware
konkret aussieht, sprich wann bzw. wo USB und wann bzw.
wo RS323 zum Einsatz kommt.

Ich hoffe, jetzt ist das klar.

Post by Peter Götz

Post by Martin Eckel
Nun habe ich aber noch einen anderen PC hier, welcher eine extra
Schnittstellenkarte bis 921600bps drin hat.

Von welchem Hersteller ist diese Karte und welche
Typenbezeichnung hat diese?

EXSYS 4025A - kann auch 230400, 460800 und 921600.



Also nochmal:

Wir haben Datensatz A und B.

An der RS232 meines Gerätes hängt Rechner 1.
Am USB-Port (welcher Windows-Seitig als COM-Port eingebunden wird) hängt
Rechner 2.

Rechner 1 sendet an mein Gerät an den RS232-Port.
Zum Testen habe ich mein Gerät so umprogrammiert, daß es die Daten
sofort an den USB/Seriell Wandler schickt, von da gehts über USB an
Rechner 2, und in Rechner 2 kommen diese am virtuellen COM-Port an.

Die UARTs der CPU in meinem Gerät steht natürlich jeweils auf den
passenden Taktraten.

Der virtuelle COM-Port steht auf 460800 bps (oder auch 3MBit/s, egal),
was bedeutet, daß die Daten zwischen der CPU und dem USB/Seriell Wandler
in meinem Gerät mit 460800bps wandern.

Sendet Rechner 1 Datensatz A oder B mit 115200bps weg, so kommen die
Daten an Rechner 2 natürlich im Mittel auch mit 115200bps an - halt mit
Pausen zwischen den Bytes.
Hierbei gibt es nie ein Problem, egal ob mit dem SerialPort-Objekt oder
direkt mit Windows-API.

Sendet Rechner 1 jedoch Datensatz A mit 230400bps weg, so kommt es auf
Rechner 2 bei Empfang mit dem SerialPort-Objekt IMMER zu Datenverlusten.
Bei Empfang über Windows-API NIEMALS.
Datensatz B wird jedoch auch mit dem SerialPort-Objekt IMMER korrekt
empfangen.

Sobald also die durchschnittliche Datenrate über 115200bps steigt
(unabhängig von der wirklichen Baudrate des COM-Ports) gibt es
datenabhängige Fehler bei Empfang über das Serial-Port Objekt.
Bei einer durchschnittlichen Datenrate von 230400bps sind es mehr Fehler
als bei einer durchschnittlichen Datenrate von 180000bps (so wie die
Daten normal aus meinem Gerät kommen), was vermuten läßt, das es um so
mehr Fehler werden, je schneller man wird.

Da diese Fehler über die Windows-API nicht auftreten, kann mir keiner
erzählen, das seien echte Übertragungsfehler in der Hardware.
Da sich der selbe Datensatz bei niedriger durchschnittlicher Datenrate
problemlos über das SerialPort Objekt übertragen läßt, scheint mir eine
Fehlkonfiguration des SerialPort Objekts meinerseits auch unmöglich.

Deshalb bleibt mir im Moment nur die Schlußfolgerung, das das SerialPort
Objekt mehr als 115200bps durchschnittliche Rate nicht verträgt. Warum
auch immer.


Wie gesagt, ich stelle meinen Datensatz A gerne zu Verfügung. Wer zwei
Rechner hat, welche beide 230400bps können, möge diesen Datensatz bitte
einmal von Rechner 1 zu Rechner 2 mit 230400bps übertragen. Und auf
Rechner 2 mit dem SerialPort Objekt empfangen. Ich bin echt gespannt, ob
dann alles ankommt.

Es wäre natürlich möglich, daß das etwas mit dem virtuellen COM-Port zu
tun hat und es über eine "echte RS232" funktioniert - erklärt aber immer
noch nicht, warum es über die Windows-API immer klappt.

Gruß,
Martin

[Peter Fleischer]

Post by Martin Eckel
...
Von FTDI gibt es dann einen fertigen Windows-Treiber, der den Anschluß
via USB in einen virtuellen COM-Port umwandelt.

Hi Martin,
hast du den Herstaller mal dazu konsultiert? Ich hatte bereits USB-Treiber,
die Com-Ports bereitgestellt haben und bei größeren Übertragungsraten
Probleme brachten. Ich würde erst einmal die Priorität (entsprechend
Beschreibung) hochsetzen.

[Martin Eckel]

Post by Peter Fleischer
hast du den Herstaller mal dazu konsultiert? Ich hatte bereits
USB-Treiber, die Com-Ports bereitgestellt haben und bei größeren
Übertragungsraten Probleme brachten.

Aber warum sollte es dann beim Zugriff direkt über Windows-API keine
Datenverluste geben?
Weiß eigentlich jemand, wie das funktioniert? Setzt das
SerialPort-Objekt auf der API auf, oder mogelt sich NET dran vorbei?

Aber jetzt will ich es wissen - ich werde auch auf dem Rechner mit der
High-Speed-Seriell-Karte die NET-Entwicklungsumgebung installieren und
testen, ob das Problem dort auch auftritt.

Gruß,
Martin

[Peter Götz]

Hallo Martin,

ich nehme mal an, richtig verstanden zu haben, dass
Dein Gerät eine USB-Schnittstelle hat und frage mich
deshalb, warum Du diese nicht mit einem passenden
Treiber (auf Windowsseite) nutzt.

Wie Du ja selbst schon angemerkt hast, werden inzwischen
viele, wenn nicht sogar die meisten PCs ohne konkrete
RS232 - Schnittstelle angeboten. Warum also der Umweg
von USB via USB-RS232-Adapter auf einen Com-Port
bzw. auf einen virtuellen Com-Port? Wäre es nicht deutlich
einfacher und mit weniger "Umwegen" verbunden, einen
USB-Treiber, sofern es diesen nicht schon gibt, für Dein
Gerät zu schreiben?

Für Deine Baudraten mit offenbar bis zu 3.000.000 pbs
würde ich sicher keine Übertragung via RS232 wählen.
Bei meinen Anwendungen, Messdatenerfassung von
Messautomaten in einer industriellen Fertigungs- und
Prüfstrecke wird meist mit max. 57.600 gearbeitet,
was bei den anfallenden Messungen bis zu max. 2 bis 3
Messwerte / Sec. pro Messautomat mehr als ausreichend ist.
Jeder dieser Automaten wird von einem PC kontrolliert bzw.
liefert seine Daten an diesen PC, wo sie aufbereitet und
dann via schnelles LAN auf einem gemeinsamen DB-Server
zusammengeführt werden.

Dort wo höhere Übertragungsraten erforderlich sind, nutze
ich USB-Schnittstellen.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Martin Eckel]

Post by Peter Götz
Hallo Martin,
ich nehme mal an, richtig verstanden zu haben, dass
Dein Gerät eine USB-Schnittstelle hat und frage mich
deshalb, warum Du diese nicht mit einem passenden
Treiber (auf Windowsseite) nutzt.

Anscheinend hast Du mich nicht richtig verstanden.

Das Gerät besitzt eine USB-Schnittstelle, diese wird über einen internen
USB/seriell-Wandler realisiert.

Also:
-------------------------------------------------
| |
| MEIN GERÄT |
| ----------------- --------------- |
| | | | | |
| | CPU mit UART | RXD,TXD | USB/seriell | |
| | on chip |----------| Wandler | |
| | | | | |
| ----------------- --------------| |
| || |
|------------------------------------||---------|
||
|| USB
||
||
------------
| |
| PC |
| |
------------

Mittels des Treibers des Herstellers wird der USB/seriell Wandler am USB
Port des PCs als virtueller COM-Port eingebunden.
Es handelt sich also quasi um einen RS232 Port, welcher im PC emuliert
und dann über USB "getunnelt" wird - mit Datenraten bis zu 3MBit/s,
welche aufgrund der direkten Verbindung USB/seriell Wandler und CPU
problemlos sind.

Dieser USB-Anschluß soll hauptsächlich benutzt werden.

Warum steuer ich nun mit der CPU nicht einen normalen USB-Chip an?
Das habe ich bei einem anderen Gerät bereits einmal gemacht. Das war auf
firmwareseite eine Menge Arbeit, da man sich auch um das ganze
Verwaltungsprotokoll, die Enumeration beim Einstecken usw. kümmern
mußte. Noch mehr Arbeit war es, den USB-Chip dazu überreden, die volle
USB 1.1 Bandbreite auszunutzen.

Auf Windows-Seite war es Arbeit, einen Treiber zu schreiben bzw.
vorhandene Beispiele soweit anzupassen, bis sie zufriedenstellend mit
voller Bandbreite funktionierten.

Ein wahres Chaos war es, dann unter VB6 dieses USB-Gerät auch zu finden
und anzusteuern.

Da ich keinerlei Features von USB wie mehrere PIPEs, Interrupt-Transfers
oder sonstiges brauche, kommt mir die Implementierung als serielle
Schnittstelle ganz zupaß - nur leider bringt das SerialPort-Objekt halt
Datenverlust, sobald die durchschnittliche Rate über 115200bps steigt.

Ich werde das ganze noch mit dem anderen Rechner testen, welcher die
High-Speed-Schnittstellenkarte hat - ob beim Empfang auf diesen Rechner
bei 230400bps auch Datenverluste mit dem SerialPort-Objekt auftreten.
Aber das wird wohl erst nächste Woche etwas.

Gruß,
Martin

[René König]

Hallo!

Post by Martin Eckel
Warum steuer ich nun mit der CPU nicht einen normalen USB-Chip an?
Das habe ich bei einem anderen Gerät bereits einmal gemacht. Das war auf
firmwareseite eine Menge Arbeit, da man sich auch um das ganze
Verwaltungsprotokoll, die Enumeration beim Einstecken usw. kümmern

Na, so viel Arbeit ist das nun auch wieder nicht. Der USB ist
ausreichend simpel gestaltet, von daher verstehe ich das Argument nicht
ganz.

Post by Martin Eckel
mußte. Noch mehr Arbeit war es, den USB-Chip dazu überreden, die volle
USB 1.1 Bandbreite auszunutzen.

Wir haben im Jahre 2000 die Spezifikation 2.0 bekommen. Wann hast Du
Dich denn das letzte Mal mit USB auseinander gesetzt, wenn Du noch nach
1.1 entwickelt hast? Vielleicht solltest Du Dir das einfach nochmals
anschauen. Du wirst sehen, so schlimm ist das nicht. USB ist simpel.

Post by Martin Eckel
Auf Windows-Seite war es Arbeit, einen Treiber zu schreiben bzw.
vorhandene Beispiele soweit anzupassen, bis sie zufriedenstellend mit
voller Bandbreite funktionierten.

Ab Windows 2000 gibt es beinahe ausreichend in das System eingebaute
Treiber, und XP hat nochmals zugelegt. Aber gut, Deine letzte
Entwicklung liegt ja länger zurück. Oder war Dein Gerät tatsächlich
derart speziell?

Post by Martin Eckel
Ein wahres Chaos war es, dann unter VB6 dieses USB-Gerät auch zu finden
und anzusteuern.

Dann hast Du aber ganz eindeutig etwas falsch gemacht. Das ist ja nun
wirklich nicht weiter wild.

Post by Martin Eckel
Da ich keinerlei Features von USB wie mehrere PIPEs, Interrupt-Transfers
oder sonstiges brauche, kommt mir die Implementierung als serielle
Schnittstelle ganz zupaß - nur leider bringt das SerialPort-Objekt halt
Datenverlust, sobald die durchschnittliche Rate über 115200bps steigt.

Was genau heißt "Datenverlust"? Hast Du Deinen Datenverlust mal mit dem
Log des Protokoll-Analyzers verglichen? Fehlen einzelne Bytes einer
Übertragung oder fehlt der komplette Block?


Gruß,
René

[Martin Eckel]

Post by René König
Na, so viel Arbeit ist das nun auch wieder nicht. Der USB ist
ausreichend simpel gestaltet, von daher verstehe ich das Argument nicht
ganz.

Naja gut, die Entwicklung war um das Jahr 2000 herum. Da war es
tatsächlich eine relativ große Programmierarbeit - und um die Hardware
zur realen 1MByte/s zu überreden (also quasi volle USB 1.1 Bandbreite)
war einiges an Trickserei nötig.

Post by René König
Ab Windows 2000 gibt es beinahe ausreichend in das System eingebaute
Treiber, und XP hat nochmals zugelegt. Aber gut, Deine letzte
Entwicklung liegt ja länger zurück. Oder war Dein Gerät tatsächlich
derart speziell?

Ich bin vom BULKUSB des WinDDK ausgegangen. Dieser hatte jedoch so
einige Macken und die volle Bandbreite lief auch nicht sofort. Da ich
bis dahin zwar viel Programmiererfahrung hatte, jedoch noch nie einen
Treiber für Windows programmiert hatte, war das schon ein Abenteuer ;-)

Post by René König

Post by Martin Eckel
Ein wahres Chaos war es, dann unter VB6 dieses USB-Gerät auch zu
finden und anzusteuern.

Dann hast Du aber ganz eindeutig etwas falsch gemacht. Das ist ja nun
wirklich nicht weiter wild.

Den symbolischen Namen fürs CreateFile auf die Pipe zu finden war schon
nicht ganz primitiv. Und viel Beispielcode gabs damals noch nicht.

Kann schon sein, daß das heute alles deutlich einfacher ist.

Post by René König
Was genau heißt "Datenverlust"? Hast Du Deinen Datenverlust mal mit dem
Log des Protokoll-Analyzers verglichen? Fehlen einzelne Bytes einer
Übertragung oder fehlt der komplette Block?

Wie an anderer Stelle erwähnt, bin ich davon überzeugt, daß die Daten
nicht hardwareeitig verloren gehen, sondern irgendwo zwischen
Windows-API und SerialPort-Objekt ins Datennirvana verschwinden.

Der endgültige Test dafür steht noch aus.

Gruß,
Martin

[René König]

Hallo!

Post by Martin Eckel
Naja gut, die Entwicklung war um das Jahr 2000 herum. Da war es
tatsächlich eine relativ große Programmierarbeit - und um die Hardware
zur realen 1MByte/s zu überreden (also quasi volle USB 1.1 Bandbreite)
war einiges an Trickserei nötig.

Das hört sich irgendwie nach einem externen USB-Controller an, wie z.B.
USBN9604 oder PDIUSB11 oder 12, kann das sein?

Wenn Du die USB-Engine direkt auf dem Chip hast, brauchst Du jedenfalls
nicht zu tricksen. Du knallst die Daten in die FIFOs und ab geht's.
Idealerweise hast Du Double-Buffering und fährst sozusagen im Ping-Pong
Modus.

Post by Martin Eckel
Ich bin vom BULKUSB des WinDDK ausgegangen. Dieser hatte jedoch so
einige Macken und die volle Bandbreite lief auch nicht sofort. Da ich
bis dahin zwar viel Programmiererfahrung hatte, jedoch noch nie einen
Treiber für Windows programmiert hatte, war das schon ein Abenteuer ;-)

Das ist natürlich ein Abenteuer. Du hättest aber auch einen der
eingebauten Treiber nehmen können, z.B. den für CDC. Immerhin kann Dir
dann schon mal die Baudrate egal sein, da Du keine Verbindung mehr
zwischen externer Bridge und Deinem Controller hast.

Post by Martin Eckel
Den symbolischen Namen fürs CreateFile auf die Pipe zu finden war schon
nicht ganz primitiv. Und viel Beispielcode gabs damals noch nicht.

Doku gab's damals aber schon, und so schlecht war die auch nicht.

Davon ab: Wenn Du bereits vor 9 Jahren herausgefunden hast, wie USB
funktioniert, warum bist Du nicht dabei geblieben? Beim zweiten Gerät
wär es doch schon deutlich schneller gegangen, beim dritten wieder etwas...

Und für das Geld, das Du für die externe Bridge ausgegeben hast,
bekommst Du schon einen gescheiten Controller, der das alles gleich mit
eingebaut hat. Und an Flexibilität ist das dann auch nicht mehr zu schlagen.

Post by Martin Eckel
Wie an anderer Stelle erwähnt, bin ich davon überzeugt, daß die Daten
nicht hardwareeitig verloren gehen, sondern irgendwo zwischen
Windows-API und SerialPort-Objekt ins Datennirvana verschwinden.

Und ich bin davon überzeugt, dass Du etwas falsch machst. Schließlich
sieht der Host nichts von der eingestellten Baudrate, die ist nur
zwischen Controller und Bridge interessant.

Überzeugung hilft uns also nicht weiter, wir brauchen Fakten.

Post by Martin Eckel
Der endgültige Test dafür steht noch aus.

Ich bin gespannt.


Gruß,
René

[Martin Eckel]

Post by René König
Hallo!
Das hört sich irgendwie nach einem externen USB-Controller an, wie z.B.
USBN9604 oder PDIUSB11 oder 12, kann das sein?

ich glaub der USBN9603 wars...

Post by René König
Wenn Du die USB-Engine direkt auf dem Chip hast, brauchst Du jedenfalls
nicht zu tricksen. Du knallst die Daten in die FIFOs und ab geht's.
Idealerweise hast Du Double-Buffering und fährst sozusagen im Ping-Pong
Modus.

Diesen Ping-Pong Modus konnte der USBN eigentlich nur für isochronen
Transfer. Mittels vieler Tricks und abwechselnder Aktivierung und
Deaktivierung einzelner Endpunkte (mit selber Nummer) gings dann auch
für Bulk-Transfers (ich habe viele Postings gesehen, wo die Leute
gemeckert haben, das mit dem USBN nicht mehr als 500kByte/s gehen)...

Post by René König
Davon ab: Wenn Du bereits vor 9 Jahren herausgefunden hast, wie USB
funktioniert, warum bist Du nicht dabei geblieben? Beim zweiten Gerät
wär es doch schon deutlich schneller gegangen, beim dritten wieder etwas...

Naja, die jetzige Lösung spart trotzdem Entwicklungszeit. Ich bin damit
nicht unbedingt unglücklich. Bei anderen Rahmenbedingungen hätte ich es
vielleicht anders gelöst.

Hängt immer von den Gegebenheiten ab. Für ein anderes Projekt benutze
ich einen Epson LCD-Controller mit USB on chip. Das geht auch ganz gut
(sobald man die Silicon Errata umgangen hat...)

Post by René König
Und ich bin davon überzeugt, dass Du etwas falsch machst. Schließlich
sieht der Host nichts von der eingestellten Baudrate, die ist nur
zwischen Controller und Bridge interessant.

Es geht ja nicht um die Baudrate, sondern um die tatsächliche Datenrate.
Wenn die Baudrate auf 3MBit/s steht, aber die Daten trotzdem nur mit im
Mittel 115200 bps ankommen, dann gibts ja kein Problem. Sobald es mehr
als 115200 bps werden, kommt das Problem.

Post by René König

Post by Martin Eckel
Der endgültige Test dafür steht noch aus.

Ich bin gespannt.

Ich auch.

Gruß,
Martin

[Karsten Sosna]

Post by Martin Eckel
Da ich keine besonderen Funktionen des USB-Ports brauche, sondern
einfach nur die höhere Bandbreite benötige (und weiterhin neue PCs
teilweise keine RS232 mehr haben), sitzt in dem Gerät ein FT2232D USB /
UART Wandler. Dieser hängt am zweiten seriellen Port der CPU mit bis zu
3MBit/s an ultrakurzen Verbindungswegen (und ja, der FT2232D unterstützt
das bei TTL-Pegel - und die CPU auch).

Hallo Martin,
vielleicht solltest Du mal richtig lesen. So steht im Manual:
"...
Transfer Data Rate 300 to 1 Mega Baud (RS232).
Transfer Data Rate 300 to 3 Mega Baud (at TTL levels and RS422 / RS485).
..."
Ich glaube kaum, das Deine Verbindung zur CPU eine RS422 respektive RS485
ist, damit fallen Deine 3 MegaBaud schon mal aus!

"...
RTS/CTS, DSR/DTR and Xon/Xoff handshaking options are also supported.
Handshaking, where required, is handled in hardware to ensure fast response
times.
..."
Da Du wohl weder ein Hardware- noch Softwareprotokoll fährst dürften sich
dann auch die 1 MegaBaud in Luft auflösen.


"...
Baud Rate Generator
The Baud Rate Generator provides a x16 clock input to the UART's from the
48MHz reference clock and consists of a 14 bit prescaler and 3 register bits
which provide fine tuning of the baud rate (used to divide by a number plus
a fraction). This determines the Baud Rate of the UART which is programmable
from 183 baud to 3 million baud.
..."
Und hier hast Du denn Beweis, das Du nicht irgendeine Baud-Rate annehmen
kannst. Da ich selber Bausteine von FTDI(besonders gerne den FT232RL)
berbaue kann ich Dir mit Bestimmtheit sagen, dass das

Post by Martin Eckel

Post by Peter Götz
d) Wie sind SerialPort
.BaudRate

3000000 (nicht wundern, ist ein spezieller USB/Seriell Adapter)

sicherlich nicht stimmt. Denn wenn FTDI von Mega spricht dann sind das 2^20
= 1048576. Ergo bei 3 MegaBaud 3 * 1048576 = 3145728. Hört sich vielleicht
als Kleinkrämmerei an ist aber auf Seite der Übertragung schon ein
gewaltiger Unterschied. Kein Baud-Erkennungsgenerator würde das mitmachen
und schon gar nicht der FT2232D denn da steht definitv das er nur 17 Bit zur
Verfügung hat und erst bei 183 Baud beginnt.

Das Deine Lösung mit der API funktionieren soll, kann ich eigentlich nicht
glauben. Ich gehe mal von einem glücklichen Umstand aus, aber ein Release
sollte das niemals werden! Bedenke: Es gibt immer mindestens 2 Seiten. Einen
Sender und einen Empfänger. Die maximale Übertragungsrate wird immer vom
schwächsten Glied bestimmt. Wenn der Empfänger nur 9600 Baud verträgt, dann
darf der Sender auch nicht mehr anbieten. Und mal ganz davon abgesehen,
Peter G. hatte es auch geschrieben

"Bei meinen Anwendungen, Messdatenerfassung von Messautomaten in einer
industriellen Fertigungs- und Prüfstrecke wird meist mit max. 57.600
gearbeitet,..."

, reicht das völlig aus. das macht bei 1 Startbit, 8 Datenbits 1.5 Stoppbits
und 1 Paritybit(vobei man sich dieses auch noch sparen könnte) immer noch
eine Übertragungsrate von ca 5000 Bytes/s
Entscheidend an dieser Stelle sind von Dir diese Ausagen:

"Aber bei bestimmten Meßsignalen fehlen einfach einige Bytes."
"Da es sich jedoch um Meßwerte handelt, welche nicht jedesmal absolut gleich
sind, kann ich so ohne weiteres gar nicht sagen, welche Werte fehlen."
"Leider habe ich in der Hardware nicht genügend Speicher, um alle Daten
zwischenzuspeichern."

Was soll das werden? Eine Datenschleuder ohne Rückwärtsgang? Selbst im
Studium haben ich und ein "Mitanwärter" ein Projekt realisiert das 256KB
Speicher beinhaltet(Damals war Speicher noch richtig teuer, selbst die
AD-Wandler haben ein kleines Vermögen gekostet).

Faktrum ist, das Du wohl nur einen "vom grossen Marsch" erzählen willst und
nicht einsiehst, das u evtl. schon einen Design-Fehler gemacht hast. Denk da
nochmal drüber nach.
--
Gruß Scotty

[Martin Eckel]

Post by Karsten Sosna
"...
Transfer Data Rate 300 to 1 Mega Baud (RS232).
Transfer Data Rate 300 to 3 Mega Baud (at TTL levels and RS422 / RS485).
..."
Ich glaube kaum, das Deine Verbindung zur CPU eine RS422 respektive RS485
ist, damit fallen Deine 3 MegaBaud schon mal aus!

Vielleicht solltest DU mal richtig lesen.
Wenn Du lesen würdest, was ich schreibe, dann siehst Du, daß ich vom
TTL-Pegel sprach. Und der TTL-Pegel ist ja ausdrücklich im PDF erwähnt
erwähnt.

Da der FT2232D keinen eigenen RS422 Anschluß mitbringt, braucht man
einen extra TTL-RS422 Level Converter um einen RS422 zu realisieren.
Dieser wird natürlich auch über TTL angebunden (siehe Datenblatt Seite 31).
Und ob ich nun über ultrakurze Leitungen einen TTL-RS422 Chip anbinde
oder direkt meine CPU (welche auch mittels TTL-Pegel arbeitet) ist ja
wohl elektrisch völlig wurst.

Außerdem habe ich bereit geschrieben, daß das Problem auch bei 460800
bps auftritt. Also geht Dein Einwand ins Leere.

Post by Karsten Sosna
Da Du wohl weder ein Hardware- noch Softwareprotokoll fährst dürften sich
dann auch die 1 MegaBaud in Luft auflösen.

Meine CPU ist schnell genug, um 3MBit/s selbst ohne FIFO
interruptgesteuert verlustfrei abzunehmen.
Zusätzlich hat sie noch einen 16-Byte FIFO. Und selbstverständlich kommt
noch ein Softwareprotokoll dazu. Jedoch geht das alles am Thema vorbei,
wieso es beim direkten API-Zugriff zu keinen Datenverlusten kommt.

Post by Karsten Sosna
kannst. Da ich selber Bausteine von FTDI(besonders gerne den FT232RL)
berbaue kann ich Dir mit Bestimmtheit sagen, dass das

Post by Martin Eckel

Post by Peter Götz
d) Wie sind SerialPort
.BaudRate

3000000 (nicht wundern, ist ein spezieller USB/Seriell Adapter)

sicherlich nicht stimmt. Denn wenn FTDI von Mega spricht dann sind das 2^20
= 1048576. Ergo bei 3 MegaBaud 3 * 1048576 = 3145728. Hört sich vielleicht
als Kleinkrämmerei an ist aber auf Seite der Übertragung schon ein

FALSCH. Wenn Du Dir Application Note AN232B-05 ansiehst, so wirst Du
sehen, daß es sich um 3000000 bps handelt (Seite 5).
Woher sollte bei einem Eingangstakt von 6.000 MHz multipliziert auf
48MHz auch ein Teiler für 2^20 Baud kommen??

DAS war ja wohl ein glattes Eigentor.

Post by Karsten Sosna
Was soll das werden? Eine Datenschleuder ohne Rückwärtsgang? Selbst im
Studium haben ich und ein "Mitanwärter" ein Projekt realisiert das 256KB
Speicher beinhaltet(Damals war Speicher noch richtig teuer, selbst die
AD-Wandler haben ein kleines Vermögen gekostet).

Es handelt sich um einen Prototyp. Augenscheinlich komme ich problemlos
mit dem Speicher on Chip aus, da eine Übertragung in nahezu Echtzeit
keinerlei Probleme macht (solange ich direkt über die Windows-API zugreife).

Sollte sich diese Annahme als falsch herausstellen, ist es eine
Kleinigkeit, in der Endversion noch einen externen Speicher
hinzuzufügen. Doch das wird nicht nötig sein, da bin ich ziemlich sicher.

Wenn Du die anderen Zweige dieses Threads verfolgt hast, weißt Du, daß
ich hier jetzt einen Datensatz habe, welcher über das SerialPort-Objekt
definitiv Verluste bringt - und über die API nicht.

Wie gesagt, ich werde definitiv nochmal einen Test fahren mit zwei PCs,
welche eine RS232 haben, welche 230400bps kann und ich vermute sehr
stark, daß dort die selben Probleme auftreten - komplett unabhängig von
meiner Hardware.
Aber bis ich dazu komme, dauert noch etwas.

Post by Karsten Sosna
Faktrum ist, das Du wohl nur einen "vom grossen Marsch" erzählen willst und
nicht einsiehst, das u evtl. schon einen Design-Fehler gemacht hast. Denk da
nochmal drüber nach.

Fakt ist, daß mir jeder hier erzählen will, was ich falsch mache - daß
vieles davon aber bewiesenermaßen ziemlicher Unsinn ist und noch keine
echte Erklärung für den Unterschied API und SerialPort-Objekt aufkam -
außer meiner Hypothese, daß das SerialPort-Objekt fehlerhaft ist.

Gruß,
Martin

[Armin Zingler]

Post by Martin Eckel
Fakt ist, daß mir jeder hier erzählen will, was ich falsch mache - daß
vieles davon aber bewiesenermaßen ziemlicher Unsinn ist und noch keine
echte Erklärung für den Unterschied API und SerialPort-Objekt aufkam -
außer meiner Hypothese, daß das SerialPort-Objekt fehlerhaft ist.

Ich verstehe momentan auch nicht, warum das Problem woanders gesucht
wird wenn's ja per API funktioniert.

Trotzdem bin ich eher der Meinung, dass es, mit Verlaub ;), an deinem
Code liegt und nicht am SerialPort-Objekt - kann ich aber natürlich
nicht ausschließen. Mangels Hardware kann ich es nicht nachvollziehen.

Ohne aber irgendwelchen Code gesehen zu haben - oder hast du
mittlerweile welchen gepostet? - und zwar den API und den managed Code,
kann man nun überhaupt nichts dazu sagen. Kannst du nicht ein minmimales
Projekt bereitstellen, mit dem wenigstens du das Problem nachvollziehen
kannst? Ich kann mir/wir können uns dann immerhin den Code ansehen.


Armin

[Martin Eckel]

Post by Armin Zingler
Ich verstehe momentan auch nicht, warum das Problem woanders gesucht
wird wenn's ja per API funktioniert.

Inzwischen habe ich mir eine API-Implementierung für VB.NET aus dem
Internet gezogen (die war für die früheren VB.NET Versionen gedacht,
welche noch kein SerialPort-Objekt hatten). Mit dieser Implementierung
habe ich keinerlei Datenverlust mehr und die Instabilitäten, welche ich
mit meiner selbstgestrickten API-Ansteuerung hatte, sind auch weg -
warum auch immer, ist mir aber im Endeffekt auch egal.

Post by Armin Zingler
Trotzdem bin ich eher der Meinung, dass es, mit Verlaub ;), an deinem
Code liegt und nicht am SerialPort-Objekt - kann ich aber natürlich
nicht ausschließen. Mangels Hardware kann ich es nicht nachvollziehen.

Ich kann es zwar nicht glauben, aber manchmal sieht man ja den Wald nicht...

Post by Armin Zingler
Kannst du nicht ein minmimales
Projekt bereitstellen, mit dem wenigstens du das Problem nachvollziehen
kannst? Ich kann mir/wir können uns dann immerhin den Code ansehen.

Wie gesagt, um die letzten Abhängigkeiten von meiner Hardware
auszumerzen, werde ich noch zwei PCs mit 230400bps koppeln und ein
minimales VB.NET Programm auf dem Empfänger-PC laufen lassen.

Wenn dort das selbe Problem auftritt (und nach meinen bisherigen
Erfahrungen muß es das), werde ich den Code posten.

Dauert aber noch etwas - dafür muß ich nämlich auf dem einen PC noch die
NET-Entwicklungsumgebung installieren und für den Sender-PC mein altes
Notebook ausgraben (welches mittels SHSMOD bzw. hiserial.sys bis zu
921600 bps kann)...

Gruß,
Martin

[Joachim Fuchs]

Hallo Peter,

Post by Peter Götz

Post by Joachim Fuchs
Wesentlich sicherer ist es, einen dedizierten Thread anzulegen
(z. B. Backgroundworker), der in einer Endlosschleife z. B. über
einen StreamReader oder einen BinaryReader von der
Schnittstelle liest, die Daten kontinuierlich aufbereitet und über
eine Queue an andere Programmteile weitergibt.

Genau das ist es, was ich als Lotteriespiel bezeichne.
Mit reinem Polling, ohne definiertes Übertragungsprotokoll
gibt es keine sichere Datenübertragung.

diese Antwort passt überhaupt nicht zu meinem Vorschlag. Von Polling habe
ich nichts geschrieben, Polling ist was ganz anderes. Auch ein
Übertragungsprotokoll lässt sich mit meinem Vorschlag einfach
implementieren, wesentlich einfacher, als mit einer für die eventbasierte
Variante notwendigen Zustandsmaschine.

Post by Peter Götz

Post by Joachim Fuchs
Bei dieser Variante lassen sich auch leicht andere Codierungen
mit unterschiedlichen Byte-Längen (z. B. UTF8) dekodieren,
was bei der Ereignisgesteuerten Variante recht kompliziert wird.

Bei der Datenübertragung via RS232 / V24 gibt es entweder 7 oder
8 Bits pro Byte und bei rein byteorientierter Arbeitsweise sind
Codierungen wie UTF8 und andere für den reinen Übertragungsweg
völlig ohne Bedeutung.

Welche Art von Daten übertragen werden, ist doch anwendungsspezifisch. Ich
hatte durchaus schon den Fall, dass UTF8-kodierte Texte übertragen werden
sollten. Wenn man dann die Framework-Implementierungen für die Umwandlung
nutzen will, kann man nicht die Bytes einzeln lesen, sondern muss das Lesen
den vorhandenen Methoden überlassen. Streams sind in diesem Fall wesentlich
eleganter.

Post by Peter Götz

Post by Joachim Fuchs
- Überlauf des Zwischenpuffers, wenn der Thread nicht oft
genug die Daten abholen kann

Alleine schon das ein ausreichender Grund nicht mit simplem
Polling zu arbeiten.

Wie gesagt, mit Polling hat mein Vorschlag überhaupt nichts zu tun.

Post by Peter Götz
Eine ganz andere Frage wäre noch, ob für eine Übertragungs-
rate von 3.000.000 Baud oder sogar noch mehr eine
Übertragung via RS232 / V24 das geeignete Verfahren ist.

das ist es ganz sicher nicht. Grundsätzlich halte ich das
Übertragungsverfahren, was ja ursprünglich eher für Geräte wie Fernschreiber
gedacht war, für völlig überholt und nicht mehr zeitgemäß. Aber leider gibt
es vorzugsweise im Industriebereich ja immer noch viele Geräte, die damit
arbeiten.

Gruß
Joachim

[Peter Götz]

Hallo Joachim,

Post by Joachim Fuchs

Post by Peter Götz

Post by Joachim Fuchs
Wesentlich sicherer ist es, einen dedizierten Thread anzulegen
(z. B. Backgroundworker), der in einer Endlosschleife z. B. über
einen StreamReader oder einen BinaryReader von der
Schnittstelle liest, die Daten kontinuierlich aufbereitet und über
eine Queue an andere Programmteile weitergibt.

Genau das ist es, was ich als Lotteriespiel bezeichne.
Mit reinem Polling, ohne definiertes Übertragungsprotokoll
gibt es keine sichere Datenübertragung.

diese Antwort passt überhaupt nicht zu meinem Vorschlag. Von Polling
habe ich nichts geschrieben, Polling ist was ganz anderes.

Polling meint, dass zyklisch (in einer Schleife) immer wieder
versucht wird zu lesen. Da Du von einer "Endlosschleife"
geschrieben hast, interpretiere ich das erst mal als Polling.

Post by Joachim Fuchs
Auch ein Übertragungsprotokoll lässt sich mit meinem Vorschlag
einfach implementieren,

Ja, natürlich ist es auch damit möglich, irgendeine Art von
Übertragungsprotokoll zu realisieren.

Post by Joachim Fuchs
wesentlich einfacher, als mit einer für die eventbasierte
Variante notwendigen Zustandsmaschine.

Warum es einfacher sein sollte, sehe ich nicht unbedingt.
Aber einfacher oder weniger einfach ist eher eine
subjektive Betrachtungsweise.
Natürlich sind z.B. HDLC, MSV1 oder MSV2 keine
ausgesprochen simplen Übertragungsprotokolle, aber
einmal in einer entsprechenden Klasse verpackt, ist die
Verwendung solcher Klassen kein nennenswertes Problem
mehr.

Post by Joachim Fuchs

Post by Peter Götz

Post by Joachim Fuchs
Bei dieser Variante lassen sich auch leicht andere Codierungen
mit unterschiedlichen Byte-Längen (z. B. UTF8) dekodieren,
was bei der Ereignisgesteuerten Variante recht kompliziert wird.

Bei der Datenübertragung via RS232 / V24 gibt es entweder 7 oder
8 Bits pro Byte und bei rein byteorientierter Arbeitsweise sind
Codierungen wie UTF8 und andere für den reinen Übertragungsweg
völlig ohne Bedeutung.

Welche Art von Daten übertragen werden, ist doch anwendungsspezifisch.

Ja, natürlich.
Alle Postings von Martin, legen aber den Schluss nahe, dass er
rein byteorientiert arbeitet. Da Martin bisher keinerlei relevanten
Code gezeigt hat, ist das natürlich auch nur eine Vermutung.

Post by Joachim Fuchs
Ich hatte durchaus schon den Fall, dass UTF8-kodierte Texte übertragen
werden sollten.

Keine Frage, dass dies möglich ist und auch in vielen
Fällen so gemacht wird. Nur eben in diesem Fall geht
es offensichtlich um rein byteorientierte Übertragung.

Post by Joachim Fuchs
Wenn man dann die Framework-Implementierungen für die
Umwandlung nutzen will, kann man nicht die Bytes einzeln lesen,
sondern muss das Lesen den vorhandenen Methoden überlassen.
Streams sind in diesem Fall wesentlich eleganter.

s.oben:
Bezug auf rein byteorientierte Arbeitsweise

Post by Joachim Fuchs

Post by Peter Götz

Post by Joachim Fuchs
- Überlauf des Zwischenpuffers, wenn der Thread nicht oft
genug die Daten abholen kann

Alleine schon das ein ausreichender Grund nicht mit simplem
Polling zu arbeiten.

Wie gesagt, mit Polling hat mein Vorschlag überhaupt nichts zu tun.

Letztlich ist eine Endlosschleife eben doch Polling und die
Gefahr von Pufferüberläufen, sollte man für eine sichere
Datenübertragung eben von vorneherein ausschliessen,
wozu dann eben Ereignissteuerung ein probates Mittel ist.

Post by Joachim Fuchs

Post by Peter Götz
Eine ganz andere Frage wäre noch, ob für eine Übertragungs-
rate von 3.000.000 Baud oder sogar noch mehr eine
Übertragung via RS232 / V24 das geeignete Verfahren ist.

das ist es ganz sicher nicht.

Ja, zumindest gibt es für solche Übertragungsgeschwindigkeiten
deutlich besser geeignete Techniken.

Wobei ich bisher noch immer nicht verstanden habe,
wozu Martin diese für RS232 unüblich hohen Übertragungsraten
überhaupt braucht.
Da es augenscheinlich um die Übertragung von Messwerten
geht, womit ich auch ständig zu tun habe, verstehe ich (noch
immer) nicht, warum "normale" Übertragungsraten bis max.
115.200 bps in Martins Fall nicht ausreichen.

Post by Joachim Fuchs
Grundsätzlich halte ich das Übertragungsverfahren, was ja
ursprünglich eher für Geräte wie Fernschreiber gedacht war,

Na ja, auf ausschliesslich Fernschreiber würde ich das nun
nicht beschränken wollen. So wurde z.B. der Datenaustausch
zwischen Rechnern der Siemens Transdata - Reihe und auch
der Datenaustausch zwischen diesen Rechnern und einer
Vielzahl von unterschiedlichsten Endgeräten über V24 -
Schnittstellen via MSV1/2- bzw. LSV1/2- Prozeduren abgewickelt.
Beim Datenaustausch zwischen den Transdata-Rechnern kam
bevorzugt HDLC als Übertragungsprotokoll zum Einsatz. Filialen
verschiedener Banken waren z.B. auf diese Weise landesweit
vernetzt.

Post by Joachim Fuchs
für völlig überholt und nicht mehr zeitgemäß.

Das würde ich in dieser Absolutheit nicht unterschreiben.
In vielen Fällen ist der Einsatz von V24 / RS232 - Schnittstellen
nach wie vor sinnvoll und dabei sicher und kostengünstig.

Post by Joachim Fuchs
Aber leider gibt es vorzugsweise im Industriebereich ja immer
noch viele Geräte, die damit arbeiten.

Ja, im Industriebereich sind V24 - resp. RS232 - Schnittstellen
nach wie vor sehr häufig anzutreffen und ich verstehe nicht, warum
man das mit dem Prädikat "leider" belegen sollte. In einem
industriellen Umfeld gibt es eben ganz andere Anforderungen als
z.B. in einem privaten Umfeld mit Multimedia und anderen
Spielchen und das wird natürlich auch bei der verwendeten Hardware
sichtbar.
Ich habe eine ganze Reihe von Anwendungen in einem solchen
industriellen Fertigungsbereich im Einsatz, bei denen ein
Datenaustausch zwischen PCs und den unterschiedlichsten Endgeräten
via V24 / RS232 - Schnittstelle ohne Probleme abgewickelt wird.
Da diese Endgeräte auch gar keine anderen Schnittstellen
zur Verfügung stellen, muss über Alternativen nicht diskutiert
werden.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Joachim Fuchs]

Hallo Peter,

Post by Peter Götz
Polling meint, dass zyklisch (in einer Schleife) immer wieder
versucht wird zu lesen. Da Du von einer "Endlosschleife"
geschrieben hast, interpretiere ich das erst mal als Polling.

der Schleifenaufbau hat doch nichts mit der Zugriffsart zu tun.

Post by Peter Götz

Post by Joachim Fuchs
wesentlich einfacher, als mit einer für die eventbasierte
Variante notwendigen Zustandsmaschine.

Warum es einfacher sein sollte, sehe ich nicht unbedingt.

Post by Joachim Fuchs
Wie gesagt, mit Polling hat mein Vorschlag überhaupt nichts zu tun.

Letztlich ist eine Endlosschleife eben doch Polling ...

nein.

Beispiel:

Private Sub BackgroundWorker1_DoWork(...) Handles BackgroundWorker1.DoWork
Dim comport As SerialPort = CType(e.Argument, SerialPort)
comport.Open() ' Das ffnen kann auch bereits im GUI-Thread erfolgen
' sonstige Initialisierungen des Comports bzw. Gertes
' Endlosschleife, bis explizit abgebrochen wird
Do Until BackgroundWorker1.CancellationPending
' Blockierender Aufruf von Readline bis Zeile empfangen wurde
Dim msg As String = comport.ReadLine()
' oder andere blockierende Read-Methoden wie z. B. comport.Read(...)

' Protokoll abarbeiten, bis Verarbeitungseinheit (Datensatz o. .)
erreicht
' dann Weitergabe der fertigen Datenblöcke mit
BackgroundWorker1.ReportProgress(0, msg)

' ggfs. Aufforderung an Gegenseite schicken
' comport.Write("?" & vbCr) o. ä.
Loop
e.Cancel = BackgroundWorker1.CancellationPending
comport.Close()
End Sub

oder einen StreamReader oder BinaryReader auf comport.BaseStream aufsetzen
und die jeweiligen Methoden zum Einlesen der Daten verwenden. Kein Polling,
Lesevorgänge blockieren den Thread, bis alle angeforderten Bytes eingelesen
worden sind oder ein Timeout aufgetregen ist.

Gruß
Joachim

[Peter Götz]

Hallo Joachim,

Post by Joachim Fuchs
Private Sub BackgroundWorker1_DoWork(...) Handles
BackgroundWorker1.DoWork
Dim comport As SerialPort = CType(e.Argument, SerialPort)
comport.Open() ' Das ffnen kann auch bereits im GUI-Thread erfolgen
' sonstige Initialisierungen des Comports bzw. Gertes
' Endlosschleife, bis explizit abgebrochen wird
Do Until BackgroundWorker1.CancellationPending
' Blockierender Aufruf von Readline bis Zeile empfangen wurde
Dim msg As String = comport.ReadLine()

Es geht um byteweise Arbeitsweise,
womit ReadLine erst mal ausscheidet.

Post by Joachim Fuchs
' oder andere blockierende Read-Methoden wie
z. B. comport.Read(...)
' Protokoll abarbeiten, bis Verarbeitungseinheit (Datensatz o. .)
erreicht
' dann Weitergabe der fertigen Datenblöcke mit
BackgroundWorker1.ReportProgress(0, msg)
' ggfs. Aufforderung an Gegenseite schicken
' comport.Write("?" & vbCr) o. ä.

Das wäre dann eine Art "minimalistisches Protokoll",
was z.B. bei Verwendung von HDLC-, MSV- oder
sonstigen gesicherten Übertragungsprotokollen völlig überflüssig
wäre, das solche Protokolle das Wechselspiel zwischen
Daten lesen, Sendeaufforderung und Senden der beiden
Endgeräte schon regeln.

Post by Joachim Fuchs
Loop
e.Cancel = BackgroundWorker1.CancellationPending
comport.Close()
End Sub
oder einen StreamReader oder BinaryReader auf comport.BaseStream
aufsetzen und die jeweiligen Methoden zum Einlesen der Daten
verwenden. Kein Polling, Lesevorgänge blockieren den Thread,
bis alle angeforderten Bytes eingelesen
worden sind oder ein Timeout aufgetregen ist.

Ich sehe nicht, was eine solche Arbeitsweise gegenüber
einer Ereignissteuerung verbessern sollte.
Für mich wäre das keine Alternative.
Da ziehe ich in jedem Fall Ereignissteuerung und eine
gesicherte Übertragungsprozedur vor.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Joachim Fuchs]

Hallo Peter,

Post by Peter Götz
Ich sehe nicht, was eine solche Arbeitsweise gegenüber
einer Ereignissteuerung verbessern sollte.
Für mich wäre das keine Alternative.
Da ziehe ich in jedem Fall Ereignissteuerung und eine
gesicherte Übertragungsprozedur vor.

die ereignisgesteuerte Vorgehensweise besitzt keinerlei Vorteile gegenüber
meinem Ansatz. Alles, was damit erreichbar und umsetzbar ist, kann ich
genauso gut in einem einzigen Hintergrundthread mit blockierenden
Methodenaufrufen erledigen. Es ergibt sich dadurch eine einfachere
Programmierung, da eine komplexe Zustandsmaschine entfällt.

Abgesehen von der vereinfachten Programmierung kommt meine Lösung mit
wesentlich geringerem Overhead aus. Bei der ereingnisgesteuerten Variante
muss für jedes Event wieder ein Thread aus dem Threadpool aktiviert werden.
Wenn man dann auf jedes Byte einzeln reagieren will, werden unnötig
Ressourcen gebunden.

Gruß
Joachim

[Peter Götz]

Hallo Joachim,

Post by Joachim Fuchs
die ereignisgesteuerte Vorgehensweise besitzt keinerlei
Vorteile gegenüber meinem Ansatz.

Was ich wg. prakt. Erfahrung bezweifle.

Post by Joachim Fuchs
Alles, was damit erreichbar und umsetzbar ist, kann ich
genauso gut in einem einzigen Hintergrundthread mit
blockierenden Methodenaufrufen erledigen.

Ja, letztlich kann man den gesamten Ablauf einer HDLC-
Procedur in solchen Methoden nachbilden.

Post by Joachim Fuchs
Es ergibt sich dadurch eine einfachere
Programmierung, da eine komplexe Zustandsmaschine
entfällt.
Abgesehen von der vereinfachten Programmierung kommt
meine Lösung mit wesentlich geringerem Overhead aus.

Die von Dir gezeigte Lösung hat nun aber recht wenig
mit einem "gesicherten Übertragungsprotokoll" zu tun.
Ein gesichertes Übertragungsprotokoll erfordert einiges
mehr als lediglich eine erneute Sendeaufforderung, wenn
ein TimeOut aufgetreten ist. Ich empfehle hier das Studium
der Dokumentation zu Übertragungsprotokollen wie HDLC,
MSV1 oder MSV2.

Post by Joachim Fuchs
Bei der ereingnisgesteuerten Variante muss für jedes
Event wieder ein Thread aus dem Threadpool aktiviert
werden.
Wenn man dann auf jedes Byte einzeln reagieren will,
werden unnötig Ressourcen gebunden.

Ich verstehe nicht, was Du mit "auf jedes Byte einzeln
reagieren" meinst. Bei der Übertragung von Binärdaten
wird einem nichts anderes übrigbleiben, als auf jedes Byte
zu reagieren, bzw. es zu analysieren und entsprechend zu
bewerten. Wie sonst sollte man bei gesicherten Prozeduren
Synchronisationszeichen, Steuerbytes und Blocksicherungs-
zeichen erkennen?

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Joachim Fuchs]

Hallo Peter,

Post by Peter Götz
Die von Dir gezeigte Lösung hat nun aber recht wenig
mit einem "gesicherten Übertragungsprotokoll" zu tun.
Ein gesichertes Übertragungsprotokoll erfordert einiges
mehr als lediglich eine erneute Sendeaufforderung, wenn
ein TimeOut aufgetreten ist. Ich empfehle hier das Studium
der Dokumentation zu Übertragungsprotokollen wie HDLC,
MSV1 oder MSV2.

Du vermischst hier Dinge, die nichts miteinander zu tun haben. Es geht mir
ausschließlich um die Technik, sicher die einzelnen Bytes von der seriellen
Schnittstelle entgegen zu nehmen bzw. zu senden. Übertragungsprotokolle sind
eine Abstraktionsebene höher und setzen auf dieser Technik auf. Sie lassen
sich sowohl mit der ereignisgesteuerten als auch mit der Stream-basierten
Variante umsetzen.

Viele Grüße
Joachim

[Armin Zingler]

Post by Martin Eckel
Beim Zugriff über NET lese ich über SerialPort.Read immer alle
vorhandenen Daten aus und zwar gleich an die richtige Stelle des
Byte-Array, so daß ich am Ende alle Daten im Byte-Array habe.
Aber es fehlen halt manchmal welche.

Da ich immer noch nicht sehe, wie du das machst, kann ich auch keinen
Fehler suchen und erkennen.

Post by Martin Eckel
Ich kann aber Montag gern noch mal ein Code-Fragment reinstellen.

Ok.



Armin

[Martin Eckel]

Post by Armin Zingler
Da ich immer noch nicht sehe, wie du das machst, kann ich auch keinen
Fehler suchen und erkennen.

Ich sage Dir aber, der Fehler liegt nicht in meiner Verarbeitung der Daten.

Wenn ich SerialPort.ReadBufferSize so groß mache, daß alle Daten dort
hineinpassen und dann nichts anderes mache, als zu warten bis
SerialPort.BytesToRead die gewünschte Menge an Daten im Buffer anzeigt,
so passiert genau das selbe.

Mit den einen Daten klappt es immer, im Buffer sind soviele Zeichen wie
erwartet und mit den anderen Daten klappt es nie, es sind immer zu
wenige Zeichen.

Das Problem kann also nur irgendwo in der Konfiguration des
SerialPort-Objekts liegen - oder es ist gar ein grundsätzliches Problem
des SerialPort-Objekts!?

Leider sind die Daten wie gesagt Meßdaten, und somit nicht jedesmal
exakt gleich - sonst könnte ich ja wenigstens zweimal dasselbe
empfangen, einmal über NET und einmal über API und vergleichen...

Gruß,
Martin

[Armin Zingler]

Post by Martin Eckel
Das Problem kann also nur irgendwo in der Konfiguration des
SerialPort-Objekts liegen -

kann sein

Post by Martin Eckel
oder es ist gar ein grundsätzliches Problem
des SerialPort-Objekts!?

Dann hätte der Hersteller jetzt ein größeres Problem. :)


Armin

[Martin Eckel]

Post by Armin Zingler
Dann hätte der Hersteller jetzt ein größeres Problem. :)

Naja, es wäre nicht das erste Mal, daß man über Seltsamkeiten stolpert.

Warum gibt es in der MSDN-Doku zB. keinen Hinweis, das das Zeichnen
eines Polygonzuges mittels API unter Win9x nur bis zu 16384 Punkten
funktioniert....? Da hab ich auch erstmal dumm geguckt damals...

Gruß,
Martin

[Armin Zingler]

Post by Martin Eckel

Post by Armin Zingler
Dann hätte der Hersteller jetzt ein größeres Problem. :)

Naja, es wäre nicht das erste Mal, daß man über Seltsamkeiten stolpert.
Warum gibt es in der MSDN-Doku zB. keinen Hinweis, das das Zeichnen
eines Polygonzuges mittels API unter Win9x nur bis zu 16384 Punkten
funktioniert....? Da hab ich auch erstmal dumm geguckt damals...

Ich meinte eher damit, dass du dann nicht der einzige wärst. Da ich noch
nichts von einem generellen Problem gehört hab - was nichts heißen muss
- gehe ich davon aus, dass es individuelle Seltsamkeiten sind. ;)


Armin

[Martin Eckel]

Post by Armin Zingler
- gehe ich davon aus, dass es individuelle Seltsamkeiten sind. ;)

Das Problem ist wohl, daß ich wirklich allgemein bekannte Seltsamkeiten
schon früher durch eine Google-Suche gefunden hätte.

Somit passiert es mir oft, daß mir bei den Problemen, bei denen ich dann
hängen bleibe, keiner mehr helfen kann...

Aber ich werde berichten, wenn ich eine Lösung finde.


Gruß,
Martin

[Peter Götz]

Hall Martin,

Post by Martin Eckel
ich habe hier ein Projekt, welche relativ große Datenmengen
über die serielle Schnittstelle empfängt.
Dazu benutze ich System.IO.Ports - leider kommt es ab und
an zu Datenverlusten.

Armin hat Dich schon darauf aufmerksam gemacht, dass
etwas relevanter Code hilfreich wäre, um Dein Problem
erkennen zu können.
Ansonsten schau Dir mal

www.gssg.de -> Visual Basic -> VB.net
-> Serial Port (RS232) Chat

an. Vielleicht findest Du darin ja schon irgendeinen
Hinweis.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[Karsten Sosna]

Post by Martin Eckel
ich habe hier ein Projekt, welche relativ große Datenmengen über die
serielle Schnittstelle empfängt.
Dazu benutze ich System.IO.Ports - leider kommt es ab und an zu
Datenverlusten.
Seltsamerweise sind diese Datenverluste abhängig von den Daten - die
Datenmenge ist immer gleich, das ist kein Problem. Aber bei bestimmten
Meßsignalen fehlen einfach einige Bytes.
Zum Auslesen benutze ich SerialPort.Read in ein Byte-Array, so sollte es
nach meinem Verständnis kein Problem mit Codierungseinstellungen geben.
DiscardNull steht auch auf False.
Wenn ich die serielle Schnittstelle wie unter VB6 direkt mittels API
ansteuere, so habe ich dieses Problem nicht. Leider kommt es aber bei der
direkten API-Ansteuerung zu Instabilitäten beim Programmablauf, was mir
nicht wirklich klar ist.

Hallo Martin,
es liegt sicherlich(auch bei der VB6-Übertragung) darin, das Dir die
Datenübertragung nich ganz klar ist. :=(
Über die serielle Schnittstelle werden die Daten asynchron übertragen. Will
heissen das Paket was Du bekommst ggf. noch nicht komplett ist. Der
Datenstrom muss also erst synchronisiert werden, bevor erst ausgewertet
werden kann. Dafür gibt es aber keine allgemein gültige Lösung, sondern die
muss je nach Protokoll selber implementiert werden. Dazu gehören das
einhalten des Protokolls und ggf. irgendwelcher Timeouts. Wie das genau
geschieht hängt vom verwendeten Protokoll ab. Da jeder Hersteller sein
eigenes Süppchen kocht ist die Auswahl am Suppenbüffet dementsprechend groß.
;=)
Grundsätzlich gibt es aber 2 Protokollarten:
Textbasierende Protokolle - Sie beginnen grundsätzlich mit irgendeinem
Zeichen aus dem dem ASCII-Alphabet das kleiner ist als &H20 bzw.
SOT(StartOfText) und enden wenn Du Glück hast mit EOT(EndOfText).
Byteorientierte Prokolle - Sie beginnen ebenfalls mit ein Startbyte oder
einer Bytefolge die zur Synchronisation dient. Eigentlich folgt dann ein
Header in dem u.a. die Anzahl der zu erwartenden Bytes übertragen wird. Im
gesatz zu textbasierenden Protokollen können auch Zeichen beinhaltet sein
die kleine als ASCII &H20 sind(Bei textbasierenden kann das auch der Fall
sein bzw. CR oder LF). Bei Byteorientierten Protokolle werden aber keine
Steuzeichen(ASCII < &H20) ausgewertet.
Vorteil an byteorientierten Protokollen ist, das die Datenübertragung bei
bzw. Messdaten schneller geht, da weniger Daten übertragen werden müssen.
Ausführen möchte ich das nicht, das haben andere schon weit vor mir getan.

BTW.: Da wir schon wieder bei dem Thema sind. Seriel-Ports sind bei weitem
nicht legacy. Problem ist halt nur das viele PC-Hersteller keine RS232 oder
RS485 Anschlüsse bereitsellen, dafür aber dutzende von USB-Anschlüssen. Wer
aber trotzdem auf ein Serial-Port ala RS232, RS422, RS485 angewiesen sollte
sich dieses Ding mal anschauen.
http://www.ftdichip.com/Products/FT232R.htm
Dieser Baustein braucht vielleicht noch einen Kondensator in der
Spannungsversorgung, kein externes EPROM, kein Treiber(wird selbst von
Windows 7 erkannt).Die Übertragungsrate geht von 300Baud bis 3MBaud und ist
USB2.0-High-Speed kompatibel.
Ich persönlich nutze den FT232RL zur Buskontrolle mehrerer I²C-Busse, das
Ding ist einfach genial und vor allem billig:
http://such001.reichelt.de/?SID=***@Ayf6wQAQ8AAFwSllg9813e82cf3bb112812b0ce2426414334;ACTION=444
Gut, SSOP28-Package, braucht etwas Geduld um ihn zu verlöten, also mit einem
Baumarkt-Lötkolben ist das nicht zu schaffen. Da heben sich wohl eher die
Pads ab oder man hat ihn durch die Hitze in die "ewigen Jagdgründe der
Elektronik gesandt";=)
TIPP an dieser Stelle:
Wer solche Bauteile ein- oder auslöten muss dem sei ein temperaturgeregleter
Heizlüfter angeraten.Temperatur auf ca. 350-380°C. Bauteil nur kurz
aufheizen(2-5sec) und schon kann mann es mit einer Pinzette abheben. Beim
Einlöten Lötpaste benutzen. Auf die Pads hauchdünn(0,1-0,2mm)
auftragen(Achtung Brücken vermeiden). Danach den Baustein aufsetzen und
unterwärts mit etwas Sekundenkleber oder spezieller Klemme fixieren.
Fixieren ist wichtig, da der Baustein sich durch den Druck des Heizlüfters
verschieben könnte. Danach den Heizlüfter kurz über die Anschlußbeine führen
bis Lötpaste silbrig wird(ist normalerweise Grau). Geübt braucht man für
SSOP28 keine Sekunde, alles was darüber hinaus geht, lässt den Baustein,
egal welcher, eh einen Hitzetod sterben.
Diese Verfahren stammt übrigens aus der Industrie und ist neben einer
Lötwelle das am meisten angewendete.
--
Gruß Scotty

[René König]

Hallo!

Post by Karsten Sosna
BTW.: Da wir schon wieder bei dem Thema sind. Seriel-Ports sind bei weitem
nicht legacy. Problem ist halt nur das viele PC-Hersteller keine RS232 oder
RS485 Anschlüsse bereitsellen, dafür aber dutzende von USB-Anschlüssen. Wer

Es gibt die Anschlüsse nicht mehr, von daher würde ich das schon als
legacy einstufen.

Post by Karsten Sosna
aber trotzdem auf ein Serial-Port ala RS232, RS422, RS485 angewiesen sollte
sich dieses Ding mal anschauen.
http://www.ftdichip.com/Products/FT232R.htm

Das Ding ist lediglich für Bastler interessant, oder aber man muss sich
mit legacy Hardware auseinandersetzen. Für neue Entwicklungen ist das
gar nichts.

Post by Karsten Sosna
Dieser Baustein braucht vielleicht noch einen Kondensator in der
Spannungsversorgung, kein externes EPROM, kein Treiber(wird selbst von

Zusätzlich braucht der Baustein Strom und Platz auf der Platine.

Post by Karsten Sosna
Windows 7 erkannt).Die Übertragungsrate geht von 300Baud bis 3MBaud und ist
USB2.0-High-Speed kompatibel.

USB2.0 ja, High-Speed nein. Der kann nur Full-Speed, siehe Datenblatt.

Post by Karsten Sosna
Ich persönlich nutze den FT232RL zur Buskontrolle mehrerer I²C-Busse, das

Ich persönlich benutze den gar nicht, da er tatsächlich billig ist.
Schade nur, dass es den Baustein nicht in preiswert gibt.

Post by Karsten Sosna
Gut, SSOP28-Package, braucht etwas Geduld um ihn zu verlöten, also mit einem
Baumarkt-Lötkolben ist das nicht zu schaffen. Da heben sich wohl eher die

Ein SSOP28 schafft jeder Baumarkt-Kolben, aber wohl nicht das QFN. Aber
auch das geht per Hand.


Gruß,
René

[Peter Götz]

Hallo René,

Post by René König

Post by Karsten Sosna
BTW.: Da wir schon wieder bei dem Thema sind. Seriel-Ports
sind bei weitem nicht legacy. Problem ist halt nur das viele
PC-Hersteller keine RS232 oder RS485 Anschlüsse bereitsellen,
dafür aber dutzende von USB-Anschlüssen. Wer

Es gibt die Anschlüsse nicht mehr, von daher würde ich das schon
als legacy einstufen.

Nur weil viele Hersteller von Standard-PC solche Schnittstellen
nicht mehr in ihre Geräte einbauen, heisst das noch lange nicht,
dass es solche Schnittstellen nicht mehr gibt.
Im industriellen Umfeld werden diese Schnittstellen nach wie vor
genutzt und natürlich gibt es eine ganze Reihe von Herstellern,
die Schnittstellenkarten (V24 bzw. RS232) anbieten, mit denen
sich sowohl Standard-PC als auch spezielle für den industriellen
Einsatz konzipierte PC ausrüsten lassen.

Datenverarbeitung beschränkt sich nicht nur auf Office-Anwendungen
und Multimedia-Spielereien und so sind Schnittstellen wie V24 / RS232
u.ä. ser. Schnittstellen im industriellen Umfeld nach wie vor gebräuchlich
und werden es wohl noch über längere Zeit bleiben.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[René König]

Hallo!

Post by Peter Götz
Nur weil viele Hersteller von Standard-PC solche Schnittstellen
nicht mehr in ihre Geräte einbauen, heisst das noch lange nicht,
dass es solche Schnittstellen nicht mehr gibt.

Es wird aber deutlich weniger, da eindeutig legacy.

Post by Peter Götz
Im industriellen Umfeld werden diese Schnittstellen nach wie vor
genutzt und natürlich gibt es eine ganze Reihe von Herstellern,

Leider viel zu häufig, aber es wird ja zum Glück weniger.

Post by Peter Götz
die Schnittstellenkarten (V24 bzw. RS232) anbieten, mit denen
sich sowohl Standard-PC als auch spezielle für den industriellen
Einsatz konzipierte PC ausrüsten lassen.

Für legacy Systeme und die ewig Gestrigen ist das auch das Einzige das
bleibt. ;-)

Post by Peter Götz
Datenverarbeitung beschränkt sich nicht nur auf Office-Anwendungen
und Multimedia-Spielereien und so sind Schnittstellen wie V24 / RS232

Das ist mir schon klar, denn die bediene ich nicht. Wir sind auch
überwiegend im industriellen Umfeld unterwegs. Bei uns geht der Trend
aber ganz eindeutig weg vom 08/15 UART.

Post by Peter Götz
u.ä. ser. Schnittstellen im industriellen Umfeld nach wie vor gebräuchlich
und werden es wohl noch über längere Zeit bleiben.

Leider.


Gruß,
René

[Peter Götz]

Hallo René,

Post by René König

Post by Peter Götz
Im industriellen Umfeld werden diese Schnittstellen
nach wie vor genutzt und natürlich gibt es eine ganze
Reihe von Herstellern,

Leider viel zu häufig, aber es wird ja zum Glück weniger.

Meine Anwendungen laufen nahezu ausschliesslich in
industriellen Fertigungsabläufen und eben dort hat sich
an der Verwendung von ser. Schnittstellen wie z.B. V24 /
RS232 wenig bis gar nichts geändert.

Post by René König

Post by Peter Götz
die Schnittstellenkarten (V24 bzw. RS232) anbieten,
mit denen sich sowohl Standard-PC als auch spezielle
für den industriellen Einsatz konzipierte PC ausrüsten
lassen.

Für legacy Systeme und die ewig Gestrigen ist das auch
das Einzige das bleibt. ;-)

Na, ich denke nicht, dass man Industrieunternehmen wie
z.B Osram oder ähnliche als "ewig Gestrige" einstufen
kann / sollte.
Kein vernünftig geführtes Unternehmen wird Produktions-
straßen, die oft mehrere Millionen teuer sind, alle Nase
lang wegwerfen und durch andere ersetzen, nur weil man
bei Standard-PCs mehr und mehr auf RS232-Schnittstellen
verzichtet. Ich vermute mal, Du hast wenig bis gar keinen
Einblick in Fertigungsabläufe bei grossen, mittleren und
auch kleinen Industrieunternehmen. Hier werden Investitionen
nicht nach Modetrends getätitigt, sondern nach den jeweils
gegebenen Erfordernissen.

Post by René König

Post by Peter Götz
Datenverarbeitung beschränkt sich nicht nur auf
Office-Anwendungen und Multimedia-Spielereien
und so sind Schnittstellen wie V24 / RS232

Das ist mir schon klar, denn die bediene ich nicht.

Neben Anwendungen für die Überwachung und Steuerung
von Fertigungsabläufen, habe ich auch div. Anwendungen
im reinen Verwaltungsbereich im Einsatz, weshalb mir
auch dieses Office-Umfeld nicht fremd ist.

Post by René König
Wir sind auch überwiegend im industriellen Umfeld unterwegs.

Dann wundert mich Deine Einschätzung von V24 / RS232
aber schon ein wenig.

Post by René König
Bei uns geht der Trend
aber ganz eindeutig weg vom 08/15 UART.

Post by Peter Götz
u.ä. ser. Schnittstellen im industriellen Umfeld nach wie vor
gebräuchlich und werden es wohl noch über längere Zeit
bleiben.

Leider.

Warum "Leider"?
Welches konkrete Problem siehst Du bei Verwendung
von V24 resp. RS232 und ähnlichen Schnittstellen?

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[René König]

Hallo!

Post by Peter Götz
Warum "Leider"?
Welches konkrete Problem siehst Du bei Verwendung
von V24 resp. RS232 und ähnlichen Schnittstellen?

Ich sehe überhaupt kein Problem. Oder ist das Bedingung, um den alten
Krempel nicht zu mögen?

Ich sehe nur, dass das alles unnötig kompliziert ist. Um wieder das
Beispiel USB aufzugreifen: Ich muss mir nicht notwendigerweise ein
Protokoll überlegen, das erbe ich einfach vom BUS. Zudem kann ich noch
sicher sein, dass die Daten in Ordnung sind. Schließlich werden sie,
ohne mein Zutun, CRC gesichert übertragen. Auch brauche ich mir keinen
Mechanismus zu überlegen, um zu erkennen, ob das Gerät überhaupt noch da
ist. Auch nett ist, dass ich eine Vielzahl von Geräten über den Bus
versorgen kann.

Selbst in der Anwendung ist USB einfacher, da Du nichts konfigurieren
musst -> einstecken und los geht's.

Und welchen Vorteil hat jetzt das alte Zeugs, außer das es Dich in der
Übertragungsrate einschränkt?

Gruß,
René

[Peter Götz]

Hallo René,

Post by René König

Post by Peter Götz
Warum "Leider"?
Welches konkrete Problem siehst Du bei Verwendung
von V24 resp. RS232 und ähnlichen Schnittstellen?

Ich sehe überhaupt kein Problem. Oder ist das Bedingung,
um den alten Krempel nicht zu mögen?

Warum sollte ein Industriebetrieb Maschinen und sonstige
Einrichtungen einer Fertigungsstraße, die ihren Dienst zur
vollen Zufriedenheit verrichtet durch andere Maschinen und
Einrichtungen ersetzen, die lediglich andere Schnittstellen-
steckern haben aber ansonsten keinerlei Mehrwert bringen?

Post by René König
Ich sehe nur, dass das alles unnötig kompliziert ist.

Was ist denn kompliziert?

Post by René König
Um wieder das Beispiel USB aufzugreifen: Ich muss mir
nicht notwendigerweise ein Protokoll überlegen, das erbe
ich einfach vom BUS.

Eine HDLC-, MSV- oder LSV- Prozedur "erbe" ich von
Klassenmodulen, die seit Jahren Ihren Dienst tun und
bestens ausgereift und ausgetestet sind. Da muss ich
nicht viel überlegen. Ein simpler Verweis auf eine
entsprechende DLL genügt.

Post by René König
Zudem kann ich noch sicher sein, dass die Daten in Ordnung
sind.

Und warum sollten sie via V24 / RS232 mit einem gesicherten
Protokoll weniger sicher sein?

Post by René König
Schließlich werden sie, ohne mein Zutun, CRC gesichert
übertragen.

Du weisst schon, wie z.B. HDLC funktioniert?

Post by René König
Auch brauche ich mir keinen Mechanismus zu überlegen, um
zu erkennen, ob das Gerät überhaupt noch da ist. Auch nett
ist, dass ich eine Vielzahl von Geräten über den Bus
versorgen kann.
Selbst in der Anwendung ist USB einfacher, da Du nichts
konfigurieren musst -> einstecken und los geht's.

Aha...?
Und die Firmware bzw. gerätespezifische Treiber für
irgendein neu entwickeltes Gerät fallen vom Himmel?

Post by René König
Und welchen Vorteil hat jetzt das alte Zeugs, außer das es
Dich in der Übertragungsrate einschränkt?

Bei meinen Anwendungen, die industrielle Fertigungsprozesse
steuern und überwachen, wären selbst Übertragungsraten von
19.200 bps in vielen Fällen noch mehr als ausreichend. Was
also schränkt mich in der Übertragungsrate ein?

Was mich als SW-Entwickler jedoch ohne Frage einschränkt, ist
der "zahlende" Kunde. Der hat eine Maschine oder sonstige
Einrichtung, welche eine RS232 - Schnittstelle hat und er möchte
eine bestimmte Software haben mit deren Hilfe von einer solchen
Einrichtung gelieferte Daten übernommen und ver- und bearbeitet
werden. Ins Pflichtenheft schreibt der Kunde, dass der
Datenaustausch via RS232 zu erfolgen hat. Willst Du nun mit dem
Kunden diskutieren und ihm sagen, dass Du keinen Auftrag für
die Entwicklung einer entsprechenden Software annimmst, weil
Dir RS232 Schnittstellen nicht gefallen?

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[René König]

Hallo Peter,

Post by Peter Götz
Datenaustausch via RS232 zu erfolgen hat. Willst Du nun mit dem
Kunden diskutieren und ihm sagen, dass Du keinen Auftrag für
die Entwicklung einer entsprechenden Software annimmst, weil
Dir RS232 Schnittstellen nicht gefallen?

Will ich nicht, wieso auch, was soll der Blödsinn? Ich kann mich auch
nicht entsinnen, so etwas gesagt zu haben. Ich sage lediglich, dass ich
RS232 als legacy einstufe, da die Bedingung RS232 nun mal deutlich
weniger geworden ist. Wir haben hier auch einige Geräte mit dieser
Schnittstelle, weil die eben so sein müssen. Davon wird die
Schnittstelle aber nicht besser, deswegen mag ich sie nicht lieber.

Gruß,
René

[Thorsten Albers]

Post by René König
...
Leider viel zu häufig, aber es wird ja zum Glück weniger.
...
Für legacy Systeme und die ewig Gestrigen ist das auch das Einzige das
bleibt. ;-)
...
Leider.

Die herkömmliche serielle Schnittstelle hat gegenüber dem USB-Anschluß
einen ganz oberflächlichen, aber äußerst praktischen Vorteil, der
sicherlich so manchen vom Wechsel abhält: Die Stecker werden verschraubt.
Einen verschraubbaren USB-Anschluß habe ich noch nie gesehen. Und die
Dinger rutschen, zumal nach häufigem Ein- und Ausstecken, dermaßen schnell
aus der Dose...

[Thomas Scheidegger]

Hallo Thorsten

Post by Thorsten Albers
Einen verschraubbaren USB-Anschluß habe ich noch nie gesehen.

für den Industrie-Bereich gibt es davon durchaus Varianten, nur zB:
http://www.usbfield.com/
http://www.phoenixcontact.de/news/222_11131.htm

[Thorsten Albers]

Post by Thomas Scheidegger
http://www.usbfield.com/
http://www.phoenixcontact.de/news/222_11131.htm

Ja, durch zusätzliche Gehäuse - das ist klar, das kann ich mir sogar selbst
basteln. Aber das eine Teil davon muß erst einmal in das Gerät eingesetzt
werden, das andere am Kabel. Und längst nicht in jedes Gerät läßt sich so
etwas einbauen. Das ist kaum vergleichbar mit der unkomplizierten
Handhabung und Sicherheit, welche der 'normale' serielle Stecker bietet.

[Thomas Scheidegger]

...unkomplizierten Handhabung und Sicherheit,
welche der 'normale' serielle Stecker bietet.

tja, und trotzdem kommt diese Stecker-Bauform ('D-SUB')
generell bei neuen Schnittstellen kaum mehr zum Zuge.
Und für den 'anspruchsvolleren' Industrie-Einsatz
ist er alleine auch nicht tauglich (IP-Schutzgrade/EMV usw),
braucht es genauso Spezial-Bauformen.

Für den Home/Office-Bereich genügt USB,
der Platz für die ('D-SUB'-) Schrauben
wäre insbesondere bei Mobile auch gar nicht mehr vorhanden!

Aber das Killer-Kriterium für RS232 ist eh
die heute auftretende, stets zunehmende Datenmenge.

RS232 kann man heute nur noch als 'Ausrede'
für das absolute Minimum
einer 'Connectivity' gelten lassen.
('kleinster gemeinsamer Nenner' zwischen Fremdsystemen)

Technologisch ist das Teil heute ansonst regelrecht eine 'Beleidigung'.

[Peter Götz]

Hallo Thomas,

Post by Thomas Scheidegger
tja, und trotzdem kommt diese Stecker-Bauform ('D-SUB')
generell bei neuen Schnittstellen kaum mehr zum Zuge.

Sie ist bei vielen in der industriellen Fertigung verwendeten
Maschinen und sonstigen Einrichtungen einfach vorhanden
und wird es solange sein, wie diese Maschinen und Einrichtungen
in einer laufenden Fertigung ihren Dienst tun.

Post by Thomas Scheidegger
Und für den 'anspruchsvolleren' Industrie-Einsatz
ist er alleine auch nicht tauglich (IP-Schutzgrade/EMV usw),
braucht es genauso Spezial-Bauformen.

Welche IP-Schutzgrade könnten damit konkret nicht erfüllt werden?
Nenne konkrete, nicht lösbare Probleme bezügl. EMV.

Post by Thomas Scheidegger
Für den Home/Office-Bereich genügt USB,
der Platz für die ('D-SUB'-) Schrauben
wäre insbesondere bei Mobile auch gar nicht mehr vorhanden!

Im Thread geht es nicht um Home/Office-Bereich und
noch viel weniger um "Mobile", sondern um Schnittstellen
in industriellen Fertigunganlagen.

Post by Thomas Scheidegger
Aber das Killer-Kriterium für RS232 ist eh
die heute auftretende, stets zunehmende Datenmenge.

Welches Problem mit Datenmengen siehst Du z.B. bei
Mess-/Prüfautomaten, die elektr. Baugruppen prüfen und
beispielsweise alle 5 bis 10 Sek. ein Gruppe von 5 bis 10
Messwerten vom Typ Single oder Double liefern?

Post by Thomas Scheidegger
RS232 kann man heute nur noch als 'Ausrede'
für das absolute Minimum
einer 'Connectivity' gelten lassen.
('kleinster gemeinsamer Nenner' zwischen Fremdsystemen)
Technologisch ist das Teil heute ansonst regelrecht eine
'Beleidigung'.

Solche von Dir immer wieder vorgebrachten, nichtssagenden
Allgemeinplätze will ich nicht kommentieren.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

[René König]

Hallo!

Post by Peter Götz
Welche IP-Schutzgrade könnten damit konkret nicht erfüllt werden?
Nenne konkrete, nicht lösbare Probleme bezügl. EMV.

Thomas hat doch klar gesagt, dass es gelöst werden kann. Nur bedeutet
das eben zusätzlichen Aufwand, wie beim Beispiel USB auch.

Gruß,
René

[Thorsten Albers]

Post by Thomas Scheidegger
tja, und trotzdem kommt diese Stecker-Bauform ('D-SUB')
generell bei neuen Schnittstellen kaum mehr zum Zuge.

Ich habe gerade für ein Büro ein aktuelles Nadeldrucker-Modell von Epson
(Epson LX-300+II) besorgt, ein Drucker, der sicherlich nicht für den
Heimbedarf gedacht ist, sondern für Büro, Industrie etc. Im Gegensatz zu
handelsüblichen Druckern für den Heimbedarf, die in der Regel nur noch mit
USB-Anschluß kommen, hat dieser Drucker neben einem USB- auch einen
parallelen IEEE 1284- und einen seriellen RS-232C-Anschluß. Andere
Nadeldrucker von Epson sind gleichermaßen ausgestattet. Hier würde ich nun
nicht gerade von 'kaum noch' oder von extremen Ausnahmen sprechen.
Zumindest Epson sieht bei seinen Kunden offenbar immernoch ein großes
Interesse an diesen 'veralteten' Anschlüssen.
Sogar bei Neugeräten im Heimbedarf finden sich nach wie vor häufig
herkömmliche serielle Schnittstellen, etwa bei DVB T-Receivern.

Post by Thomas Scheidegger
Und für den 'anspruchsvolleren' Industrie-Einsatz
ist er alleine auch nicht tauglich (IP-Schutzgrade/EMV usw),
braucht es genauso Spezial-Bauformen.

Wenn ich mich so in Büros etc. umschaue, dann scheinen sehr viele Deine
Sicherheitsbedenken nicht zu teilen, denn sie verwenden die ganz 'normale'
Buchse. Speziellen Steckern bin ich eigentlich nur in Bereichen begegnet,
wo extreme Bedingungen wie etwa hohe Feuchtigkeit herrschen.

Post by Thomas Scheidegger
Für den Home/Office-Bereich genügt USB,

Also stimmst immerhin Du zu, daß 'unerweitertes' USB für den Büro-,
Industrie-Bereich >>nicht<< genügt.

Post by Thomas Scheidegger
Aber das Killer-Kriterium für RS232 ist eh
die heute auftretende, stets zunehmende Datenmenge.
RS232 kann man heute nur noch als 'Ausrede'
für das absolute Minimum
einer 'Connectivity' gelten lassen.
('kleinster gemeinsamer Nenner' zwischen Fremdsystemen)
Technologisch ist das Teil heute ansonst regelrecht eine 'Beleidigung'.

Auch hier kann ich nur sagen: Für viele scheint das kein Problem zu sein,
sonst wäre die herkömmliche serielle Schnittstelle nicht noch so weit
verbreitet.
Interessant ist die Schnelligkeit, mit der USB seinen 'Siegeszug'
angetreten hat: Von einer solchen kann nämlich keineswegs die Rede sein.
AFAIK Mitte der 1990er Jahre entwickelt, brauchte USB um und bei 15 Jahre,
um einen hohen Verbreitungsgrad zu erreichen. Und eine hohe Verbreitung
kann USB eigentlich auch nur eben durch den 'Heimbereich' zuerkannt werden,
insbesondere durch allerlei Spielzeuge wie Handys, Digitalkameras,
Datenträger u.dgl.

[René König]

Hallo!

Post by Thorsten Albers
Wenn ich mich so in Büros etc. umschaue, dann scheinen sehr viele Deine
Sicherheitsbedenken nicht zu teilen, denn sie verwenden die ganz 'normale'
Buchse. Speziellen Steckern bin ich eigentlich nur in Bereichen begegnet,
wo extreme Bedingungen wie etwa hohe Feuchtigkeit herrschen.

Im Büro ist das auch kein Problem, da habe ich auch noch nie spezielle
Stecker gesehen.

Post by Thorsten Albers

Post by Thomas Scheidegger
Für den Home/Office-Bereich genügt USB,

Also stimmst immerhin Du zu, daß 'unerweitertes' USB für den Büro-,
Industrie-Bereich >>nicht<< genügt.

Für das Büro genügt Standard USB Steckverbinder, im rauen Betrieb
natürlich nicht. Das selbe gilt aber auch für die "normale" serielle
Verbindung.

Post by Thorsten Albers
Auch hier kann ich nur sagen: Für viele scheint das kein Problem zu sein,
sonst wäre die herkömmliche serielle Schnittstelle nicht noch so weit
verbreitet.

So weit verbreitet ist sie zum Glück nicht mehr.

Post by Thorsten Albers
Interessant ist die Schnelligkeit, mit der USB seinen 'Siegeszug'
angetreten hat: Von einer solchen kann nämlich keineswegs die Rede sein.
AFAIK Mitte der 1990er Jahre entwickelt, brauchte USB um und bei 15 Jahre,
um einen hohen Verbreitungsgrad zu erreichen. Und eine hohe Verbreitung

Die Spezifikation 1.0 ist von Januar 1996. Eine hohe Verbreitung haben
wir schon etwas länger, da brauchen wir sicherlich nicht noch bis 2011
zu warten.

Gruß,
René

[Thorsten Albers]

Post by René König
So weit verbreitet ist sie zum Glück nicht mehr.

Da haben wir offensichtlich sehr unterschiedliche Erfahrungen.

Post by René König
Die Spezifikation 1.0 ist von Januar 1996. Eine hohe Verbreitung haben
wir schon etwas länger

Auch da haben wir offensichtlich sehr unterschiedliche Erfahrungen.