Nachrichten per TCP versenden

[Marha]

Hallo,

ich versuche eine Nachricht mit dem EibPC an mehrere Devices über TCP zu versenden.
Solange die Nachricht an nur ein einziges Device geht funktioniert alles einwandfrei. Sobald die Nachricht an zwei oder mehr Devices "gleichzeitig" verschickt werden soll, führt das bei mir zu Problemen. Vermutlich passt dann mein Timing nicht mehr. Was muss ich beachten? Wie kann ich dem Fehler auf die Spur kommen?
Im Moment baue ich zunächst erstmal eine Verbindung zu einem Device auf über connecttcp. Wann kann ich die Verbindung zum nächsten Device aufbauen? Im nächsten Programmdurchlauf? Nach einer Wartezeit von 200ms? Oder erst dann, wenn die Verbindung zum ersten Device besteht? Wie handelt die Firmware dies?
Glaube im Handbuch gelesen zu haben, dass das letzte connecttcp pro Programmdurchlauf gewinnt.
connectStatus1 = connecttcp(Port1,IP1)
connectStatus2 = connecttcp(Port2,IP2)
Überschreibt mir connecttcp(Port2,IP2) die Variable connectStatus1 oder schreibt jedes connecttcp seinen Rückgabewert in "seine eigene" Variable?
Kann mir jemand einen Tipp geben?


Gruß Markus

[enertegus]

Glaube im Handbuch gelesen zu haben, dass das letzte connecttcp pro Programmdurchlauf gewinnt.

Ja, aber nur bezogen auf den gleichen Empfänger. Wenn Du mehrere verschiedene Empfänger hast, dann sind die vollkommen getrennt.

connectStatus1 = connecttcp(Port1,IP1)
connectStatus2 = connecttcp(Port2,IP2)
Überschreibt mir connecttcp(Port2,IP2) die Variable connectStatus1 oder schreibt jedes connecttcp seinen Rückgabewert in "seine eigene" Variable?

Nein.
Du muss nur bei der Auswertung aufpassen, von wem du was empfängst:
[highlight=epc]
if event(readtcp(..,IP , .)) and IP == IP1 then ... endif
if event(readtcp(..,IP , .)) and IP == IP2 then ... endif
[/highlight]

[saft6luck]

Du muss nur bei der Auswertung aufpassen, von wem du was empfängst:
[highlight=epc]
if event(readtcp(..,IP , .)) and IP == IP1 then ... endif
if event(readtcp(..,IP , .)) and IP == IP2 then ... endif
[/highlight]

Wie? Alle readtcp() werden bei einem eintreffenden Telegramm invalid und die Argumente Port und IP müssen Variablen sein?

Werden dann auch alle "Buffer"-Variablen aller readtcp()s im Code bereits gefüllt?

Dann sollte die Beschreibung der TCP/UDP-Kommandos aber entsprechend ergänzt und auch korrigiert werden.

Meine Erwartungshaltung ist, dass die Argumente für einen Kommando-internen Vergleich vorgegeben werden, also Konstanten sind.

Zudem meckert der Compiler auch nicht, wenn man Konstanten vorgibt.

Damit lassen sich dann aber auch etliche "Timing"-Probleme erklären.

[enertegus]

Wie? Alle readtcp() werden bei einem eintreffenden Telegramm invalid und die Argumente Port und IP müssen Variablen sein?

Ja genauso ist es

Werden dann auch alle "Buffer"-Variablen aller readtcp()s im Code bereits gefüllt?

Ja stimmt auch.
Ich weiß gar nicht, ob die Dokumentation genauso gemacht ist. Aber wenn ich wenn wir das ergänzen. Die Beispiele sind jedenfalls genauso gemacht und im neuen Handbuch Kapitel Programmierung für Experten ist das eigentlich hinterlegt.

Damit lassen sich dann aber auch etliche "Timing"-Probleme erklären.

Was meinst du mit Timing Probleme?

[saft6luck]

Ja genauso ist es

Ok, muss man einfach verstanden haben. Wenn die Buffer-Variablen (Arg1,..) auch überschrieben werden, muss man diese auf jeden Fall umkopieren. Bei einer Verarbeitung in mehreren Schritten also sehr wichtig!

Ich weiß gar nicht, ob die Dokumentation genauso gemacht ist. Aber wenn ich wenn wir das ergänzen. Die Beispiele sind jedenfalls genauso gemacht und im neuen Handbuch Kapitel Programmierung für Experten ist das eigentlich hinterlegt.

Wenn man es so liest, ja, die meisten Beispiele sind so geschrieben. Es steht aber auch da: Port kann Variable oder Ausdruck sein und wenn man das Gerät über Namen ansprechen kann, kann man resolve() verwenden.

In der Kommando-Beschreibung sollte auf jeden Fall das Argument besser beschrieben werden, es ist eine (temporäre) Variable, deren Inhalt später ausgewertet werden muss. Und gleich hier das Beispiel.

Der Compiler hat aber auch ein Problem, denn er sollte wohl einen Fehler melden, oder? Was macht er denn mit der Konstanten?

Was meinst du mit Timing Probleme?

Da ich die Adresse oder den Port als Variable für die Definition des Gerätes verwendet habe, sind die Pakete immer an die Adresse des letzten empfangenen Telegramms geschickt worden. Bei wenig Traffic gibt es kein Problem, bei mehreren CommandFusion und Moxa wird es aber problematisch. Bei verschachtelten Antwort-Abfrage-Szenarien scheint dann die Kommunikation zu stocken und mit ein paar delays passt es komischerweise wieder.

[enertegus]

Ok, muss man einfach verstanden haben. Wenn die Buffer-Variablen (Arg1,..) auch überschrieben werden, muss man diese auf jeden Fall umkopieren.

Die Argumente werden quasi per Referenz übergeben, also von der Funktion verändert. Das gilt auch für die Funktionen readrs232, readknx, readrawknx usw.

Der Compiler hat aber auch ein Problem, denn er sollte wohl einen Fehler melden, oder? Was macht er denn mit der Konstanten?

Der Compiler hat kein Problem, könnte/sollte aber einen Fehler werfen. Ich muss das nach dem Urlaub mal genauer anschauen.

Bei wenig Traffic gibt es kein Problem, bei mehreren CommandFusion und Moxa wird es aber problematisch.

Ja, das kann ich mir vorstellen.
Zumindest sollte das nun klar sein. Wie gesagt, in der Doku werden wir das nochmal deutlicher machen und im Compiler schau ich mir das mal an.