Gaspruefstand - Programm

' schrieb:Ich bin momentan vom Rang der LabVIEW Meister hier

Na guck, dann steht du auf einer Stufe mit Einstein: Alles relativ. (:yahoo<= Lieblingsicon)

Zitat:Problem: die Schleife wartet ja doch und liest nicht den selben Wert nochmal. Man sieht das daran dass der Counter nicht hochzaehlt.

Kann fast nicht sein.
Erstens muss in die While-Schleife eine Wartezeit rein. Das ist - leider - so. Ohne Wartezeit wird i zwar erhöht - aber das FP nicht refreshed. Daher siehst du nix. Mach also mal eine Wartezeit (Metronom oder Wait) von ca. 10ms rein.
Außerdem muss das mit dem Melder gehen - ich mach das nämlich so. Kuck mal, ob da irgendwo ein Eingang ist, der entsprechend beschaltet werden muss. An eine Änderung der Melderfunktionalität von 7.1 nach 8.x glaube ich jetzt nicht. Ich prüfe das aber.

Zitat:Ich kann im channel keinen Datentyp U8 auswaehlen. Nur Unsigned, Singed und IEEE Float.

Mach folgendes:
Erstelle 8 Channels. Jeder 8 Bit breit (Number of Bits), also unsigned (Datatyp). Der erste beginnt bei Bit 0 (Startbit), der zweite bei Bit 8 der, dritte bei Bit 16 usw. Als Name gibst du Byte0 bis Byte7 an. Diese Namen musst du dann auch angeben, wenn du die Sendetask erstellt: Die Sendetask hat dann 8 Variablen - und das sind dann deine 8 Byte 5F bis FF.

Zitat:Auf der linken Seite sieht man es mit dem Example Programm fuer CAN Frames. Das geht einwandfrei. Der Sensor springt an und wenn ich es abschalte geht er sofort wieder aus.

Can-Frame hat den Nachteil, dass du dich um die Aufteilung der 64 Datenbits selbst kümmern musst. In deinem Falle ist das ein Vorteil, da du einen definierten 64-Bitstream hast. Und den einfach auf als Frame senden lassen kannst.

Zitat:Erstens muss in die While-Schleife eine Wartezeit rein. Das ist - leider - so. Ohne Wartezeit wird i zwar erhöht - aber das FP nicht refreshed. Daher siehst du nix. Mach also mal eine Wartezeit (Metronom oder Wait) von ca. 10ms rein.
Außerdem muss das mit dem Melder gehen - ich mach das nämlich so. Kuck mal, ob da irgendwo ein Eingang ist, der entsprechend beschaltet werden muss. An eine Änderung der Melderfunktionalität von 7.1 nach 8.x glaube ich jetzt nicht. Ich prüfe das aber.

Auch mit Wartezeit kein Erfolg. Wenn das der ausschlaggebende Punkt gewesen waere, haette in meinem ersten Versuch nach Druecken des Stopknopfes die Anzahl der durchgelaufenen Loops dastehen muessen - oder? Nagut um ehrlich zu sein, ich hab darauf nicht geachtet

Einen brauchbaren Eingang zum beschalten habe ich nicht gefunden.
Also bei dir zaehlt diese Programm hoch?

  notifier5.vi (Größe: 21,16 KB / Downloads: 352)


Das mit dem CAN teste ich sofort. Ich muss dazu immer zum PC im Labor rennen

Dir ist schon klar, das du gerade wie schon wahrschenlich sehr oft den Status 'persoenlicher Held' bekommen hast?
Das 'write' geht wirklich mit deiner Methode!!! Saufett.
Nur warum spielt es eigentlich keine Rolle ob ich Intel oder Motorola verwende? Hab beides getestet.

Zusammen schaut es nun so aus:
War das ungefaher das was du gemeint hast?
   

' schrieb:Dir ist schon klar, das du gerade wie schon wahrschenlich sehr oft den Status 'persoenlicher Held' bekommen hast?

Zitat:Nur warum spielt es eigentlich keine Rolle ob ich Intel oder Motorola verwende? Hab beides getestet.

"Inten" und "Motorola" gibt an, in welcher Reihenfolge z.B. die vier Bytes des Types U32 im Frame angeordnet werden. U32 besteht aus einem Low-Byte, zwei in der Mitte und einem High-Byte. Intelprozessoren speichern U32-Zahlen in der Reihenfolge Low->High ab. D.h. an der niederwertigen Adesse steht das niederwertige Byte. Bei Motorola-Prozessoren ist das genau umgekehrt. Wenn der Channel also lediglich U8 ist, hat die Vorwahl InteL/Motorola keine Auswirkung.

Zitat:War das ungefaher das was du gemeint hast?

Jawohl.

Noch was zum Melder:

Verwende nicht die Funktion "Auf Meldung warten". Diese Funktion wartet nämlich "auf den nächsten Wert". Das willst du arber gar nicht haben.

Nimm die Funktion "Melderstatus lesen". Diese Funktion gibt den Status aus - und dazu gehört eben auch die letzte, also noch aktuelle Meldung.

Zitat:"Inten" und "Motorola" gibt an, in welcher Reihenfolge z.B. die vier Bytes des Types U32 im Frame angeordnet werden.

Aso, ich dachte zuvor, dass es um die allgemein Anordnung der Bits innerhalb eines Bytes geht. Deshalb auch meine Frage
Aber dann ist natuerlich klar, dass es keine Rolle spielt, wenn man sowieso nur einzelne Bytes schickt (solange diese in der richtigen Reihenfolge sind)

Zitat:Nimm die Funktion "Melderstatus lesen". Diese Funktion gibt den Status aus - und dazu gehört eben auch die letzte, also noch aktuelle Meldung.

Seufz- wie lame von mir.
Danke, danke !!

Ich hoffe, dass du jetzt einen Tag Ruhe hast- den hast du dir verdient !

Hehe, ich muss das hier kurz mal aufgreifen:
Rekapitulation:

Ein Loop, dass Analog-DAQ mit hoher Samplerate ausliest und mit moderater Rate (1-100 Hz) in eine Datei schreibt.
Ein anderes Loop, das CAN - Daten ausliest und diese in einen Notifier schreibt.

Das AnalogDAQ Loop liest den Notifier und schreibt dessen Werte mit in die selbe Datei wie die AI-Werte.

CAN Daten sind aber pro Schreibvorgang weniger/mehr (je nach eingestellen Sampleraten) vorhanden als AI Daten. Also die Loops laufen mit verschiedenen Geschwindigkeiten


Meine Idee war jetzt, die Anzahl der Werte die aus dem Puffer gelesen werden bei beiden Loops identisch zu machen. Dann sind die Daten Arrays wenigstens gleich lang.
Allerdings hat man damit gravierende Probleme:
Z. B. wenn CAN nur mit 1 Hz laueft, aber das AI/DAQ Loop mit 100 Hz schreibt: Dann dauert es jedesmal 100 Sekunden bis ein neues CAN Paket fertig ist.

1. Wenn der Anwender zwischenzeitlich abbricht, muss er a)100 Sekunden warten und b) ist das Schreiben-Loop schon laengst vom Stop-Befehl beendet worden, die letzen Daten gehen also verloren.

2. Das Schreiben-Loop schreibt solang bis der Notifier aktualisiert wurde 100 x das 100er-Paket CAN Daten in Folge in die Ausgabedatei. Man hat also ein Muster dass sich wiederholt und einfach nur falsch ist.

3. Die Zeitinformation passt ja sowieso dann ueberhaupt nicht mehr...
Insofern verwerfe ich meine Idee sofort wieder - war quatsch.

Gibts da irgendwie eine geschickte Moeglichkeit das hinzubiegen? Meine Notloesung ist, CAN nicht individuell in der Samplerate zu gestalten sondern an die Datei-Schreib-Rate zu koppeln.
Dann hat man keine Probleme, kann aber auch nur maximal CAN mit 100 Hz lesen

' schrieb:CAN Daten sind aber pro Schreibvorgang weniger/mehr (je nach eingestellen Sampleraten) vorhanden als AI Daten. Also die Loops laufen mit verschiedenen Geschwindigkeiten

Das Problem, das hier auftritt, ist also die Synchronität der Daten. Die Daten selbst werden tatsächlich synchron produziert. Allerdings in unterschiedlichen Datenstreams. Beim Zusammenführen dieser beiden Streams zu einem treten genau die Probleme auf, die du beschrieben hast.

Setze dich mal mit Signalverläufen auseinander. Ein Signalverlauf enthält immer auch den Samplezeitpunkt (wenn auch nur indirekt aus Start und Offset etc.). LV sollte also in der Lage sein, beim Zusammenführen zweier Siganlverläufe diese so zusammenzuführen, dass ein synchroner Datenstream entsteht. Ich selbst war noch nie in der Verlegenheit, derartiges machen zu müssen.

Zitat:Allerdings hat man damit gravierende Probleme:

Stimmt.

Zitat:Z. B. wenn CAN nur mit 1 Hz laueft, aber das AI/DAQ Loop mit 100 Hz schreibt: Dann dauert es jedesmal 100 Sekunden bis ein neues CAN Paket fertig ist.

Wenn ein derart großer Unterschied zwischen den Abtastraten besteht, kann man (bin ich) wie folgt vorgehen: Der langsame Prozess schreibt seine Daten in einen Melder. Der wird dann halt alle Sekunden refresht. Der schnellere Prozess fügt zu jedem seiner Datenpakete einfach den Wert aus dem Melder hinzu. Bei diesem Verfahren gehe ich davon aus, dass der eine Wert für den gesamten Zeitraum gültig ist. Ist der Unterschied der Abtastraten groß genug und die Samplepakete der schnellen Task klein genug, so minimiert sich der "Gleichzeitigkeits"-Fehler, den dieses Verfahren automatisch beinhaltet.

Zitat:Wenn der Anwender zwischenzeitlich abbricht, muss er a)100 Sekunden warten und b) ist das Schreiben-Loop schon laengst vom Stop-Befehl beendet worden, die letzen Daten gehen also verloren.

Solchen Effekten kann man programmatisch vorbeugen: indem man die 100 Sekunden nicht am Stück wartet, sondern 1000x100ms. Dann kann man auch 100 Sekunden schlenn abbrechen.

Zitat:Meine Notloesung ist, CAN nicht individuell in der Samplerate zu gestalten sondern an die Datei-Schreib-Rate zu koppeln.

Wenn das für die Applikation kein Nachteil ist, würde ich das so machen.