Welches Feature ist denn das?

' schrieb:Ich schätze das ist bloß ein "Darstellungsproblem"

' schrieb:Also wenn es bei der Frage zu dem Screenshot um die Verbindungslinien geht, dann tippe ich darauf, dass die Option "Constant Folding" aktiviert ist.

Aha, eine neue Darstellungsoption auf das die LV-Gemeinde gewartet hat.
Könnte man diesem nicht auch Express-Wire sagen.
Ich schalte das sofort wieder aus.

Danke für die Info.

' schrieb:LV 8.5, WinXPPro. Kein RT. Spezielle hardware: Hm. 5xCan-Ports mit Channel-VIs, 2xCan-Ports mit CanOpen-Modul von NI, 2xNI-PCI-6518, 1xNI-PCI-6224, 2xNI-4351-PCI (Traditional-Daq). Alles neueste Versionen: Da da nämlich schon ein Problem mit dem Can war, das ich bereits gelöst habe, hab ich von allem die neuesten Treiber geladen.

Das könnte erst in vierzehn Tagen was werden - wenn der dritte Prüfstand gemacht werden soll.

Tja, sieht nicht nach 0815 Anwendung aus, habe ich noch fast vermutet, da kann ich vermutlich nicht viel helfen.
Wie hast du das den getestet/entwickelt wenn du die HW nicht hast?

Mein Kommentar war ja auch eher als Gedankenstütze gedacht, ob was anders ist zwischen Entw. und RT.

Hier trotzdem noch ein paar Bemerkungen:
- die neuste Version (LV oder Treiber) ist nicht unbedingt auch die stabilste.
- Frühere Versionen von LV haben gezeigt, das man immer auf die x.x.1 Version warten sollte.
Scheinbar ist ein Update auf LV8.5.1 im kommen. ReadmeLV8.5.1
und wenn ich hier die bekannten Fehler von 8.5 anschaue...... ev. findest du hier was, wenn du noch nicht gesucht hast. Da vermutlich eher selten bis gar nie diese Kombination von HW verwendet wird, kann es durchaus noch unbekannte Fehler haben.
Ich habe selber kein 8.5, die Version überspringe ich.

Das einfachste ist sicher mal warten auf den dritten Prüfstand

' schrieb:Wie hast du das den getestet/entwickelt wenn du die HW nicht hast?

Die Entwicklung hab ich schon mit der Hardware gemacht worden. Das ist aber auch schon ein halbes Jahr her. Dann hat der Kunde die Hardware bekommen und erste Tests gemacht. Die haben ja alle funktioniert. Erst jetzt, die letzten Wochen, wo er Dauertest über 10 Tage laufen soll, treten die Probleme auf.

Ich hab aber vor Auslieferung selbst einen "Dauerlauf" gemacht habe - und da ist nichts angesteigen. Weder Speeicher noch Handle. Dann sind zwar einige Erweiterungen gekommen, aber die haben doch alle nichts mit Handle zu tun - zumindest nicht direkt. Ich hab ja immernoch die Can-Treiber in Verdacht. Aber wie will ich denn das nachweisen.

Zitat:Ich habe selber kein 8.5, die Version überspringe ich.

Wegen des Fehlers mit dem Can-VI bin ich ja von 8.2.1 auf 8.5 umgestiegen. Hat zwar nichts gebracht, jetzt ist es aber da.

Naja.

' schrieb:Aha, eine neue Darstellungsoption auf das die LV-Gemeinde gewartet hat.
Könnte man diesem nicht auch Express-Wire sagen.
Ich schalte das sofort wieder aus.

Danke für die Info.

Also das kann schon interessant sein wenn Du Speicheroptimalisierung machen willst. Und im Zusammenhang mit ein paar Bugs mit Konstantfolding in 8.0 und 8.2.0 könnte das auch mal interessant sein um zu sehen.

Rolf Kalbermatter

Ich wollte euch ja noch mitteilen, was aus der Sache mit den Handles und dem Fokus geworden ist: Es geht jetzt.

Gelegen war es - wenn man der Lösung glauben darf - am CanOpen-Modul (mit dem ein Delta-Netzteil angesteuert wird). Da wird mit einer Timeoutzeit von 15ms ein PDO, der auf 10ms eingestellt ist, gelesen. Dannach ein weiterer PDO (Raster auch 10ms, Timeout 0ms). Zuletzt kommt eine Node Guard Überwachung (Einstellung 100ms, Timeout 5ms). Ist alles in Ordnung, so hat dieser Case eine Durchlaufzeit von ca. 10ms.

Und der "Fehler" ist weg, wenn am Ende dieses Cases eine Wartezeit von 1 Millisekunde eingefügt wird. - Er würde auch weggehen, wenn die Wartezeit mit 0 Millisekunden gleich nach dem ersten PDO-Lesen quasi parallel zum zweiten PDO-Lesen eingefügt wird (vergleiche Bild. Beachte: eine Wartezeit reicht!). Ich habe mich vorerst aber für die erste Version entschieden. Sequenziert scheint mir sicherer.

' schrieb:Und der "Fehler" ist weg,

Was ich noch sagen wollte:

Nicht dass einer denkt, der Fehler wäre weg. Die Wahrscheinlichkeit, dass er auftritt, ist lediglich erheblich gesunken. Was mich bei "zeitgesteuerter Fehlerbehebung" eigentlich ja auch nicht wundern sollte.

Er ist sogar wieder reproduzierbar: Man muss nur schnell genug von LV nach Taskmanager und wieder zurück wechseln. Und das in 100, 200 Millisekunden. Dann ist die Wahrscheinlichkeit groß, dass die Handle wieder hochlaufen. Zwar langsamer als vorher, aber immerhin.

Dieser Effekt z.B. ist ein wahrer Grund, warum NI eigenlich nur noch PXI machen will.

Anzeige

Ach, neue Experten, neuer Anlauf.

Da ja jetzt hier weitere Experten eingetroffen sind, zieh ich doch mal mein Thema wieder hoch. Vielleicht hat ja einer einen Tipp in welche Richtung auch immer.

Das Problem mit den hochlaufenden Handles unter LV 8.5 und dem folgenden Programmabsturz besteht nämlich immer noch. Es sei denn, man fokusiert eine andere Anwendung - z.B. Taskmanager.

Neue Info:

Erstens gibts schon wieder neue Can-DLL, jetzt Version 2.6.1.

Außerdem hab ich folgendes geändert: siehe Bild.
Eigentlich war ich ja der Meinung, dass der Parameter "behavior after final output" pro Task gilt - zumal der Parameter ja auch unter Task steht. Es kam ja auch nur ganz selten warum auch immer ein Fehler beim Setzen dieses Parameters. Dann hab ich das halt mal so umgebaut, dass das VI pro Channel in Task aufgerufen wird. Seitdem tritt zumindest hier kein Fehler mehr auf.

Laut Kunden tritt jetzt aber auch das Problem mit den Handles nicht mehr auf.

Was jetzt ursächlich für das Nicht-Mehr-Erscheinen des Fehlers zuständig ist, kann ich natürlich nicht sagen: die neue DLL, der geänderte Source - oder gar die standardmäßig regelmäßigen Betriebssystem-update durch den Kunden selbst.