Erfahrungen Mit NI-PCICAN/2

Hallo Gemeinde

Hat einer von euch Erfahrungen mit den CAN-Karten PCI-CAN/2 Serie 2 von NI?

Ich hab davon vier Stück im Einsatz zusammen mit drei weiteren DAQMx-fähigen NI-PCI-Karten (1xAnalogeingabe und 2xDigital-IO) sowie zwei Stück NI-4351 (Temperaturerfassung). Drei der CAN-Karten werden mit der Channel-API verwendet (eine mit den CANOpen-VIs von NI). Verwendet werden fünf Schnittstellen. Die Tasks der Schnittstellen sind in einem Array zusammengefasst, sodass alle Operationen mittels einer FOR-Schleife immer über alle Schnittstellen stattfinden. Für das Management aller Schnittstellen gibt es ein einziges SubVI. (Es wäre wohl auch pro Schnitsttelle ein geklontes SubVI möglich gewesen, hab ich aber so nicht gemacht.)

Die Applikation muss nur Daten erfassen. Die Applikation ist soweit funktionsfähig.

Mein Problem ist nun folgendes:
Sobald das Lesen aktiviert wird (gelesen wird eigentlich immer - es sei denn, man legt einen Deaktivierungscase drüber), stürzt das gesamte LV-System ab. Mal früher, mal später. Die Schwere der Abstürze ist abgestuft:
Anzeige der "Windows-Applikations-Ansturz-Meldung". Hierbei ist nur eine der ca. 30 LV-Tasks abgestürtzt - nämlich das CAN-SubVI. Alle anderen LV-Tasks laufen problemlos weiter, während die Windowsmeldung dasteht. Wird diese Meldung quittiert, wird das gesamte LV-System beendet.
Das gesamte LV-System ist von einer (Milli-)Sekunde auf die nächste verschwunden - d.h. der LV-Prozess (siehe Taskmanager) ist nicht mehr da. Eine Windows-Fehlermedung erscheint nicht.
Der komplette Rechner stürzt quasi wie mit einem Bluescreen ab und rebootet.


Hat einer von euch Erfahrungen mit den CAN-Karten und der Channel-API?

Kann es sein, das ein PCI-WinXP-Rechner (Beckhoff, aktuelle Rechner-Technologie) mit der Masse der NI-DaqMX-Karten in Verbindung mit dem Traditional-DAQ überfordert ist?

Ich häng mal ein ZIP-File an mit dem CAN-SubVI. Vielleicht kann ja einer was damit anfangen.

Anzeige

ich hab mir das VI mal angeschaut. So auf die Schnelle kann ich nix erkennen. Ich hab bereits mehrfach NI CAN Karten verwendet und sowas wie die von dir beschriebenen Probleme hab ich damit noch nie erlebt.

Für mich klingt das irgendwie so als würde der Treiber mit einem falschen Gerätekontext gefüttert. Ich würde mir mal die Channel API VIs genauer anschauen, ob da ggf. ein Draht nicht richtig durchgeschliffen wird? Beim CAN Read Multi ist mir z.B: aufgefallen, dass da ein Coercion Dot bei der Task reference ist, obwohl der Datentyp augenscheinlich richtig ist. Wenn man diese Controls löscht und neu erstellt sind se weg ... ich würd da auf jedenfall mal mit NI drüber diskutieren ...

' schrieb:sowas wie die von dir beschriebenen Probleme hab ich damit noch nie erlebt.

Ich hätte es auch nicht geglaubt, wenn ich es nicht selbst gesehen hätte.

Zitat:Beim CAN Read Multi ist mir z.B: aufgefallen, dass da ein Coercion Dot bei der Task reference ist,

zu deutsch: Ein Konvertierungspunkt? An mindestens einem Channel-VI befindet sich bei dir eine automatische Konvertierung? Hab ich das richtig verstanden? Bei mir ist da nämlich nichts von zu sehen! Ich habe hier die Version 2.5.2 (Oktober 2007).

Zitat:Wenn man diese Controls löscht und neu erstellt sind se weg

Ja, dieses Verfahren kenne ich. Ich werde das also auch mal hier probieren.

Zitat:ich würd da auf jedenfall mal mit NI drüber diskutieren

Ätsch. Hab ich schon. Bei uns im Hause! Antwort neben Achselzucken: Er mir geraten den Deaktivierungscase über das GetProperty zu machen - dadurch wird nämlich die Wahrscheinlichkeit eines Absturzes geringer.

' schrieb:zu deutsch: Ein Konvertierungspunkt? An mindestens einem Channel-VI befindet sich bei dir eine automatische Konvertierung? Hab ich das richtig verstanden? Bei mir ist da nämlich nichts von zu sehen! Ich habe hier die Version 2.5.2 (Oktober 2007).

ja, genau dieses:

   

ich hab auch CAN 2.5.2 (f0)

' schrieb:Ätsch. Hab ich schon. Bei uns im Hause! Antwort neben Achselzucken: Er mir geraten den Deaktivierungscase über das GetProperty zu machen - dadurch wird nämlich die Wahrscheinlichkeit eines Absturzes geringer.

passiert das auch, wenn du die Funktionalität in einem Test VI so abspeckst, dass quasi kein drumherum mehr stattfindet sonder nur das parallele Lesen/Schreiben auf den CAN Ports? Ich würde so rangehen und versuchen rauszufinden, "ab welchem Punkt" sich das Verhalten reproduzieren läßt.

Im Übrigen (die Stelle passt grad und drum will ich das hier ma loswerden): ich bemängle schon seit einiger Zeit, dass die Qualität der SoftWare von NI immer mehr abnimmt. Offensichtlich werden da in der Entwicklung zu viele Ressourcen in marketing-wirksame Features wie LVOOP (<sarkasmus> ein Feature auf das die LV Welt nun wirklich DRINGEND gewartet hat ... </sarkasmus> und ähnlichen Schnickschnack gesteckt anstatt die Qualität des Produkts gleichbleibend hoch zu halten. Manchmal bedauere ich wirklich, dass es keinen echten Wettbewerb gibt ...

' schrieb:ja, genau dieses:

Ach, IM SubVI.

Zitat:passiert das auch, wenn du die Funktionalität in einem Test VI so abspeckst, dass quasi kein drumherum mehr stattfindet sonder nur das parallele Lesen/Schreiben auf den CAN Ports? Ich würde so rangehen und versuchen rauszufinden, "ab welchem Punkt" sich das Verhalten reproduzieren läßt.

Ich hab schon alles - naja sagen wir halt sehr, sehr viel - ausprobiert. Nichts hat bisher funktioniert. Jetzt fehlt noch das mit dem Ersetzen und folgendes will ich probieren: Pro Task ein Read-VI.

Im übrigen: Mit einer einzigen Task geht's - nur ab zwei geht's halt nicht mehr.

Zitat:marketing-wirksame Features wie LVOOP

Ja, ja. OOP und Datenfluß.

' schrieb:Im übrigen: Mit einer einzigen Task geht's - nur ab zwei geht's halt nicht mehr.

also so eine Windows Fehlermeldung kommt ja nur bei einer Schutzverletzung oder ähnlichem Hoch. Ich würde dann mal eiskalt auf einen Bug in der CAN DLL tippen, irgendwie bringt die wohl ihre handles durcheinander ...

Anzeige

' schrieb:ja, genau dieses:
[attachment=37559:canreadcoerce.png]

Bist du sicher, dass beim Ersetzen diese Konvertierungspunkte verschwunden sind?

Ich hab das VI mal ersetzt, hat aber nichts gebracht. (Auch die Massenkompilierung hat nichts gebracht). Ich bin der Meinung, die Konvertierungspunkte sind gar nicht wegzubekommen. Und zwar aus folgendem Grund: Der Eingang am DLL-Knoten ist ein bestimmter Typ - hier U32. Die Task-Variable aber hat einen anderen Typ: CAN Task Reference.ctl! Die ist zwar vom Basistyp U32. Aufgrund aber der expliziten Typdefinition ist beides - Variable und DLL-Eingang - nicht 100% identisch - daher ein Konvertierungspunkt. Würdest du das auch so sehen?

' schrieb:Ich würde dann mal eiskalt auf einen Bug in der CAN DLL tippen, irgendwie bringt die wohl ihre handles durcheinander ...

Ja, man muss das fast vermuten. Nur: was nützt mir das? Der Kunde will sein Programm. Im übrigen hat "der in München bei der Entwicklungsabteilung von NI" gesagt: Er kann keinen Fehler finden.

' schrieb:Bist du sicher, dass beim Ersetzen diese Konvertierungspunkte verschwunden sind?
Ich hab das VI mal ersetzt, hat aber nichts gebracht. (Auch die Massenkompilierung hat nichts gebracht). Ich bin der Meinung, die Konvertierungspunkte sind gar nicht wegzubekommen. Und zwar aus folgendem Grund: Der Eingang am DLL-Knoten ist ein bestimmter Typ - hier U32. Die Task-Variable aber hat einen anderen Typ: CAN Task Reference.ctl! Die ist zwar vom Basistyp U32. Aufgrund aber der expliziten Typdefinition ist beides - Variable und DLL-Eingang - nicht 100% identisch - daher ein Konvertierungspunkt. Würdest du das auch so sehen?

da hab ich nochma genauer geguckt:
Joh, CAN Task Reference.ctl ist einfach nur ein Typedef mit einem U32 - IMHO eine völlig unsinnige Aktion, es sei denn der Programmierer war sich nicht sicher, welchen Datentyp er denn bei Auslieferung verwenden möchte. Wenn man den wieder anschließt bleibt der Coercion Dot bestehen. Ich hatte nur einfach mal die Controls ersetzt, dadurch ist dann zwar der Coercion DOT innerhalb des VIs verschwunden, dafür hätte man ihn dann in den aufrufenden VIs ==> bringt nix sich darum zu kümmern, weil man sonst die ganze CAN Lib anpassen müsste <seufz> ==> bringt auch nix sich über diesen Coercion Dot Gedanken zu machen, weil der in dem Fall nicht zu verhindern ist ...

Zur Information:

Ich wage - wieder mal - zu sagen, dass es geht.

Und zwar hab ich einen Umbau gemacht. Siehe Anhang. Die Verbindung "Pro CanTask ein CanRead" mit "Speicher immer kopieren" scheint jetzt zu funktionieren. Ohne "Immer kopieren" geht es auf jeden Fall nicht. Warum geht es überhaupt, wenn "Immer kopieren" eingefügt wird?

Die Frage ist jetzt folgende: Wenn "Immer kopieren" die Lösung ist, wie heißt dann die Frage - spricht das Problem? - Speichermanager?


Ich bin ja mal gespannt, was da noch alles auf mich zukommt.

' schrieb:Ach, IM SubVI.

Ich hab schon alles - naja sagen wir halt sehr, sehr viel - ausprobiert. Nichts hat bisher funktioniert. Jetzt fehlt noch das mit dem Ersetzen und folgendes will ich probieren: Pro Task ein Read-VI.

Im übrigen: Mit einer einzigen Task geht's - nur ab zwei geht's halt nicht mehr.

Ja, ja. OOP und Datenfluß.

Klingt gefährlich nach einer Race Condition entweder im Treiber selber oder wahrscheinlich im DLL Interface zum Treiber. Vielleicht auch im Zusammenhang mit MultiCore CPUs.

Hatte erst kürzlich so ein Problem obwohl nicht gerade ein Systemcrash provoziert wurde. Mit meinem ODBC Treiber hatte ich eine Applikation gebaut die sowohl eine Access Datenbank als auch eine grössere SQL Server Datenbank und ein Oracle basiertes Bestellungssystem ansprach. Bei mir lief alles immer perfekt aber beim Kunden ging es regelmässig falsch beim Auslesen von grossen Queries aus der Access Datenbank. Kam manchmal innerhalb der Query ein Fehlermeldung vom ODBC Treiber dass das Cursor Keyset ungültig war.

Kürzlich bekam ich einen neuen Notebook, ein DualCore und plötzlich hatte ich genau die selben Fehler. Mit dem Debugger in meine ODBC Interface DLL getaucht aber ich konnte nichts feststellen auch weil der Fehler nicht gut reproduzierbar war. Manchmal geschah er in der 20sten Row der Query manchmal in der 400sten und manchmal nicht.

Bis mir plötzlich die Idee kam dass es mit dem DualCore zu tun haben könnte. Habe das VI das die gesamte Access Query ausführt versuchshalber in den UI Thread verlegt, so dass die Query komplet in immer demselben Thread ausgeführt wird und seither keinen einzigen Fehler mehr gesehen. Scheinbar kommt der Access ODBC Treiber manchmal ins Trudeln wenn er von verschillenden Threads aus aufgerufen wird auch wenn diese Aufrufe an sich sequentiel also nicht parallel sind.

Die Can VIs alle in den UI Thread zu verlegen scheint mir keine gute Idee, aber vielleicht könntest Du die entsprechenden Top Level VIs von denen die CAN Tasks ausgeführt werden in ein spezifisches Execution Sytem setzen und dieses Execution System so konfigurieren (vi.libUtilitysysinfo.llbthreadconfig.vi) das es nur mit einem Thread läuft. Wäre zumindest ein Versuch wert.

' schrieb:Zur Information:

Ich wage - wieder mal - zu sagen, dass es geht.

Und zwar hab ich einen Umbau gemacht. Siehe Anhang. Die Verbindung "Pro CanTask ein CanRead" mit "Speicher immer kopieren" scheint jetzt zu funktionieren. Ohne "Immer kopieren" geht es auf jeden Fall nicht. Warum geht es überhaupt, wenn "Immer kopieren" eingefügt wird?

Die Frage ist jetzt folgende: Wenn "Immer kopieren" die Lösung ist, wie heißt dann die Frage - spricht das Problem? - Speichermanager?
Ich bin ja mal gespannt, was da noch alles auf mich zukommt.

Könnte eine Race Condition sein. Irgendwie probiert LabVIEW zu optimalisieren und kopiert die Daten nicht immer und die DLL hält da irgendwie noch eine Referenz darauf. Wenn diese Referenz dann in der DLL angesprochen wird geht es falsch. Hat aber wohl am wahrscheinlichsten etwas mit einer Optimalisierung im Zusammenhang mit den neuen Clones zu tun, das dieses CAN VI ja verwendet. Nur dass man durch einen LabVIEW Fehler eine BSOD bekommt ist schon etwas komisch. Das ist etwas für Device Drivers aber nicht für Applikationen. Aber so Dinge als die Timed Loop gehen ja inzwischen direkt aus LabVIEW so tief ins System, dass das eben schon passieren kann.

Ganz sicher ein Bug, wo und warum auch immer. Wer weiss vielleicht hat LabVIEW 8.5.1 ja einen Fix dafür.

Rolf Kalbermatter