Speicher wird erst geleert nach schließen des Programms
Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
05.07.2013, 09:43 (Dieser Beitrag wurde zuletzt bearbeitet: 05.07.2013 09:48 von raverel.)
Speicher wird erst geleert nach schließen des Programms
Hallo zusammen.
Ich habe folgendes Problem:
Ich habe eine cifX EtherNet/IP Feldbuskarte der Firma Hilscher. Ich habe mir ein Programm geschrieben, um nun die sich im Netzwerk befindlichen Slaves darstellen. Die IP-Adressen der Teilnehmer schreibe ich nacheinander über ein Schieberegister in ein String Array. Das VI "EtherNet IP`s" schreibt mir die zurückgesendeten Daten aus dem Cluster in das IP Adressen Array. Das VI "Remove Same Array" filtert alle gleichen IP`s raus, da er sonst die letzte gefundene IP-Adresse mehrfach in das Array einträgt. Das Problem was ich jetzt habe ist, wenn ich beispielsweise ein Slave im Netzwerk habe und den Suchlauf starte, funktioniert alles reibungslos. Ziehe ich das Netzwerkkabel ab und starte den Suchlauf erneut, wird mir immernoch signalisiert, dass sich 1 Teilnehmer im Netzwerk befindet. Obwohl physikalisch kein Slave mehr im Netzwerk ist. Anscheinend hat LabView noch irgendwo diesen Wert im Speicher. Schließe ich jetzt komplett mein LabView Projekt, öffne mein Projekt/Programm erneut und starte dann den Suchlauf dann nocheinmal, funktioniert alles so wie es soll. Es wird mir als Slaveanzahl der Wert "0" angezeigt. Lösche ich links vom Schieberegister aus dem Array die String Konstante, füge danach eine neue String Konstante ein und starte dann den Suchlauf erneut, funktioniert ebenfalls alles wunderbar. Kann mir da jemand eine Hilfestellung geben? Bin hier am verzweifeln
Vielen Dank
RE: Speicher wird erst geleert nach schließen des Programms
Nochmal zu allgemeinen Verständnis. Das Sub-VI "EtherNet IP`s" gehört in das "Haupt" VI EtherNet IP Lifelist. Das Sub VI "Remove Same Array" kommt wiederum in das Sub VI "EtherNet IP`s".
RE: Speicher wird erst geleert nach schließen des Programms
(05.07.2013 11:00 )raverel schrieb: Nochmal zu allgemeinen Verständnis. Das Sub-VI "EtherNet IP`s" gehört in das "Haupt" VI EtherNet IP Lifelist. Das Sub VI "Remove Same Array" kommt wiederum in das Sub VI "EtherNet IP`s".
Deine hochgeladenen VIs heißen aber allesamt anders, als du sie beschreibst und LV will auch andere Namen haben.
RE: Speicher wird erst geleert nach schließen des Programms
Hallo raverel,
also in deinen VIs sehe ich nicht so recht, wie die sich da was merken sollten. Hast du mal versucht, einfach mal so längere Zeit zu warten zwischen den Aufrufen.
An der Programmierung kann´s nach meinem Dafürhalten nicht liegen. Wenn du die Konstante erneuerst, muss LV auch das VI neu kompilieren - vielleicht hängt´s auch damit zusammen.
Gruß, Marko
05.07.2013, 11:45 (Dieser Beitrag wurde zuletzt bearbeitet: 05.07.2013 11:59 von GerdW.)
RE: Speicher wird erst geleert nach schließen des Programms
Hallo raverel,
Zitat:Anscheinend hat LabView noch irgendwo diesen Wert im Speicher.
Warum soll LabVIEW schuld sein? Merkt sich die aufgerufene DLL evtl. die gefundenen Slaves? Diese meldet dir doch die Slaves im Cluster...
Zitat:Schließe ich jetzt komplett mein LabView Projekt, öffne mein Projekt/Programm erneut und starte dann den Suchlauf dann nocheinmal, funktioniert alles so wie es soll. Es wird mir als Slaveanzahl der Wert "0" angezeigt. Lösche ich links vom Schieberegister aus dem Array die String Konstante, füge danach eine neue String Konstante ein und starte dann den Suchlauf erneut, funktioniert ebenfalls alles wunderbar.
Im ersten Fall wird die DLL aus dem Speicher entfernt, weil der Aufrufer (LabVIEW bzw. das Projekt mit dem VI) beendet wird. Im zweiten Fall wird LabVIEW die DLL aus dem Speicher schmeißen, weil das VI neu kompiliert wird und dazu alle alten Referenzen etc. aufgeräumt werden. Ich würde der DLL den schwarzen Peter zuschieben...
RE: Speicher wird erst geleert nach schließen des Programms
Viele Dank für die schnellen Antworten.
Ja mit der dll hört sich plausibel an. Fragt sich jetzt nur, wie ich das Problem mit der dll löse.
Muss mir dann wohl nochmal das Datasheet durchlesen.