Zugriffszeiten auf RS232 über Visual Basic .NET mit Windows

[xyuser (Gast)]

Hallo,

ich habe eine Frage zu der RS232 Schnittstelle am PC. Ich habe eine PC
Applikation in Visual Basic .NET, die über die serielle Schnittstelle
auf eine externe Hardware zugreift.

Ich kann mir vorstellen, dass das Programm nach der Abarbeitung des
senden Befehls eine gewisse Zeit benötigt, bis die Daten physisch
versendet werden. Das kann sicherlich im ms Bereich liegen und ist auch
unterschiedlich. Vor allem aber läuft die Applikation auf einen Windows
Rechner, dass für die jeweilige Hardwareansteuerung nicht Echtzeitfähig
ist. Aus diesem Grund möchte ich Wissen, wieviel Zeit maximal vergehen
kann vom Aufruf des Befehls bis zum physischen senden der Daten.

Leider konnte ich darüber in verschiedenen Büchern nichts finden. Das
muss doch ein bekanntes Problem sein? Es wäre auch schön, wenn jemand
dazu einen Link kennt, indem solche Informationen stehen.

Vielen Dank für eure Unterstützung

[Rufus Τ. F. (rufus)]

Da Windows kein Echtzeitbetriebssystem ist und auch nicht vorgibt, eines
zu sein, sind derartige Dinge nicht dokumentiert und können auch gar
nicht dokumentiert werden.
Das hast Du ja auch selbst erkannt, daher widerspricht Deine Frage
dieser Erkenntnis.

Je nach Systemlast kann da sehr viel Zeit vergehen, muss aber nicht.
Wenn der verwendete Rechner zu wenig Arbeitsspeicher hat, und erst mal
Teile der .Net-Runtime aus dem Speicher pagen muss, um andere Teile der
Runtime zu laden oder was auch immmer zu tun, dann kann das halt
ziemlich bis sehr lange dauern. Ist beispielsweise die Festplatte
gerade abgeschaltet, so kann es mehrere Sekunden dauern, bis die wieder
angelaufen ist.
Dieser Betriebsfall ist zwar recht unwahrscheinlich (man kann das
Abschalten der Festplatten über die Energieoptionen in der
Systemsteuerung beeinflussen), aber nicht auszuschließen.

Fazit: Unter Windows gibt es keine maximalen Zeiten für irgendwelche
Vorgänge, sondern nur "typische" Zeiten.

[Wolfram (Gast)]

Ganz davon abgesehen das ein Empfänger bei verschiedenen Protokollen
auch das Senden blockieren könnte.
Für so etwas gibt es Timeoutzeiten.
USB-Seriellwandler verzögern evt. noch zusätzlich Bsp: FTDI 16ms
siehe Applikation Note FTDI Durchstz und Latenz

[xyuser (Gast)]

Das hab ich mir schon gedacht, dass es in etwa so ausgehen wird. Aber
eine Frage hab ich dennoch an den Beitrag von Wolfram. Was meinst du
genau damit, dass der Empfänger auch das senden blockieren könnte und
wann tritt der Timeout ein? Das versteh ich nicht ganz.

[Rufus Τ. F. (rufus)]

Was Wolfram meint, kann auftreten, wenn Hardwarehandshake verwendet
wird.

[xyuser (Gast)]

Wie ist das beim FTDI chip. Muss dann vom Programm aus ein neues senden
ausgelöst werden oder kümmert sich die DLL, die von FTDI ist, um das
wiederholte senden. Versucht diese dann im 16 ms intervall die Daten zu
senden? Ich hab glaub ich mal gelesen, dass bei den neuen Bausteinen,
diese Zeit  eingestellt werden kann.

Wenn das so wäre, dann würde ich doch immer den Timeout mit der
kleinsten Zeitdauer einstellen.

Danke für eure Antworten!

[Wolfram (Gast)]

Schau in die Applikation Note das steht es genau drin

[Rufus Τ. F. (rufus)]

Wieso wiederholtes Senden? Das ist bei Verwendung von Hardwarehandshake
nicht nötig; die Hardware der Schnittstelle sendet solange nicht, wie
ihr das durch die Handshakeleitungen verboten wird.
Sobald aber das Senden durch die Handshakeleitung freigegeben wird,
werden alle bislang im Sendepuffer des Schnittstellenbausteines
gespeicherten Daten gesendet; verloren geht dabei nichts.