Problem mit MUX und Klimaschrank

(03.02.2021 08:17 )Stefan198 schrieb:  Hallo Martin,

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.