Signal-Peaks bei Temperaturaufnahme

Gerd leidet wohl am Syndrom "Zeitmangel wegen Berufstätigkeit" - deshalb sind seine (richtigen) Antworten manchmal sehr kurz.
Aber im Ernst: Der angegebene Link behandelt die Formatierungszeichen - nicht aber den Formatstring an sich, der auch noch andere Zeichen enthalten kann.
Hier noch mal das Beispiel:
   
Im Formatierungsstring bedeuten
"%x":
die ersten Zeichen sind als Hex-String zu interpretieren und in eine Zahl zu konvertieren. Normalerweise hätte diese Zahl das Fomat U16. Da ich aber an den Eingang des VI eine DBL-Konstante angeschlossen habe, wird der Zahlenwert gewissermaßen gleich ein zweites Mal konvertiert und im Format DBL ausgegeben.
"h,":
Diese beiden Zeichen sind keine Formatierungszeichen, kommen aber gleichlautend im String vor. Das heißt: sie sind zu überlesen.
"%x":
Die nächsten Zeichen sind als HexString zu interpretieren.
Für den Rest des Strings gibt es keine Formatierungsanweisung. Dieser Rest wird als "verbleibender String" ausgegeben - hier nicht benutzt.

Hallo Lucki,

Zitat:Gerd leidet wohl am Syndrom "Zeitmangel wegen Berufstätigkeit"

Schön ausgedrückt - heute sollte ich z.B. nach Kilometergeld arbeiten Aber für einen Link in die Online-Hilfe reichts immer noch!

Hallo zusammen,

@Lucki: Danke für die ausführliche Erklärung
@GerdW: der Link war auch sehr hilfreich

Hab mal am Programm weiter gearbeitet. Krieg jetzt aber eine Fehlermeldung beim Auslesen der Strings. Es ist Fehler Nr. 1, siehe Anhang.

Habt Ihr eine Idee?

Hallo taichi,

wenn du null Bytes vom seriellen Port liest, hat ScanFromString natürlich nichts zum Scannen...

Außerdem sagt doch die Fehlermeldung eindeutig "at ScanFromString (arg1)", da hättest du doch einfach mal ein paar Probes anlegen können!

P.S.: Warum ist dein VI in LV2010, wenn du lt. Profil nur LV2009 verwendest?

Es funktioniert, wenn Du an das Read-VI 10**6 Bytes anschließt, aber nicht mit Null Bytes. Das Read-VI wartet dann immer so lange, bis ein Zeilenende-Zeichen eintrifft.
Und wenn Du das änderst und es funktioniert, ist das trotzdem noch kein Programm für profesionellen Gebrauch. Dazu gehört das Abfangen diverser Fehler, damit das Programm wegen eines falschen Bytes bei der Datenübertragung nicht gleich den Geist aufgibt.

Hab jetzt rausgefunden, dass der PIC im 18 byte-Paket sendet, bisher scheint alles zu laufen.

(13.07.2011 12:17 )taichi schrieb:  Hab jetzt rausgefunden, dass der PIC im 18 byte-Paket sendet, bisher scheint alles zu laufen.

Das ist war aber seit Deinem ersten Bild im ersten Posting schon klar. Du solltest aber etwas mehr als 18 byte an des Read-VI anschließen und mit Endezeichen arbeiten. Dazu mußt Du wissen, ob das Gerät am Ende x0A oder x0D oder etwas Anderes sendet und das Zeichen im Visa Konfig-VI entsprechend eingeben.

Hallöchen zusammen,

@Lucki: bitte habe etwas Nachsicht mit mir, ich studiere noch und arbeite das erste mal mit LabVIEW und habe sonst auch nicht viel Programmiererfahrungen.

Warum sollte ich etwas mehr als 18 byte ans VISA-VI anschließen und wie kann ich rausfinden was das "Gerät" am Ende (am Ende wovon?) sendet?

Hallo taichi,

Zitat:Warum sollte ich etwas mehr als 18 byte ans VISA-VI anschließen

Siehe Beitrag #15!

Zitat:wie kann ich rausfinden was das "Gerät" am Ende (am Ende wovon?) sendet?

Das zugehörige Manual lesen? ("Am Ende" bedeutet am Ende jeder einzelnen Nachricht, die das Gerät versendet. Auch als Abschluß- oder Endezeichen oder EOT bezeichnet.)

Gerd hat ja die Frage schon richtig beantortet, meine Aufgabe ist jetzt die literarische Auschmückung
Wenn Du an das Read am Eingang 18 Byte anschließt und das Abschlußzeichen deaktivierst, dann kann das durchaus eine ganz Weile gut gehen. Es ist aber von der Synchronisation her nicht besonders stabil. Es besteht z.B. die folgende Gefahr: wenn Du das Vi startest und der µC sendet bereits, dann kann es passieren, daß das Programm im dritten Byte eines Datensatzes anfängt zu lesen. Und das synchronisiert sich nie wieder, weil immer wieder genau 18 Byte gelesen werden. Also immer vom dritten Byte eines Datensatzes bis zum zweiten Byte das nächsten Datensatzes.

Zur Arbeitsweise von Read: Es wartet, bis eine von drei Bedingungen erfüllt ist:
a) Es ist die Anzahl von Bytes im Buffer, die am Eingang anliegt.
b) Es ist ein Endezeichen im Buffer (Nur bei aktivierten Endezeichen)
c) Timeout ist erreicht (mit Fehlermeldung).

Als Abschlußzeichen kommt bei Dir LF (x0A) oder CR (x0D) in Frage. Wenn das Manual nicht zu Hand ist, wäre das auch in 10 sec durchprobiert, mit welchem Zeichen es funktioniert und mit welchem nicht.