Hallo Kurt,
Zitat:Mein Gedanke dahinter war, dass es auf lange Sicht vielleicht schneller ist, den Wert in die Datei zu schreiben, als den Riesen-Array in der Schleife zu halten.
Der Gedanke ist durchaus richtig, aber das bedeutet nicht, dass der FileAccess in der Messschleife stattfinden muss!
Vielleicht
liest du einfach bei NoWay mit, der hatte heute ein sehr ähnliches Problem!
Grundgedanke: Dateizugriffe in paralleler Schleife, Datentransport per Queue…
(01.10.2014 20:16 )GerdW schrieb: [ -> ]Hallo Kurt,
Zitat:Mein Gedanke dahinter war, dass es auf lange Sicht vielleicht schneller ist, den Wert in die Datei zu schreiben, als den Riesen-Array in der Schleife zu halten.
Der Gedanke ist durchaus richtig, aber das bedeutet nicht, dass der FileAccess in der Messschleife stattfinden muss!
Vielleicht liest du einfach bei NoWay mit, der hatte heute ein sehr ähnliches Problem!
Grundgedanke: Dateizugriffe in paralleler Schleife, Datentransport per Queue…
Super, ist wirklich identisch das Problem.
Aber im Endeffekt ja nicht das Kernproblem.
Ich bin gespannt, ob jemand eine Lösung hat. HBM selber hat sie ja noch nicht, vielleicht kommt denen jemand zuvor :-P
Bis dahin bessere ich mal meine LabVIEW-Grundkenntnisse auf, damit ich irgendwann vielleicht auch mal ein VI posten kann, durch welches nicht gleich alle abgeschreckt sind ;-)
@Mod: Bitte meinen Anhang aus dem ersten Post löschen! Ich hatte nicht auf dem Schirm, dass dort mein Name im Klartext zu lesen ist. Das VI ist ja im späteren Verlauf des Threads noch mal zu sehen...
Wenn es um das Erfassen und Speichern vieler Datenpunkte geht, da bietet sich TDMS als Speicherformat an. Und für die Auswertung gibt es ebenfalls bessere Programme als Excel, angefangen von DIAdem bis zu Origin.
Und nochmal, das Speichern gehört in einen parallelen Prozess (aka extra Schleife, Stichwort Producer-Consumer).
Ich habe schon Prüfstände für mehrere Wochen Messdauer programmiert (ein akt. Bsp: Datenerfassung läuft hier mit 20 Hz, davon werden aber nicht alle gespeichert), und da laufen Erfassung, Visualisierung und Speicherung natürlich parallel!!!
Gruß, Jens
(01.10.2014 20:25 )Kurt.Döner schrieb: [ -> ] @Mod: Bitte meinen Anhang aus dem ersten Post löschen! Ich hatte nicht auf dem Schirm, dass dort mein Name im Klartext zu lesen ist. Das VI ist ja im späteren Verlauf des Threads noch mal zu sehen...
Und das gleich mehrfach. Nicht nur im FP, auch in Pfad-Konstanten...
Hallo Kurt,
da sind wirklich üble RaceConditions in deinen VIs! Lösche so viele lokale Variablen wie nur irgend möglich!
Dein subVI "Kolben zurück" könnte z.B. so aussehen:
[
attachment=50958]
- Drähte statt lokaler Variablen
- FeedbackNodes (Rückkopplungsknoten) statt lokaler Variablen!
THINK DATAFLOW!
(01.10.2014 20:28 )jg schrieb: [ -> ]Wenn es um das Erfassen und Speichern vieler Datenpunkte geht, da bietet sich TDMS als Speicherformat an. Und für die Auswertung gibt es ebenfalls bessere Programme als Excel, angefangen von DIAdem bis zu Origin.
Und nochmal, das Speichern gehört in einen parallelen Prozess (aka extra Schleife, Stichwort Producer-Consumer).
Ich habe schon Prüfstände für mehrere Wochen Messdauer programmiert (ein akt. Bsp: Datenerfassung läuft hier mit 20 Hz, davon werden aber nicht alle gespeichert), und da laufen Erfassung, Visualisierung und Speicherung natürlich parallel!!!
Jau, ich versuche das hinzukriegen!
(01.10.2014 20:28 )jg schrieb: [ -> ] (01.10.2014 20:25 )Kurt.Döner schrieb: [ -> ] @Mod: Bitte meinen Anhang aus dem ersten Post löschen! Ich hatte nicht auf dem Schirm, dass dort mein Name im Klartext zu lesen ist. Das VI ist ja im späteren Verlauf des Threads noch mal zu sehen...
Und das gleich mehrfach. Nicht nur im FP, auch in Pfad-Konstanten...
Sehr richtig.......
Mit welcher Schnittstelle kommunizierst du mit deinem HBM Quantum? 100 Hz bei Einzelwert-Abfrage und Setzen per Ethernet ist IMHO für einen Windows-Rechner schon recht gut.
Gruß, Jens
(01.10.2014 20:35 )GerdW schrieb: [ -> ]Hallo Kurt,
da sind wirklich üble RaceConditions in deinen VIs! Lösche so viele lokale Variablen wie nur irgend möglich!
Dein subVI "Kolben zurück" könnte z.B. so aussehen:
- Drähte statt lokaler Variablen
- FeedbackNodes (Rückkopplungsknoten) statt lokaler Variablen!
THINK DATAFLOW!
Da habe ich echt lange nicht mehr reingeschaut... das ist wirklich übel.... Da ist ja sogar ein Bedienelement drin, was nix tut...
Vielen Dank für die Veranschaulichung!
Hallo Kurt,
Zitat:Da ist ja sogar ein Bedienelement drin, was nix tut...
- Es war eines drin, welches nicht verdrahtet war. Dafür wurde lieber eine lokale Variable davon gelesen…
- Noch übler ist allerdings, wenn man einerseits Werte von Eingängen gleich in die Ausgänge
verdrahtet und dann parallel versucht, eben diese Ausgänge nochmal
per lokaler Variable zu setzen! PFUI!
(01.10.2014 20:39 )jg schrieb: [ -> ]Mit welcher Schnittstelle kommunizierst du mit deinem HBM Quantum? 100 Hz bei Einzelwert-Abfrage und Setzen per Ethernet ist IMHO für einen Windows-Rechner schon recht gut.
Gruß, Jens
Ich bin mir gerade nicht sicher, was genau du meinst...
Vielleicht beantwortet das Bild im Anhang meine Frage... (?)
*Nachtrag: Aus dem Cluster wird noch ein Array....! :-)
Zitat aus der Beschreibung vom MX878 auf der HBM Homepage:
Zitat:Als Kommunikationsschnittstelle können Sie den Ethernet- oder FireWire-Anschluss nutzen.
Der .NET API von HBM bleibt am Ende auch nichts anderes übrig, als die Daten über deine Netzwerkschnittstelle (oder doch Firewire) zu schicken. 100 Hz (also alle 10 ms 1x alle Ist-Werte abholen) ist nicht schlecht.
Gruß, Jens
EDIT: Wozu ist der Konstruktor "Connector-Types" gut? Wird ohne weiter Verwendung wieder geschlossen.
