borg

So eine Trennung müsste ganz schön viel leisten. Wir haben auf dem Bricklet Stecker einiges liegen: GND, 3.3V, 5V, 4xIO, 1xAD, 1xI2C, 1xSelect D.h. man bräuchte einen DC/DC Wandler für die 5V, einen Step-Down Regler für die 3.3V sowie sechs digitale und einen analogen Optokoppler. Puh... Das kommt halt drauf an was man genau an Bauteilen verwendet, das kann man sich fast beliebig auswählen. Mit größerem Messbereich sinkt aber natürlich die Messgenauigkeit. Da muss man also einen Kompromiss finden.

Die galvanisch getrennten Bricklets heißen bei uns "Industrial ... Bricklet". Die Industrial Digital In, Industrial Digital Out und Industrial Quad Relay Bricklet sind galvanisch getrennt. Ein (galvanisch getrenntes) Industrial Bricklet um Spannungen/Ströme zu messen ist schon länger geplant, wir sind aber noch nicht ganz damit durch. Dazu hätte ich aber eine Frage wo wir das Thema gerade haben. Es gibt zwei Möglichkeiten das zu machen: 1. Die Spannung für die Messseite wird von außen eingespeist 2. Die Spannung für die Messseite wird über den Brick durch einen DC/DC Wandler auf dem Bricklet bereitgestellt. Bei der 2. Lösung muss man keine Spannung einspeisen, dafür kostet sie im Verkauf ca. ~10€ mehr. Was wäre euch da lieber? Eine galvanisch getrennte Spannungsmessung die von 0V bis zur (vom Benutzer eingespeisten) Eingangsspannung misst wäre denke ich die günstigste Variante.

OK, dann melde dich bitte per email mit der Bestellnummer bei info@tinkerforge.com. Wir schicken einen neuen DC Brick raus mit Rückumschlag für den defekten, damit wir uns das angucken können. Entschuldigung für die Probleme!

Kannst du da nochmal Probieren den zweiten Master mit in den Stack zu stecken? Funktioniert dann auch noch alles?

@AuronX: Der Pull Request ist nicht abwärtskompatibel, hast du ja auch selbst geschrieben. Interfaces für die Bricks/Bricklets könnte man generieren, das wäre unproblematisch (halte ich aber nicht für kriegsentscheidend). Aber Abstraktionen von Werteeinheiten (wie JoergK es bei der Version gemacht hat) ist echt schwierig. Wir haben ja z.B. an unterschiedlichen Stellen Spannungen, zum Teil mit unterschiedlichen Einheiten (mV, mv/100). Da wäre es ja schön eine Voltage-Class zu haben die das abstrahiert. Allerdings sind diese Art von Informationen aktuell nicht vorhanden. Ein Verbesserungsvorschlag in dieser Richtung sollte also wenn möglich immer mit einer Änderung in der Config anfangen. Also welche Informationen müssen wir in der Config hinzufügen um soetwas generieren zu können? Wie lassen sich diese Informationen in den anderen Sprachen nutzen? Wenn wir da ein gutes Konzept ausgearbeitet bekommen und das Ergebnis was dabei rauskommt hinreichend gut ist um den Aufwand zu rechtfertigen, könnte ich mir gut vorstellen eine neue Version 3.X für alle Bindings zu machen die nicht abwärtskompatibel ist.

Ah, hatte diesen Thread erst übersehen. Ich hab im Prinzip im anderen Thread schon etwas dazu geschrieben: http://www.tinkerunity.org/forum/index.php/topic,2152.msg14230.html#msg14230

http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_Java.html#konstanten 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.

Du könntest den Counter bei 0 Anfangen lassen und dann das Setzen der Segmente so machen: counter = counter+1 segments = (DIGITS[(counter/1000) % 10], DIGITS[(counter/100) % 10], DIGITS[(counter/10) % 10], DIGITS[counter % 10]) Aber deine Lösung führt ja auch zum Ziel .

Die Hard- und Software ist Open Source, du kannst also Problemlos hergehen und dir ein Design machen welches mehrere Bricks und Bricklets beinhaltet und das produzieren lassen. Wenn du da bei einzelnen Bauteilen Beschaffungsprobleme hast kannst du dich bei uns melden, das kriegen wir dann schon irgendwie hin. So ein "Bausatz aus den Bauteilen" wäre ein riesiger Aufwand. Die ganzen Bauteile haben wir ja als "Tape and Reel" auf Lager, da kann man nicht so ohne weiteres einfach immer ein Bauteil rausnehmen. Wir haben sowas für Firmen übrigens schon gemacht: Ein Design das mehre Bricks/Bricklets auf eine große Leiterplatte und in ein Industrie-Hutschienengehäuse bringt. Das lohnt sich aber finanziell erst ab 250-500 Stück, sonst wird das exorbitant teuer auf Grund der Entwicklungs- sowie Einmalkosten (Bestückungsschablonen usw).

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.

Das VMWare Thema gab es hier schonmal im Forum: http://www.tinkerunity.org/forum/index.php?topic=1972.0

Cool! Was du machen könntest mit den digitalen LEDs ist eine Anzeige die so ähnlich funktioniert wie die im Brick Viewer. D.h. du nutzt die LEDs um ein Farbspektrum von grün auf rot darzustellen (unten grün, oben rot) und machst die Anzahl der LEDs die an sind (von unten nach oben) abhängig von der Lautstärke.

Die LEDs sind leider nicht bei jedem Hersteller gleich angeschlossen. Wir können das aber von außen nicht feststellen, daher kann es da zu einer beliebigen Vertauschung kommen . Also einfach einmal am Anfang durchprobieren was genau R, G und B ist und dann passend nutzen .

Je nachdem welcher Pin krumm war, wird das EEPROM evtl. zuviel Spannung abbekommen haben und dadurch wurden die Daten im ROM korrumpiert. Das könnte ich mir zumindest vorstellen .

Ist vielleicht eines der Beinchen im Bricklet Stecker krumm (beim Master oder bei einem der Bricklets)? So wie hier: http://www.tinkerforge.com/de/doc/FAQ.html#mein-brick-wird-heisz

1000 Nachrichten/Sekunde ist das Maximum was die USB Spezifikation zulässt für die USB Version und USB Class die wir nutzen. Bzgl der SPI Performance können wir erst eine Aussage treffen wenn wir da wirklich einen Treiber für fertig haben. Die SPI Schnittstelle wird auf jeden Fall nicht mit anderen Teilnehmern geteilt (Maus, Tastatur, USB Festplatte etc), dadurch sollte sie in dem Sinne schon zuverlässiger sein vom Durchsatz her.

"Starter Kit: Server Room Monitoring" jetzt mit pulverbeschichteter Aluminium-Frontblende: Blogeintrag

"Starter Kit: Server Room Monitoring" now with powder coated aluminum front panel: Blog entry

Doch, werden sie. Es wird über eine Schablone Lötpaste aufgetragen, dann werden die Bauteile mit einem Bestückungsautomat bestückt und dann wird das Panel durch einen Ofen geschoben. Danach wird die Leiterplatte umgedreht und das ganze passiert nochmal von vorne. Das kann man auch daran erkennen das die unteren Board-to-Board Stecker ein bisschen dunkler sind als die oberen (sind 2x durch den Ofen gegangen). Dabei wird beim zweiten Durchgang das Zinn natürlich wieder flüssig, allerdings ist die Oberflächenspannung von der Lötpaste bei den ganzen kleinen Bauteilen groß genug das trotzdem nichts herunterfällt. Einzige Ausnahme sind bei uns glaube ich die großen Kondensatoren beim Servo Brick. Da kann man auch manchmal an der Seite so rote Flecken sehen neben den Kondensatoren, da wurde dann vorher Kleber auf der Leiterplatte aufgetragen.

Plugins: Dual Button Bricklet 2.0.2 Fix links/rechts Vertauschung Download: Dual Button Bricklet

Plugins: Dual Button Bricklet 2.0.2 Fix left/right button permutation Download: Dual Button Bricklet

IoT mit JavaFX / iOS Apps im App Store Blogeintrag

IoT with JavaFX / iOS Apps in App Store Blog entry

Plugins: Dual Button Bricklet 2.0.1 Fix selected_led_state Bug Download: Dual Button Bricklet

Plugins: Dual Button Bricklet 2.0.1 Fix selected_led_state bug Download: Dual Button Bricklet