Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
05.12.2006, 09:54 (Dieser Beitrag wurde zuletzt bearbeitet: 05.12.2006 09:56 von SGeisler.)
Wie genau habe ich mir diese "Byte at port"-Geschichte vorzustellen? Ich habe gerade den Fall, dass an meiner Schnittstelle (RS-232) genau ein Byte anliegen soll. Meine Gegenseite hat die Aufgabe, zu überprüfen, ob in dessen Transmitter-Buffer etwas drin ist (nämlich dieses eine Byte) oder dieser leer ist. Wenn der nämlich leer sein sollte, soll wieder dieses eine Byte hineingestellt werden.
Irgendwie werde ich das Gefühl aber nicht los, dass diese "Byte at port"-Funktion dieses Byte tatsächlich liest und dabei dann irgendwo zwischenspeichert. Es folgen nämlich von der Gegenseite immer wieder neue Bytes (zähle dort zur Überprüfung mit). Wie sonst sollte es auch in der Lage sein, zu sehen, wie viele Bytes tatsächlich am Port anliegen, da sie ja seriell -also nacheinander- anstehen.
Bytes On Port ist keine Funktion, sondern eine Eigenschaft des seriellen Ports. Sie liest dein Byte nicht aus, dafür gibt es das VI Read Visa.
Mit Bytes On Port kannst du die Anzahl der Zeichen(Bytes) an Port zum Zeitpunkt der Abfrage. Natürlich können zwischen dem Abfragen und Auslesen neue Zeichen dazukommen, aber damit muss man leben.
Die gegenüberlegende Seite (Controller für Linearantrieb) ist in der Lage, exakt ein Byte zum Lesen bereitzustellen. Liegt ein Byte im Buffer, schreibt es kein weiteres hinein. Dies ist aber genau der Fall. Das heisst jetzt für mich, dass dieses Byte irgendwohin verschwunden ist.
[5 Minuten später]
Habe nun folgendes gemacht:
Für den Controller nochmal ein Programm geschrieben, welches exakt nur ein Byte auf die Schnittstelle setzt.
Mit LabVIEW untenangeführtes Programm gezeichnet.
Will folgendes erreichen:
Öffne die Schnittstelle, guck, wie viele Bytes anliegen, warte, guck nochmal. Lasse ich das Programm laufen, erscheint es genauso, wie vermutet: "Byte da. Ich warte. Byte immer noch da. Programmende."
Beim nächsten Programmstart ist das Byte aber verschwunden. Oder liegt das daran, dass das Schliessen edr Schnittstelle auch deren Inhalt (Buffer) löscht.
Ich bin leider nur Anwender und habe nicht soviel Ahnung, was genau an so einer Schnittstelle passiert.
' schrieb:Meine Gegenseite hat die Aufgabe, zu überprüfen, ob in dessen Transmitter-Buffer etwas drin ist (nämlich dieses eine Byte) oder dieser leer ist. Wenn der nämlich leer sein sollte, soll wieder dieses eine Byte hineingestellt werden.
Ist mit "dessen Transmittpuffer" der Transmittpuffer der Gegenseite gemeint?
Ich würde sagen, sobald etwas im Transmittpuffer steht, wird es auch gesendet - es sei denn das Senden wird explizit über ein entsprechendes Handshake unterbunden. Benutzt du ein Handshake? Ohne Handshake wird die Gegenseite immer senden - auch wenn die Empfangsseite nichts abnimmt und nur die Zeichen zählt.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Was ich nicht verstehe. Woran erkennt der µC ob du das Byte abgeholt hast oder nicht? Ich glaube das geht gar nicht.
Gruss, Eugen
Die Programmierung auf dem Controller erfolgt über C. Der Hersteller (Rockwell) liefert dazu eine entsprechende Bibliothek, in der unter anderem Funktionen vorhanden sind, die die Kommunikation via serieller Schnittstelle vereinfachen sollen. Hier kann ich zum Beispiel sagen, dass es ein Byte senden oder lesen soll. Ausserdem kann ich den Status des Buffers (Sende- und Empfangs-) bekommen (Buffer voll/leer).
@IchSelbst:
Das sind halt die Fragen, die ich (noch) nicht beantworten kann. Bilde mir halt ein, dass bei einer Schnittstelle erst dann gesendet wird, wenn die Gegenseite ihr OK gibt. Sonst würde das für mich heissen, dass gesendet wird und die Daten damit weg sind.
Anzeige
05.12.2006, 11:52 (Dieser Beitrag wurde zuletzt bearbeitet: 05.12.2006 11:54 von IchSelbst.)
' schrieb:Bilde mir halt ein, dass bei einer Schnittstelle erst dann gesendet wird, wenn die Gegenseite ihr OK gibt.
Dieses Verfahren würde dann Handshake heißen. Man muss aber nicht zwangsläufig mit Handshake arbeiten (das hat nämlich auch Nachteile). Es gibt Hardwarehandshake (CTS/RTS bzw. DSR/DTR) und Softwarehandshake (z.B. XOn/XOff) oder Handshake über ein Master/Slave-Verfahren.
Zitat:Sonst würde das für mich heissen, dass gesendet wird und die Daten damit weg sind.
Das heißt es eigentlich nicht. Ob mit oder ohne Handshake, die Daten befinden sich im Eingangspuffer der Empfangsseite. Was die Empfangsseite mit den Zeichen im Eingangspuffer macht - lesen und verwerfen oder lesen und bearbeiten - liegt an der Software der Empfangsseite.
Normalerweise geht man davon aus, dass das, was gesendet wird, auch beim Empfänger respektive in der Applikationssoftware ankommt. (Alles andere würde auf Fehler auf der Datenleitung hinausgehen).
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Das hört sich alles sehr vernünftig an. Danke sehr!
Jetzt stellt sich mir noch die Frage, was genau die Status-Funktion von Rockwell überprüft. 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. Das widerum klingt für mich dann nicht mehr so nachvollziehbar. Muss mir vielleicht nochmal eine komplett andere Strategie zurechtlegen.
Unglaublich, was man jeden Tag neu dazulernt. Arbeite seit ca. einem Jahr mit LabVIEW, aber erst seit zwei Wochen mit dieser Schnittstellen-Sache. Und geht es Euch ähnlich, dass sich mit einem gelösten Problem meist zwei neue auftun? ;-)
' 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]
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:..........., dass das Schliessen edr Schnittstelle auch deren Inhalt (Buffer) löscht.
Ich bin leider nur Anwender und habe nicht soviel Ahnung, was genau an so einer Schnittstelle passiert.
Sollte eigentlich nicht der Fall sein!
Jedes Byte das an die serielle schnittstelle gesendet wird muss abgeholt werden!
Sobald es abgeholt worden ist, ist es auch aus dem Buffer!
Wieso schliesst du denn die serielle Schnittstelle nachdem du weisst, dass ein Byte vorhanden ist?
Geh das doch lesen?
Ich denke wenn du die Schnittstelle schliesst dann gehen automatisch die Daten im Buffer verloren!
/
Bytes at port - was passiert?
