TCP Verbindungs-ID

Hallo Freddy,

da muss ich doch glatt mal den Fehler suchen, warum zehn Klimaschränke auf meine Befehle reagieren, und das schon seit Jahren!

Noch einmal, die Kommunikation ist ok und läuft! Es geht um die Übergabe der Id in den nächsten Case!


VG

Woodeye

Ich glaube Dir ja, das es mit den anderen Schnittstellen funktioniert.
Ich habe nur das Handbuch kurz an gelesen, da wird explizit auf die Syntax hingewiesen.
Schau Dir mal die Kapitel ab Seite 128. Kann sein ich bin auf dem falschen Dampfer.

Ich hab dir das Handbuch mal angehängt.
Gruß
Freddy

Hallo Freddy,

dies ist die Softwarebeschreibung eines Drittunternehmens welches für Feutron eine Softwarelösung bereitstellt. Mit FKS kann man die Klimaschränke per PC programmieren und überwachen. Ich greife aber direkt auf den Anlagenbefehlssatz von Feutron zu und alle Anlagen reden mit mir ohne Probleme, ich möchte nur die Vorteile einer FGV nutzen und darum die Verbindungs-ID über das Schieberegister weitergeben.

Dann braucht es jetzt gutes altes Debugging. Vielleicht hilft die folgende Änderung bei der Suche:

  Forum-test.vi (Größe: 26,2 KB / Downloads: 242)

Gruß, Jens

Hallo Jens,

so einfach ist es leider nicht. Im Original-VI ist bereits ein Variant eingebaut, er übernimmt, je nach Klimaschrank, die COM oder TCP. Somit habe ich die generierte Nummer schon gesehen, sie bleibt bei allen Durchläufen gleich und erscheint auch im neuen Durchlauf / Case. Mein erster Gedanke war , dass die Umwandlung im Variant fehlerhaft ist und deswegen die Übergabe nicht funktioniert. Grundsätzlich arbeitet das VI mit dem Variant, leider aber nur mit den seriell gesteuerten Schränken.

Viele Grüße

Harald

Aha, wir sollen also an Hand eines anderes VIs herausfinden, was in deinem Orignal-VI nicht funktioniert.

Wie ich schon geschrieben habe, prinzipiell sollte dein hochgeladenes Beispiel-VI funktionieren. Ich verwende selber ähnliche FGVs.

Also, Fehlerursache eingrenzen:
Tritt das Problem auch so auf, wenn du ohne Variant arbeitest? Wenn ja, dann ist das Problem deine Gegenstelle. Wenn nein, dann liegt der Fehler in deinem VI.

Die Vergleiche mit COM hinken dagegen. Bei RS232/485 gibt es keine Verbindungs-Referenz, die von den beiden Gegenstellen "offen" gehalten werden muss, solange die Kommunikation besteht.
Oder anders ausgedrückt: VISA-Open belegt nur die HW-Resource auf deinem Rechner, TCP Open stellt schon die Kommunikation zu deiner Gegenstelle her. VISA-Read und Write erledigen das VISA-Open bei Bedarf auch implizit, TCP-Read und Write reagieren dagegen auf eine ungültige TCP-Refnum mit einem Fehler.

Gruß, Jens

EDIT: Überleg mal, ob hier ein OOP-Umsetzung sinnvoll ist.

Hallo Jens,

es war mit Sicherheit nicht so gemeint, dass Ihr meinen Fehler in einem anderen VI suchen sollt, das hochgeladene "Forum.vi" ist nur auf den wesentlichen Fehler reduziert, nämlich die Übergabe der Connection Id. Ich hatte gedacht, dass das Grundproblem so besser zu beschreiben ist. Ich glaube auch nicht, dass etwas Grundlegendes falsch programmiert ist und hatte auf einige Denkanstöße gehofft, wo der Fehler noch zu suchen sein könnte. Und da hast du dankenswerterweise schon stark mitgeholfen, auch schon wieder im letzten Post.

Vielleicht liegt es wirklich am Klimaschrank, er gibt als Endzeichen ein ETX, worauf zu reagieren ich noch keine Möglichkeit gefunden habe. Dem würde widersprechen, dass mehrere sequenziell übertragene Befehle auch funktionieren.

Ich werde heute einmal versuchen ein anderes Netzwerkgerät anzusteuern und auch einen Test mit LV2015 zu machen, am geöffneten Port eine Änderung vorzunehmen halte ich für wenig sinnvoll und weitere Maßnahmen fallen mir langsam nicht mehr ein.



Viele Grüße

Harald

Gibt es neue Erkenntnisse?

Du könntest dein VI natürlich "Fail-Safe" gestalten. Bei Auftreten eines Komm-Fehlers schließt du die TCP-Verbindung, wartest im Idealfall ein wenig, öffnest die Verbindung wieder von neuem und versuchst es nochmal.

Wenn ich bei mir ein wenig rumspiele, dann tritt "Fehler 1" genau dann auf, wenn ich mit einer ungültigen TCP-Refnum in TCP-Read reingehe.

Gruß, Jens

Nicht wirklich...

Der Test mit LV2015 brachte erwartungsgemäß das gleiche Ergebnis und zu dem Versuch mit einem weiteren Gerät bin ich heute nicht gekommen. Da muss die IT erst einem weiteren Gerät die Freigabe geben. Wie gesagt, so viel Erfahrung habe ich noch nicht mit TCP! Meine Programme laufen meistens über Wochen und Monate, somit habe ich bis jetzt immer die Netzwerkverbindung geöffnet, Nachricht gesendet und Port wieder geschlossen, ich habe im Normalfall alle Zeit der Welt für diese Abfragen. Wenn Fehlermeldung, dann einfach noch einmal. Das klappt auch mit der FGV, da ich dort ja nur COM /IP-Adresse als String übergebe.

Nun wollte ich endlich einmal einen universellen Treiber basteln und dann ....

Was ich immer noch nicht nachvollziehen kann ist, dass alle Befehle im Init-Case abgearbeitet werden, dies können auch zehn Abfragen nacheinander sein (!), und bei der sofortigen Weitergabe der Id in den nächsten Case ein Fehler auftritt. Ich glaube da einfach noch nicht an die Hardware.


Viele Grüße

Harald


PS: gerade noch einmal deinen letzten Post gelesen...

Du kannst also auf Netzwerkgeräte zugreifen? Somit wäre in meinem "Forum.vi" nur Befehl, Port und Id zu ändern um dies auszuprobieren? Darf ich dich um diesen Gefallen bitten?
Eine falsche Übergabe in LV schließe ich aber auch aus, weil die Sonde und auch die auch der "Variant nach serialisierte Daten" immer die gleichen Werte ausgeben. Morgen erhasche ich aber auch noch einmal den IT-Spezi.

Der Test war ein Link "auf mich selber", also "localhost".

Alternative: Probiere es doch mal statt Variant mit einem Cluster, der Infos für RS-232 UND TCP enthält. Also zB ein Enum über die Schnittstelle (Netzwerk oder COM), eine VISA-Variant und eine TCP-Refnum.

Noch eine andere Idee: VISA funzt auch über TCP/IP, man muss nur die VISA-Resource entsprechend erstellen.

Gruß, Jens

Edit: Tritt der Fehler mit dem 2. Case auch bei der Variante mit einer Refnum, so wie du es gepostet hast, auf? Anderenfalls wird es dringend Zeit, dass du ein VI hochlädst, welches näher an deiner wahren Umsetzung ist.