borg

Poste mal genaueres. Wann du wo oder wie die Stack IDs holst sollte vollkommen egal sein. Der Brick Viewer z.B. hält ja auch nicht irgendeine Reihenfolge ein.

Processing Bindings haben wir im Moment nicht direkt. Du könntest die Bricks/Bricklets höchstens direkt über TCP/IP ansprechen: http://www.tinkerforge.com/doc/Software/IPConnection_TCPIP.html#ipcon-tcpip

Mh, the default should be english. Your browser language isn't German, is it ? You can go to PROFIL -> Profil-Einstellungen -> Benutzerkonto -> Bevorzugte Sprache -> English Then you have to put your password in the "Aktuelles Passwort" field (at the bottom) then press "Profil ändern" (bottom right). Sorry for this, we will look into it.

Packstation geht natürlich mit DHL!

D.h., wenn ich an einem betriebsbereiten Stack, wo alle Bricklets "is_new=true" sind, ein weiteres Bricklet anstecke ist diese Bricket auf "is_new=false"? (Was ich aber nicht abfragen kann). Sobald ich ein "Enumarate" aufrufe wird das Bricklet auf "is_new=true" gesetzt und mir dann mit der entsprechenden Stack ID angezeigt?! Anders gesagt: Wenn ich Enumerate aufrufe wird immer "is_new=true" angezeigt, weil gerade durch diesen "Enumerate" Aufruf das TRUE gesetzt wird, oder gibt es einen Fall wo "is_new=false" zurueckgeliefert wird? Nein . Es gibt 3 Fälle in denen du einen Enumerate Callback bekommst: 1. Fall: Du hast Enumerate aufgerufen. Dann bekommst du alle Devices die gerade im System sind mit is_new=true 2. Fall: Du steckst einen neuen Stack per USB an (für die Bricklets gibt es kein Hotplug). Dann bekommst du alle Devices die in dem neuen Stack sind mit is_new=true 3. Fall: Du entfernst die USB Verbindung von einem Stack. Dann bekommst du alle Devices die in dem Stack waren mit is_new=false is_new=true == Device hinzugefügt zum System is_new=false == Device entfernt aus dem System

Naja die korrekte Vorgehensweise wäre ja schon das du dir am Anfang des Programms immer zuerst zu jeder UID die Stack ID holst, da kannst du dann die "Resolve UID to Stack ID" Funktionalität nehmen Von wo wurde es hinzugefuegt, bzw. entfernt? Ich dachte das binden eines Bicklets ist eine Sache innerhalb der HighLevel APIs? Nein, Wenn du einen Stack per USB anschließt werden die neuen Bricks und Bricklets an diesem Stack per Enumerate bekannt gemacht (mit is_new=true) und wenn du den USB Stecker rausziehst wird für die Bricks und Bricklets in dem Stack wieder Enumerate aufgerufen (mit is_new=false). Da es keine Physichen und Logischen Stack IDs gibt gehen ich davon aus, dass ich nicht sehen kann an welchem physischen Stack mein Bricklet haengt. Anders ausgedrueckt: Wenn ich ein Bricklet von einem physischen Stack an den anderen Physischen Stack umstecke andert sich meine Software nicht. Stimmt das? Wenn du dir beim starten des Programms zu jeder UID die dazugehörende Stack ID holst ist das korrekt, ja! Die Stack IDs ändern sich natürlich wenn du im System umsteckst.

Versand per DHL ist jetzt möglich (und sogar billiger)!

Einmal ganz allgemein zu den C# Binding Versionen: Wir bauen die ganzen Bindings unter Linux, die C# Bindings entsprechend mit mono. Wir wollen mono auch unbedingt unterstützten (wird durchaus in embedded Devices in der Robotik benutzt, also sehr interessant für uns). Allerdings ist in mono noch nicht die komplette .NET API implementiert, z.B. die asynchronen Sockets noch nicht. Auf Windows Phone wiederum wurde nicht auf Abwärtskompatibilität geachtet und es gibt z.B. keine blockenden Sockets (daher auch die #ifdefs im Code). Daher muss man da bei C# immer ein bisschen hin und her jonglieren um es auf allen Plattformen zum laufen zu kriegen.

Für gewöhnlich ist die Vorgehensweise das man dem Benutzer eine Funktion wie "AddDevice(UID)" zur Verfügung stellt, an der stelle brauchen wir für die UID eine Stack ID, dafür ist die Funktion. Das Enumerate ist eine Broadcast Funktion die an alle geht und auch alle antworten, das will man ja eigentlich nicht bei jedem AddDevice. wenn is_new "true" ist wurde das Device hinzugefügt, wenn es "false" ist wurde es entfernt. Enumerate muss du nicht aufrufen. Die Idee ist in gewisser weise, dass Enumerate eine Funktion ist die der Benutzer von Bindings aufrufen kann und Resolve UID eine die Intern benutzt wurd. Klar! Dann erstellt der brickd eine passende Routing Tabelle und setzt die IDs um.

Du solltest mit einem Kurzschluss auf einem Brick/Bricklet einen PC nicht töten können, an der Stelle haben wir eine Diode dazwischen (was der Grund ist warum z.B. beim IO16 keine echten 5V mehr ankommen wenn man keinen Step-Down PS benutzt). Wenn ein großer Stack versucht mehr als 500mA zu ziehen (durchaus möglich mit einem halben Dutzend Master und einer Unmenge an angeschlossenen Bricklets), dann wird einfach der Stack nicht mehr funktionieren. Dem PC sollte das nicht schaden.

Der Master Brick hat eine get_chibi_signal_strength() Funktion.

Wir freuen uns hier gerade einen Keks .

Aus diesem Grund laufen tinkerunity.org und tinkerforge.com auf physikalisch unterschiedlichen Servern, da können keine Daten von tinkerforge.com verloren gehen wenn tinkerunity gehackt werden sollte o.ä.

Oh, der Link war natürlich falsch . Wir machen jeden Tag um 12:00 ein Backup, da ist der Wiki Thread vermutlich noch nicht drin und für den Forenaufteilungsthread lohnt sich der Aufwand nicht ihn aus der Datenbank zu fischen. Ist blöd gelaufen, ich hab jetzt ein "Papierkorb Board" angelegt wo alle gelöschten Beiträge hinkommen. Leider ist das in der Defaulteinstellung nicht drin, entsprechend wurden die Beiträge wirklich gelöscht .

Jop, war mir auch schon aufgefallen: http://www.tinkerunity.org/forum/index.php/topic,407.0.html Ich gucke nochmal im Adminbereich ob ich sie wiederherstellen kann, hab eben aber leider auf die schnelle nichts gefunden .

Es sieht so aus als hätte ich den Original Thread zur Forenaufteilung und den Wiki Thread gelöscht (vermutlich die letzten beiden Threads die irgendwie über den Verschiebungsvermerken standen). Der Forenaufteilungsthread hat sich ja erledigt jetzt . Was im Wiki Thread genau stand weiß ich leider nicht, hier ist der Link zum Wiki Eintrag: http://www.tinkerunity.org/wiki/index.php/Code-Kitchen Sorry!

Öh, ihr müsst das "Minute" oben durch "Sekunde" ersetzen. 1000 Nachrichten/Minute wäre ein bisschen wenig .

Wir haben eine einzelne PID zu der 16d0 VID gekauft (eine komplette VID war uns damals zu teuer). Ich nehme an das GrauTec das genauso gemacht hat und das sie die ersten waren die ihre PID zum Maintainer der usb.ids geschickt haben und deswegen als Hersteller da stehen. Edit: Nur einmal zu Erklärung: Von der USB IF ist es schon so gedacht das jeder Hersteller sich eine VID kaufen muss, allerdings gab es zu den Anfangszeiten im Lizenzvertrag keinerlei Anmerkungen dazu ob man PIDs seiner VID weiterverkaufen kann. D.h. wer eine alte VID hat darf einzelne PIDs verkaufen (z.B. hier: http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1). Daher kommt das zustande. Soweit ich weiß sind wir aber kurz davor das die VIDs der USB IF aufgebraucht sind, dann müssen die sich eh was neues einfallen lassen und vermutlich selber einzelne PIDs verkaufen. Spätestens dann ist die Darstellung wie sie in der usb.ids gemacht wird hinfällig .

Wenn du keinen Rechner laufen lassen willst musst du definitiv auf die WLAN Extension warten. Wir haben im Moment kein iOS Gerät hier, deswegen gibt es auch noch kein iOS Support . Soweit ich weiß sollte Objective-C abwärtskompatibel zu C99 sein, die C/C++ Bindings könnten also out of the box funktionieren. Ist aber ungetestet .

Das ist die Spannung und der Strom, die durch den Stack gehen. D.h. die sollten immer 0 sein, es sein denn du nutzt die Step-Down Powersupply (d.h. du speist Spannung über den Stack ein). Damit ist es möglich festzustellen wieviel Strom ein ganzer Stack in Summe zieht oder wie voll eine Batterie ist (anhand des Spannungsabfalls), wenn die Step-Down Powerupply über eine Batterie gespeist wird.

Ah, "Set" gefällt mir. Schreibe ich mir mal auf, ändere ich dann mal bei Gelegenheit.

Oh, das "Save" an der Stelle bedeutet nichts permanentes. Was wäre da ein besserer Begriff? Grundsätzlich ist auf dem EEPROM noch genug Platz um solche Einstellungen zu speichern (wird z.B. beim Distance IR Bricklet mit den Stützpunkten gemacht oder beim Joystick Bricklet mit der Kalibrierung). Allerdings ist es tendenziell gefährlich bei so einem IO Bricklet mit einem anderen Zustand als Input oder Input Pullup zu starten. Ansonsten hat man schnell den alten Zustand von vor 2 Wochen vergessen und einen Kurzschluss gebaut!

Das ist schwierig umzusetzen. Per USB kann ich mit maximal 1000 Nachrichten pro Sekunde rechnen und das System ist entsprechend darauf aufgebaut. Zum Beispiel ruft unser interner Scheduler pro Bricklet Plugin nur 1x pro ms eine Task auf, wir können also auch nur 1x pro ms eine Zustandsänderung haben. Auf den meisten Bricks sind für sowas auch keine PWM oder Timer Counter Hardware Einheiten mehr über. Du musst bedenken das so ein Master Brick ja auch noch mit x Stack Teilnehmern und x Extension Slave Teilnehmern gleichzeitig sprechen können muss. Und die Treiber Bricks (Servo/Stepper/DC). Müssen ihre jeweilige Motoren steuern und Beschleunigungen/Debeschleunigungen etc. Berechnen. Das tut brickd bereits.

Neue Bindings würde ich jetzt auch einfach mal als neues "Produkt" bezeichnen. Hab das oben mal entsprechend geändert. Viel mehr Aufwand machen mehr Bricks/Bricklets allerdings nicht beim erstellen neuer Bindings, die werden ja soweit autogeneriert. Der Mehraufwand ist dann nur in den Beispielen, die kann man natürlich schlecht generieren.

Der Name "GrauTec" stammt aus der usb.ids Datei vom Linux Kernel: http://www.linux-usb.org/usb.ids Das können wir so von außen erstmal nicht beeinflussen. Ich schreibe Stephen J. Gowdy diesbezüglich mal an, aber ich kann nichts versprechen.