4-fach USB Seriell - App bzw. Win hängt sich auf

Hallo zusammen,

bevor ich zu meiner Problembeschreibung komme, erstmal einige Eckdaten:

- LabVIEW 8.5 Application
- Win XP
- 4-fach USB Seriell Umsetzer (recht hochwertig im industrietauglichen Metallgehäuse von NS-COM)
- An jedem der vier seriellen Ports hängt ein Sensor (9600 Baud), welcher alle Sekunde ausgelesen wird

Nun zum Problem:

Mein Programm liest vier Sensoren über die vier seriellen Schnittstellen nach folgendem Muster aus:

VISA Konfigurieren/öffnen -> VISA Buffer leeren (in und out Buffer) -> Befehl an den Sensor schicken (VISA Write) -> Antwort vom Sensor empfangen (VISA Read) -> VISA CLOSE -> Daten in txt-Datei speichern

Diesen Muster läuft vier mal parallel in while-Schleifen, jede Schleife hat einen Takt von einer Sekunde. Der Befehl zum Anfordern eines Telegramms ist 5 Byte lang, die Antwort ca. 150 Byte.
Der String, welcher vom Sensor gesendet wird, hat als Endzeichen ein Linefeed. Dies ist unter VISA Konfigurieren auch so eingestellt. VISA READ soll max 500 Byte lesen, nach Timeout abbrechen oder eben nach meinem Linefeed beendet werden. Ganz normale Vorgehensweise.

Ich habe mein Programm nacheinander auf zwei verschiedenen PCs (A B) laufen lassen. Auf beiden PCs lüft es erstmal einwandfrei.
Nach einiger Zeit (Stunden oder Tage) bzw. nach tausenden erfolgreichen Telegrammen folgendes Szenario:

PC A: Die empfangenen Daten werden korrupt. Beim empfangenen Telegramm fehlen die ersten 10 bis 20 Bytes. Das Telegramm wird vom Sensor jedoch korrekt gesendet. Über ein T-Stück habe ich die serielle Leitung über einen anderen PC (Hyperterminal) abgehört. Kurz nachdem die Daten korrupt sind, dies kann bei einem, bei zwei, drei oder vier Sensoren vorkommen, erscheint vielleicht noch ein VISA WRITE ERROR und das wars. Der PC hängt sich auf, nicht einmal der Mauszeiger lässt sich mehr bewegen.

PC B: Hier werden die Daten nicht korrupt. Es wird gemeldet, dass keine Daten mehr empfangen werden können. Eine beliebige Anzahl von Schnittstellen melden einen VISA WRITE ERROR und das Programm hängt sich auf. Der PC hängt sich nicht auf.

Die Verzweiflung ist langsam groß. Folgendes habe ich bereits durchgeführt:

- VISA Empfangsbuffer in der Hardwarekonfig von 4096 auf 256 Byte verkleinert
- VISA Sendebuffer in der Hardwarekonfig von 4096 auf 256 Byte verkleinert
- Empfangs- und Sendebuffer werden im VI bei jedem Zyklus geleert

Eigentlich kann sich mein Programm nicht aufängen. Ich habe allen Fehlerstrippen ein Anzeigeelement spendiert. Meine Leseroutine solle auch OK sein. Da PC A und PC B unterschiedliche Verhaltensweisen zeigen, hege ich den Verdacht, dass es etwas mit Windows zu tun hat, aber was? Der einzigste Unterschied zwischen beiden PCs ist Win Service Pack 2 und 3.

Vielleicht liegt es aber auch daran, dass ich vier while Schleifen parallel laufen lasse. Sollte ich die vier Schnittstellen eher acheinanden in einer Sequenz aufrufen?

Ich könnte noch ewig weiter schreiben, aber vorerst sollte es reichen. Vielleicht kann mir jemand weiter helfen oder mein Problem kommt jemandem bekannt vor.

Grüßle

Matthias

Hallo,
ich würd die Schnitstelle nicht immer öffnen und schliessen.

Bau das mal so auf das du auserhalb deiner While schleife den Port öffnest und nach beenden der schleife ihn wieder schliesst.
Vielleicht kommts daher.

Grüße Achimedes

Hallo!

Das könnte ich sicherlicht tun. Ich kann dann jedoch zur Laufzeit nicht mehr den Port ändern.
Außerdem wollte ich so eine Art Worst Case Szenario schaffen, indem ich die Schnittstellen immer wieder öffne und schließe.

Wenn ich einen Sensor an die COM1 Schnittstelle hänge (also keinen USB Umsetzer benutze), scheint alles zu funktionieren und zwar nicht nur für Stunden, sondern für Tage und Wochen!

Ich bin immernoch ratlos ...

Dann würde ich es einmal mit seriellen Auslesen versuchen. Kann ich mir zwar eigentlich nicht als Ursache vorstellen, aber man weiss ja nie. Schließlich geht alles über eine USB-Leitung zum PC.
Und bei einem 1 Sekunde Takt solltest du locker durchkommen mit 4 Schnittstellen.

Gruß, Jens

P.S.: Wieso solltest du zur Laufzeit den COM-Port ändern? Und bei Aufbau deines Programms als State-Machine kannst du das auch einbauen.
- Init-Case: Port öffnen. Wenn Fehler, wieder Port öffnen, ansonsten...
- Lese-Case: Befehl senden und Antwort analysieren. Wenn kein Fehler, dann wieder Lese-Case, ansonsten...
- Schließen-Case: Port schließen. Wenn Programm beenden, dann Ende, ansonsten zurück zum Init-Case.

EDIT: Wie sieht es eigentlich mit Speicher- und Prozessorlast aus? Bleibt die konstant oder steigt die an?

Du hast zwar Dein VI recht klar mit Worten beschrieben, aber trotzden gilt: Ein Bild sagt mehr als 1000 Worte. Was spricht dagegen, das VI zu posten?
Das Leeren der Buffers nach dem Konfigurieren halte ich für überflüssig.
Bei USB-Serial Ports kann es zu Verzögerungen beim Empfang kommen. Abhilfe kann sein, den TermEndChar (Ctrl A) als Eventchar zu aktivieren. (Hab ich in einer Druckschrift von FTDI gelesen)

Danke schonmal für die Antworten.

Was meinst du mit seriellem Auslesen? Die Ports nacheinander bearbeiten?

Die Prozessorlast und die Speicherauslastung ist konstant und gering.

Eine Statemachine ist schon recht. Wenn mir aber der ganze PC abschmiert, nützt das leider auch nichts mehr.

Ich habe das vi mal beigefügt.

Matthias

Anzeige

' schrieb:Kurz nachdem die Daten korrupt sind, dies kann bei einem, bei zwei, drei oder vier Sensoren vorkommen, erscheint vielleicht noch ein VISA WRITE ERROR und das wars. Der PC hängt sich auf, nicht einmal der Mauszeiger lässt sich mehr bewegen.

Ich tippe auf ein Problem mit dem USB-Adapter. Womöglich verschwindet der COM-Port, weil eben der USB-Adapter, respektive sein Treiber, "kaputt" gegangen ist. Wenn der COM-Port plötzlich verschwunden ist, sollte eben die Meldung "VISA WRITE ERROR" erscheinen. Ich kann mir vorstellen, dass infolge auch der PC stehen bleibt.

Wenn der COM-Port verschwunden ist, so sollte das an PC B feststellbar sein. Kucken, wenn LV einen Fehler bringt, ob im MAX und in Gerätemanager der COM-Port respektive der USB-Adapter noch vorhanden ist.


Dass der Fehler damit zusammenhängt, dass die vier Schleifen durch ein parametrierbares SubVI ersetztbar sind, glaube ich nicht.

Ja, die USB Umsetzer sind manchmal von *sonderbarer* Qualität.

Hatte auch schon ähnliche Erfahrungen.

Abhilfe: einen anderen teureren (?) kaufen.

Oder auf Ethernet-Seriell umsteigen, das macht (zumindest bei uns) weniger Probleme. Zum Beispiel das von Netcom oder Adam (nur die Installation ist ein wenig komplexer, aber wenn es mal installiert ist, dann läuft es gut). Dabei gibt es ein Vorteil - man kann von überall drauf zugreifen

' schrieb:Danke schonmal für die Antworten.

Was meinst du mit seriellem Auslesen? Die Ports nacheinander bearbeiten?

Genau! Hast du doch selber auch schon vorgeschlagen.

Gruß, Jens