Re: [V1.5 RC10] Elektrozähler EZD-FW nicht über TWS programmierbar
Verfasst: So Jan 19, 2020 12:32 pm
Hallo zusammen,
ja, bitte seht Euch das mit den Disconnects nochmal genau an.
Was für uns hilfreich ist sind Busmonitorlogs aus der ETS während des Programmierens. Einmal wenn es funktioniert und einmal wenn es nicht funktioniert.
Technischer Hinweis:
- Es gibt im Timing der Programmierung durch die ETS eine kritische Komponente, das ist die Berechnung der Prüfziffer über den programmierten Speicherbereich durch das programmierte Device.
- Während dieser Berechnung der Prüfziffer schickt das programmierte Device für den letzten Befehl keine Bestätigung zurück. Bei manchen Devices gerät die Berechnung / Bestätigung zeitlich etwas grenzwertig und das Verhalten der ETS darauf scheint sich womöglich abhängig von der Version zu verändern (zumindest ist das eine Beobachtung).
- Eigentlich sollte sowas nicht vorkommen, aber es ist (leider) auch so, dass ein sehr großer Teil der KNX Stacks, die in den Geräten eingesetzt sind, von wenigen kommerziellen Anbietern zugekauft werden die - hust - sich selbst zertifizieren dürfen. Meiner Ansicht nach unterläuft das ein wenig das Prinzip der unabhängigen Zertifizierung.
- Der WireGate Server basiert auf dem eibd der im Bereich Tunneling das Acknowlege auf der IP-Seite des Tunnels nicht Standard-Konform behandelt. Hierbei wird durch den eibd die IP-Seite (also die ETS) sofort mit einem Acknowlege bedient (und ist damit zufrieden) obwohl das eigentliche Device auf der TP-Seite noch gar keinen Acknowlege gesendet hat (weil es z.B. noch mit der Berechnung der Prüfsumme beschäftigt ist).
- Beim Timberwolf Server mit seinem (durch DIAL, einem separaten und unabhängiges Institut) zertifizierten KNX Stack nebst zertifiziertem KNXnet/IP Tunneling (das sind eigentlich schon zwei Zertifizierungen) wird das IP-seitige Ack erst dann gesendet, wenn es TP-seitig vom dortigen Device empfangen wurde.
Nur auf diese Weise ist es konform zum Standard, führt aber bei grenzwertigem Timing des programmierten Devices zu unterschiedlichen Ergebnissen in der ETS, je nach dem wie das IP seitige Acknowlege zur ETS hin gehandelt wird.
Ob das hier zutrifft haben wir noch nicht ganz herausgefunden, aber das ist der Grund, warum wir die Busmonitor-Aufzeichnungen der ETS benötigen, um den jeweiligen Zeitverlauf zu sehen.
lg
Stefan
ja, bitte seht Euch das mit den Disconnects nochmal genau an.
Was für uns hilfreich ist sind Busmonitorlogs aus der ETS während des Programmierens. Einmal wenn es funktioniert und einmal wenn es nicht funktioniert.
Technischer Hinweis:
- Es gibt im Timing der Programmierung durch die ETS eine kritische Komponente, das ist die Berechnung der Prüfziffer über den programmierten Speicherbereich durch das programmierte Device.
- Während dieser Berechnung der Prüfziffer schickt das programmierte Device für den letzten Befehl keine Bestätigung zurück. Bei manchen Devices gerät die Berechnung / Bestätigung zeitlich etwas grenzwertig und das Verhalten der ETS darauf scheint sich womöglich abhängig von der Version zu verändern (zumindest ist das eine Beobachtung).
- Eigentlich sollte sowas nicht vorkommen, aber es ist (leider) auch so, dass ein sehr großer Teil der KNX Stacks, die in den Geräten eingesetzt sind, von wenigen kommerziellen Anbietern zugekauft werden die - hust - sich selbst zertifizieren dürfen. Meiner Ansicht nach unterläuft das ein wenig das Prinzip der unabhängigen Zertifizierung.
- Der WireGate Server basiert auf dem eibd der im Bereich Tunneling das Acknowlege auf der IP-Seite des Tunnels nicht Standard-Konform behandelt. Hierbei wird durch den eibd die IP-Seite (also die ETS) sofort mit einem Acknowlege bedient (und ist damit zufrieden) obwohl das eigentliche Device auf der TP-Seite noch gar keinen Acknowlege gesendet hat (weil es z.B. noch mit der Berechnung der Prüfsumme beschäftigt ist).
- Beim Timberwolf Server mit seinem (durch DIAL, einem separaten und unabhängiges Institut) zertifizierten KNX Stack nebst zertifiziertem KNXnet/IP Tunneling (das sind eigentlich schon zwei Zertifizierungen) wird das IP-seitige Ack erst dann gesendet, wenn es TP-seitig vom dortigen Device empfangen wurde.
Nur auf diese Weise ist es konform zum Standard, führt aber bei grenzwertigem Timing des programmierten Devices zu unterschiedlichen Ergebnissen in der ETS, je nach dem wie das IP seitige Acknowlege zur ETS hin gehandelt wird.
Ob das hier zutrifft haben wir noch nicht ganz herausgefunden, aber das ist der Grund, warum wir die Busmonitor-Aufzeichnungen der ETS benötigen, um den jeweiligen Zeitverlauf zu sehen.
lg
Stefan
