freebus.org

Hallo,
ich habe FT1.2 auf zwei LPC Controller Platinen im Einsatz: Ein Controller ist direkt mit der seriellen Schnittstelle des PCs verbunden, der andere ist in einen wrt54 Router eingebaut. Beide Schnittstellen funktionieren (mit kleineren Problemchen).

Auf Grund einer Testaktion habe ich auf beiden Controller Platinen den 89LPC922 jeweils durch einen anderen ersetzt, der vorher in einer Freebus Applikation einwandfrei lief. Natürlich habe ich beide LPCs mit dem aktuellen FT1.2 Programm geflasht.

Danach liefen beide Schnittstellen, allerdings meldet sich die FT1.2 Schnittstelle in der ETS3 unter der physikalischen Adresse der Applikation, die vorher mal auf dem LPC lief. Bei der Programmierung einer kommerziellen BCU mit der physikalischen Adresse, die vorher von der Applikation mit dem zweiten LPC verwendet wurde, traten unterschiedliche Fehlermeldungen auf. Unter anderem wurde gemeldet, dass zwei Geräte mit der gleichen Adresse im Programmiermodus sind.

Es sieht für mich so aus, als würde die physikalische Adresse des LPC beim Programmieren des FT1.2 Programms nicht überschrieben oder zurückgesetzt. Wenn der LPC jungfräulich war, ist die Adresse 1.1.1, sonst eben die in der alten Anwendung zuletzt vergebene.
Im wrt wird die physikalische Adresse nicht angezeigt (immer 0.0.0), ist aber im "Hintergrund" scheinbar aktiv bzw. vergeben. Wenn man ein Gerät mit eben dieser unsichtbaren, vergebenen Adresse programmieren will, gibt es Probleme.

Die Einstellungen zum flashen mit Flash Magic habe ich gemäß den Angaben im Dokument "Softwareentwicklung mit LPC" vorgenommen (und noch einmal geprüft).

Wie kann man den "Fehler" beheben?

Viele Grüße
dgra

Hallo dgra,

das Fehlerbild entsprich meinen Problem im letzen Jahr. Geholfen hat folgendes bei mir

Mein Beitrag im letzten Jahr

Zu dem Thema R5 und 2N7000 gibts schon einige Beiträge -> Suche bemühen!

Hier noch ein Nachtrag:
Das Problem mit dem 2N7000 hatte ich auch. Ich habe alle 2N7000A durch 2N7000 ersetzt. Daran kann es also nicht liegen.

Soll der R5 in allen Schaltungen aller Anwendungen durch 33k ersetzt werden oder nur im LPC-Controller mit dem FT1.2 Programm? Wie sieht das mit der 2TE Controllerschaltung aus? Hat jemand anders dazu Erfahrungswerte?

Grüße

dgra

Für den R5 sollten auch 22k funktionieren, der wird bei der 2TE Variante verwendet. Der R5 sollte bei der 4TE immer angepasst werden, egal welche Software/Funktion! Verdrahtung siehe 2TE

Auch wenn 2N7000 drauf steht würde ich dem nicht trauen, dazu gab es mal eine Messreihe die irgendwo im Forum zu finden ist.

Gruß
Martin

Hallo,

habe den R5 durch einen 36K Widerstand gegen Vcc ersetzt und konnte damit tatsächlich eine Verbesserung erzielen. Geräte, die ich vorher nicht programmieren konnte, kann ich jetzt programmieren.
Es sieht so aus, als ob der 4TE Kontroller da eine Schwäche hat.

Vielen Dank für den Tipp und die Hilfe.

Grüße

dgra

Mit einem 4TE Kontroller ohne ersetzten R5 kann ich alle Bus-Komponenten (auch gekaufte) programmieren, mit einem sonst baugleichen 4TE Kontroller kann ich trotz ersetztem R5 einige gekaufte Bus-Komponenten nach wie vor nicht programmieren. Beim Programmieren des Applikationsprogramms kommt es wiederholbar zum Abbruch. Die physikalische Adresse kann ich ohne Fehler und Abbruch programmieren. Ansonsten funktionieren beide 4TE Kontroller (auch mit anderen Applikationen) einwandfrei.
Kann es sein, dass sich die Kontroller auf Grund von Bauteiltoleranzen unterschiedlich verhalten? Ich habe mir die Signale auf dem Oszilloskop angeschaut und kann keine Unterschiede zwischen den Signalformen ausmachen. Der Abbruch findet allerdings auch immer erst gegen Ende der Programmierung statt. Eventuell ist es auch ein Problem beim Empfangen von Signalen.
Hat jemand ähnliche Erfahrungen gemacht? Gibt es eine Idee, was ich noch messen kann, um dem Problem auf die Spur zu kommen?
Viele Grüße
dgra

Um welche Art und Type von Komponenten handelt es sich bei den gekauften Geräten?

Hatte vor kurzen erst viel Ärger mit Schalt-Aktoren von Busch-Jäger und ABB die sich nicht programmieren ließen, obwohl alles Zertfizierte KNX Geräte (USB-Schnittstelle und IP-Schnittstelle) waren. Nach Eröffnung eines Calls zur ETS konnte der Fehler noch einmal nachgestellt werden, danach war er verschwunden.
Was aber immer funktioniert hat war Netzteil und Schnittstelle direkt an den Aktor angeschlossen ohne weitere Geräte am Bus. Da lief die Erst-Programmierung immer sauber durch, war diese geschafft funktionierten die Komponenten auch am Bus.

Hallo,

beim Flashen wird die physik. Adr. normalerweise nicht überschrieben, bleibt also wie vorher.
Diese wird erst über die ETS gesetzt, vorher bleibt die alte erhalten.

Da vor dem flashen aper Seitenweise gelöscht wird, kann es sein, dass bei großen hex-Dateien der Speicherberiech für die physik. Adr. mit gelöscht wird.

Am Besten nach jedem Flashen in der ETS erst die physik. Adr. setzen und dann die App laden.
Dann sollte es tun.

Gruß
Petzi

Hallo,
bei meinen kommerziellen Komponenten handelt es sich um einen Raumtemperaturregler (mit 8 Tasten) von Merten, eine Universal-Tasterschnittstelle von Gira und eine Universal-Tasterschnittstelle von ABB(?). Probleme macht der Raumtemperaturregler von Merten.
Ich konnte wie gesagt, die Erst-Programmierung nur mit einem meiner Freebus-Kontroller durchführen. Bei einem zweiten baugleichen (der sonst einwandfrei funktioniert) war nichts zu holen. Das gleiche gilt auch für Programmierungen auf Grund von Änderungen. Bei meinen Programmierversuchen waren immer alle Buskomponenten am Bus angeschlossen und aktiv.
Wenn dieser eine Freebus-Kontroller kaputt geht, kann ich an der Programmierung des Raumtemperaturreglers nichts mehr ändern. Muss mir wohl doch eine kommerzielle Interface-BCU kaufen.

Grüße
dgra

Hallo Petzi,
das Problem ist, dass beim FT1.2 Programm die physikalische Adresse nicht programmiert werden kann (ich wüsste zumindest nicht wie). Daher sollte beim Laden (=Flashen) des FT1.2 Programms automatisch immer die gleiche physikalische Adresse gesetzt werden.
Bei allen anderen Programmen hast Du natürlich recht. Nach dem Flashen sollte immer zuerst die physikalische Adresse programmiert werden.
Grüße
dgra