DAQmx & PFN_LIST_CORRUPT Bluescreen

Hallo,
ich habe eine Applikation in der ich mit DAQmx Funktionen und Timed Loops arbeite. Das VI läuft ohne Einschränkungen und macht auch genau was es machen soll. Wenn ich nun aber das VI bzw. LabVIEW schließe, wird ein Bluescreen erzeugt mit der Beschreibung PFN_LIST_CORRUPT. Laut meinen Google-Recherechen hat es etwas mit dem RAM oder Harddisk zu tun. Hatte jemand schonmal ein ähnliches Problem? Ich kann mir das momentan nicht erklären.

Achso meine verwendete Hardware: NI PCI-6221 (37-Pin).

Anzeige

Versuch' mal mit einem einfachen Beispielprogramm aus dem Examplefinder Deine Hardware anzusteuern und schau', ob das gleiche passiert.
Wenn Du da das Problem auch hast, dann teste Dein PCI-6221 mal auf einem anderen Rechner.
Wenn Du da das Problem auch hast, dann würde ich mal bei NI nachhaken, ob die was dazu wissen. Vielleicht ist die Karte ja kaputt.

Gruß Markus

' schrieb:Hallo,
ich habe eine Applikation in der ich mit DAQmx Funktionen und Timed Loops arbeite. Das VI läuft ohne Einschränkungen und macht auch genau was es machen soll. Wenn ich nun aber das VI bzw. LabVIEW schließe, wird ein Bluescreen erzeugt mit der Beschreibung PFN_LIST_CORRUPT. Laut meinen Google-Recherechen hat es etwas mit dem RAM oder Harddisk zu tun. Hatte jemand schonmal ein ähnliches Problem? Ich kann mir das momentan nicht erklären.

Achso meine verwendete Hardware: NI PCI-6221 (37-Pin).

' schrieb:Versuch' mal mit einem einfachen Beispielprogramm aus dem Examplefinder Deine Hardware anzusteuern und schau', ob das gleiche passiert.
Wenn Du da das Problem auch hast, dann teste Dein PCI-6221 mal auf einem anderen Rechner.
Wenn Du da das Problem auch hast, dann würde ich mal bei NI nachhaken, ob die was dazu wissen. Vielleicht ist die Karte ja kaputt.

Gruß Markus

Danke für deine Antwort.
Ich glaube ich habe den Fehler gefunden. Wir benutzen ein Toplevel VI, was unsere Module managed. Das große Problem an diesem Modul ist, dass es wenn man auf Exit klickt einfach LabVIEW beendet auch wenn noch VI's laufen. Ich habe mal ein LabVIEW Example laufen lassen und bin zum "Getting Started" Window. Dort habe ich einfach wärend der Laufzeit des VI's LabVIEW beendet. Siehe da, die gleiche Fehlermeldung. Jetzt dachte ich mir, wenn ich mein VI nicht als Sub VI einbinde sondern dynamisch aufrufe, könnte ich umgehen das mein VI welches mit der NI Karte Kommuniziert einfach abgebrochen wird.

Es ist doch so, dass dynamisch geladene VI's (Call by reference) nach der Ausführung und schließen der Referenz nicht mehr im Speicher sind, oder?

' schrieb:Das große Problem an diesem Modul ist, dass es wenn man auf Exit klickt einfach LabVIEW beendet auch wenn noch VI's laufen.

Und da wundert ihr euch?

Zitat:Es ist doch so, dass dynamisch geladene VI's (Call by reference) nach der Ausführung und schließen der Referenz nicht mehr im Speicher sind, oder?

Erstens:
Darauf würde ich mich nicht verlassen.
Zweitens:
Was glaubst du wohl, was passiert, wenn du die Referenz einfach löscht und damit das VI hart abbrichst? Irgendwas in diesem VI wird wieder falsch laufen.

Es gibt nur eine sinnvolle Möglichkeit: Der Reihe nach alles beenden. Zuletzt LV.

' schrieb:Und da wundert ihr euch?

Dafür kann ich nix. ;-) Habs schon als Verbesserungsvorschlag angebracht.

' schrieb:Erstens:
Darauf würde ich mich nicht verlassen.

OK

' schrieb:Zweitens:
Was glaubst du wohl, was passiert, wenn du die Referenz einfach löscht und damit das VI hart abbrichst? Irgendwas in diesem VI wird wieder falsch laufen.

Es gibt nur eine sinnvolle Möglichkeit: Der Reihe nach alles beenden. Zuletzt LV.

Du hast mich glaub ich falsch verstanden. Ich selbst rufe das VI, welches mir die Kommunikation mit der NI Karte regelt nun dynamisch auf und schließe nach dem aufruf nur diese Referenz. Leider hat es nicht den erwünschten Erfolg gebracht.

Hat noch jemand einen Vorschlag?

Ich hab den Fehler nun eingegrenzt. Der Bluescreen wird von meiner Timing Source erzeugt. Ich synchronisieren zwei Timed Loops und wenn diese Ihre Arbeit getan haben, werden die Tasks wieder gestoppt und gelöscht. Aber irgendwie scheint genau das nicht so ganz zu funktionieren. Die Timed Loops arbeiten korrekt, aber ich bekomme einen Bluescreen wenn ich mein VI mit der X Taste schließe (obwohl das Sub VI mit den Timed Loops bereits beendet (ohne Fehlermeldung) ist). Verwende ich nun statt des Hardwarecounters das Daqmx VI "Create Timing Source.vi" läuft alles ohne Probleme. Das klingt jetzt alles etwas kompliziert, darum habe ich mal 2 Screenshots zur Verdeutlichung hochgeladen:
Funktioniert:
   

Funktioniert nicht:
   

Anzeige

' schrieb:Ich hab den Fehler nun eingegrenzt. Der Bluescreen wird von meiner Timing Source erzeugt. Ich synchronisieren zwei Timed Loops und wenn diese Ihre Arbeit getan haben, werden die Tasks wieder gestoppt und gelöscht. Aber irgendwie scheint genau das nicht so ganz zu funktionieren. Die Timed Loops arbeiten korrekt, aber ich bekomme einen Bluescreen wenn ich mein VI mit der X Taste schließe (obwohl das Sub VI mit den Timed Loops bereits beendet (ohne Fehlermeldung) ist). Verwende ich nun statt des Hardwarecounters das Daqmx VI "Create Timing Source.vi" läuft alles ohne Probleme. Das klingt jetzt alles etwas kompliziert, darum habe ich mal 2 Screenshots zur Verdeutlichung hochgeladen:
Funktioniert:
[attachment=43841:Timed_Lo...tioniert.jpg]

Funktioniert nicht:
[attachment=43842:Timed_Lo...rt_nicht.jpg]

Niemand eine ahnung was ich vergessen haben könnte?

' schrieb:Niemand eine ahnung was ich vergessen haben könnte?

Ich würde einfach (und weil du alle Tasks auf einer Karte laufen läßt ist es tatsächlich sehr einfach) die ganze AI/AO Geschichte auf Hardware-Timing umstellen und und auf die Timed Loops komplett verzichten. Beispiele dazu wie das geht gibt's im Example Finder ...

Ich versteh sowieso nicht warum immer wieder Timed Loops statt richtigem Hardware-Timing verwendet werden, nur weil es 'n büschen "komplizierter" ist das zur programmieren?? Ich kann die Dinger nicht leiden. Die einzige Verwendung wo Timed Loops tatsächlich Sinn machen ist IMHO im FPGA Modul wenn man die Singe Cycle Timed Loop verwendet um die Ausführungs-Geschwindigkeit zu optimieren ...

' schrieb:Ich versteh sowieso nicht warum immer wieder Timed Loops statt richtigem Hardware-Timing verwendet werden, nur weil es 'n büschen "komplizierter" ist das zur programmieren??

Ich fand eigentlich das es sehr einfach war die zu programmieren. Da ich hier bereits alles habe was ich für meine Applikation brauche (Offset, High-, Lowtime). Aber deine Anregung finde ich nicht verkehrt.

' schrieb:Ich würde einfach (und weil du alle Tasks auf einer Karte laufen läßt ist es tatsächlich sehr einfach) die ganze AI/AO Geschichte auf Hardware-Timing umstellen und und auf die Timed Loops komplett verzichten. Beispiele dazu wie das geht gibt's im Example Finder ...

Bei mir sind es DI/DO. Mit Hardware-Timing habe ich allerdings noch keine Erfahrung. Werde mir mal die Examples ansehen. Danke schonmal.

' schrieb:Ich fand eigentlich das es sehr einfach war die zu programmieren. Da ich hier bereits alles habe was ich für meine Applikation brauche (Offset, High-, Lowtime). Aber deine Anregung finde ich nicht verkehrt.
Bei mir sind es DI/DO. Mit Hardware-Timing habe ich allerdings noch keine Erfahrung. Werde mir mal die Examples ansehen. Danke schonmal.

ich hab grad mal n büschen rumprobiert und komme zu folgendem Ergebnis:

das wird schon etwas kniffliger und bei DI/DO sieht es tatsächlich so aus als müsstest du tatsächlich auf (IMHO die schlechteste aller Lösungen) Software-Timing zurückgreifen, es sei denn du hast
2 Messkarten, die in der Lage sind gepufferte DIO-Operationen auszuführen, oder eine Messkarte die auf 2 Ports gepufferte DIO Operationen ausführen kann (weiß nicht ob NI so eine im Programm hat)

Hintergrund: Hardware-Timing beruht mehr oder weniger darauf, dass man die Karte einmal "richtig" einstellt und die Karte das "harte Timing" machen läßt und mehr oder weniger "locker" einmal innerhalb eines Datenblocks liest oder schreibt. Beispiel: Analoge Erfassung mit 1000 Hz, Blockgröße 100 Samples => alle 100 ms (= Loop-Rate der Lese-Schleife von 10 Hz) holt man einmal Daten ab. Die Karte macht die schnelle Arbeit, die CPU ist relativ gelangweilt mit alle 100 ms mal 100 Werte in den Hauptspeicher übertragen. Bei Software Timing schreibt man (je nach einstellung, ich beschreib jetzt mal den schlechtesten Fall) jeden Wert als Single-Update auf die Messkarte bzw. holt jeden Wert einzeln hab, das ist jedes mal (mindestens ein) ein DLL function call, Kommunikation über den PCI-Bus, etc und das mit der vollen Sample-Rate

Aber: es gibt eine Alternative, die vielleicht gar nicht mal so schlecht ist:
mach die digitale Ausgabe mit einem analogen Ausgang, es ist ja nicht verboten immer 0 Volt oder 5 Volt auszugeben (und kannst sogar noch deinen TTL-Pegel manipuleren). Dann hast du einen gepufferte analoge Ausgabe und eine gepufferte digitale Erfassung, du kannst das ganze als synchronisierte Tasks auf der Karte laufen lassen und brauchst kein Software-Timing. Leider unterstützen gepufferte digitale Tasks (ich hab's mit einer 6259 getestet) keine start-Trigger, darum muss man sich als Krücke noch mit einem selbst erzeugten, externen Messtakt behelfen den man mit einem Counter erzeugt ...


   


  Syn_DI_DO_Example.LV851.zip (Größe: 44,31 KB / Downloads: 201)