freebus.org

Hallo allesamt,

ich lese hier schon seit gut einem Jahr fleißig mit. Jetzt ist es an der Zeit, auch mal ein kurzes Feedback über die aufgebaute Hardware und die verwendete Software zu geben.

1. Schaltaktoren.
Ich habe vor einem Jahr 6 Schaltaktoren mit dem LPC 3.43 Board aufgebaut. die haben auf dem Tisch allesamt sofort funktioniert. Im Schaltschrank fielen dann immer mal wieder welche aus. Haben einfach nicht mehr reagiert. Darauf hin hab ich einfach die Quarze rausgemacht und mit der calibrate.hex und der neuen Firmware aus dem git funktionieren sie seither problemlos.

Was mir aber aufgefallen ist, einige der LPC sind aus unerklärlichen Gründen drauf gegangen. Teilweise waren einfach I/O Pins kaputt. Der LPC wollte schalten, konnte aber nicht. Die Rückmeldung wurde brav über den Bus geschickt, aber es passierte einfach nix. Neuer LPC und schon war das Problem behoben.

4 Aktoren habe ich nun mal probehalber mit dem Atmel RF Board ausgestattet. Funktionieren soweit problemlos.

2. Rolloaktoren

Gleiches wie für die Schaltaktoren mit LPC gilt auch für die Rolloaktoren. auf einmal ist einer nach dem anderen ausgefallen. Liegt wohl auch an den Quarzen... Nur hab ich leider da bisher keine kalibrierbare firmware gefunden. Das ist wirklich schade. Denn aktuell besteht auch nicht die Möglichkeit, einfach auf das Atmel Controllerboard umzusteigen.

3. Heizungsaktoren

Ich habe 2 Heizungsaktoren aufgebaut und mit dem LPC-Board versehen (ohne Quarz und mit calibrate.hex). Irgendwann habe ich mich gewundert, warum in 2 Räumen ständig zu warm war. Also mal einen Aktor geprüft. Die Hälfte der verwendeten 240R Widerstände waren verkokelt und schwarz. Also alle Widerstände und die SSR getauscht. Fehler noch immer da. LPC getauscht. Fehler weg. Mal wieder einer, bei dem 2 I/O durch waren.

kleiner Nachtrag: Die SSR Aktoren steuern bei mir Uponor Thermoantriebe TA 230 (230V max. 0,2A <3W Wirkleistung an)

4. Binäreingänge

Ich habe 3 Stück 24Volt Binäreingänge im Betrieb. Die arbeiten mit dem LPC-Board problemlos am Tisch. Im Schaltschrank sind sie noch nicht. Hier werde ich zur gegebenen Zeit das Feedback ergänzen.

5. 4-Kanal Temp
Ich habe zwei Boards aufgebaut. Bekomme aber keines zum laufen. Controllerboard ist ok, aber es klappt einfach nicht. Einer von beiden misst nur Müll, der andere gar nichts. Ich habe bereits alles Bauteile durchgetauscht. Aber den Fehler habe ich noch nicht gefunden. Ich werde jetzt mal alles durchmessen. Also da kommt das Feedback auch später.

Nachtrag: Habe jetzt einen der beiden Boards mal an den Bus gehängt. Mir fehlen leider die Infos, wie es in der ETS parametrisiert werden muss (0-5V, etc?). Auf jeden Fall gibt das Ding immer den Wert -0,08°C aus. Der Wert verändert sich auch bei steigender Temperatur nicht. Hatte jemand evtl. das gleiche Problem?

6. Kombisensor
Mein Problemkind. Dort wird die stehende Induktivität sehr warm. Ist über ETS nicht zu erreichen. Hier hilft nur durchmessen. Hat evtl. jemand schon mal so ein Problem gehabt?


Controller allgemein

Mir kommt es so vor, dass die LPC zu empfindlich sind. Ich habe schon einige wegwerfen müssen, die einfach im Betrieb kaputt gegangen sind. Da finde ich persönlich die Atmels besser. Zukünftig werde ich alle LPC Boards gegen die Atmel tauschen. Allein der Bootloader im Atmel ist das schon wert. Endlich nicht mehr den Schaltschrank zerlegen um nen Controller neu zu flashen! Ist meine persönliche Meinung.

Allgemeines

Das Flashen der Software ist nie ein Problem gewesen. Das Finden der richtigen Version und eienr Doku zur Software leider schon. Da wäre eine konforme Benennung der Dateien wirklich sinnvoll.

Der Dateiname "rollo_AS1.hex" sagt leider gar nix aus. Worin besteht nun der Unterschied zur "rollo_AS2.hex"? Allein die Version im Dateinamen würde schon viel helfen. Und wenns ganz toll werden soll noch eine Textdatei mit einem Zweizeiler, welche Version nun für was ist.

Bei den Atmel Firmware-Dateien ist es noch etwas unübersichtlicher. Es gibt selten eine fertige hex. Ist z.B. beim Bootloader aktuell der Fall.
Dabei wäre das keine großer Aufwand, die gleich mit ins git zu stellen, wenn eine neue Version fertig ist. Man hat die für eigene Tests doch sowieso schon kompiliert.

Ich verwende selbst leider kein AVR Studio (nehme normalerweise PIC's her)

Ich habe es mir nun installiert, aber ich bekomme zig Fehlermeldungen beim Compilieren, weil irgendwelche Dateien nicht da sind, wo sie das AVR Studio gerne hätte (liegt wohl am git?). Ich denke, das passiert anderen Unerfahrenen Fast-DAU's auch. Allein von dem Aspekt her wäre eine aktuelle hex schon echt goldwert!

Hardware

Das war für mich die größte Umstellung überhaupt. Wieder zurück zu bedrahteten Bauteilen. Was da Zeit fürs löten drauf gegangen ist . aber ich bastel gerne, daher nicht weiter schlimm.
Die Platinen aus dem Shop sind qualitiativ durchaus als gut zu bezeichnen. Teilweise könnte man die Pads größer machen, oder z.B. den Pin 1 einer Stiftleiste mit einem eckigen Pad ausstatten. Das ist aber reine Kosmetik.

Passgenauigkeit: Zuerst habe ich geflucht, was das Zeug hielt, denn keine meiner zig Paltinen hat in das Hutschienengehäuse gepasst. Ich hab dann alle passend gemacht... naja da konnte nur Reichelt was dafür. Warum müssen die auch den Hersteller wechseln!


Fazit


Alles in allem muss ich sagen, ein tolles Projekt, das hier entstanden ist. Auch wenn es an manchen Ecken sehr unübersichtlich war/ist. Ich werde mich hier sehr gerne künftig auch aktiv beteiligen.

Von meiner Seite aber auf jeden Fall vielen Dank an die fleißigen Entwickler hier!

Max

Hallo Max,

ein sehr guter und netter Bericht.

Meiner Meinung nach sollte dringend mal gefortscht werden, was bei den Heizungsaktoren passiert ist.
Denn da ist ja nicht wirklich viel drauf und "durchschmoren" hört sich für mich immer nicht gut an.
Ich weiß nicht wie viel der Heizungsaktoren schon wirklich im Echtbetrieb sind. Haben hier noch andere Benutzer Probleme ?
Bzw. was kann das mit dem Durchschmoren sein ? Kann das vom LPC Board kommen, oder einem Fehler auf dem Heizungs-Appli-Board ?

Das mit der Software ist leider so.
Ich sag mal das ich nicht neu bei Freebus bin, aber man weiß nie was nun und welche die richtige Software ist. Da hilft auch die REP nichts.
Auch fehlt ein Hinweis ob ein Watchdog drin ist oder nicht, ob man klaibrieren kann oder nicht usw.

Früher war das auf der Homepage um Längen besser.

Lieben Gruß,

pukelmuckel

Danke Max für Deine Zusammenfassung, ich muß das bei Gelegeheit auch mal machen.

Ja, ein fundamentales Problem: Meiner Meinung nach muß jede SW eine Versionsnummer tragen, die sollte idealerweise auch auslesbar sein, und es muß ein ChangeLog enthalten sein.

Erstmal ein dickes Lob für einen derart sachlichen und differenzierten Erfahrungsbericht! Miit Berichten a la 'alles toll' oder 'alles mist' kann man in der Regel wenig anfangen.

Auf der damaligen Homepage gab es Softwareseiten, auf denen die Funktionen der Soft beschrieben waren und mit entsprechenden Links. Leider sind die verschwunden. Ich hoffe, die kommen wieder ans Tageslicht.

Ich habe mir angewöhnt die changelogs im Quellcode einzufügen. Wenn man sich im git zB. die kombi.c anschaut, findet man am Anfang gleich die Historie mit Versionsnummern. Da der Compiler leider immer nur den selben Namen für die .hex vergibt, ist die Versionsnummer nur händisch im Dateinamen machbar. Da siegt leider zu oft die Faulheit.

Gruß
kubi

vielen Dank für das ausführliche Feedback. Wir sind alle sehr bemüht alles was wir an Feedback bekommen wieder einfliessen zu lassen.

Was den Kommentar angeht, auf der alten Seite war es übersichtlicher was die Software kann:
Klick z.B. auf das 8-out Relais Modul dann klickst du unten bei Firmware die den Firmware Beschreibung, dann kommt die Liste wie auf der alten HP, mit einer Auflistung was die alles kann.

Die richtige hex Datei hängt an jedem Modul dran, mit einer Beschreibung, genau nach was gefragt wird, verstehe die Frage nicht.

Neue stabile Versionen kommen auf die HP, das git ist ein aktueller Arbeitstand, der nicht funktionieren muss. Also immer die Dateien von der HP nehmen und nur nach explizierter Anweisung aus dem git.

Das es mit dem Atmel Studio zum kompilieren nicht geht, ist ein Problem vom Atmel Studio, da es absolute Pfade in der Projektdatei speichert und jeder seine Datei wo anders liegen hat. Die Makefiles welche im AVR Projekt existieren arbeiten ohne diese Probleme.

Changelogs sind im git vorhanden, musst nur auf die History klicken von einer Datei oder einem Verzeichnis.

Hoffe das klärt ein paar Fragen, falls denoch etwas unklar sein sollte oder wenn jemand Verbesserungsvorschläge hat, bin ich gerne bereit diese umzusetzen.

_________________
Gruß
Matthias

Teilweise stimmt das schon. Beim AVR Board ist das z.B. aber wieder was anderes. Dort gibt es zwar Hinweise auf den Bootloader, aber eine hex-Datei gibt es nicht und auch eine Beschreibung finde ich dort nicht, sondern nur im git.

Die Trennung zwischen Module und Platinen ist ein wenig unglücklich - finde zumindest ich. Unter "Platinen" findet man zwar alle Infos über den Hardware-Aufbau, aber nur unter "Module" komme ich dann auch an die entsprechende Software. Da wäre eine Vereinfachung gar nicht so schlecht.

Das könnte man doch wunderbar zusammenfassen.


Zum Thema Software.

Beim 8out steht zum Beispiel in der Firmware Beschreibung nicht mit drin, ob diese Version nun die zum selbst kalibrieren ist oder nicht. Hier muss man einfach probieren
Außerdem kann man anhand der Bezeichnung nie wissen, wie "neu" die Software ist.

Die Changelogs würden sich aber auch bei den Releaseversionen auf der HP sehr gut machen (evtl. einfach zusammen mit dem hex file zippen). Denn dann wüsste jeder sofort, ob Bedarf besteht, die Controller neu zu flashen. So muss man immer im git UND auf der Hompage nachsehen.

Nun noch ein kleiner Nachtrag zum Feedback:

4-fach Temp:
Gestern habe ich mich noch mal ein wenig mit den beiden 4-fach Temp auseinander gesetzt. Mit dem Ergebnis, dass einer nun läuft. Beim anderen habe ich den Fehler schon eingrenzen können: Die DS18B20 bekommen keine Versorgungsspannung. Es liegen zwar 5V am Ausgang des Spannungsreglers an, aber an der Klemme kommen nur noch 0,98V an und das ist dem Sensor einfach zu wenig. Nachdem ja nicht so viel da dran ist, sollte ich den Fehler eigentlich heute relativ zügig finden.

Ich kann aber jetzt schon sagen, dass der eine Temperatursensor aktuell am Tisch so funktioniert, wie er soll. Software ist die aus dem GIT (aber Release Ordner). In den Schaltschrank kommt er heute noch.

Mit den Informationen auf der HP kann man auch schnell die richtige Parametrisierung finden und entsprechend einstellen. Das findet man so im git nicht. Aber auch hier. Diese Informationen lassen sich eigentlich sehr unkompliziert mit zur Software packen.

Viele Grüße

Max

mit calibrate.hex kannst du kalibrieren wenn sich der controller mit einem 'U' meldet.
Programmer ran, hterm.exe starten, 600bd8,1,N -connect-
Dann die beiden handshake einschalten.
ergebnis 'U'
schicke ihm ohne cr lf ein 'v' und er gibt die die Version zurück.
schick im ein 't' für type und er schickt dir den Type zurück. (compilerschalter)

Bisher hab ich in den letzten Jahren noch nie was von defekten IO's gehört.
Elektromagnetisch muss ja bei dir die Hölle sein.

_________________
LG
Andreas

Hallo,
Danke für die Info. Ist aber auch ganz schön umständlich, jedesmal gucken zu müssen, ob jetzt die Firmware kalibriert werden kann

leider programmiere ich die LPC nicht mit dem Freebus Programmer. Ich nutze dafür meinen Galep.

Ich werde mir jetzt mal einen ISP Progger bauen. Da gibts was ganz praktisches, was sich sicherlich verwenden lässt und schnell auf einer Lochrasterplatine aufgebaut ist - und ich hab noch eins rum liegen. war mal für ein anderes Projekt. Ist sogar ne LPC-Progger Schaltung dabei (2.Link):

http://www.poscope.com/pousb12
http://www.poscope.com/productattachmen ... load?id=65

Damit werde ich dann mal auf die LPC gehen.

Ich denke nicht, dass es bei mir elektromagnetisch die Hölle ist.
Was mich auch wundert... Es traf immer nur die 8out Versionen. Nix anderes... und auch verkokelte Widerstände in den Heizungsaktoren kommen sicherlich nicht von der "Hölle".

Viele Grüße

Max

das liegt einfach daran, weil wir noch keine Applikation fertig haben, um über den Bootloader das Flash neu zu schreiben. Das geht momentan nur über die Kommandozeile unter Linux.


Danke für den Tip. Ich habe den Punkt Platine aus dem Menu entfernt, damit sollte es klarer sein. Auf die Platine kommt man dann über das Modul.


tja, das muss der Programmierer machen, ich kann hier nur für die AVR Seite sprechen.


siehe Spalte Aktualisierung.


das stimmt schon, aber dann musst du Daten an zwei Stellen pflegen und dsa wird es früher oder später nicht mehr gemacht. Wenn das passiert, weiß keiner mehr, was jetzt stimmt und was nicht, also lieber an einer Stelle (dem Git) und man muss da halt reinschauen.

Hoffe das hilft dir weiter, wenn du noch andere Vorschläge hast, lass es uns bitte wissen.

_________________
Gruß
Matthias

Jetzt hast ein klein wenig zu viel entfernt. Man findet den Link zu einer Controller-Platine jetzt nur noch, wenn man über ein Modul geht.

VG Max

und genauso ist es auch gedacht. Ein Kontroller alleine bringt dir nämlich gar nichts.

_________________
Gruß
Matthias