Wie kann ein KNXNet/IP Interface auf verschiedene Adressen schreiben

[Dill]

Wenn ich einem IP-Interface 2 Adressen (zb 1.1.250+251) gebe und mich dann mit 2 ETS verbinde, dann sendet ETS1 auf 250 und ETS2 auf 251.
Die jeweils andere ETS erhaelt die Telegramme auch als indication (Also als ob ein anderes Geraet das gesendet haette)

Wie funktioniert das?

Ein TP-UART kann nur eine Adresse haben.
Telegramme die der TP-UART selbst (erfolgreich) versendet hat werden als confirmation an den Hostprozessor gegeben.

Gibt es irgendeinen Betriebsmodus des TP-UART fuer Interfaces der mir unbekannt ist, oder muss der Hostprozessor da den Uebrblick behalten und die Telegarmme umbauen (klingt murksig).

[thewhobox]

Der Uart selbst ist erstmal nur für die Bus Anbindung da.
Was du dem rein gibst an Bytes schickt er auch exakt so auf den Bus.
Den interessiert nicht was in dem Telegramm drin steht.

Ausnahme:
Man kann bei einigen (allen? Zumindest beim NCN) eine Option aktivieren, dass er Telegramme automatisch acked. Dafür muss er natürlich seine eigene PA wissen.

P. S. Die Applikation hat die PA.
Du kannst auch mehrere Applikationen auf einem Gerät laufen lassen (siehe mdt Router).

[Dill]

> Man kann bei einigen (allen? Zumindest beim NCN) eine Option aktivieren, dass er Telegramme automatisch acked.

das kann auch Siemens und elmos.
Und das wuerde dann schonmal nicht mehr funktionieren, also muss man sich selbst um die ACKs kuemmern.

Ausserdem ist mit einer Adresse die ganze Last fuer conf und ind beim TP-UART.
Das heisst,

es kommt ein telegramm -> ind vom TPUART -> im stack nach oben
wir senden ein telegramm -> conf vom TPUART -> im stack nach oben

wenn der stack auf mehrere Adressen senden will, muss er sich darum ja auch selbst kuemmern. Scheint mir sehr hacky.
Ausserdem ist in den TPUART Datenblaettern unklar, ob ueberhaupt eine conf generiert wird wenn ich ein telegramm sende mit einer absendeadresse die ungleich der im TPUART gesetzten ist.

Insgesamt gehen die TPUART Datenblaetter davon aus, dass ein device = eine adresse.
Dieser ganze mehr-adress-kram scheint mir sehr reingehackt.

[Dill]

P. S. Die Applikation hat die PA.
Du kannst auch mehrere Applikationen auf einem Gerät laufen lassen (siehe mdt Router).

Es kann sein, dass der 2 TPUART hat

- einen fuer router/interface, das dann - wie auch immer das implementiert ist - auf 4 Adressen sendet
- einen fuer den Zeitserver, ...

Bei JUNG ist das jedenfalls so, das IP-Interface hat 2 TPUART und zwei Applikationen.
Das MDT Geraet kenne ich nicht.

[thewhobox]

also muss man sich selbst um die ACKs kuemmern.

Das ist das kleinste "Problem".
Im Stack von Thelsing wird das meine ich auch "manuell" geacked.

muss er sich darum ja auch selbst kuemmern. Scheint mir sehr hacky.

Warum?
Du brauchst eh eine Queue für senden und empfangen. Welche Applikation da nun ein Telegramm in die Queue schiebt ist ja egal.

wird wenn ich ein telegramm sende mit einer absendeadresse die ungleich der im TPUART gesetzten ist.

Nochmal: Die Uart interessiert es nicht was in dem Telegramm ist. Du kannst auch kaputte Telegramme verschicken (solange der CRC stimmt).
Die Adresse ist rein nur für das automatische Acken (wenn du das überhaupt aktivierst).

Dieser ganze mehr-adress-kram scheint mir sehr reingehackt.

Wieso machen es dann viele Hersteller?
Im Datenblatt steht nirgendswo, dass mit der Uart nur eine Adresse verewendet werden darf.

Aber evtl irre ich mich ja auch und traxanos korrigiert mich gleich^^

[thewhobox]

Es kann sein, dass der 2 TPUART hat

Das hängt natürlich alles vom verwendeten KNX-Stack ab, ob er das unterstützt oder eben nicht.

Aber es ist definitiv möglich über einen Uart mehrere Adressen zu verwenden.
Nach der Logik bräuchtest du ja für jede Tunneladresse eine eigene Uart.

[Dill]

Das ist das kleinste "Problem".
Im Stack von Thelsing wird das meine ich auch "manuell" geacked.

Naja, ist 1. einfacher wenn der TPUART das macht, ausserdem Zeitkritisch, d.h. der Stack muss auf einem RTOS laufen.

Warum?
Du brauchst eh eine Queue für senden und empfangen. Welche Applikation da nun ein Telegramm in die Queue schiebt ist ja egal.

So einfach ist es nicht.
Angenommen du hast 2 Adressen A1, A2 die ueber einen TPUART senden.

A1 sendet -> conf an A1 und ind an A2
A2 sendet -> conf an A2 und ind an A1

Aber es ist definitiv möglich über einen Uart mehrere Adressen zu verwenden.
Nach der Logik bräuchtest du ja für jede Tunneladresse eine eigene Uart.

Ich sage ja nicht, dass es nicht geht, ich suche nach einer vernuenftigen Implementierung.

Gibt es denn ein Beispiel in openknx mit einem IP-Interface mit mehreren Adressen?

Wieso machen es dann viele Hersteller?

klar, jedes IP-Interface macht das.
Sind dir denn andere KNX-Geraete bekannt die auf mehr als eine Adresse senden?

[thewhobox]

Naja, ist 1. einfacher wenn der TPUART das macht

Der Uart hat doch keine TX Queue?

d.h. der Stack muss auf einem RTOS laufen.

Das bekommt man alles auch gut ohne RTOS hin, indem man einfach einen nicht blockierende Architektut hat.
Wir bei OpenKNX verwenden auch nur das Arduino FW.

A1 sendet -> conf an A1 und ind an A2

Das ist alles gar kein Problem.
A1 sendet das an den tp_uart_layer. Der schickt es in die Queue und gleichzeitig wieder zurück in den Stack als ind.
Im Stack wird dann ein weiterer Layer zwischen NetworkLayer und UARTLayer eingebaut, der das filtert und trennt.
Sprich Source ist von A1, also wird die ind nur an A2 weitergeleitet.
Wenn Source unbekannt ist, wird es an den NetworkLayerLayer von A1 und A2 weitergeleitet.

Gibt es denn ein Beispiel in openknx mit einem IP-Interface mit mehreren Adressen?

Unser IP-Router hat 17 Tunneladressen.
https://github.com/OpenKNX/knx (Stack als fork von https://github.com/thelsing/knx)


P.s.: Was hast du denn überhaupt vor?
Evtl bringt uns das weiter, als nur darüber zu philosophieren, ob es möglich ist

[Dill]

Naja, ist 1. einfacher wenn der TPUART das macht
Der Uart hat doch keine TX Queue?

hier ging es um das ACK, das ist einfacher wenn der TPUART das macht ...

d.h. der Stack muss auf einem RTOS laufen.

Das bekommt man alles auch gut ohne RTOS hin, indem man einfach einen nicht blockierende Architektut hat.
Wir bei OpenKNX verwenden auch nur das Arduino FW.

... und mein Stack laeuft auf Linux daher kann ich solche zeitkritischen Sachen wie ACK nicht machen.
Selbst mit PREEMPT_RT funktioniert das nicht 100% zuverlaessig.

Unser IP-Router hat 17 Tunneladressen.
https://github.com/OpenKNX/knx (Stack als fork von https://github.com/thelsing/knx)

ja cool, danke, das schau ich mir mal an.
EDIT: ich kann das IP-Interface repo nicht finden...!?

P.s.: Was hast du denn überhaupt vor?

IP-Interface mit *einem* socket + Logikserver.

Ich denke ich werden es nicht hinbekommen auf mehrere Adressen zu senden (wegen ACK) und muss mich dann so wie du es beschreibst selbst um das Multiplexing der conf/ind zu den einzelnen logischen Apps kuemmern. Hatte mich halt gewundert, dass es dafuer 0 Unterstuetzung in den TPUART gibt obwohl das so weit verbreitet implementiert wird.

Danke dir!

[thewhobox]

... und mein Stack laeuft auf Linux daher kann ich solche zeitkritischen Sachen wie ACK nicht machen

das glaube ich nicht.
Wir machen das auf nem rp2040, der einen Bruchteil von Rechenkapazität und Geschwindigkeit hat, von allem wo auch nur iwie Linux drauf läuft.
Im Vergleich dazu ist der rp2040 ne Kartoffel^^

EDIT: ich kann das IP-Interface repo nicht finden...!?

https://github.com/OpenKNX/OAM-IP-Router
Der ganze TpUart Teil ist ein eigenes Repo: https://github.com/OpenKNX/tpuart
Speziell interessiert dich bestimmt das: https://github.com/OpenKNX/tpuart/bl....cpp#L208-L302
Es wird gewartet bis genügend Bytes für ein Ack vorhanden sind. (Glaub 6 Bytes: Ctrl1, Ctrl2, Source, Destination) Damit kann man dann schon prüfen ob ein Ack gesendet werden soll.

auf mehrere Adressen zu senden

Nochmal, beim Senden und Empfangen selbst interessiert den Uart nicht was da drin steht.
Dein Problem ist lediglich das Acken eines empfangenen Telegrams.

Gruß Mike

[Dill]

das glaube ich nicht.

Ich schon, wir haben das intensiv getestet. Linux ohne PREMPT_RT schafft 99% der ACKs in time, mit PREMPT_RT 99.8% (auf iMX.8).
Ein beliebieger uc ohne OS 100%. Die Hardwarepotenz ist bei Echtzeitsachen nahezu irrelevant.

Nochmal, beim Senden und Empfangen selbst interessiert den Uart nicht was da drin steht.
Dein Problem ist lediglich das Acken eines empfangenen Telegrams.

Ja genau, das kann ich nicht zuverlaessig von Linux aus, s.o.

danke fuer die Links, ich schau mir das mal an.

[traxanos]

Also generell kann der OnSemi NCN53xx wie auch die Siemens TPUart(2) kein ACKs selber schicken. Einzige Ausnahme ist wenn das Telegramm an die eigene PA addressiert wurde und diese auch hinterlegt wurde. Für alles andere ist man auf den Host Controller angewiesen, das ACK rechtzeitig zu setzen. Dafür hast du, nur wenige ms Zeit (abhängig von der länge des Frames)

Und ja ich halte es auch für Linux & Co schwierig das Timing sauber hinzubekommen. Da kann ich also nur zustimmen. Allerdings hast du dann auch Probleme mit dem Empfangen, weil du die Pause von 2.6ms erkennen musst und dass ist sogar noch schwieriger als das ACK. Daher werden Datenverluste in kauf genommen (man sync sich notfalls wieder auf) oder macht andere Sprüngen um Probleme zu umgehen bzw. so klein wie möglich zuhalten.

Wir lösen das mittlerweile per DMA und und suchen rekursiv nach Telegramme.




Wobei ich schon erwartet hätte das PREMPT_RT das Problem hätte lösen können, aber dafür kenne ich mich nicht genug damit aus.

[Dill]

Allerdings hast du dann auch Probleme mit dem Empfangen, weil du die Pause von 2.6ms erkennen musst und dass ist sogar noch schwieriger als das ACK. Daher werden Datenverluste in kauf genommen (man sync sich notfalls wieder auf) oder macht andere Sprüngen um Probleme zu umgehen bzw. so klein wie möglich zuhalten.

Du meinst das:

The host either has to detect an end of packet timeout by supervising the EOP gap of 2 - 2,5 ms or check the end of frame by calculating the CCITT CRC (must be enabled by the U_ActivateCRC service).

[Siemens TPUART2]

Das haben wir im Griff, aber ich weiss nicht genau wie...

Wobei ich schon erwartet hätte das PREMPT_RT das Problem hätte lösen können, aber dafür kenne ich mich nicht genug damit aus.

Wir haben das vor ca 2(?) Jahren gemessen.
Kann sein, dass es inzwischen besser ist.
Da wir PREMPT_RT sowieso eher nicht verwenden wollen haben wir das nicht weiter verfolgt.