Mehrere Signale darstellen (EKG)

Hi Gerd,

das letzte VI das Xi hochgeladen hat kommt von mir, hab ich ohne großes Vorwissen der gegebenen Situation erstellt. Es ist erst einmal dazu gedacht gewesen, genauere Infos über die vorliegenden Daten zu erhalten.

(28.06.2014 17:53 )GerdW schrieb:  - wozu die Sequenz um die Case-Struktur zum Speichern der Daten?

Ich hab die Sequenz eingefügt um sicherzustellen, dass der "Save?"-Button erst nach Beendigung der While-Schleife ausgelesen wird.

(28.06.2014 17:53 )GerdW schrieb:  - wozu formatierst du die erhaltenen Daten als 10stelliges Float mit 5 Nachkommastellen, wenn alles, was du da empfängst ein einzelnes Byte (Wertebereich 0…255) ist?

Hab ich schnell eingetragen ohne, zugegebenermaßen, groß über den Sinn oder Unsinn der Formatierung nachzudenken, die Nachkommastellen hätte ich allerdings wirklich weg lassen können. Ich gebe im Allgemeinen gern eine größere Feldbreite vor als wirklich notwendig ist, finde ich in einem Text-File übersichtlicher.

(28.06.2014 17:53 )GerdW schrieb:  - die Nutzung von BytesAtPort ist (schon immer) höchstwahrscheinlich verkehrt: du solltest wissen, wie die Botschaft deines Messgerätes aussieht. Dementsprechend solltest du wissen, wieviele Bytes du zu erwarten hast und eben genau diese lesen.

Inwieweit ist die Nutzung von "BytesAtPort" verkehrt? Wenn ich keine Ahnung hab welche Datenbreite übertragen wird muss ich sie ja irgendwie ermitteln und Xi konnte uns dazu bisher keine konkrete Aussage liefern. Es ist natürlich klar, dass man wissen muss wie die übertragene Botschaft aussieht, damit man die Daten entsprechend weiterverarbeiten kann. Bisher hat Xi aber einfach das erste Byte verarbeitet, ohne die genaue Botschaft zu kennen
Wie fragst du die Nachricht ab, wenn du noch nicht genau sagen kannst wie viele Bytes zu erwarten sind? Ich bin immer dankbar für Verbesserungsvorschläge

Gruß

dauz

Anzeige

Hallo dauz,

Zitat:Ich gebe im Allgemeinen gern eine größere Feldbreite vor als wirklich notwendig ist, finde ich in einem Text-File übersichtlicher.

Damit fügst du aber öfter mal mehrere Leerzeichen mit in den Text ein, was bei CSV-Dateien störend sein kann. Je nach Formatierung hat man es dann mit mehrfachen (und dazu ungleichmäßig vielen) Trennzeichen zwischen den Werten zu tun…

Zitat:Bisher hat Xi aber einfach das erste Byte verarbeitet, ohne die genaue Botschaft zu kennen
Wie fragst du die Nachricht ab, wenn du noch nicht genau sagen kannst wie viele Bytes zu erwarten sind?

Xi liest eine unbestimmte Anzahl von Zeichen und verwendet immer nur das erste Byte. Daraus folgt, dass er entweder immer nur einzelne Bytes pro Botschaft empfängt und theoretisch jedes Byte einer Botschaft verwenden könnte. Wenn dem nicht so wäre, würde er keinen so schönen Graph erzeugen können, da er dann "falsche" Daten mit einlesen würde.
Darauf aufbauend würde ich (bei Sampleraten <=100Hz) gleich nur ein einzelnes Byte abfragen, dann übernimmt das VISARead automatisch das Warten auf dieses eine Byte. Bei höheren Sampleraten würde ich gleich mehrere Bytes abfragen (z.B. je 5 Bytes bei 500Hz Samplerate) und eben alle Bytes verwenden…

Hallo Gerd,

danke für die Anregungen, insbesondere was das Einlesen der Daten über VISA angeht, das werde ich zukünftig berücksichtigen.
Was die Speicherung der Daten mit einer längeren Feldbreite angeht, da hatte ich bisher noch keine Probleme beim Weiterverarbeiten. Aber stimmt schon, was die unregelmäßige Anzahl der Zeichen angeht, da kann es wohl durchaus zu Komplikationen kommen, danke für den Hinweis.


Gruß
dauz