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!
02.02.2021, 15:59 (Dieser Beitrag wurde zuletzt bearbeitet: 02.02.2021 16:01 von Stefan198.)
Hallo,
Ich habe hier zwei Geräte, die nicht richtig funktionieren.
Das erste Gerät ist ein agilent 34970A-Mess-MUX, der über einen agilent 82357A-GPIB-zu-USB-Adapter mit einem PC verbunden ist. Ansteuerung ist mit Hilfe von SCPI-Kommandos umgesetzt, welche über VISA verschickt werden. Das Problem hierbei ist, dass Labview manchmal, wenn es einen Messwert von diesem Gerät lesen möchte, einen zufälligen Fehler auf diesem auslöst. Der MUX kann erst wieder verwendet werden, nachdem der 82357A am PC ausgesteckt und wieder eingesteckt wurde. Gerätetreiber scheinen ok zu sein, denn über Connection-Expert von LabView bzw. NI-MAX-Testpanel tritt kein Fehler auf, nur in LV selbst.
Das zweite Gerät ist ein weiss wt3-340/40. Das Problem dabei ist, dass manchmal ein Befehl nicht erkannt wird, der über eine VISA-LAN-Verbindung gesendet wird. Dies geschieht in einem zufälligen Muster mit nahezu jedem Befehl, der gesendet wird, und derselbe Befehl funktioniert 5 Minuten später, ohne dass Änderungen vorgenommen wurden, ohne Probleme.
Deshalb möchte ich fragen, ob hier jemand Erfahrung mit diesen Geräten hat und mir hier weiterhelfen kann.
bezüglich 34970A,82357A:
es könnte durchaus ein USB Steckerproblem sein. Also einfach mal einen anderen USB-Port verwenden oder mal einen USB-Hub (einen mit einer eigenen Stromversorgung) dazwischen schalten.
Welche Fehlermeldungen bekommst du denn genau? So zufällig wird das kaum sein...
bezüglich wt3-340/40:
Dazu müsste etwas mehr über das Kommunikationsprotokoll bekannt sein und natürlich dem was du genau machst.
Die letzten Fehlermeldungen beim MUX, an die ich mich erinnere, wahren 410 "query interrupted" , 261 "scan can not be executed" und 550 (bei dem weiss ich den text nicht mehr).
Das mit dem USB HUB kann natürlich sein, dass da die Stromversorgung nicht hundert prozentig funktioniert - sollte ich mal testen, wenn ich auf die schnelle einen aktiven HUB auftreiben kann.
Was den Klimaschrank angeht, da häng ich mal die vi's an, welche zur Ansteuerung benutzt werden. Was ich rausgefunden hab ist, dass da ein sogenanntes simserv-Protokoll verwendet wird, was wohl schon älter zu sein scheint. Ich sollte vielleicht noch erwähnen, dass Programm, in welchem die verwendet werden nicht von mir erstellt wurde, sondern von einem Kollegen. Angeblich hätte es wohl auch schon problemlos funktioniert, was es momentan aber eindeutig nicht tut. Eine Möglichkeit, die mir noch einfällt, ist, dass an der Kammer mal ein Firmware-Update durchgeführt worden sein könnte und dass die alten Befehle aus den VI's nicht mehr unterstützt werden, aber warum funktionieren die dann manchmal und manchmal nicht? Die müssten dann ja eher ganz weggefallen sein.
Gruß,
Stefan
03.02.2021, 10:01 (Dieser Beitrag wurde zuletzt bearbeitet: 03.02.2021 10:01 von Martin.Henz.)
die Fehlermeldungen beim MUX sehen aber doch eher nach Rückmeldungen von der MUX aus oder von Fehlermeldungen die der Gerätetreiber selbst generiert. Jedenfalls ist es nichts, was von VISA oder LabVIEW Funktionen kommt.
<ironie on>
Zitat:Angeblich hätte es wohl auch schon problemlos funktioniert,
Gewöhne dich schon mal daran - es hat bisher immer 100% zuverlässig funktioniert.
Das ist eher ein untrügliches Zeichen dafür, dass etwas nicht stimmt.
<ironie off>
Zum Treiber selbst könnte ich jetzt gerade den nächsten Abschnitt mit "Ironie" anfangen. Das lasse ich jetzt mal besser.
So vom Prinzip her sollte es weitgehend schon funktionieren. Das tut es ja auch manchmal. Vielleicht ist es ja einer von der besonders langsamen Sorte und du hast jetzt einfach einen deutlich schnelleren PC und müllst den Klimaschrank mit Befehlen zu ohne es zu ahnen. Der Treiber wartet zwar immer schön auf die Antwort vom Klimaschrank und theoretisch sollte das genügen, doch das ist eben auch nur Theorie. Es wäre nicht der erste und auch nicht der einzige Klimaschrank der das trotzdem nicht mag.
Ansonsten bleibt dir wahrscheinlich nur die Möglichkeit, dass du dich mit dem Protokoll und den Rückmeldungen des Klimaschranks genauer befasst und das suchst, woran das liegt.
Hallo Martin,
-----
"die Fehlermeldungen beim MUX sehen aber doch eher nach Rückmeldungen von der MUX aus oder von Fehlermeldungen die der Gerätetreiber selbst generiert. Jedenfalls ist es nichts, was von VISA oder LabVIEW Funktionen kommt."
ja, das stimmt, die beschriebenen Fehlermeldungen stammen vom MUX selbst. LabView giebt dann entweder nur den üblichen "Timeout vor Vervollständigung abgelaufen"-Fehler aus oder gar keinen.
-----
ich habe das mit dem aktiven USB HUB umgesetzt
ich mache grade einen Testlauf(fast fertig) und soweit ist nur einmal die Sache mit dem MUX aufgetreten (ich installier wohl sicherheitshalber auch den treiber noch mal neu)- scheint also so zumindest besser zu funktionieren. Der Klimaschrank hat diesmal nur bei der Initialisierung Probleme gemacht, seit dem neustart nach Problemauftritt hat er aber keine Probleme mehr gemacht. Ich mach nachher lieber noch nen zweiten Testlauf, nicht dass das nur ein Zufall ist.
-okay, mist, grade als ich das hier geschrieben habe ist das mit dem Klimaschrank doch wieder passiert. - ich hänge einfach mal die fehlermeldungen an (chronologisch nummeriert).
es scheinen jeweils zwei meldungen zusammen zu gehören, eine, die in einem subVI erzeugt wird und wohl aussagen soll, dass die Kammer nicht antwortet und eine, von LV selbst, die darauf hinweist, dass für die TCP Verbindung ein timeout abgelaufen ist. Vielleicht sollte ich den Grenzwert für den timeout ausfindig machen und erhöhen vielleicht reicht das.
danke für die hilfe
03.02.2021, 12:39 (Dieser Beitrag wurde zuletzt bearbeitet: 03.02.2021 12:40 von GerdW.)
Zitat:es scheinen jeweils zwei meldungen zusammen zu gehören, eine, die in einem subVI erzeugt wird und wohl aussagen soll, dass die Kammer nicht antwortet und eine, von LV selbst, die darauf hinweist, dass für die TCP Verbindung ein timeout abgelaufen ist. Vielleicht sollte ich den Grenzwert für den timeout ausfindig machen und erhöhen vielleicht reicht das.
<ironie>Wenn das Gerät nicht antwortet, hilft es ganz sicherlich, einfach länger auf eine Antwort zu warten…</ironie>
Vielleicht könnte es ja helfen, wenn man mal überprüft, ob der zum Gerät gesendete Befehl überhaupt gültig ist und vom Gerät verarbeitet werden kann!
Wenn das Gerät einen Befehl nicht (er)kennt, muss es ja auch nicht zwingend eine Antwort schicken…
Der Selbe Befehl, an der Selben Stelle im Programm hat gestern noch keine Probleme gemacht, dafür aber der selbe Befehl an einer anderen Stelle deutlich früher im Programm. An der Stelle wo gestern Probleme auftauchten ist heute kein Fehler aufgetreten. Das ist das was hier nicht so ganz zusammen passt. Die Fehler folgen einfach keinem erkennbarem Muster und genau das ist ja der Flachwitz an der Sache.
------------
"Vielleicht könnte es ja helfen, wenn man mal überprüft, ob der zum Gerät gesendete Befehl überhaupt gültig ist und vom Gerät verarbeitet werden kann!
Wenn das Gerät einen Befehl nicht (er)kennt, muss es ja auch nicht zwingend eine Antwort schicken…"
Die Befehlsverarbeitung ist hier einfach nachzuprüfen. Es sollte eine Soll-Temperatur eingestellt werden, was auch umgesetzt wurde. allerdings hat der Fehler gestern zu einem Sprung im Programm geführt, heute allerdings nicht.
Auch wenn der Befehl korrekt an diesem Gerät ausgeführt wird kann ich mir so ja wohl trotzdem nicht sicher sein, ob das am ende nicht den Rest der Messungen nicht negativ beeinflusst.
---------
zu den Fehlermeldungen:
Fehler 56: Du kannst von Anfang an gar keine Verbindung zu der Klimekammer herstellen. Da funktioniert schon das "TCP Open Connection" nicht.
Das ist ein bisschen arg doof gemacht in dem Treiber. Da ist ganz unten ein Error Handler vergraben und wenn die Verbindung nicht hergestellt werden kann dann poppt da bei jedem Befehl der Fehler 56 auf und parallel (real meist anscheinend erst nach dem Error Handler) wird der gesendete Befehl angezeigt. Das sieht dann im ersten Ansatz so aus, als würden die einzelnen Befehle nicht funktionieren, dabei geht da schon ganz am Anfang etwas schief.
Zitat:-okay, mist, grade als ich das hier geschrieben habe ist das mit dem Klimaschrank doch wieder passiert. - ich hänge einfach mal die fehlermeldungen an (chronologisch nummeriert).
Ich kann nur vermuten, dass du auch noch einen Klassiker in dein Programm eingebaut hast und du immer wieder unnötigerweise die Verbindung zur Klimakammer herstellst und wieder trennst (oder schlimmer noch: die Verbindung gar nicht trennst). Das kann die Klimakammer schon etwas verwirren ...
Anders formuliert: solange du nur den Fehler 56 bekommst brauchen wir uns gar nicht um die einzelnen Befehle zu kümmern und auch nicht nicht um den Treiber, sondern ausschließlich eher um deine VIs.
@GerdW: mal ganz abgesehen davon, dass es momentan gar nicht mehr um einzelne Befehle geht...
Zum Timeout wäre ich nicht so ironisch. Grundsätzlich zwar nicht falsch, denn die Klimakammer sollte innerhalb von einigen Millisekunden antworten. Ich hatte auch schon mal eine Klimakammer, die hat nach dem setzen eines Temperatursollwertes schon mal sekundenlang vor sich hin gerappelt und dabei nicht mehr auf Befehle reagiert. Im Treiber selbst sind die Timeouts auf 1 Sekunde eingestellt.
(03.02.2021 14:14 )Martin.Henz schrieb: Ich kann nur vermuten, dass du auch noch einen Klassiker in dein Programm eingebaut hast und du immer wieder unnötigerweise die Verbindung zur Klimakammer herstellst und wieder trennst (oder schlimmer noch: die Verbindung gar nicht trennst). Das kann die Klimakammer schon etwas verwirren ...
Ah, stimmt, hier gibt es für die Übermittlung jedes einzelnen Befehls ein subvi, in dem erst eine Verbindung hergestellt wird, dann wird der Befehl übermittlelt und dann die verbindung beendet. Stellenweise werden solche subvi's mehrfach direkt hintereinander aufgerufen. Da hab ich nicht drauf geachtet, da ich Verbindungen normalerweise ganz zu Beginn öffne und ganz am ende schließe (die meisten Programme die ich in LV erstelle sind klein genug dafür).
Das hätte ich eigentlich sehen müssen, weil ich genau den Fehler am Anfang auch immer gemacht habe.
Das rauszubügeln wird ne weile dauern.
sicherheitshalber werde ich aber auch die timeouts leicht erhöhen.
vielen, vielen dank!
03.02.2021, 15:08 (Dieser Beitrag wurde zuletzt bearbeitet: 03.02.2021 15:31 von jg.)
Die letzten Fehlermeldungen beim MUX, an die ich mich erinnere, wahren 410 "query interrupted" , 261 "scan can not be executed" und 550 (bei dem weiss ich den text nicht mehr).
Das mit dem USB HUB kann natürlich sein, dass da die Stromversorgung nicht hundert prozentig funktioniert - sollte ich mal testen, wenn ich auf die schnelle einen aktiven HUB auftreiben kann.
Was den Klimaschrank angeht, da häng ich mal die vi's an, welche zur Ansteuerung benutzt werden. Was ich rausgefunden hab ist, dass da ein sogenanntes simserv-Protokoll verwendet wird, was wohl schon älter zu sein scheint. Ich sollte vielleicht noch erwähnen, dass Programm, in welchem die verwendet werden nicht von mir erstellt wurde, sondern von einem Kollegen. Angeblich hätte es wohl auch schon problemlos funktioniert, was es momentan aber eindeutig nicht tut. Eine Möglichkeit, die mir noch einfällt, ist, dass an der Kammer mal ein Firmware-Update durchgeführt worden sein könnte und dass die alten Befehle aus den VI's nicht mehr unterstützt werden, aber warum funktionieren die dann manchmal und manchmal nicht? Die müssten dann ja eher ganz weggefallen sein.
Gruß,
Stefan
Oha, dieser <ironie on>geile<ironie off> Weiss Klimaklammer Treiber, für den man sogar bezahlen muss, wenn ich mich richtig erinnere. Den hat mir aber, wie ich den verwendet habe, der Kunde zur Verfügung gestellt, also vielleicht irre ich mich da auch.
Den habe ich heftig umgeschrieben, der ging ja so gar nicht...
Eine globale Variable muss gesetzt werden, um zu entscheiden, wie ich empfangene "Real-Zahlen-Strings" auf meinen System umwandle. Grausam.
Eine globale Variable für die UnitID der Klimakammer, sprich der Treiber ist so eigentlich nur mit einer Klimakammer einsetzbar.
Der Zusammenbau eines Kommandos an die Klimakammer ("get_simserv.vi") ist bei mir eingedampft auf das hier:
Im großen und ganzen läuft das in meinem Projekt aber stabil. Die Dialoge im "comm_simserv.vi" wurden von mir allerdings deaktiviert, die Fehlerbehandlung läuft bei mir automatisch.
Aufbau als parallel laufender Kommunikationsservice, der per Queue gesteuert wird.
Startet selbstständig die Kommunikation, im Leerlauf werden verschiedene Ist-Werte der KK abgefragt, und per Queue können neue Sollwerte oder Kommados geschickt werden. Sollte die TCP/IP-Kommunikation einen Fehler werfen, dann versucht der Service selbstständig die Verbindung wieder aufzubauen.
Ich habe keine Beschwerden des Kunden.
Zusammenfassung: Prinzipiell funzt dieser Treiber ohne größere Zicken - trotz seiner suboptimalen Programmierung. Dauerndes Öffnen und Schließen der TCP/IP-Verbindung sollte man aber, wie bei jedweder Kommunikation, tunlichst unterlassen.
Gruß, Jens
P.S.: Was läuft an deiner Gegenstelle? Simpati oder Simpac? Meine Aussagen zwecks Stabilität gelten für TCP/Port 2049 bzw. Simpac.
EDIT: OK, immer Open/Close und dann noch parallel an mehreren Stellen, das erklärt natürlich dein Fehlerbild.
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
/
Problem mit MUX und Klimaschrank
Problem mit MUX und Klimaschrank 
Anders formuliert: solange du nur den Fehler 56 bekommst brauchen wir uns gar nicht um die einzelnen Befehle zu kümmern und auch nicht nicht um den Treiber, sondern ausschließlich eher um deine VIs.
