OpenKNX-Logikmodul release

[Ing-Dom]

Oder irre ich da?

Sollte so passen.


verbinde mal USB mit Notebook und KNX mit KNX, starte am Notebook die serielle konsole.
dann machst du mal ein r - enter und dann postet du die Ausgabe hier.

Wenn du den prog mode aktivierst wird die led rot?


Dass es an der BCU liegt ist sehr unwahrscheinlich, vor allem wenn es eine voll bestückte BCU ist.

[stoepf]

UART nicht available

Ich hatte mal RX und TX gedreht, das ist ja auch immer ein klassischer Fehler beim Aufbau eine seriellen Verbindung.
Da hatte ich dann ein "TP-UART not found" oder so ähnlich.
Mit richtiger Verkabelung war die Meldung dann weg.

Meine anderen Module haben den NCN direkt auf der Platine.
Ich werde mir eine neue BCU bestellen, kann aber bisschen dauern.

Emailadresse kommt der PN.

Viele Grüße
Stefan

[mumpf]

Ja... In der alten ist aber ein

UART nicht available

oder so was ähnliches. Das wird Stefan schon erkennen, wenn er darauf achtet.

Und wenn du mir deine Mail-Adresse schickst, kann ich dir auch eine Vorabversion der neuen zukommen lassen, die steht sowieso kurz vor dem Release. Die ist deutlicher in den Meldungen, wenn an TP was nicht stimmt.

Gruß, Waldemar

[traxanos]

Der Hinweis kommt aber erst mit der neuen (zukünftrigen) Firmware!

[mumpf]

Noch ne andere BCU zum ausprobieren?
Meldet der denn auf der Konsole direkt nach dem boot, dass KNX da ist?

0d 00:00:03: KNX:                     TP is connected

Oder alternativ:

0d 00:00:54: KNX:                     TP is disconnected

Das wäre schon mal ein Hinweis...

Gruß, Waldemar

[stoepf]

Versuch erstmal ohne USB, nur um auszuschließen, dass es stört. Der PiPico kann ja auch über KNX versorgt werden.

Hab es auch mal ohne USB probiert, aber auch keine Meldung in der ETS.

NanoBCU keinen Wackler hat...

Das kann ich leider nicht ausschließen. Werde mir wohl eine neue BCU bestellen, den PiPico hab ich schon getauscht.

oder auch mal in einem Minimalsystem

Hab ich leider nicht.

Danke euch

[willisurf]

oder auch mal in einem Minimalsystem, d.h. nur SV und Schnittstelle, falls Du so etwas verfügbar hast oder leihen kannst.

[mumpf]

Versuch erstmal ohne USB, nur um auszuschließen, dass es stört. Der PiPico kann ja auch über KNX versorgt werden.

Sonst fällt mir nichts ein, wenn Du sicher bist, dass die KNX-Leitung wirklich verbunden ist und die NanoBCU keinen Wackler hat...

Gruß, Waldemar

[stoepf]

Ich hab heute versucht eine PiPico über NanoBCU und BCU-Breadboard-Adapter mit dem Logikmodul in Betrieb zu nehmen.
Das Programmieren des PiPico über USB hat problemlos funktioniert, ich sehe auch die Ausgaben auf der Console.
Ich kann auch in dern Programmiermode schaltem, allerdings lässt sich die Adresse nicht programmieren.
Aktuell hab ich noch keinen ADUM eingebaut, weil ich auf der USB-Seite das Notebook im Akkubetrieb einsetze und die glavanische Trennung nach meinem Verständnis dann nicht notwenig ist. Oder irre ich da?

Fehlermeldung in der Console sobald ich die ETS nach Geräten im Programmiermodus suchen lasse:

L_data_con not received within expected time

Zu der Fehlermeldung hab ich Hinweise gefunden, dass wegen dem KNXD evtl. 2 Geräte gleichzeitig im Programmiermodus erscheinen. Abschalten vom KNXD hat aber leider nichts gebracht.
Ein Sensormodul funktioniert ohne Problem


Irgendwelche Ideen?

Viele Grüße
Stefan

[mumpf]

Wie gesagt, das "was" ist klar.

Ich weiß auch inzwischen das "wie": Es wird im nächsten Release eine Endlosschleifen-Erkennung geben, ich konnte das so lokal bauen, dass es nur dezidierte Kanäle deaktiviert werden und der Rest des Logikmoduls unbeeinflusst bleibt.

Rahmendaten: Es müssen mehr als 50 Aufrufe eines Kanals in einer Sekunde erfolgen, dann wird er deaktiviert. Es wird nicht aktiv gemeldet. Man kann den Zustand über das Diagnoseobjekt abfragen und zurücksetzen. Da die Endlosschleifen-Erkennung eine Fehlkonfiguration behebt, ist das primäre Ziel, dass das Gerät programmierbar bleibt. Danach kann man es neu programmieren und weitere Versuche machen.

Gruß, Waldemar

[TabSel]

…Ich bin schon seit längeren am überlegen, was ich gegen so was machen kann, aber mir ist noch keine gute Idee eingefallen, die nicht potentiell Logiken kaputt macht…

Idee: durchschnittliche Anzahl Eingangsimpulse/Sekunde über ein Zeitfenster x Sekunden errechnen und bei Überschreiten einer Rate y/Sekunden das Processing unterbinden und an KO senden (b01) bis ein Resetimpuls am KO (b00) empfangen wird. Ein/Ausschaltbar per ETS-Parameter.

[mumpf]

Eine Idee zu der Erkennung von solchen Endlosschleifen hätte ich noch.
Da ich beruflich aus der Leitsystem-Ecke komme, kenne ich ein ähnliches Problem.
Wenn ein Messfühler "spinnt", kommt es zu einem Schwall von unsinnigen Eingangswerten auf den Eingangsschnittstellen. (IEC-104 kann das sogar übertragen.)
Man kann das so abfangen, dass man die maximal Anzahl an Änderungen (auf Eingangsseite) pro Zeiteinheit limitiert.

Danke für die Info, aber mir ist das von Dir beschriebene verfahren natürlich klar und bekannt. Meine Aussage bezog sich darauf, dass ich eine Stelle im Logikmodul finden muss, die die Funktionalität der anderen Kanäle nicht beeinflusst und auch Wege bereitstellen muss, um solche deaktivierten Kanäle anzuzeigen und erneut aktivieren zu lassen.
Das Problem ist also nicht das "was man machen muss" sondern das "wie".

Gruß, Waldemar

[mumpf]

Hi knxPaul,

der "Verursacher" ist sicherlich eine Kombi aus einem unerfahrenen User und der Verwendung von ChatGPT unter Umgehung jeglicher dokumentation. Das erkenne ich alleine daran, dass Inverter-Logikkanäle verwendet wurden, ob wohl man bei mir bei jedem Eingang einstellen kann, ob er invertiert wird - mit einem Click statt mit 20.

Du hast es richtig erkannt, mein Logikmodul implementiert eine ereignisgesteuerte Logik. Es bietet aber auch Möglichkeiten, die Ereignisse zu beeinflussen. Indem man z.B. nur bei Wertänderung senden lässt oder einen Ausgangsfilter setzt, der gleiche Werte ausfiltert. Beides würde wahrscheinlich das obige Problem lösen.

Ich habe aber die Lösung schon im Ausgangs-Thread beschrieben (Ich glaube, Dein Link ist falsch, es ist der hier: https://knx-user-forum.de/forum/%C3%...33#post1956733), es müssen einfach nur 2 Flags geändert werden.

Der Originalansatz war:

1. AUS und AUS ergibt AUS
2. EIN und EIN ergibt EIN

Alle anderen Kombinationen sollen nichts tun.
Genau so würde ich es parametrieren:

1. Kanal: A ODER B, nur AUS senden
2. Kanal: A UND B, nur EIN senden

Jetzt hat man 2 Ausgänge, die auf die selbe GA senden und natürlich beim Read falsche Werte liefern, weil immer beide antworten. Die Lösung ist dann aber nicht eine irre komplizierte Logik zu erfinden, sondern einfach die Eigenschaften von KNX zu nutzen:
Der eine Ausgang bekommt die Flags KLSÜ, der andere nur KÜ. Der mit KLSÜ hat jetzt immer den richtigen Zustand und antwortet als einziger auf das Lesetelegramm.

Gruß, Waldemar

[knxPaul]

eine Schleife (Ausgang geht auf Eingang ...

ich muss mich als Quasi Verursacher outen: Genau die Schleife ist wohl passiert.
Die Aufgabe ist eine Logik zu erstellen, die nicht einfach kombinatorisch die Eingänge verknüpft, sondern ein Gedächtnis hat. Wie unten verlinkt sollen zwei unterschiedliche Kombinatoriken abgearbeitet werden in Abhängig vom aktuellen Ausgang der Logik.
In einem getakteten System kann man den Ausgang auf einen Eingang zurückführen, alle Zwischenzustände des Logikausgangs spielen keine Rolle; erst beim nächsten Takt wird der alte Zustand in der Logik als Eingang wieder ausgewertet.

• Im ereignisgesteuerten KNX gibt es erst mal kein getaktetes System.

Das erklärt das nicht mehr nachvollziehbare Verhalten, das in Ventilatordrehzahl über Dimmaktor beschrieben wird. Die Zwischenzustände beschäftigen die Kombinatorik durch die direkte Rückkopplung.

Nun braucht es einen sehr guten Kenner des Logikmoduls, der bei der Lösung helfen kann.

[willisurf]

Also habe ich "blauäugig" die Frage mal an ChatGPT gestellt:

Tatsächlich -wie Du jetzt sicher auch weißt- keine gute Idee. Aber Danke, das Du das hier klargestellt hast.