Feuerwerk Fernzündanlage

Hallo,

nach einigen threads mit denen ich die Machbarkeit meines Projektes theoretisch geprüft habe, bin ich dazu übergegangen arduino und co den Laufpass zu geben und das ganze mit Tinkerforge zu probieren.

Die ersten Bauteile sind heute bestellt worden.

Features Stufe 1:

Hardware:

- unterstützung Eingangsspannung 12-36V

- Max. Schaltleistung pro Kanal 8A

- Max. Schaltleistung alle Kanäle pro Zündung 8A

- Zündkreis Test mit Angabe der Anzahl Zünder und Leitungslänge.

- Sicherheitsschaltungen

Software:

- Konfigurations Zünderart pro Kanal

- Manuelles auslösen je Kanal

- Serien/parallelschaltung von Zündkanälen

- Pausen zwischen Zündungen

- Test/Zündung/Erfolgreiche Zündungsprüfung

- Drag&Drop der o.g. Funktionen zu einer Zündkette (Baustein A -> Baustein B -> Baustein C... ; mit Baustein A Kanal 1 Zünden, Baustein B Pause 30sec , Baustein C Zünden Kanal 2,3,4)

Features Stufe 2:

- Wlan oder anderes funkmodul zur steuerung aus kurzer Distanz per Tablet o.ä.

Gruß

Jörg

Gestern habe ich das Paket mit folgenden TF Komponenten erhalten:

Master Brick

Power-Step-Down

AnalogIn Bricklet

VoltageCurrent Bricklet

2x IO16 Bricklet

Leider war das AnalogIn Bricklet notwendig, da ja leider der VoltageCurrent Bricklet Polungsabhängig und dazu auch noch mit TF Masse verbunden ist. Damit wird das Messen einer Spannung irgendwo in einer Schaltung verwehrt. Hoffe das hat einen wirklich gut begründeten Sinn, dass die Masse von TF im Messkreis angebunden ist...

Erster Test der Konfiguration mit BrickViewer war erfolgreich. Alles wurde erkannt. Tests der Analog und Current Bricklets mit Werten fehlt aber noch.

Zweiter Test über die "API" mit C# hat soweit auch funktioniert. Ich konnte eine Verbindung herstellen und nach langem suchen der absolut schlechten Doku auch die Bricklets UIDs auslesen.

Leider muss ich aber einiges an Arbeit an die TF API stecken. Diese ist leider weit entfernt von jeglichen Standards (jedenfalls was ich bei C# gesehen habe) und benötigt einiges an Überarbeitung. Leider gehe ich damit weg von den einfachen Aktualisierungsmöglichkeit über TF, aber ich kann es nicht übers Herz bringen, einen so schlechten Quellcode zu nutzen. OO scheint noch nicht bei TF angekommen zu sein. Hier wird noch mit Bits und Bytes gearbeitet, was OK ist für hardwarenahe Programmierung (Firmware etc.) aber nicht für professionelle Programmierung darüber hinaus.

Leider muss ich aber einiges an Arbeit an die TF API stecken. Diese ist leider weit entfernt von jeglichen Standards (jedenfalls was ich bei C# gesehen habe) und benötigt einiges an Überarbeitung. Leider gehe ich damit weg von den einfachen Aktualisierungsmöglichkeit über TF, aber ich kann es nicht übers Herz bringen, einen so schlechten Quellcode zu nutzen. OO scheint noch nicht bei TF angekommen zu sein. Hier wird noch mit Bits und Bytes gearbeitet, was OK ist für hardwarenahe Programmierung (Firmware etc.) aber nicht für professionelle Programmierung darüber hinaus.

Das verstehe ich nicht, warum willst du die API an sich ueberarbeiten. Die funkioniert doch.

Es bleibt doch Dir ueberlassen noch weitere Routinen zwischen C* und den Tinkerforgebindungs zu schreiben. Die Bindings sind dafuer da die Hardware anzusprechen und nicht um fertige Wuensche zu erfuellen.

Ist durch die Bindings irgendwas nicht realisierbar, dann sollte Tinkerforge hier weiterhelfen.

Der Loetkoben

Darf ich fragen an welcher Stelle die API besser dokumentiert hätte sein können? Die Bricklet UIDs hättest du dir übrigens auch einfach über den Brick Viewer holen können .

Und wo musste man zuviel mit Bits und Bytes arbeiten? Wahrscheinlich bei der IO16? Ist eigentlich das einzige Bricklet was du hast welches mit Bitmasken arbeitet. Beim setzen von einzelnen Pins machen Bitmasken einfach immernoch sehr viel Sinn.

Ich würde mich sehr über etwas konstruktivere Kritik freuen. Also der Teil mit "Kritik" war schon da, jetzt noch der Teil mit "konstruktiv"...

Wo war die Doku schlecht? (das war bisher nie ein Mangel für mich)

Dass an manchen Stellen die Bindings nicht optimal sind, weiß ich... mich würde da interessieren wo bei dir der Schuh drückt, da ich gerade bei den C#-Bindings ein wenig zur Qualitätssteigerung beigetragen habe.

Vielleicht noch zum Verständnis: Die meisten API-Funktionen werden bei TF generiert, damit die Vielzahl an Bricklets und Sprachen unterstützt werden kann. Ich finde es aber nciht vollkommen abseits der Objekt-Orientierung was hier passiert, da würde mich deine Kritik am meisten interessieren.

Viele Grüße

Jan

Sehr gut, dass das "Faß" dazu mal auf gemacht wird.

OO ist in den Bindings kaum vorhanden.

Die Doku sagt:

Da C# nicht mehrere Rückgabewerte direkt unterstützt, wird das out Schlüsselwort genutzt, um mehrere Werte aus einer Funktion zurückzugeben.

Bestes Beispiel ist dafür die Methode "GetIdentity". Da könnte man wunderbar mit Objekten arbeiten das beim "GetIdentity" ein Object "DeviceIdentity" mit den jeweiligen Propertys zurückbekommt. Das sollte über all gemacht werden wo das out Schlüsselwort für mehrere rückgabewerte benutzt wird.

Was es beim IO16 Bricklet angenehmer machen würde, wäre eine Abfrage für einen einzelnen Pin. Dann müsste man die Rückgabe nicht mehr selbst zerlegen.

Wie schon einige vorher geschrieben haben, fängt das Fehlen von OO schon bei IPConnection an.

Zum Thema BrickViewer: Ja hier kann ich die UIDs herausfinden. Aber wenn ich eine Software schreibe, dann sollte die auch für andere gelten. Wenn nun jemand seinen eigenen Stack aufbaut und meine Software einsetzt, wird derjenige nur notwendige Konfiguration machen müssen.

Bezüglich konstruktiver Kritik werde ich selbstverständlich meinen Ansatz einer API darstellen. Wohl aber in einem anderen Thread, da hier mehr auf mein Projekt eingegangen wird und welche Schmerzen/Erfolge ich erziele.

Auch habe ich erst angefangen, einen Einblick in die "API" zu bekommen. Aber wenn ich beispielsweise IpConnection.Enumerate aufrufe und im Callback short-Arrays sowie ints für DeviceIdentifier finde und die nicht dokumentiert (woher bekomme ich die Info beim programmieren, welche ID ein BrickMaster hat?) sind, dann kribbelt es mir in den Fingern, direkt die API in Frage zu stellen.

Hierfür gibt es Kommentare im Quellcode! Wenn einer meiner Entwickler zu mir kommt und Quellcode abliefert, der nicht kommentiert ist, kann er zurück gehen und dies nachholen...

Wie gesagt, jetzt nicht aus der Hose springen, konstruktiv wird das noch und zumindest IPConnection ist kaum dokumentiert.

Beispielsweise könnte folgender Ansatz in Betracht gezogen werden, um mal meine ersten Gedanken aufzuzeigen. Das Ganze muss detailiert und umgebaut werden, sobald ich mehr Einblick habe!

1. Grundsatz der OO: Programming against an interface not an implementation:

IStack

- Connect(IConnection con) : boolean // falls es mal eine andere Connection Art gibt

- GetMaster : IBrickMaster

- Bricks : IList<IDevice>  // könnte auch IBrick sein

- Bricklets(IDevice device) : IList<IDevice> // könnte auch IBrick / IBricklet sein

- Disconnect : boolean

IConnection

IIpConnection : IConnection

IDevice

IBrickMaster

IBrickletAnalogIn

abstract Version

HardwareVersion : Version

FirmwareVersion : Version

Enum DeviceIdentifier

usw.

Kein Handling von Bitmasken, ints oder shorts. In Objekten denken.

Quasi mal schauen wir TF aufgebaut wird.

Mal bildet einen TF-Stack.

Jeder Stack muss einen MasterBrick haben.

Es können bis zu ? Bricks ein einem Stack sein.

Ein Brick kann Bricklets verwalten.

Etc. In den vier Sätzen stecken eine Menge Objekte.

Morgen erhalte ich meine später eingesetzte Stromversorgung (12V 7ah Batterie nebst Ladestation, letztere brauche ich für mein Auto daher trifft sich das ganz gut). Mit der Batterie werde ich dann mal erste Tests mit den Current und Analog Bricklets machen.

Jetzt habe ich nebenher die IPConnection umgebaut. Ich erstelle mal einen anderen Thread.

Aber wenn ich beispielsweise IpConnection.Enumerate aufrufe und im Callback short-Arrays sowie ints für DeviceIdentifier finde und die nicht dokumentiert (woher bekomme ich die Info beim programmieren, welche ID ein BrickMaster hat?) sind, dann kribbelt es mir in den Fingern, direkt die API in Frage zu stellen.

Master.DEVICE_IDENTIFIER

Wert: 13

Diese Konstante wird verwendet um einen Master Brick zu identifizieren.

Irgendwie verstehe ich das alles nicht. Vielleicht sollte man anstelle der API mal OO in Frage stellen. 

Der Loetkolben

Dokumentiert ist es schon (irgendwo).

Die Frage ist, ob es gut auffindbar ist (Doku-Problem) und ob es nicht bereits besser benutzbare Sprachkonstrukte gibt, um solche Dinge darzustellen (z.B. enums).

Aber wenn ich beispielsweise IpConnection.Enumerate aufrufe und im Callback short-Arrays sowie ints für DeviceIdentifier finde und die nicht dokumentiert (woher bekomme ich die Info beim programmieren, welche ID ein BrickMaster hat?) sind, dann kribbelt es mir in den Fingern, direkt die API in Frage zu stellen.

http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_Java.html#konstanten

Beispielsweise könnte folgender Ansatz in Betracht gezogen werden, um mal meine ersten Gedanken aufzuzeigen. Das Ganze muss detailiert und umgebaut werden, sobald ich mehr Einblick habe!

 

1. Grundsatz der OO: Programming against an interface not an implementation:

IStack

- Connect(IConnection con) : boolean // falls es mal eine andere Connection Art gibt

- GetMaster : IBrickMaster

- Bricks : IList<IDevice>  // könnte auch IBrick sein

- Bricklets(IDevice device) : IList<IDevice> // könnte auch IBrick / IBricklet sein

- Disconnect : boolean

IConnection

IIpConnection : IConnection

IDevice

IBrickMaster

IBrickletAnalogIn

abstract Version

HardwareVersion : Version

FirmwareVersion : Version

Enum DeviceIdentifier

usw.

 

Kein Handling von Bitmasken, ints oder shorts. In Objekten denken.

Quasi mal schauen wir TF aufgebaut wird.

Mal bildet einen TF-Stack.

Jeder Stack muss einen MasterBrick haben.

Es können bis zu ? Bricks ein einem Stack sein.

Ein Brick kann Bricklets verwalten.

Etc. In den vier Sätzen stecken eine Menge Objekte.

OK, das ist natürlich als "Top to Bottom"-Ansatz einfach nachvollziehbar. Du darfst dabei aber nicht vergessen das wir ein komplexes System von Firmwares, Plugins, Schnitstellen, Hardware, USB/Ethernet/Wi-Fi, usw. haben. Die API für C# ist ja nur ein winziger Teil.

Die APIs für unsere Produkte werden automatisch generiert aus Konfigurationsdateien. Die Config für das Voltage/Current Bricklet sieht z.B. so aus: https://github.com/Tinkerforge/generators/blob/master/configs/bricklet_voltage_current_config.py

Die API des Voltage/Current Bricklet für die ganzen Sprachen muss also aus dieser Datei generiert werden. Viele der Informationen die für deinen Vorschlag benötigt werden sind dort einfach nicht vorhanden.

Grundsätzlich sehen wir es so: Wir wollen einem Programm (welches Bricks/Bricklets nutzt) möglichst wenig Zeilen Code aufzwingen. D.h. ein durchschnittliches Programm nutzt wenige Zeilen Code um Objekte für die IPConnection und die Bricks/Bricklets zu erzeugen und ruft auf diesen Objekten dann eine Reihe von Gettern und Settern auf wenn notwendig. Mehr mischen wir uns nicht ein, alles andere ist dem Nutzer überlassen.

Hallo,

nachdem ich nun länger nicht hier war, mal einen Zwischenstand.

1) Ich habe einiges bezüglich Elektronik aufzuholen/aufzuarbeiten. Daher meine lange Abwesenheit. Nun habe ich endlich meinen Kompromiss zwischen Hauruck-Elektrik und Elektronik gefunden. Dennoch wollte ich TF-Einheiten galvanisch trennen, also hab ich einige Optokoppler verbaut. Vielleicht nicht schön, aber mir war es sicherer.

2) Finales Design ist nun hardseitig:

- Tinkerforge, 12V Batterie, 12V-36V DC-DC-Konverter, Pufferung und galvanische Trennung kommen in einen Koffer. Zusätzlich habe ich in dem Koffer noch 14-Zündkänale vorgesehen.

- Weitere 14-Zündkanäle sind in einem externen Gehäuse über einen Kombi-Sub-D angeschlossen (36V; GND über Hochstromkontakte, 5V + Steuerleitungen und Rückkopplung zur Widerstandsmessung und Spannungsmessungen über AWG24)

- Weitere externe Gehäuse erweiterbar, wenn notwendig.

3) Platinen sind gerade in der Fertigung

4) DC-DC-Wandler ist auch bald da (Hongkong...)

5) WLAN Modul bei TF bestellt und einen Tag später vorhanden! TOP-Leistung!!!

Sobald alles da ist, stelle ich ein paar Fotos ein. Wenn gewünscht, kann ich auch ein paar - unschönere - Zwischenergebnisfotos einstellen.

Softwareseitig bin ich durch ein paar private Hindernisse etwas in Verzug, aber sobald die Hardware steht, kann ich dann ja wenigstens Live-Ergbnisse sehen.

Soweit der Stand an der pyrotechnischen Front...

Beste Grüße

Jörg

Firework.pdf

MainIgnition.pdf