Bytes at port - was passiert?

' schrieb:Jetzt stellt sich mir noch die Frage, was genau die Status-Funktion von Rockwell überprüft.

Ich tippe mal, im SIO-Controller wird eines der beiden (oder vielleicht beide) Flags "Schieberegister ist leer" (das ist das Register, das die Daten physikalisch mit der entsprechenden Baudrate etc. auf die Leitung schiebt) oder "Transferbuffer ist leer" (das ist ein dem Schieberegister vorgelagertes Register, durch das es möglich ist, den Datendurchsatz praktisch zu erhöhen). Normalerweise sollte für ein übergeordnetes Programm (eine Applikation also) der Zustand dieser Flags unerheblich sein. Das Management der Datenübertragung an sich sollte ein "Systemtreiber" machen, dem die Applikation lediglich z.B. ein String übergibt.

Zitat:Wenn das so sein sollte, dass die Daten sich dann auf der Eingangsseite des Empfängers befinden, müsste die Funktion ja in der Lage sein, dort auch den Zustand zu überprüfen.

Der Sender selbst kann nicht überprüfen, ob auf der Empfangsseite alles richtig geklappt hat. Das würde nur über ein entsprechend (kompliziertes) Handshake auf Applikationsebene gehen. Das sicherste ist eine Blockübertragung mit Checksumme: Daten senden und warten auf Antwort. Kommt ein ACK ist alles richtig beim Empfänger angekommen. Kommt ein NAK oder nichts (Timeout), ist ein Fehler aufgetreten. Nur alleine Hardware- oder XOn/XOff-Handshake bringt keine Datensicherheit (Anmerkung: Auch Hardwarehandshake CTS/RTS bzw DSR/DTR wird per Software gemacht).

Zitat:Muss mir vielleicht nochmal eine komplett andere Strategie zurechtlegen.

Die Strategie hängt davon ab, was du machen willst. Willst du z.B. nur Messwerte übertragen, kann man das wie folgt machen: Alle 25ms den Messwert in einem Frame packen, sichern und senden. Ob der Frame richtig beim Empfänger ankommt, ist dem Sender egal. Er sendet ja sowieso alle 25ms. Dem Empfänger obliegt es, festzustellen, ob ein 25ms-Frame fehlt.


[offtopic]

Zitat:Und geht es Euch ähnlich, dass sich mit einem gelösten Problem meist zwei neue auftun?

Jetzt hab ich das Problem mit LV8.2 gelöst (also installiert). Erstes neues Problem: DLL-Knoten gehen nicht mehr sequenzieren über den Eingang "Rückgabewert", den es bei LV8.2 nicht mehr gibt (im Gegensatz zu LV7.1.1). Jetzt muss per Errorcluster sequenziert werden => Zweites Problem: Ohne Anschluss eines Ausgabeelementes an den letzten Error-Ausgang kommt eine Meldung "Referenz ohne Label. Melden Sie das an NI". Nur: was soll ich denn mit dem Anzeigeelement, es ist sowieso nicht sichtbar.
[/offtopic]