Bug in Funktion gettime()

[enertegus]

ist halt immer der Spagat zwischen "optimal konfigurierbar" und "noch für jedermann verständlich".

Genau das war hier das Problem, nicht die technische Machbarkeit.

In drei Punkten stimme ich aber zu: Die Wartezeit sollte einmalig am Ende

Siehe letzte Antwort und den zitierten Thread. Macht euch keine Hoffnung. Im Schnitt schafft die IP eh nur 4T/s und da ist die Antwort eines jeden Aktors da. Bei 100 Abfragen wartet man dann halt 25 Sekunden - sorry aber das ist der Bus (ich weiss nicht, wie lange da der HS braucht, aber er kann sicher nicht schneller sein, weils ja an der Schnittstelle liegt).

Und: Irgendwie sollte man feststellen können, ob eine Antwort kam, oder nicht.

Wie gesagt, wenn richtig parametriert, MUSS eine Antwort kommen, wenn nicht, dann NIE.Man müsste das ja jederzeit am Busmontor sehen können. Wenn man es mal richtig hat, geht's ja immer.
Ansonsten wäre dann ein Featurewunsch (?).

[enertegus]

Ich finde es auch nicht so gut, das gettime() immer wieder ausgeführt wird, vielleicht will ich ja nur hin und wieder synchronisieren. Und was passiert, wenn der Zeitmaster am Bus ausfällt? Bleibt die Zeit des EPCs dann quasi stehen? Weil die GA sich nicht mehr ändert aber immer wieder verwendet wird?

Ist ja nun ausgebessert (neuer Eibparser notwendig).
Wenn Die GA sich nicht ändert, läuft der EibPC einfach vor sich hin (mit seinem Quarz, wenn kein ntp vorhanden)

[pio]

Code in InitGA ist nicht erlaubt.

Das ist wirklich sehr schade!!!!

[Tessi]

ist halt immer der Spagat zwischen "optimal konfigurierbar" und "noch für jedermann verständlich".

Eigentlich ist das kein Spagat zwischen diesen beiden Punkten sondern eine Frage des Designs des Interfaces zwischen Mensch und Maschine. Die Sektion muß ja nicht mit mehr als nur einer GA-Liste gefüllt werden, sie soll nur optional auch weitergehende Parameter, ggf. sogar Code verstehen, wenn der Nutzer das verwenden will. Generell macht man das doch an anderen Stellen auch schon jetzt so: Wer keinen Bock hat, nutzt nur die vorhandenen Makros und setzt sich mit dem Rest gar nicht erst auseinander. Wer mehr will, muß halt auch den Rest der Doku lesen, verstehen, und sich mit der Programmiersprache des EPCs auseinandersetzen. Warum dieses Konzept nicht auch für die Initialisierung anwenden?

Und: Irgendwie sollte man feststellen können, ob eine Antwort kam, oder nicht. DIe Idee einen "Status" zur GA abzufragen, ist vielleicht gar nciht so dumm, also "Status(GA)" liefert die Zeit in Sek seit dem letzten empfangenen Programm oder 0, wenn noch keines empfangen.

Wenn ich dann zufällig weniger als 1s nach der Aktualisierung abfrage, bekomme ich auch 0s geliefert, und glaube dann an eine nicht initialisierte GA - das wäre wohl nicht so gut...

Nein lt. Standard, muss nach dieser Zeit (plus eine Enertex Sicherheit) die Antwort da sein. Wenn das früher der Fall ist, dauert das nicht so lange.

D.h., sobald eine Antwort gekommen ist, geht es mit der nächsten Anfrage weiter?

"Warum überhaupt die Sache mit dem Timeout, kann man nicht einfach alles rausblasen und dann halt nach der letzten GA warten?" - So dachte ich auch bis hier:
https://knx-user-forum.de/knx-eib-fo...nterfaces.html

Das Problem ist, dass dann die [von mir getestete] IP Schnittstellen sonst rumzicken. Wie gesagt, wenn's schneller geht, ist es ja eh kein Problem. Die optimale Performance braucht man eben nicht zu "tunen".

OK, das Problem war mir jetzt so noch nicht bekannt, ich habe bislang gedacht, die FT1.2 wäre die langsamste Schnittstelle...
Wobei mir das schon merkwürdig vorkommt, sollen IP-Schnittstellen doch auch als LKs eingesetzt werden können. Aber ein LK mit nur 4 Telegrammen/s???

Nein, dann hast Du eben einen Fehler bei Deiner Installation. Die Teile müssen antworten, lt. Standard. Ausnahme: Das Leseflag ist nicht gesetzt.

Oder aber aus irgenwelchen Gründen kam die erste Anfrage nicht an, oder das betreffende Gerät war zum Zeitpunkt der Anfrage selbst noch nicht so weit mit seiner Initialisierung, als das es schon antworten konnte, oder....
Ich habe es einige Male beobachten können, das vereinzelt keine Antwort kam (wenn der ganze Bus neu gestartet wurde), bei wiederholter Anfrage (per ETS) dann aber doch. Standard und Praxis scheinen da nicht immer zusammenzupassen.

Code in InitGA ist nicht erlaubt.

Schade, ich habe leider Geräte, die antworten nicht auf Read, die liefern den Wert einer GA, wenn man einen bestimmten Wert auf einer anderen GA sendet. Das geht wohl nur mit Code, sollte aber vor dem Start der folgenden Sektion abgeschlossen sein.

Wie gesagt, wenn richtig parametriert, MUSS eine Antwort kommen, wenn nicht, dann NIE.Man müsste das ja jederzeit am Busmontor sehen können. Wenn man es mal richtig hat, geht's ja immer.
Ansonsten wäre dann ein Featurewunsch (?).

Klar ist das ein Featurewunsch, denn der Status interessiert ja nicht nur bei abgefragten GAs sondern bei allen. Vor allem bei denen, die eben nicht abgefragt werden können (siehe oben) und nur selten aktualisiert werden. Und in bestimmten Fällen ist auch interessant, wie "alt" ein Wert schon ist.
Klar kann ich das mit internen Variablen und Code auch selber "basteln" - nur ist in der Init-Sektion ja leider kein Code erlaubt!

Ist ja nun ausgebessert (neuer Eibparser notwendig).
Wenn Die GA sich nicht ändert, läuft der EibPC einfach vor sich hin (mit seinem Quarz, wenn kein ntp vorhanden)

Gut, dann läuft es jetzt genau so, wie ich es schon von Anfang an erwartet hatte.

Das ist wirklich sehr schade!!!!

Ja, aber dafür wunschgemäß "einfach". Da müssten wir uns wohl der Mehrheit beugen - wenn denn lieber einfach als flexibel tatsächlich der Mehrheitswunsch ist...



Aber mittlerweile sind schon einige Features gekommen, die Anfangs ja angeblich auch keiner brauchte. Kommt Zeit, kommt Feature - und irgendwann ist es dann doch flexibel, wir müssen nur warten können

[salixer]

OK, das Problem war mir jetzt so noch nicht bekannt, ich habe bislang gedacht, die FT1.2 wäre die langsamste Schnittstelle...
Wobei mir das schon merkwürdig vorkommt, sollen IP-Schnittstellen doch auch als LKs eingesetzt werden können. Aber ein LK mit nur 4 Telegrammen/s???

Linienkoppler geht nur mit IP-Routern.

[Tessi]

Ups!

[enertegus]

D.h., sobald eine Antwort gekommen ist, geht es mit der nächsten Anfrage weiter?

Klar.

OK, das Problem war mir jetzt so noch nicht bekannt, ich habe bislang gedacht, die FT1.2 wäre die langsamste Schnittstelle...
Wobei mir das schon merkwürdig vorkommt, sollen IP-Schnittstellen doch auch als LKs eingesetzt werden können. Aber ein LK mit nur 4 Telegrammen/s???

Ich glaube ja immer noch an einen Fehler bei mir, aber bisher hat mir da keiner so recht geantwortet, was ich falsch mache. Immerhin hat einer geschrieben, dass er deswegen eine FT1.2 an den Bus gehängt hat.

Schade, ich habe leider Geräte, die antworten nicht auf Read, die liefern den Wert einer GA, wenn man einen bestimmten Wert auf einer anderen GA sendet.

Wenn ich z.B. einen Lichtaktor mit Statusobjekt habe, wird bei Read auf dem Statusobjekt geantwortet.

Ja, aber dafür wunschgemäß "einfach". Da müssten wir uns wohl der Mehrheit beugen - wenn denn lieber einfach als flexibel tatsächlich der Mehrheitswunsch ist...

Das ist so.

Aber mittlerweile sind schon einige Features gekommen, die Anfangs ja angeblich auch keiner brauchte. Kommt Zeit, kommt Feature - und irgendwann ist es dann doch flexibel, wir müssen nur warten können

ja, der Dolch vom MatthiasS beim Franken-Stammtisch "Aah, ich denke man braucht keine Visu" sitzt immer noch tief im Fleisch. Ich sag halt: Stur, aber immer noch ein wenig lernfähig...

[saft6luck]

Genau das war hier das Problem, nicht die technische Machbarkeit.

Das zeugt eher von Phantasielosigkeit und maßloser Unterschätzung der Nutzer. Glaubst du wirklich, der Nutzer schafft es nur die GA im Tool einzugeben? Und nicht auch noch z.B. die Anzahl der Wiederholungen, den Namen der Fehlervariable oder die Anzahl der Anfragen, die raus gehen dürfen, ohne dass bisher Antworten hierfür da sind?

Siehe letzte Antwort und den zitierten Thread. Macht euch keine Hoffnung. Im Schnitt schafft die IP eh nur 4T/s und da ist die Antwort eines jeden Aktors da. Bei 100 Abfragen wartet man dann halt 25 Sekunden - sorry aber das ist der Bus (ich weiss nicht, wie lange da der HS braucht, aber er kann sicher nicht schneller sein, weils ja an der Schnittstelle liegt).

Eine Schnittstelle schafft 100%ig mehr als 4 Telegramme pro Sekunde! Und ob die Antwort dann da ist legt nicht nur der Aktor fest! Das ist der Bus, ja, aber so langsam wie du das darstellst ist er wirklich nicht.
Beleg? Meine Aktoren schicken regelmäßig 8 Telegramme der Strommessungen, alle in einem Rutsch, ohne Telegrammratenbegrenzung und die kann ich problemlos loggen und wenn die Waschmaschine läuft auch gerne mal alle 50ms ein Telegramm (20/s) und das merkt man am Bus nicht.

Wie gesagt, wenn richtig parametriert, MUSS eine Antwort kommen, wenn nicht, dann NIE.Man müsste das ja jederzeit am Busmontor sehen können. Wenn man es mal richtig hat, geht's ja immer.
Ansonsten wäre dann ein Featurewunsch (?).

Interessant ist da ja eben die Fehlererkennung. Wenn tatsächlich keine Antwort kommt, muss ich nachher doch wieder alle GAs testen.

-> Nicht robust

[saft6luck]

Linienkoppler geht nur mit IP-Routern.

Bereichskoppler gehen mit IP-Routern.

[saft6luck]

Wenn ich z.B. einen Lichtaktor mit Statusobjekt habe, wird bei Read auf dem Statusobjekt geantwortet.

Das mag bei manchem DALI-Gateway nicht so recht funktionieren, insbesondere wenn man auch noch den Status der Lampen lesen will

[enertegus]

Eine Schnittstelle schafft 100%ig mehr als 4 Telegramme pro Sekunde! Und ob die Antwort dann da ist legt nicht nur der Aktor fest! Das ist der Bus, ja, aber so langsam wie du das darstellst ist er wirklich nicht.
Beleg? Meine Aktoren schicken regelmäßig 8 Telegramme der Strommessungen, alle in einem Rutsch, ohne Telegrammratenbegrenzung und die kann ich problemlos loggen und wenn die Waschmaschine läuft auch gerne mal alle 50ms ein Telegramm (20/s) und das merkt man am Bus nicht.

Welche Schnittstelle? Hast Du mal 100 Telegramme auf einen Rutsch rausgeschrieben und den Bus mit einer 2. Schnittstelle beobachtet? Ich bin da echt am zweifeln, vielleicht mache ich was falsch, aber es hat definitiv nach 10 bis 20 Telegrammen den Bus dicht gemacht. Also nochmal die Bitte: Welche Schnittstelle, so dass wir das testen können.

[vento66]

Hi Micha!

Ich hab jetzt mal schnell einen Mittschnitt einer Buskommunikation gemacht. Es laufen viele "Sicherheitsmechanismen" über den Bus, so das Stromwerte zyklisch gesendet werden. Die Anlage besteht aus 2 Linien, die über IP verbunden sind. Als LK sind ABB IPR/S 1.1 verbaut. auf die Schnelle hab ich da 12 Tel/sek von einer Linie gesehen.(Tel 3-14) Ohne das der Bus in die Knie geht.

[enertegus]

Hi Micha!
Ich hab jetzt mal schnell einen Mittschnitt einer Buskommunikation gemacht. Es laufen viele "Sicherheitsmechanismen" über den Bus, so das Stromwerte zyklisch gesendet werden. Die Anlage besteht aus 2 Linien, die über IP verbunden sind. Als LK sind ABB IPR/S 1.1 verbaut. auf die Schnelle hab ich da 12 Tel/sek von einer Linie gesehen.(Tel 3-14) Ohne das der Bus in die Knie geht.

Hi Micha,
Danke. Aber lt.Deinem Mitschnitt tritt das nur 1x auf. Was ich meine: Dauerhaft (~ 5..10 Sekunden) ruhig mal 10 T/s auf die Schnittstelle "blasen".

[vento66]

Naja 8 Telegramme/ sek tauchen da schon noch 3 mal auf. Ich werd morgen mal die Aktoren voll aufdrehen (morgen ist dort keiner da ) Dann schick ich Dir noch nen anderen Mittschnitt

[saft6luck]

Im Bild wird das Senden des eibPCs über die ABB IPS/S 2.1 dargestellt, gecaptured über den Siemens N146/02.
Das ging bei Daten 0 los und endete bei FFFF. Der eibPC scheint die write()s aber irgendwie zu limitieren, denn durchgängig schaffte ich es nur bis ca. 1Telegramm/100ms (ich hab aber auch nicht alles getestet), schneller wurde er erst, wenn er Telegramme verwirft?! Obwohl ja trotzdem längere Passagen durchgängig sind.