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!
17.07.2013, 12:50 (Dieser Beitrag wurde zuletzt bearbeitet: 17.07.2013 12:55 von MODDER.)
ich arbeite seit Kurzem mit LV 6.1 an der Verbesserung einer Kontroll- und Messsoftware für ein Messgerät. Im Folgenden möchte ich ein Problem bei der Datenabfrage mit VISA an mehreren RS232 - Anschlüssen beschreiben. Der Mess-PC wurde mit Windows XP und LV 6.1 frisch aufgesetzt. Eine eingebaute PCI-Karte mit 4 RS232-Anschlüssen befindet sich auf der Hauptplatine. In der Haupt-VI "data acquisition" befindet sich eine Zeitschleife, die aller x Sekunden 3 Abfragen über RS232-Anschlüsse ausführt. Diese ruft immer 3 Unter VIs auf:
Thermo1.vi
Thermo2.vi
DewPoint.vi
Thermo1/2.vi fragen die aktuelle Wassertemperatur am Thermostaten 1/2 ab. DewPoint.vi fragt die Informationen von einem Taupunktsspiegel ab.
Normalerweise funktioniert das Programm ohne Probleme, doch von Zeit zu Zeit erscheint folgender Fehler:
Fehler: -1073807339 in Thermo0/1.vi->SERIAL data acquisition.vi aufgetreten.
Mögliche Ursache:
VISA: (Hex: 0xBFFF0015) Timeout aufgetreten bevor Operation beendet wurde.
Mögliche andere Lösungsthreads haben ergeben, dass ich den Timeout Paramter höher setzen sollte, 5 bzw 10 Sekunden haben das Problem nicht gelöst.
Ein Kollege von der Arbeit hat gesagt, dass das Problem darin liegen könnte, dass die gleichzeitig stattfindenden Abfragen einander behindern könnten ?!
Ich in der Zeitschleife also die Abfragen nacheinander statt nebeneinander ablaufen lassen sollte.
Was würdet ihr empfehlen?
Gruß, MODDER
17.07.2013, 12:57 (Dieser Beitrag wurde zuletzt bearbeitet: 17.07.2013 13:08 von GerdW.)
Zitat:Ein Kollege von der Arbeit hat gesagt, dass das Problem darin liegen könnte, dass die gleichzeitig stattfindenden Abfragen einander behindern könnten ?! Ich in der Zeitschleife also die Abfragen nacheinander statt nebeneinander ablaufen lassen sollte
Das erscheint mir nur sinnvoll, wenn alle Geräte an einem RS232-Anschluss hängen. Und das ist eher unüblich...
Andererseits schadet es auch nicht, die Geräte nacheinander abzufragen (solange sie nicht selbst x Sekunden für die Antwort brauchen)...
Zitat:Der Mess-PC wurde mit Windows XP und LV 6.1 frisch aufgesetzt.
Eine 12 Jahre alte Software auf einem 12 Jahre alten OS, welches ab nächstes Jahr nicht mehr supported wird. Das nenn ich "zukunftssicher"!
(Sag nicht, es käme auf die 4 RS232-Ports an. Ein entsprechendes USB-Teil kostet vielleicht 20Eur...)
Thema gesplittet, da neue Frage!
Zitat:Timeout Paramter höher setzen sollte, 5 bzw 10 Sekunden haben das Problem nicht gelöst.
Deine Schleife läuft mit >=1Hz, da sind TimeOuts mit >1s eher hinderlich...
Zitat:Ein Kollege von der Arbeit hat gesagt, dass das Problem darin liegen könnte, dass die gleichzeitig stattfindenden Abfragen einander behindern könnten ?! Ich in der Zeitschleife also die Abfragen nacheinander statt nebeneinander ablaufen lassen sollte
Das erscheint mir nur sinnvoll, wenn alle Geräte an einem RS232-Anschluss hängen. Und das ist eher unüblich...
Andererseits schadet es auch nicht, die Geräte nacheinander abzufragen (solange sie nicht selbst x Sekunden für die Antwort brauchen)...
Nein es sind wirklich 4 RS232 Ports und 3 sind besetzt!
Klingt logisch, bei 5 sec Abfragezeit und alle 1 sec abfragen! Da werde ich die Datenerfassungsrate mal auf 10 sec und das Timeout auf 5 sec setzen.
(17.07.2013 12:57 )GerdW schrieb:
Zitat:Der Mess-PC wurde mit Windows XP und LV 6.1 frisch aufgesetzt.
Eine 12 Jahre alte Software auf einem 12 Jahre alten OS, welches ab nächstes Jahr nicht mehr supported wird. Das nenn ich "zukunftssicher"!
(Sag nicht, es käme auf die 4 RS232-Ports an. Ein entsprechendes USB-Teil kostet vielleicht 20Eur...)
Tja, das Messsystem ist 10 Jahre alt und es soll in 2 Monaten laufen - demnach also keine Zeit für ne Konvertierung auf eine neue LabView Version.
2 oder 3 Stunden läuft alles perfekt ab und dann kommt plötzlich ne Fehlermeldung. Neue RS232 Kabel habe ich auch eingesetzt.
Du meinst also, ich solle mal ne USB to RS232 Box kaufen und mal schauen ob der Fehler noch auftritt ?!
17.07.2013, 13:10 (Dieser Beitrag wurde zuletzt bearbeitet: 17.07.2013 13:13 von GerdW.)
vielleicht würde es ja helfen, die VISA-Verbindungen nicht dauernd neu zu erstellen und gleich wieder zu beenden. Diese Vorgehensweise legt jedenfalls dein Bild oben nahe...
Stattdessen: VISA-Referenzen beim Start erstellen und erst nach der Schleife wieder beenden. Nur wenn Fehler zwischendrin auftauchen, durch Schließen/Neuöffnen den Fehler zu beheben versuchen!
Zitat:Du meinst also, ich solle mal ne USB to RS232 Box kaufen und mal schauen ob der Fehler noch auftritt ?!
Ich meine, dass es sinnvoll sein kann (nicht "muss"), Uralt-Hardware durch etwas Neues zu ersetzen. Mit diesem Rechner und dieser Software würde ich aber auch keine USB-Box betreiben wollen! Vor einem Neukauf kann man aber auch Probleme in der Software beheben, wie oben angedeutet...
vielleicht würde es ja helfen, die VISA-Verbindungen nicht dauernd neu zu erstellen und gleich wieder zu beenden. Diese Vorgehensweise legt jedenfalls dein Bild oben nahe...
Stattdessen: VISA-Referenzen beim Start erstellen und erst nach der Schleife wieder beenden. Nur wenn Fehler zwischendrin auftauchen, durch Schließen/Neuöffnen den Fehler zu beheben versuchen!
Zitat:Du meinst also, ich solle mal ne USB to RS232 Box kaufen und mal schauen ob der Fehler noch auftritt ?!
Ich meine, dass es sinnvoll sein kann (nicht "muss"), Uralt-Hardware durch etwas Neues zu ersetzen. Mit diesem Rechner und dieser Software würde ich aber auch keine USB-Box betreiben wollen! Vor einem Neukauf kann man aber auch Probleme in der Software beheben, wie oben angedeutet...
Du hast vollkommen Recht - die Verbindung wird ständig neu aufgebaut und beendet.
Thermo0.vi
Thermo1.vi
Der Mess-PC wurde auch hardwaremäßig auf den neuesten Stand gebracht!
Gruss, MODDER
17.07.2013, 13:40 (Dieser Beitrag wurde zuletzt bearbeitet: 17.07.2013 13:41 von GerdW.)
wenn Thermo0 und Thermo1 den gleichen Frame1 in ihrer Sequenzstruktur haben, dann habt ihr dort eine prima RaceCondition programmiert. Da solltet ihr die subVIs doch besser nacheinander aufrufen!
Wozu überhaupt die Sequenzstruktur? Das geht doch auch ohne gleich gut/schlecht...
Ich hoffe, der User muss nicht die ganze Zeit auf das FP der subVIs schauen. Die Farbe hält man ja nicht lange aus
jedes VI hat seine eigene VISA - Objekt. Das heißt aller x Sekunden werden 3 VISA Objekte erstellt und geschlossen. Ich verstehe den Sinn der Sequenzstrukturen nicht - Es wird doch erst Frame0 und dann Frame1 durchlaufen - Das reicht doch wenn man das ohne diese Struktur darstellt, sprich auf einem Bildschirm! Was bringt eigentlich, dass 'number of runs' in der Zeitschleife hier
Das löst aber nicht dein Problem mit TimeOut und möglicher RaceCondition...
- Wie oben beschrieben solltest du nicht ständig die Verbindung neu aufbauen.
- Ich würde die Schleifen aus den subVIs entfernen. Du hast doch schon eine Hauptschleife! Außerdem musst du momentan jedes subVI einzeln beenden, auch nicht der Weisheit letzter Schluss...
ich habe mein Messgerät nun in Betrieb genommen! Doch die Fehler treten weiter auf. Gibt es in Labview 6.1 irgendwie ne Möglichkeit die Fehlerausgabe zu unterbinden, damit nicht jedes Mal mein ganzes Messbetriebsprogramm mit stoppt. Reicht es den error_out zu entfernen? Bei der SERIAL data acqusistion handelt es sich um Schleife die immer wieder die Thermostaten und den Dew Pointer nacheinander anspricht.
Zitat:Gibt es in Labview 6.1 irgendwie ne Möglichkeit die Fehlerausgabe zu unterbinden, damit nicht jedes Mal mein ganzes Messbetriebsprogramm mit stoppt. Reicht es den error_out zu entfernen?
Nein, das reicht nicht, das macht es nur schlimmer Außerdem hast du doch selbst den ErrorHandler reinprogrammiert und lässt dir die Fehlerdialoge anzeigen: Warum machst du das, wenn es dich stört?
Fehler sollte man behandeln: d.h. IF ERROR THEN DO SOMETHING!
Als "unsaubere" Lösung könnte man den Fehler natürlich auch löschen - da gibt es eine fertige Funktion für...
THINK DATAFLOW!
- Dein Stopp-Button ist nutzlos (in der jetzigen Form)...
- Dein "Serial"-Globale Variable sollte als Cluster-Input/Output durch die 3 subVIs durchgeschliffen werden. Schon brauchst du keine Sequenz mehr (als Nebeneffekt des DATAFLOW)!
- Funktionen sollten auch einen ErrorIn haben - auch das würde die Sequenz unnötig machen...
- Man muss nicht in jeder Iteration die seriellen Schnittstellen neu initialisieren...
- Bunte FP führen schnell zu Augenkrebs
- Die Auswertung der Thermostat-Daten geht auch einfacher mit (genau einem) ScanFromString ("%.;%f" mit Offset 2)...