RS232 undokumentierter Fehler beim senden von zu großen Datein

' schrieb:Ich verstehe leider immer noch nicht was bei meinem Programm (also die letzte Version) schief geht, aber da werde ich auch noch draufkommen.

Stift nehmen, die realen Werte ansehen und aufschreiben, was sich der Reihe nach tut.

Zitat:Wo lernt man LabVIEW-programmieren am besten?

Auch hier gilt: Übung:tippen:macht den Meister. (Deswegen sind die Meister ja immer alt und die Lehrlinge jung. Guck dir den Lucki an, der ist schon 73. )

Lehrgänge gibt es bei NI. Fragen zu stellen hier im Forum ist auch sehr geeignet besser zu werden. Um ein bestimmtes Maß an Intuition kommt man aber nicht herum.

Habe auch mal ein VI erstellt, es gilt für beliebige Dateifomate (Txt, Midi, allg. binär).
Zu beachten ist, daß diese Art der seriellen Übertragung in Form von Bytes im Bereich 0..255 unüblich ist. Es stehen dann keine Steuerzeichen zur Verfügung, um dem Empfänger z.B. das Ende der Datei anzuzeigen. Die einzige Möglichkeit ist dann von seiten des Empfängers, daß, wenn eine bestimmte Zeit lang nichts mehr im Empfangspuffer ist, dann das Dateiende zu vermuten.

(Üblich ist es, binäre Bytes vor der Übertragung in zweistellige ASCII-Hex-Strings zu konvertieren, Also Byte(255) = FF. Der Nachteil ist dann natürch die Verdoppelung des Übertragungvolumens )

Hinweis: Bei direkter Übertragung von Binärbytes als Stringzeichen die Option "EOL konvertieren" ausschalten (rechte Maustatseausschalten bei "In Textdatei schreiben/lesen"), sonst kann es zu Datenverfälschungen kommen.
Habe das Beispiel so gemacht, daß es auch mit GByte- Dateien funktionieren sollte. D.h. die Datei wird niemals als Ganzes eingelesen, sondern in Häppchen für je ca. 100ms Übertragungsdauer, die jeweils sofort übertragen werden.
Die Übetragung lässt sich so auch jederzeit stoppen.
Bei hohen Baudraten (15200) kam es bei mir in seltenen Fällen beim Empfang zur Fehlermeldungen, oder es wurde 1 Byte weniger empfangen als gesendet. Das wird aber mit der gleichzeitigen Verwendung der beiden Schnittstellen im gleichen PC zusammenhängen.
lv90

Danke, für die riesige VI!;)Aber ich glaube die ist etwas zu groß für meinen Anwendungsbereich!;)Lernen kann ich aber aus der VI sicher was! Also vielen Dank!

' schrieb:Danke, für die riesige VI!;)Aber ich glaube die ist etwas zu groß für meinen Anwendungsbereich!;)Lernen kann ich aber aus der VI sicher was! Also vielen Dank!

Wieso zu groß? Das Rücklesen des Datenstromes über eine andere Schnittstelle des PC ist doch nur eine Kür zum Test, die dann in der echten Anwendung wegfallen würde. Und was ich anders gemacht habe, ist doch nur eine Vereinfachung: Dieses Hin- und Rückkonvertieren von String zu Byte habe ich ersatzlos gestrichen, und ebenso diese Umbenennungen des File Suffix.
Dafür ist als kleiner Luxus hinzugekommen, daß unabhängig von der Baudrate ca. alle 100ms bytes aus der Datei gelesen und über die Schnittstelle gesendet werden. Damit ist es möglich - außer daß die Datei niemals als Ganzes im Memory sein muss - daß a) der laufende Vorgang jederzeit innerhalb von 100ms abgebrochen werden kann, und b) ein Fortschrittsbalken den Stand der Dinge anzeigt. Bei fest eingestellter Baudrate können die dafür erforderlichen Berechnungen natürlich entfallen und durch Konstanten ersetzt werden - dann würde es ganz einfach.
Ich schätze auch mal, daß Dich auf der Mikrokontrollerseite noch ein paar Probleme erwarten. Z.B. kannst Du da nicht davon ausgehen,, daß Dir dort ein mehrere kByte großer Empfangsbuffer zu Verfügung steht, wie das auf der LabVIEW/Windows-Seite der Fall ist.

' schrieb:Ich schätze auch mal, daß Dich auf der Mikrokontrollerseite noch ein paar Probleme erwarten. Z.B. kannst Du da nicht davon ausgehen,, daß Dir dort ein mehrere kByte großer Empfangsbuffer zu Verfügung steht, wie das auf der LabVIEW/Windows-Seite der Fall ist.

Ich steueren dann mit den µ-Controller über I2C einen 64kByte großen Speicher an wo ich alles reinschreibe!;)Also das sollt sich ausgehn und wann micht hänge ich einen 2ten dazu! Danke trotzdem für den Tipp!