(24.11.2015 14:36 )m.werle schrieb: Den Teil hier verstehe ich allerdings nicht. Hier gibt es zwei Aufrufe der FGV, allerdings werden beim ersten Aufruf weder Werte im FGV geändert, noch entnommen. Das einzige, was als Datenausgang wichtig ist, ist der Clustertyp, also die Form in welcher die Daten im FGV gespeichert sind. Diese ändert sich aber im gesamten Programm nicht während der Laufzeit. Das ist nur für die "Bundle by Name" Funktion wichtig. Wo soll es hier zu einem Raceconditionfehler kommen?
Es geht ums Prinzip.
Das Verfahren "Daten aus FGV lesen, diese Daten
extern ändern, Daten nach FGV schreiben" ist per se Race-Conditions-anfällig. Das Problem "RaceCondition" tritt dann auf, wenn genau das selbe Verfahren (mit dem selben Datencluster) parallel - also z.B. in einem anderen VI - gleichzeitig(!) gemacht wird. "Gleichzeitig" auslesen scheint nur kein Problem, ist aber auch schon eines. Hauptproblem ist das zurückschreiben. Einer der beiden ist immer der Erste, der hat verloren, und einer ist der zweite, dessen Daten stehen letztendlich in der FGV.
Grundsätzlich umgangen wird dieses Problem eben dadurch, dass die Änderung in der FGV stattfindet. Dann stehen nämlich zuerst die Daten des Ersten drinnen - die dann nämlich der zweite bereits ausliest ...
Problem ist auch nicht der aktuelle Stand des Programmes, sondern die Änderung, die erst in zwei Wochen kommt: Dann fällt nämlich deinem Chef ein, dass er einen weiteren Parameter, diesmal online geändert, im Sample-VI haben will. Und den würdest du dann, weil's eben so ganz einfach geht, per FGV übertragen - und schon hast du den gleichzeitigen Zugriff in zwei VIs. Du siehst, dein Programm läuft wochenlang ohne erkennbaren Fehler und plötzlich nach einer Änderung funktionieren Sachen nicht mehr, die mit der Änderung gar nichts zu tun haben.
Den Rest kuck ich mir heute Abend mal an.
(24.11.2015 14:36 )m.werle schrieb: DAQmx für die Erfassung der DI-Signale (Kann ich in MAX nicht sehen, welches der dort aufgelisteten simulationsfähigen Devices mir eine kontinuierliche DAQ von DI-Signalen erlaubt? :/ Heißt wohl durchprobieren...)
Ich gehe davon aus, dass jede DAQmx-Karte für DIs eine kontinuierliche Erfassung von DIs machen kann - zumindest habe ich noch nie das Gegenteil gehört.
Zitat:Prüfalgorithmen für diese programmieren. In welcher Form soll ich den Alarm speichern, wenn dieser aufgetreten ist? In einer Enum Variablen? Dann kann die Reaktion in einer Casestruktur abgehandelt werden.
Strikter Enum ist sehr gut. Enum einfach auf Case-Struktur geben. In der Case-Struktur lässt du den Standard-Fall weg! Wenn du jetzt einen Enum-Wert hinzufügst, bringt dir die IDE einen Fehler - und du weist ganz genau, welche Case-Strukturen du noch bearbeiten musst.
Zitat:Thema Datenlogging: Ist Speichern in TDMS Format überhaupt sinnvoll? Was ist mit Datalog-Dateien? Oder einer simplen txt-Datei? Die Daten sollen später zum Beispiel leicht in Excel importiert werden. Hab die Anweisung bekommen, dass einfach in eine txt-Datei zu packen, allerdings kennt sich von denen auch niemand groß mit den verschiedenen Datentypen aus. Wäre auf jedenfall recht kompatibel und wieder einfach auszuwerten.
Eigentlich würde mir TDMS am besten gefallen. Das ist einfacher als Textdateien. Zum Auswerten würde ich Diadem empfehlen.
Dummerweise wollen immer alle mit Excel arbeiten. Auch Excel kann TDMS-Files importieren (allerdings nur bis zu einer maximalen Größe, glaub ich). Speziell für Excel würde man CSV-Dateien machen.
/
DAQ-Anzeige in seperatem VI und Speicherung in TDMS Format
