ETS-Programmierung - Strommessender Schaltaktor 6OUT

[Darthyson]

Hallo Florian,

ich denke mal, du hast die 0x4B00 wegen diesem Issue gewählt. Sry, du hast natürlich Recht. Im letzten AllocAbsDataSegment wird der Speicherbereich angefordert und dann halt auch beschrieben. Dein MemMapperMod schickt diese Daten ja mehr oder weniger ins Nirvana. Das sollte man meiner Meinung nach in die sblib mit reinbringen. Ebenso muss langfristig das Issue gelöst werden, da diese Grenze bei anderen Apps woanders liegen kann. Ich will aber diesen Thread hier nicht kapern.

Viele Grüße
Denis

[Florian]

Hallo Gerhard,

gibt es irgendwelche Neuigkeiten bei Deinen Problemen? Oder hast Du es inzwischen aufgegeben?

Ich kann Dein Problem leider bei mir nach wie vor nicht nachvollziehen. So ist es mir dann auch nicht möglich, den Fehler, soweit denn möglich, zu beheben.

Am meisten helfen würde mir ein Mitschrieb der Buskommunikation während des Programmierens. Falls Du keine andere Möglichkeit hast, ich habe inzwischen folgendes wieder gangbar gemacht: Die Benutzung eines TS-ARM zur Ausgabe der Buskommunikation als Debugging-Ausgaben. Der Selbus USB-Programmer kann dann als Seriell-USB Wandler dienen.

Funktionieren tut das folgendermassen:
- Am besten wäre es, den störrischen Schaltaktor in einem kleinen KNX-Testaufbau zu haben. Mit eigener Stromversorgung und Interface zu ETS. Dann ist möglichst wenig anderer Verkehr auf dem KNX-Bus und dieser komplett getrennt von der eigentlichen Installation.
- Nur für den Versuch ist es wohl auch akzeptabel, wenn das ganze im echten System durchgeführt wird. Allerdings wird über die Logging-Geschichte aus TS-ARM und Programmer der KNX-Bus dann galvanisch mit dem PC verbunden, was eigentlich unerwünscht ist. Der KNX-Bus sollte zwar immer sicher von jeglicher Netzspannung getrennt sein, die weitere Trennung des KNX-Bus von den Schnittstellen wird jedoch als Sicherheitsmaßnahme betrachtet. Wenn ein Notebook ohne Netzanschluss für die Logging-Aktionen verwendet wird, vermeidet man auf alle Fälle einen Massebezug des KNX-Systems. (Massebezug würde die Störfestigkeit des KNX-Bus senken.)
- Ein TS-Arm wird mit dem .hex, was im angehängten .zip enthalten ist, programmiert. Dies kann natürlich gleich mit dem Selfbus USB-Programmer gemacht werden.
- Die Kabelverbindung zwischen Programmer und TS-ARM dient anschließend zur Übertragung der Debugausgaben.
- Zur Anzeige und zum Abspeichern der Ausgaben wird ein Terminal-Programm benötigt, dass DTR und RTS nach Wahl ansteuern kann. HTerm leistet hier gute Dienste
- Die notwendigen Einstellungen sind: 115200 Baud, 8 Datenbit, 1 Stopbit, keine Parity, kein "CTS Flow control", Newline at "CR+LF". Mit "Connect" wird die Schnittstelle verbunden. Bei HTerm weiter unten im Bereich "Input control" müssen DTR und RTS ausgeschaltet sein. Eingeschaltetes DTR zieht die Reset-Leitung der TS-ARM, der Effekt kann einfach beobachtet werden, da nach Ausschalten von DTR die Meldung "Telegram dump enabled" empfangen werden sollte.
- Wird das Gespann aus TS-ARM und USB-Programmer nun mit dem KNX-Bus verbunden, werden alle Telegramme ausgegeben, schon vordekodiert in halbwegs lesbare Texte.
- Bei HTerm kann man empfangene Daten abspeichern, indem man nach dem Datenempfang "Save output" benutzt. Mit "Clear received" kann man den Empfangsbuffer leeren, z.B. damit man nicht immer alles seit Programmstart abspeichert.

Wenn es Dir so gelingt, einen kompletten, fehlerhaften Downloadversuch aufzuzeichnen, würden mir die aufgezeichneten Daten schon deutlich weiterhelfen.

Alternativ könnte mir auch Dein Projekt weiterhelfen. Dann müsstest Du jedoch so viele Geräte aus einer Kopie Deines Projekts herauslöschen, dass ich die mit meiner Lite-Version der ETS öffnen kann. (Beschränkung auf 20 Geräte.). Es ist dann immer noch möglich, dass der Fehler bei mir nicht auftritt, alleine schon weil ich nur USB-KNX-Interfaces hier habe - und Du soweit ich weiss ein IP-Interface benutzt. Aber einen Versuch wäre es alle Male wert.