21.07.2014, 14:07
Hallo Freunde des LabView,
ich versuche es mal in Kurz.
Ich habe hier Geräte welche ich über RS232 Abfrage, die empfangenen Daten werden aufbereitet und in ein SQL-Befehl an eine passende Datenbank gesendet.
Mein Datenerfassungstool kommuniziert sekündlich mit dem externen Gerät, jeder eingelesene Datensatz soll in die Datenbank.
Hierbei kann es sein, dass ich unterschiedliche Spaltenbezeichner von einer auf die andere Abfrage habe, (deshalb das Sub-VI Spaltenprüfer).
So in meiner einfachen LabView/SQL-Welt dachte ich mir:
„Connection öffen“ -> „Befehl absetzten“ -> „Recordset vernichten“ -> „Connection schließen“
Das heißt es sind zwei SQL-Connections pro Sekunde welche geöffnet werden und geschlossen werden sollten.
Da ist das Problem, der Server verzeichnet eine geschlossene Verbindung, der TCP-Port auf der Clientseite wird nicht geschlossen, bzw. steht auf „wartend“ und wird dem Prozess „System Idle Process 0“ mit der PID 0 übergeben und nicht geschlossen. LV hat eine 4 Stellige PID d.h. LV hat keine Kontrolle mehr über diesen Port.
Für mich sieht es aus als ob er den Port Clinet seitig nicht richtig beendet.
Das Problem nun nach ca 2 Minuten sind 240 Ports voll, das VI wartet bei jeden neuen Verbindung darauf das einer dieser Ports durch einen Timeout freigegeben wird.
Dadurch wird das VI immer langsamer und benötigt nach ca. 2 Tagen laufzeit anstatt 10 Sekunden zum abarbeiten aller States nun 10 Sekunden...
//Eine Stunde später
So und nun wird es richtig skurril, ich bin hier gerade am basteln, um euch ein VI zum überprüfen bereit zu stellen. Und mir unterläuft der Fehler, dass ich eine dritte Connection öffne ohne sie zu nutzen oder zu schließen, und siehe da es bliebt bei ZWEI Verbindungen, die eine die offene ungenutzte Verbindung und die andere Verbindung sind effektiv die "beiden connections" welche permanent geöffnet werden und geschlossen… Mit dem schalter "funzt/funzt nicht" könnt ihr umschalten (vor dem Start bitte betätigen) um beide beschriebenen Versionen zu haben.
Hat jemand eine plausible Erklärung für dieses Verhalten?
Und/Oder ein besseren Workaround als diesen?
Viele Grüße
Alea
ich versuche es mal in Kurz.
Ich habe hier Geräte welche ich über RS232 Abfrage, die empfangenen Daten werden aufbereitet und in ein SQL-Befehl an eine passende Datenbank gesendet.
Mein Datenerfassungstool kommuniziert sekündlich mit dem externen Gerät, jeder eingelesene Datensatz soll in die Datenbank.
Hierbei kann es sein, dass ich unterschiedliche Spaltenbezeichner von einer auf die andere Abfrage habe, (deshalb das Sub-VI Spaltenprüfer).
So in meiner einfachen LabView/SQL-Welt dachte ich mir:
„Connection öffen“ -> „Befehl absetzten“ -> „Recordset vernichten“ -> „Connection schließen“
Das heißt es sind zwei SQL-Connections pro Sekunde welche geöffnet werden und geschlossen werden sollten.
Da ist das Problem, der Server verzeichnet eine geschlossene Verbindung, der TCP-Port auf der Clientseite wird nicht geschlossen, bzw. steht auf „wartend“ und wird dem Prozess „System Idle Process 0“ mit der PID 0 übergeben und nicht geschlossen. LV hat eine 4 Stellige PID d.h. LV hat keine Kontrolle mehr über diesen Port.
Für mich sieht es aus als ob er den Port Clinet seitig nicht richtig beendet.
Das Problem nun nach ca 2 Minuten sind 240 Ports voll, das VI wartet bei jeden neuen Verbindung darauf das einer dieser Ports durch einen Timeout freigegeben wird.
Dadurch wird das VI immer langsamer und benötigt nach ca. 2 Tagen laufzeit anstatt 10 Sekunden zum abarbeiten aller States nun 10 Sekunden...
//Eine Stunde später
So und nun wird es richtig skurril, ich bin hier gerade am basteln, um euch ein VI zum überprüfen bereit zu stellen. Und mir unterläuft der Fehler, dass ich eine dritte Connection öffne ohne sie zu nutzen oder zu schließen, und siehe da es bliebt bei ZWEI Verbindungen, die eine die offene ungenutzte Verbindung und die andere Verbindung sind effektiv die "beiden connections" welche permanent geöffnet werden und geschlossen… Mit dem schalter "funzt/funzt nicht" könnt ihr umschalten (vor dem Start bitte betätigen) um beide beschriebenen Versionen zu haben.
Hat jemand eine plausible Erklärung für dieses Verhalten?
Und/Oder ein besseren Workaround als diesen?
Viele Grüße
Alea
*)