selfbus.org

Hallo zusammen,

ich bin gerade dabei einige Selfbus Komponenten aufzubauen und scheitere schon am FT1.2 Adapter.

Der Testaufbau ist aktuell wie folgt:
- ABB SV/S30.320.2.1 Spannungsversorgung mit Diagnosefunktion 320 mA
- FT1.2 Adapter (Mit externem Oszillator an XTAL1, ist auch konfiguriert)

Die Hardware scheint mir auf den ersten Blick OK zu sein.
- ich kann mit ETS mit dem eibd kommunizieren
- es werden Daten auf den Bus geschrieben
- an der Eingangsschaltung kommen Busdaten zurück

Ich messe aktuell mit einem Uralt Oszi (kommt aus Zeiten bevor es DSOs gab).
Deshalb kann ich sagen, dass Daten auf den Bus gehen und etwas empfangen wird.
Das KNX Signal sieht ähnlich aus wie hier (https://freebus.org/content/signale).
D.h. die Spannung geht von 30V um ca. 7V runter. Ein Low-Bit ist ca. 33µsec lang.

Leider bkomme ich vom ABB Netzteil immer einen Kommunikationsfehler gemeldet.
Ich vermute mal das bedeutet, dass die Signale nicht ok sind oder fehlt ggf. ein ACK Signal vom Empfänger?
Ich kenne mich mit dem KNX Protokoll nicht aus!

Wenn ich versuche mit ETS Busteilnehmer zu programmieren kommt ebenfalls der Fehler.

Ich hab auch mal die RS232 Hex getestet. Gleiches Fehlerbild. Beim Senden auf den Bus kommt ein Kommunikationsfehler am Netzteil.

Habt Ihr noch Ideen was ich prüfen oder testen kann?

Bin für jede Hilfe dankbar.


Viele Grüße

Hallo nochmal,

ich konnte dieses Problem jetzt lösen. Es war ein Bestückungsfehler im Eingangspfad (shame on me).

Jetzt funktioniert die Kommunikation prinzipiell. D.h. ich bin in der Lage Buskomponenten zu resetten, physikalische Adressen zu programmieren, Geräte zu entladen und Geräteinfos zu lesen.
Damit würde ich vermuten, dass die Kommunikation stabil funktioniert.

Was nicht funktioniert ist das Programmieren der Applikation.
Bei der ABB Spannungsversorgung ist scheinbar die Firmware so zerschossen, dass ETS die komplette Applikation neu schreiben möchte. Dabei sehe ich am Bus eine ganze Weile viel Kommunikation, die dann abbricht.
ETS5 meldet dann "Gerät nicht gefunden".

Im Forum gibt es ja schon einige Posts, bei denen es mit dem FT1.2 und Raspi Probleme beim Programmieren der Applikation gibt.

Lässt sich dieses Problem irgendwie eingrenzen?
- Performance Probleme des LPC922 (wäre das mit dem ARM gelöst?)
- Fehlerhafte Konfiguration im ETS
- Adresse des FT1.2 Moduls stimmt nicht (ist aktuell 0.0.0), Geräte sind aber 1.1.x
- Unsaubere Bussignale (Timing, Flankensteilheit)

Ist das FT1.2 Modul generell für ETS geeignet? Benutzt das jemand stabil mit ETS oder nur als IP Gateway?
Gibt es ein alternatives Selfbus Modul um stabil jede Art von Geräten zu programmieren?


Vielen Dank für euer Hilfe

Probleme scheint es bei neueren Geräten zu geben. Ich hatte die ft1.2 sorftware bereits modifiziert.
Sie hat jetzt einen Empfangs und Sendepuffer in beiden Richtungen. Was genau aus dem Ruder läuft beim Applikationsprogrammieren kann ich nicht sagen. Freebusgeräte und BCU1 Geräte funktionieren ohne Probleme. Mit der neuen Version auch ein Heizungsaktor von einem Hersteller, der sich vorher nicht programmieren hat lassen. ich Hatte dieses Problem auch schon mit unseren Tastern usw...später gings dann wieder einwandfrei. Ich vermute schon fast dass es auch ein Rechner/ ETS/unsere FT1.2 kombinationsproblem sein könnte.
Weiters kann ICH dir leider nicht helfen.
0.0.0 ist ein Raspiproblem, es ist nicht wirklich eins, soweit ich noch weiss, übertägt die ft1.2 Richtung bus aber die korrekte PA, gibt aber zum Busmonitor die 0.0.0 zurück.
Alternativen gibts sehr wohl bei den renomierten Herstellern.
Ob das an der performance des LPC liegt kann ich nicht sagen. Möglich wäre eine Überschneidung bei der RS zu Bus Wandelung und zurück die durch mehr Rechenleistung korrigiert wird
Zerschossen ist dein Gerät eher nicht. Es ist in den Stopzustand gegangen der nur durch Überschreiben mit Aplikation rückgesetzt werden kann. Genau hier liegt jetzt ein Henne-Ei Problem

Hast Du den knxd probiert? Lt. der notes behebt dieser fork u. a. eine Inkompatibilität des eibd mit der ETS5.

KNXD habe ich noch nicht probiert. Danke für den Hinweis. Allerdings habe ich das gleiche Fehlerbild auch mit ETS4.

Klingt für mich so, als ob es das Sinnvollste wäre mindestens Netzteil/Drossel und Programmiermodul von offiziellen Herstellern zu nutzen. Damit sollte man hoffentlich jeden Busteilnehmer (sowohl offiziell als auch Selfbus) programmieren können. Und alles an Aktoren und Sensoren kann man sich selbst basteln.

Dann wäre nur noch die Frage, ob man einen USB-KNX-Gateway oder einen IP-KNX-Gateway kauft. Die USB-Varianten sind doch meist günstiger. Sofern das FT1.2 Modul für Nicht-ETS-Zwecke stabil funktioniert wäre das auch ein Weg.

Erst mal: ich denke nicht, dass das Applikationsprogramm zerschossen wurde. Bei meiner ABB Dali-Schnittstelle muss auch zwingend bei jeder Änderung die ganze Applikation neu programmiert werden.

oldcoolman hat geschrieben:Ich vermute schon fast dass es auch ein Rechner/ ETS/unsere FT1.2 kombinationsproblem sein könnte.

Das möchte ich ausschließen. Bei mir ging zur ABB-Applikationsprogrammierung weder ETS4 noch ETS5. Ebenso habe ich den FT1.2-Adapter an einen leistungsstarken Rechner angeschlossen.

Ferner habe ich eh knxd benutzt (und dann auch eibd). Beide funktionieren einwandfrei, wie Tests darüber auf eine IP-Schnittstelle zeigten.

Ich habe jetzt (nachdem eine käuflich angebotene Alternative nicht vernünftig zu bekommen war) einen günstigen Siemens Busankoppler 5WG1117-2AB12 (aka TP-UART 2 Evaluation Board) benutzt. Funktioniert einwandfrei.
Als Ergänzung ob USB-Adapter: bisher habe ich den Siemens Busankoppler erst mal ohne galvanische Trennung über einen USB TTL Seriell Adapter (PL2303 oder FT232RL) benutzt gehabt. Sogar das klappt! Adapter für RPi stricke ich gerade erst.

Nach meinem Ermessen liegt es folglich ausschließlich am FT1.2-Adapter.

Als Nebenbemerkung: durch das Eingangspost bin ich erst drauf gekommen, dass es eine strommessende Spannungsversorgung gibt. Ich hatte gedacht ich hätte mit meinem Strombegrenzungs-Eigenbau mit galvanisch getrenntem seriellen Anschluss, der die Buslast ausgibt, was Neues geschaffen