ElabNET Technik Forum

Hi Dominic,

ich hab mal kurz auf deinen TWS126 geschaut.

Kannst du bitte nochmals das Projekt-File hochladen.
Und anschließend bitte überprüfen, ob das Objekt K-609 auch in der Objekt-Verwaltung zu sehen ist.

Falls das geklappt hat, kannst du die Logik mit K-609 verknüpfen (aktuell ist sie mit L02-609 verknüpft, aber das ist nicht ansprechbar, da diese Schnittstelle nur passiv am KNX-Bus ist).

Eine Umstellung des Applikationsmodus auf die andere Schnittstelle (L02/) würde ich dir nicht empfehlen, da bereits alle 1-W-Regeln mit den K-... Objekten verbunden sind. Das müsstest du vorerst sonst noch alles per Hand ändern.

Hallo Stefan,
das neue Projektfile ist jetzt drin.
Leider kann ich die Logik immer noch nicht mit dem K-609 verbinden.

Eine Umstellung des Applikationsmodus auf die andere Schnittstelle (L02/) würde ich dir nicht empfehlen, da bereits alle 1-W-Regeln mit den K-... Objekten verbunden sind. Das müsstest du vorerst sonst noch alles per Hand ändern.

Wie würdest du mir empfehlen, dass ich aktuell meine Schnittstellen konfiguriere? Welche soll ich zum Programmieren mit der ETS verwenden?

Hallo Dominic,

ich fürchte, du musst die Schnittstelle auch nochmal neu von der ETS programmieren.
Der Upload des Projekt-Files hat offensichtlich nicht ausgereicht.

Wenn ich mit der ETS den TWS selbst programmieren will, würde ich die Schnittstelle im Applikationsmodus verwenden, da dann die Telegramme nicht über den Bus müssen.
Wenn du ein anderes Gerät programmierst, kannst du die andere Schnittstelle (nicht im Applikationsmodus) verwenden, dann sollte die Kommunikation mit den eigenen KOs nicht unterbrochen werden.

S. Kolbinger hat geschrieben: ↑Mi Jul 10, 2019 9:49 pm Wenn ich mit der ETS den TWS selbst programmieren will, würde ich die Schnittstelle im Applikationsmodus verwenden, da dann die Telegramme nicht über den Bus müssen.
Wenn du ein anderes Gerät programmierst, kannst du die andere Schnittstelle (nicht im Applikationsmodus) verwenden, dann sollte die Kommunikation mit den eigenen KOs nicht unterbrochen werden.

Der letzte Satz ließ mich ja eben aufhorchen.
Bedeutet also wer auf seinem TWS sehr viele Logiken usw. am Laufen hat und damit viel Bustraffic erzeugt und konsumiert dem stoppt das alles während Aktionen mit der ETS laufen andere Geräte zu programmieren?

Liegt die Unterbrechung darin begründet, das der Bus während der Geräteprogrammierung eh geflutet wird oder weil der TWS intern erstmal den Job priorisiert und alles andere blockt? Ersteres hätte man ja auch im wesentlichen mit anderen Schnittstellen, letzteres muss man eben wissen, das man da nicht viel erwarten kann wenn man da Mal einige komplexe Geräte am Stück programmiert.

Wenn beide Schnittstellen am TWS aktiv sind ist der Switch ja dann nur ein Klick in der ETS oder?

gbglace hat geschrieben: ↑Do Jul 11, 2019 6:51 amBedeutet also wer auf seinem TWS sehr viele Logiken usw. am Laufen hat und damit viel Bustraffic erzeugt und konsumiert dem stoppt das alles während Aktionen mit der ETS laufen andere Geräte zu programmieren?

Nein. Stefan hat hier was anderes gemeint.

Wenn der Bus schon mit vielen Telegrammen vom Busverkehr genutzt wird, dann wird die Programmierung mit der ETS entsprechend langsamer, wobei es auch System-Telegramme gibt, die Priorität haben. Es kann aber sein, dass Telegramme auch mal eine halbe Sekunde später ausgeliefert werden. Das passiert auch beim Starten vom Bus, da wollen alle Geräte Ihren Status loswerden und da ist ein heftiges Aufkommen.

lg

Stefan

Hallo Göran,

vielen Dank, dass du das ansprichst:

gbglace hat geschrieben: ↑Do Jul 11, 2019 6:51 am Der letzte Satz ließ mich ja eben aufhorchen.
Bedeutet also wer auf seinem TWS sehr viele Logiken usw. am Laufen hat und damit viel Bustraffic erzeugt und konsumiert dem stoppt das alles während Aktionen mit der ETS laufen andere Geräte zu programmieren?

Sorry, hab mich missverständlich ausgedrückt.
Die Programmierung durch die ETS stoppt den normalen IO der Objekte NICHT (außer natürlich, der TWS selbst wird programmiert)!
Und wenn beide Schnittstelle auf der selben Linie hängen, gibt es auch keinen Performance-Vorteil.

Was lerne ich daraus:
Ich sollte spät Abends nicht noch schnell eine Frage beantworten.
Besonders dann, wenn ich noch gleichzeitig mit 2-3 anderen Themen beschäftigt bin

OK dann ja alles gut. Also soweit das bekannte Schnitstellenverhalten. Programmiertelegramme kommen in hoher Stückzahl und haben hohe Prio, das kann halt den Bus für den sonstigen Datenferkehr bremsen. Kennt man ja aber auch von allen anderen Schnittstellen wenn die ETS da aktiv ist.

Hi,
tut mir leid das ich so lange benötige, um mich wieder zu melden.

@S.Kolbinger

Eine Umstellung des Applikationsmodus auf die andere Schnittstelle (L02/) würde ich dir nicht empfehlen, da bereits alle 1-W-Regeln mit den K-... Objekten verbunden sind. Das müsstest du vorerst sonst noch alles per Hand ändern.

Wie kann ich es denn bewerkstelligen, das die 1-W Regeln alle über L02 senden? Und wenn ich die alle per Hand ändern muss, ich möchte endlich Ordnung in die Sache bringen und nur noch die eine Schnittstelle mit den 8 Tunneln verwenden.

Bitte nochmals um ein paar Tipps, damit dich die 1-fach Schnittstelle loswerde. Danke!

Ich muss die Sache nochmal hochholen. Mittlerweile läuft Edomi im Docker und da findet die KNX Kommunikation auch noch über den Port 3674 statt. Dies hat dann zur Folge, das ich Probleme habe, wenn ich mit der ETS über Port 3674 programmieren möchte.

Ich würde immer noch gerne wissen, wie ich meine Installation nun ordentlich konfiguriere, damit sich ETS, Edomi und der TWS (KNX Kommunikation) gut vertragen.

Funktioniert es denn nicht, wenn Du die ETS (ggf. auch den Docker) auf Port 3675 umstellst, den die USB Schnittstelle hat? Ansonsten turnen alle auf derselben Schnittstelle herum, die nur einen Tunnel erlaubt...