LabView 2012 SP1 und TwinCat 2 Ads.Net

Hallo zusammen,

Ich habe ein Problem mit der Kommunikation zwischen LabView und TwinCat über die ADS.Net Schnittstelle.
Um verschiedene Werte mit einer Frequenz von 10Hz aus den Merkern der SPS abzufragen nutze ich diese Anleitung: Anleitung.

Klappt soweit auch ganz gut, jedoch "müllt" sich der RAM stückweise zu, bis das Programm (nach ca. 4Stunden) folgende Fehlermeldung ausgibt.
   

In einem anderen Beitrag gab es das selbe Problem, welches gelöst werden konnte. Ich habe denselben Ansatz versucht (siehe angehängtes VI) jedoch brachte mir diese Lösung keinen Erfolg.
http://www.labviewforum.de/Thread-Arbeit...dll-Aufruf

Ohne die .Net Kommunikation, also mit selbst generierten Werten läuft das VI stundenlang ohne an Geschwindigkeit oder Speicher einzubüßen, weshalb sich die Ursache auf die beschriebene Kommunikationsschnittstelle zurückführen lässt.

Auch ein Port öffnen und schließen nach jedem Aufruf brachte keinen wirklichen Erfolg.

Leider finde ich auch keine gute Dokumentation zu der ADS.Net Schnittstelle und dessen Funktionen.

Hat jemand eine Idee wo ich ansetzen könnte?
Bei Beckhoff wird mir nur gesagt ich sollte die Frequenz auf 1Hz drosseln, wobei dies meiner Meinung nach das Problem nur zeitlich hinausschieben wird, statt es zu lösen. Die Messungen die realisiert werden sollen können jedoch auch länger als 10 Stunden andauern.

Ich bedanke mich vorab schonmal für jeglichen konstruktiven Beitrag.

Gruß

Edit jg: Externer Link gelöscht.

Anzeige

Kein Wunder, dass der Speicher vollläuft. Dauernd machst du neue Konstruktoren/Referenzen auf, schließt diese aber NIE.

Gruß, Jens

Moin,

erstmal vielen Dank für die Antwort.
Hatte auch schon versucht, die Referenzen stets zu schließen, jedoch bleibt das Problem weiterhin bestehen...

Hab mal die Version angehängt mit der es 4 Stunden lang lief.
Wie sollte ich das VI deiner Meinung nach ändern?

Gruß

Dann zeig mal die Variante mit Refnum Schließen. Würde mich nicht wundern, wenn du was übersehen hast.

Gruß, Jens

Habs mal oben angehängt an den vorherigen Post...über die dispose-Funktion wird die Verbindung laut Beckhoff wieder getrennt und der Speicher sollte sich nicht zumüllen...naja denkste

Gruß

Okay konnte das Problem lösen.

Scheinbar wurden bei der Nutzung der ADS.Net Schnittstelle die erzeugten Objekte nicht schnell genug gelöscht und blieben so peu a peu im Speicher. Habe daraufhin die ADSOCX Schnittstelle mal angetestet, da diese Pointerbasiert arbeitet und siehe da schon klappt es. Einziges Manko war, dass man nicht alle Datentypen nutzen kann (bpsw. nen einfaches Byte oder unsigned ints).

Vielen Dank für die Hilfestellung.

Gruß

Anzeige

(14.08.2014 09:31 )RughNeXX schrieb:  Okay konnte das Problem lösen.

Scheinbar wurden bei der Nutzung der ADS.Net Schnittstelle die erzeugten Objekte nicht schnell genug gelöscht und blieben so peu a peu im Speicher. Habe daraufhin die ADSOCX Schnittstelle mal angetestet, da diese Pointerbasiert arbeitet und siehe da schon klappt es. Einziges Manko war, dass man nicht alle Datentypen nutzen kann (bpsw. nen einfaches Byte oder unsigned ints).

Vielen Dank für die Hilfestellung.

Gruß

Klingt ein bischen wie: Also die Tür zu meinem Haus klemmte immer, deshalb habe ich mir ein neues Haus gekauft!

Jens hat's dir schon gesagt: für jede Konstruktor Node MUSST Du auch eine Close Reference Node verwenden. Ich denke Du weisst was eine Konstruktor Node ist??

Das gilt übrigens für OCX auch, nur so mal als extra Information, ausser dass da die Funktion um ein Objekt zu generieren nicht Konstruktor Node heisst sondern Open Automation Refnum.

Ansonsten möchte ich keine Worte über Dein Server.vi verlieren. Da ist nichts positives zu sagen!

Hallo,

tut mir leid, dass ich einen eher sehr alten Threat noch einmal aufmache, ich wollte aber keinen neuen öffnen.

Für ein aktuelles Projekt bin ich gerade dabei eine Schnittstelle zu einer Beckhoff SPS über TwinCAT zu erstellen. Normalerweise nutzen wir Siemens, daher ist das auch Neuland. In der vom ursprünglichen Threadersteller erwähnten "server.vi" fehlt meines Erachtens jeweils das Schließen der "ADSBinaryReader" und der "AdsStream", sodass diese ja im LabVIEW-Speicher verbleiben. Außerdem tue ich mich schwer, gestapelte Sequenzstrukturen zu lesen. Daher will ich lieber eine state-machine nutzen.
Im Init-Case der state-machine wird im Grunde nur der TcAdsClient über eine Konstruktor- und Methodenknoten zur SPS gestartet. Die weiteren cases beinhalten dann die einzelen Lese- und Schreibbefehle. Als Beispielbild habe ich das Auslesen einer festgelegten Variable (Array aus 56 singles) als Anhang beigefügt. Würde das so funktionieren? Im Exit-state (aufgerufen durch Betätigen von Stop oder einen Fehler, würde dann noch der TcAdsClient geschlossen werden.
Mein Problem ist, dass die Hardware für das Projekt aktuell noch in Bestellung ist und ich vorher so viel wie möglich vorbereiten will (ohne es aber testen zu können). Außerdem kann ich das LabVIEW Programm dann nur als EXE auf den Mess-PC nutzen. Daher die Frage an die Profis, ob das generell so funktionieren würde oder ob da eventuell irgendwo noch Stolpersteine vorhanden sind. Als Orientierung habe ich die Beispiel-VIs von Beckhoff genommen.

Viele Grüße,
Ralf

PS: Der Fehlercluster muss dann natürlich noch aus dem case raus (bzw. vorne rein), um im Fehlerfall das Exit case-aufzurufen. Das ist jetzt noch nicht implementiert, kommt aber auf alle Fälle mit rein.