Messdatenaufbereitung

' schrieb:Entschuldigung, ich hatte nur das erste kleine Beispiel im Auge.
Das zweite habe ich mir jetzt mal angeschaut, und da sind mir bei der Synchronisation am Anfang auch gleich zwei Ungereimtheiten aufgefallen (Aber wie gesagt, bezog sich die Anfrage ja gar nicht auf Synchronisation mit den beiden 7F 7F Bytes. Also Perfektion war hier gar nicht gefragt)
Hier der BD-Ausschnitt:

[attachment=45158:Ausschnitt.png]
Damit meine ich

1. Angenommen, die (noch nicht synchronisierte) Bytefolge ist am Anfang 7F 00 00 7F. Dann bleiben am Ausgang des "VI Muster suchen" die 3 Bytes 00 00 7F übrig. Die nachfolgende Subtraktion 2-3 ergibt -1. Und das soll doch wohl bestimmt nicht als Byteanzahl vom nachfolgenden VI gelesen werden.

Hier hast Du Recht.

Zitat:2. Kleiner Flüchtigkeitsfehler: Bei "regulär expression" hätte die code - Darstellung gewählt werden müssen. So wie hier in der Normalansicht wird nicht das Byte 0x7F, sondern es wird die 3 char lange Zeichenkette "7F" gesucht.

Das stimmt nicht. Der Backslash ist bei Match Pattern ein Escape Character. Was danach folgt wird je nach dem was es ist anders interpretiert.

r -> carriage return
n -> line feed
usw.
-> dann ist es wirklich ein Backslash
0 -> folgt eine Octal Zahl die als ASCI code interpretiert wird
x -> folgt eine hexadezimal Zahl die als ASCI Code interpretiert wird
Zahl aber nicht 0, dasselbe als mit x (dies ist in der Match Pattern Hilfe aber nicht dokumentiert).

Rolf Kalbermatter

Anzeige

' schrieb:Der Backslash ist bei Match Pattern ein Escape Character.

Das hatte ich vergessen. Anders kann es ja auch gar nicht sein. Diese detailreiche Syntax für Muster suchen wurde ja von einer Open Souce der Cambridge-Universität 1:1 übernommen. Von daher kann man gar nicht erwarten, daß die üblichen LabVIEW-Konventionen gelten.

' schrieb:Das hatte ich vergessen. Anders kann es ja auch gar nicht sein. Diese detailreiche Syntax für Muster suchen wurde ja von einer Open Souce der Cambridge-Universität 1:1 übernommen. Von daher kann man gar nicht erwarten, daß die üblichen LabVIEW-Konventionen gelten.

Wenn Du mit der Open Source Lösung die Perl Compatible Regular Expression (PCRE) Library meinst dann hast Du nicht ganz Recht. Die PCRE Node kam erst mit LabVIEW 8 hinzu. Match Pattern ist aber seit LabVIEW 3 oder noch früher in LabVIEW und ist in der Regular Expression Syntax doch signifikant anders und vor allem eingeschränkter dann die PCRE. Sie basiert auf dem selben Konzept aber ist weniger ausgebreitet und auch etwas weniger formal. Am meisten gleicht sie wohl der Posix Regular Expression (Basic und Extended aber auch hier mit ein paar Einschränkungen).

Regular Expressions haben eine lange Geschichte. Da etwas zu machen was hauptsächlich auf LabVIEW Gegebenheiten Rücksicht nimmt wäre höchstens kontraproduktiv, da die bereits bestehenden Varianten und Dialekte die ganze Sache schon mehr als kompliziert machen.

Rolf Kalbermatter

' schrieb:Nun ist es aber so, dass ich es in ein anderes Vi implementiert habe. Dort ist das Ziel mehrere Messungen nacheinander durchführen zu können. Wenn ich also mehrmals hintereinander Starte und Stope, krieg ich komische werte raus. Ich denke das Vi hat probleme mit den Start und Stop Commands. Es gibt dann komische byte Paarungen die, die Auswertung beeinträchtigen.

Hier ein Auszug aus den erhaltenen Werten
676F 0D0A 7F7F 0000 ...

Plötzlich fangst Du an von Start- und Stop- Kommandos zu reden. Wo kommen denn die auf einmal her? Wieso hast die Du vorher davon nichts gesagt? Was sind das für Bytes? Natürlich ist es möglich, die Datensätze auf Start-Stop-Basis zu filtern (- du meinst ahrscheinlich zu trennen -), aber dazu fehlen Angaben, wie die Start/Stop-Information aussieht.

Wenn es andere übertragenen Informationen außer denen von Typ 7F 7F XX XX gibt, dann kannst nur Du die Bedeutung uns sagen. In meinem VI werden diese Bytes alle ignoriert, es zähle ausschließlich Daten mit vorangestellten 7F7F.

Zwischen den Datensätzen von Typ 7F7F XXXX gibt es andere Daten mit einer ungeraden Anzahl von Bytes. Da ist es natürlich etwas unglücklich, die Bytes im String zu paaren, also z.B 7F7F XXXX. Besser wäre in diesem Falle die Strindarstellung ohne Leerzeichen oder mit Leerzeichen zwischen jedem einzelnen Bytes, also 7F 7F XX XX. Das hat aber mit der Auswertung in meinem VI nichts zu tun, das funktioniert trotzdem, es ist nur eine Frage der Optik - die z.B. Dich verwirrt.

Bei Deinem "Auszug aus erhaltenen Werten" werden doch anscheinend vernünftig aussehende Daten gesendet, was willst Du mehr?

   

Mir ist ehrlich gesagt der Drahtwirrwar in Deinem VI zu groß, als daß ich Lust hätte das zu ordnen, um es dann vielleicht zu verstehen.... Außerden kann man die original - VISI-Inputs sowieso nicht ohne großen Aufwand simulieren. Hier wirst Du Dir wohl selbst helfen müssen.

' schrieb:Plötzlich fangst Du an von Start- und Stop- Kommandos zu reden. Wo kommen denn die auf einmal her? Wieso hast die Du vorher davon nichts gesagt? Was sind das für Bytes? Natürlich ist es möglich, die Datensätze auf Start-Stop-Basis zu filtern (- du meinst ahrscheinlich zu trennen -), aber dazu fehlen Angaben, wie die Start/Stop-Information aussieht.

@Lucki: Indirekt hierher: http://www.LabVIEWforum.de/index.php?s=&am...ost&p=69059

@danii. Ich stimme meinen Vorschreibern zu, wenn du natürlich noch zwischenrein Kommandos sendest, dann musst du etwas mehr Intelligenz in dein Programm stopfen. Auch mein Bsp. (wie auch die Bsp der anderen hier)war nur gedacht, einen Stream von Messwerten nach einem "Go-Befehl" zu parsen. Es erkennt nur den Anfang des Streams, und wenn dazwischen weitere Rückmeldungen gibt, dann funktioniert das nicht. War auch eher als Hinweis-Idee gedacht, wie man das Ganze mal Online aufziehen könnte, und nicht am Schluss einen Komplett-Stream zu zerlegen.
Du "missbrauchst" momentan die Grundstruktur von Eugens Terminal, ohne an die Consumer-Loop weiterzugeben, wann Kommandos geschickt werden. Dass muss jetzt in die Hose gehen, denn dies war in diesem Programm auch gar nicht vorgesehen.
Eines zeigt dein Daten-Stream: Die Anleitung ist scheinbar nicht ganz korrekt.
   
Offenbar wird der gesendete Startbefehl "gon" ebenfalls mit "gon" quittiert, und das Stopkommando wird mit "snOKn" quittiert.

Offtopic:
Stell deinen "Start" und "Stop" Button lieber auf "Latch when Released", dann wird das Event erst ausgelöst, wenn du den Mouse-Button wieder loslässt->Bessere optische Rückmeldung an den User. Und bei Latch kannst du dir die Case-Strukturen sparen, das Event wird nur einmal ausgelöst.

Gruß Jens

' schrieb:Eines zeigt dein Daten-Stream: Die Anleitung ist scheinbar nicht ganz korrekt.
[attachment=45172:Image01.png]
Offenbar wird der gesendete Startbefehl "gon" ebenfalls mit "gon" quittiert, und das Stopkommando wird mit "snOKn" quittiert.

Aha, dann handelt es sich also bei dem Beispiel um 3 verschiedene Datensätze, und die Werte sind Temeraturen mit 0.01deg/digit.

Habe mal die Datensätze getrennt und die Temperaturen eingerechnet, dann kommt dieser langweilige Verlauf heraus:
       

Hallo

Ich hab es eingesehen, dass es nichts bringt aus bestehenden Programmen was zusammen zu basteln.
Ich werde nun mit euren Tipps ein eigenes Vi erstellen um den Sensor anzusteuern.

Nochmals Danke für die zahlreichen Tipp. Die haben mir echt weiter geholfen.

Gruss Danii