Serielle Schnittstelle hängt nach gewisser Zeit auf

Hallo allerseits erstmal und frohes neues Jahr.

Nach langer Zeit bin ich mal wieder hier im Forum *Anmerkung: Mit neuem Arbeitgeber deswegen nur noch LV 2011* und habe ein Problem:

Ich möchte ein Magnetnetzteil mit zwei Kanälen steuern und benutze dafür die serielle Schnittstelle über VISA read / write. Hardwareseitig stecken hinter den zwei com ports zwei getrennte USB auf seriell Adapter. Dazu nutze ich das angehängte VI.
Das ganze läuft auch anfangs einwandfrei und wie gewünscht ohne das es zu Problemen kommt. Nach 30 Minuten aufwärts (bei den bisherigen Tests) hängt sich das ganze jedoch irgendwann auf (laut Highlighmodus läuft die Eventschleife und pulst weiter die Occurence, die Hauptschleife jedoch steht bei einer der VISA Operationen; in zwei Tests wo ich es konkret beobachten konnte an unterschiedlichen Stellen). Das irritiert mich insofern, als der Timeout das eigentlich verhindern sollte.
Ein beenden des VI ist in diesem Zustand weder mit dem Roten Knopf noch durch schließen mit X (dann erscheint "Resetting VI" und scheint nicht zu terminieren) möglich. Selbst ein beenden von Labview über den Taskmanager ist in diesem Zustand nichtmehr möglich.
Ich habe außerdem getestet wie sich ein Build einer EXE verhält - selbes Problem. Hier lässt sich dann die Exe nichtmal per Taskmanager abschießen, eine parallel gestartete zweite Instanz wirft den Fehler -1073807246 (Resource aktuell nicht verfügbar).

Rücksetzen lässt sich das Problem auf dem (Win 7) System nur durch Systemneustart. Das Fehlerverhalten sieht für mich so aus, als ob ich es schaffe die Schnittstelle auf Betriebssystem-Ebene abzuschießen. Mir fällt aber mittlerweile kein Grund mehr ein warum ich das schaffe.

Anmerkung zu den Testbedingungen: Das Program wurde laufen gelassen ohne äußeren Eingriff. Genaugenommen wird also nur die ganze Zeit zum Endgerät immer wieder der gleiche Setzwert für den Strom geschrieben und anschließend vom Gerät der Wert sowie Fehlerfälle vom Gerät ausgelesen.

P.S: Betrieben wurde das Program mit einer Wartezeit von 500ms; das 0ms aktuell nichts sinniges macht weis ich, das werde ich in einer späteren Version noch abfangen. Ein Teil der etwas unaufgeräumten Struktur liegt daran, dass das Program in der Ursprungsfassung nicht von mir stammt und ich Hotfixes auf verschiedene mögliche Quellen des Problems angewendet hatte die aber auch nichts am Verhalten geändert haben.
*Fixversuche: Seriellen Port konfigurieren wurde nach außerhalb der Schleife verlegt, ebenso wie Referenz schließen

P.P.S: Ja ich ziehe aktuell auch in Erwägung das Programm strukturell noch mal neu und besser zu bauen, es musste bei der Ursprungsversion halt schnell gehen ^^ Ich möchte trotzdem verstehen was falsch läuft um mir dabei nicht genau den gleichen Fehler wieder einzubauen.

P.P.P.S: Ich vermute ihr könnte den Fehler nicht reproduzieren da er nur mit angeschlossener Hardware auftauchen dürfte, ansonsten wird halt nur ein timeout geworfen und das wars. Mir wäre es aber wichtig zu wissen ob ich schon im Programmaufbau Probleme habe...

Vielen Dank und viele Grüße
Kiesch

P.P.P.P.S: @BNT ist ne Ansteuerung für ein Bruker BEC-1 das könntest du evtl. auch kennen.

Hallo Kiesch,

- bessere USB-2-Seriell-Konverter verwenden
- statt der USB-Konverter eine PCIe-Steckkarte (mit 2 oder 4 Ports) in den PC einbauen
- evtl. USB-Stromsparmodi ausschalten

Zitat:Ja ich ziehe aktuell auch in Erwägung das Programm strukturell noch mal neu und besser zu bauen, es musste bei der Ursprungsversion halt schnell gehen ^^ Ich möchte trotzdem verstehen was falsch läuft um mir dabei nicht genau den gleichen Fehler wieder einzubauen.

Gute Idee!
- Dann bitte solche Dinge wie "Array zu Cluster", gefolgt von Unbundle durch ein einfaches IndexArray ersetzen. Und mehr subVIs nutzen, um solche "Gerätetreiber"-Geschichten sinnvoll zu verpacken!
- Statt mit der Occurance eine Schleife zu triggern könntest du auch einen QMH (queued message handler) implementieren…

@GerdW

Dachte eher an eine Queue driven State Machine evtl. zur Entkopplung der Endgeräte mit zwei getrennten Schleifen (potentiell in SUBVIs ausgelagert) - eine pro Endgerät. Da die über getrennte Schnittstellen laufen sollte ich mir damit ja auch keine Resourcenkonflikte einhandeln.
Das ganze gepolle der Magente trotz nicht ändernder Eingabewerte gefällt mir nämlich eigentlich nicht (unelegant) auch wenns immerhin recht robust funktinieren sollte.

Zitat:- evtl. USB-Stromsparmodi ausschalten

Ich habe das Gefühl das hilft mir weiter. Zumindest hab ich jetzt wieder nen Lösungsansatz. Eventuell schießt mir der Energiesparmodus die Kommunikation unwiederbringlich ab. Mal austesten. Danke.

@bessere Hardware

Ich bin an ner Uni... So lange die Hardware ausreichend ist um das zu betreiben, werd ich keine neue kriegen da wir kein Geld haben...

Deswegen gehe ich erstmal davon aus dass es ein Softwareproblem ist und erst wenn ich das ausschließen kann gehts an die Hardware. Deswegen schonmal danke für deinen Kommentar, ich probier das mit dem Energiesparmodus mal aus ob sich da was machen lässt.

P.S:

Zitat:- Dann bitte solche Dinge wie "Array zu Cluster", gefolgt von Unbundle durch ein einfaches IndexArray ersetzen. Und mehr subVIs nutzen, um solche "Gerätetreiber"-Geschichten sinnvoll zu verpacken!

Jupp ich weis ^^ der Teil war nicht mein code - auch wenn ich zugeben muss dass ich auch ne Weile gebraucht, um mitzukriegen, dass unbundle aufziehbar ist und nen Default auf den eingängen hat.

(05.01.2018 12:23 )Kiesch schrieb:  Ein beenden des VI ist in diesem Zustand weder mit dem Roten Knopf noch durch schließen mit X (dann erscheint "Resetting VI" und scheint nicht zu terminieren) möglich. Selbst ein beenden von Labview über den Taskmanager ist in diesem Zustand nichtmehr möglich.

Kann ich nachvollziehen ...

Zitat:Das Fehlerverhalten sieht für mich so aus, als ob ich es schaffe die Schnittstelle auf Betriebssystem-Ebene abzuschießen.

Du bist es nicht, der das schaffst. Ich bin der Meinung, das sind mangelhafte USB-Treiber. Ich kann dich in sofern beruhigen: Unter Win10 tritt das Problem wesentlich seltener (= nur noch nachmal) auf.

Ich rate zu hochwertigen RS232/RS422-USB-Konvertern.


Ach ja, noch eins: Das soll ich mal geschrieben haben? Auf jeden Fall stimmt's.

1. Ich würde versuchweise den Sende- und Empfangspuffer leeren, und nicht nur den Empfangspuffer.
2. Hast Du die neueste Version des VCP-Treibers vom Chip-Hersteller installiert? (VCP = Virtueller COM-Port)
3. Der VCP hat in den Eigenschaften (so wie ich mich erinnere) unübersichtlich viele Einstellmöglichkeiten. Geduldiges Herumprobieren an den Einstellungen könnte das Problem lösen.
4. Wenn das nicht hilft, rate ich zu einem Konverter mit Chip von FTDI. Den kleinen zweistelligen Betrag könntest Du von Deinem Taschengeld bezahlen, wenn dein Arbeitgeber nichts rausrückt. Wenn die Firma größer ist, müsste sich auch ein anderer Konverter zu Versuchszwecken irgendwa ausleihen lassen.

Bruker BEC-1: Ich hatte das Vergnügen noch nicht.
Gruß Holger

Hallo Kiesch,
Du hast eine Baudrate von 9600 eingestellt.
Du gibst zwar eine Fehlermeldung aus, unterbrichst aber im Fehlerfall nicht (bei VISA leeren keine Eingangserrorrleitung). D.h. es wird die Schnittstelle ohne Unterbrechung vollgeschrieben.
Das könnte der Grund des Absturzes sein.

Gruß
Freddy

Hallo Kiesch,
ich hatte mal ähnliche Probleme.
Lösung war bei mir, alle "VISA write" und "VISA read" Functions auf "synchronous" umzustellen.

Des weiteren kann ich ebenfalls den Einsatz von PCIe Steckkarten empfehlen.

Gruß
Ralf

@IchSelbst

Hattest du in deiner Signatur vor ner ganzen Weile

(05.01.2018 14:40 )Lucki schrieb:  1. Ich würde versuchweise den Sende- und Empfangspuffer leeren, und nicht nur den Empfangspuffer.
2. Hast Du die neueste Version des VCP-Treibers vom Chip-Hersteller installiert? (VCP = Virtueller COM-Port)
3. Der VCP hat in den Eigenschaften (so wie ich mich erinnere) unübersichtlich viele Einstellmöglichkeiten. Geduldiges Herumprobieren an den Einstellungen könnte das Problem lösen.
4. Wenn das nicht hilft, rate ich zu einem Konverter mit Chip von FTDI. Den kleinen zweistelligen Betrag könntest Du von Deinem Taschengeld bezahlen, wenn dein Arbeitgeber nichts rausrückt. Wenn die Firma größer ist, müsste sich auch ein anderer Konverter zu Versuchszwecken irgendwa ausleihen lassen.

1. Muss ich mal austesten.
2. Soweit ich das beurteilen kann ja (frisch runtergeladen vor den Tests). Das ist doch letztlich nur der normale Gerätetreiber?
3. Öm XD Ich hoffe da muss ich nicht noch reinschauen werd ich mal schauen.
4. Wie oben gesagt: Wenns nicht an der Software liegt, dann werd ich wohl doch nochmal zu Chef rennen müssen. Würd ich aber gerne vermeiden. Denke mal dann wirds auch wohl ne interne PCI Karte statt USB auf seriell Konverter (da ja auch schon einige zu ner internen Karte geraten haben).

@Freddy

Guter Hinweis. Sollte vielleicht im Fehlerfall einfach mit Fehler blockieren lassen, dass ich eventuell vor dem Absturz auftretende Fehler auch sehe. Muss ehrlich sagen, dass ich da einfach auch noch kein Abfangen für nen Timeout reinbauen wollte weil ich von ausgegangen war, dass der eigentlich nicht passieren sollte. Kommt noch dazu.

@rasta

Da wär ich nicht drauf gekommen. Danke für den Hinweis, gleich mal ausprobieren.

@alle

Danke für die Hinweise. Bin grad Schritt für Schritt dabei auszuprobieren was davon wirkt. Läuft leider auf nem Laborrechner und das der Absturz erst nach ner ganzen Weile kommt macht das Testen auch nicht grad einfacher -.-

P.S: Achso, Energiesparmodus war wohl nicht der Schuldige.

*edit sagt*

Es scheint ich hatte das gleiche Problem wie Ralf - mit der Änderung auf Synchronous IO Mode läuft das jetzt bereits seit über 24h stabil - ich denke also das Problem ist behoben. Vielen Dank für die Hilfe und die weiteren Lösungsvorschläge. Werde mich dann jetzt nebenher darum kümmern das Program noch strukturell zu verbessern wo nötig (SubVIs etc. pp.)