Serielle Zeichenübertragung

' schrieb:aber wenn ein zufällig erzeugtes Datum irgendwo mittendrin ein "0D" oder ein "0A" hat, wird dieses jeweils als "0D0A" geschrieben! Und das nicht am Zeilenende. Es handelt sich um ein Byte, das eben auch mal "0D" sein darf, und unverändert in der Reihe an Bytes in die Datei geschrieben werden soll!

Das ist kein Bug. Das ist per Definition richtig so. In als Textfile deklarierte Files gibt es nur lesbaren Text. 0D oder 0A (1A gilt sogar ggf. als Textfileende) können also per se nicht als Datenzeichen vorkommen.

Fazit: als Binär deklariertes File verwenden.

Anzeige

Hallo wohl,
auch wenn mein Posting scheinbar informativ untergegangen ist, eine zusätzliche Info zu:
...ist das so? oder kommt 0A von dem (Write To Spreadsheet File.vi)
in der LV Hilfe gibt es unter dem Suchbegriff:ASCII_Codes nachfolgende allgemeingültige Tabelle
   
hier sind somit auch die nicht darstellbaren Zeichen aufgelistet, die wenn sie als ASCII Code in eine Text geschrieben werden Funktionalität besitzen.

nun zur Frage nach:
0A-> soll hier in ein einer Datei tatsächlich eine Zeilenschaltung durchgeführt werden, ohne das der Einfügepunkt wieder am Zeilenanfang beginnt, also versetzt in der nächten Zeile weiter?
0D-> soll hier ein Wagenrücklauf erfolgen, ohne Zeilenschaltung, also die Zeile überschieben werden?

wie man sieht, wurde das logische Ergänzen seitens LV realisiert, wenn in Textdateien Steuerzeichen geschrieben werden.

' schrieb:Das ist kein Bug. Das ist per Definition richtig so. In als Textfile deklarierte Files gibt es nur lesbaren Text. 0D oder 0A (1A gilt sogar ggf. als Textfileende) können also per se nicht als Datenzeichen vorkommen.

Fazit: als Binär deklariertes File verwenden.

Ich komme zwar zum selben Fazit, aber nicht mit derselben Erklärung. h0D und h0A kommen schon in einem normalen Textfile vor, bloß sind es halt die Zeichen "Carriage Return" und "Newline" (oder r und n in der Codes-Darstellung von LV).

So, LV interpretiert in einem String sowohl r als auch n für sich alleine schon als Zeilenumbruch (in der Unix-Welt langt schließlich schon ein n für Zeilenvorschub). Jetzt schreibst du unter Windows einen String per "Write To Text" (dieses VI wird nämlich tief untem im Write To Spreadsheet verwendet) auf deine HDD, und LabVIEW ersetzt nun schön brav jedes r und n durch den Windowszeilenumbruch, der da lautet rn.

Gruß, Jens

Vielen Dank für die vielen gut gemeinten Belehrungen.

Daß Wondows die Fernschreiber-Kommandos für einen Zeilen-Neuanfang übernommen hat ist mir bekannt. Dennoch, wenn ich nun wirklich nur eines dieses Doppel-Bytes schreiben möchte, sollte dieses nicht mit Konsequenz verboten werden.

Meine Anfrage richtete mich eigentlich an die Bit- und Byte-Jongleure, die auch kleinere Einheiten, als Text-Bestandteile verwenden.

Wolfgang

' schrieb:Vielen Dank für die vielen gut gemeinten Belehrungen.

Meine Anfrage richtete mich eigentlich an die Bit- und Byte-Jongleure, die auch kleinere Einheiten, als Text-Bestandteile verwenden.

Die Lösung wurde mehrfach genannt (z.Bsp. Post#10), es sind nicht nur Belehrungen -_-
Hier die relativ einfachen 2 Lösungen zum Problem. (ohne Bit und Byte jonglieren)

Vielen Dank,

sieht plausibel aus, nur die VIs zum Datenspeichern habe ich in meiner Palette nicht gefunden. Ich habe nur das eine Symbol zumSchreiben in Tabellenkalkulation. Und wenn ich einen Integer an dieses Symbol führe, gibt es eine Fehlermeldung. (Habe ich vor dem Posten schon probiert, erst als gar nichts klappte ..)

Kann sein, daß in meiner Version von LabVIEW dieses vi nicht enthalten ist???

Anzeige

Brille zuhaus vergessen-> sind doch die ersten 2 auf deinem Bild.

Es gibt VI die sind polymorph, d.h sie können verschiedene Datentypen verarbeiten.
In der Regel wird das autom. anhand des angeschlossenen Verbindung erkannt.

Mit einem rechteMausTaste klick auf das VI, dort wählst du Visible Item View-Polymor... oder weiter unten *Select Typ*
(wie das im deutschen LV heisst ???)

' schrieb:So, LV interpretiert in einem String sowohl r als auch n für sich alleine schon als Zeilenumbruch (in der Unix-Welt langt schließlich schon ein n für Zeilenvorschub). Jetzt schreibst du unter Windows einen String per "Write To Text" (dieses VI wird nämlich tief untem im Write To Spreadsheet verwendet) auf deine HDD, und LabVIEW ersetzt nun schön brav jedes r und n durch den Windowszeilenumbruch, der da lautet rn.

Ja, und umgekehrt funktioniert es natürlich genau so: Beim Einlesen einer Windows-Textdatei mit 0D0A als Zeilenendezeichen ersetzt LabVIEW jedes 0D0A durch 0A. LabVIEW beachtet also die Konventionen des jeweiligen Betriebssystems beim Schreiben und Lesen von Textfiles. Intern, d.h in LabVIEW-Strings, wird aber nur 0A als Zeilenende benutzt. (Ja, LabVIEW akzeptiert auch 0D - weil es tolerant ist)

Falls es jemand wegen sein Jugendlichkeit nicht weiß, wie das 0D0A als Zeilende-Zeichen zustandekam: Die ersten Fernschreiber hatten noch keine digitale Elektronik, die diesen Namen verdient, insbesondere keinen Datenpuffer. Für den Wagenrücklauf hatte man also nicht mehr Zeit als für das Schreiben eines einzelnen Zeichens. Mit 0D0A hatte man aber immerhin zwei Zeichen Zeit und schaffte damit sagenhafte 50Baud.

Was lange währt ...

Die Lösung dieses Problems ist ja sooo simpel, man muß nur darauf kommen: Anstelle "In Tabellenkalkulation schreiben" nahm ich das vi "In Textdatei schreiben". Mir war die ganze zeit entgangen, mit Rechtsklick auf das Symbol erscheint ein Fenster, dort muß "EOL konvertieren" abgewählt werden.



Vielen Dank jedenfalls für die vielen Meldungen.

Wolfgang

' schrieb:Mir war die ganze zeit entgangen, mit Rechtsklick auf das Symbol erscheint ein Fenster, dort muß "EOL konvertieren" abgewählt werden.

Ja mir auch, gesucht habe ich das, aber nicht gefunden.
Bis LV8 war das auch als Eingang am LowLevel-File Read/Write als Eingang vorhanden.
Ich fand die alten FileI/O VI besser, die neuen sind für mich LowLevelVI mit Express-Konfiguration, welcher Depp bei NI hat das wohl zu verantworten.