' 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
