borg

Wir hatten festgelegt das es standalone auf Linux und Windows sowie mit Apache funktionieren sollte. pcntl_fork funktioniert nicht auf Windows oder mit Apache und andere Lösungen funktionieren nur mit Windows und unter Apache sieht man ganz alt aus. Daher haben wir uns für die Lösung ohne Threads entschieden. Mal davon abgesehen: Wenn ich einen zweiten Prozess hab (wie einen System_Daemon oder mit pcntl_fork) muss man immernoch pollen um die Daten die beim geforkten Prozess aufgelaufen sind abzuholen! Dadurch würde man nicht viel gewinnen.

Das muss einmal pro IP Connection passieren. Das hatte ich doch glatt in der Zwischenzeit vergessen, mir ist erst nach dem Thread hier wieder eingefallen was da Sache ist . Werden wir gleich morgen früh mit in die Dokumentation aufnehmen. Was da passiert ist folgendes: der Brick Daemon müsste rein theoretisch zu jeder Socket Verbindung Callbacks von jedem auch nur irgendwie angeschlossenen Brick/Bricklet schicken (da er grundsätzlich erstmal nicht weiß welche Socket Verbindung sich für welches Brick/Bricklet interessiert). Um das zu verhindern guckt er sich die Pakete an und schickt Callbacks nur dann raus wenn eine Socket Verbindung zu dem Brick/Bricklet schon einmal eine Stack ID abgefragt hat (das ist bei den Bindings natürlich immer der Fall). Wenn man direkt TCP/IP verwendet kann das natürlich auf einmal zu einem Fallstrick werden. Also: Wenn ein Brick/Bricklet verwendet werden soll, immer vorher die Stack ID zu der UID holen!

Zweiteres meinte ich mit gewinkelten Pfostenstecker. Gibt es denn Knöpfe die man da direkt draufstecken kann oder muss man da auch löten? Würden dann nicht auch Lötpunkte reichen?

An und für sich eine gute Idee, würden dir da nicht auch einfach Pads reichen wo man was anlöten kann? Die Pfostenstecker müssten gewinkelt sein und vorne rausgucken (wegen der Höhe), das ist für 99% der Leute die ein LCD Bricklet benutzen wollen blöd. Bzgl. kosten: Relevante Kosten entstehen da durch die zusätzliche THT Bestückung, der Preis für die Stiftleiste ist vernachlässigbar.

Naja, die Versandkosten fallen an und müssen irgendwie bezahlt werden, bringt ja nichts . Als wir mit der Post verschickt haben, konnten wir die kleineren Bestellungen mit Großbriefen statt Maxibriefen verschicken und an der Stelle wieder Geld reinbekommen. Das geht jetzt mit DHL nicht mehr. Da die 10% Rabattaktionen so gut angekommen sind haben wir uns überlegt lieber regelmäßiger Rabattaktionen zu machen als die Versandkosten zu sponsern. Im Endeffekt zahlt ihr die Versandkosten sowieso, im Zweifelsfall halt über höhere Produktpreise .

Das bedeutet mit aller höchster Wahrscheinlichkeit dass der Widerstand über den wir den Strom messen nicht richtig angelötet ist . Wenn du die Strommessung benötigst meld dich bei info@tinkerforge.com mit der Bestellnummer, den Master Brick tauschen wir dann aus. Entschuldigung dafür!

Doesn't it register with your computer at all? If the Server Brick is in the bootloader it should at least be shown as some atmel device or something. You can find a description on how to flash a new firmware on Bricks here: http://www.tinkerforge.com/doc/Software/Firmwares_And_Plugins.html#flash-firmware-on-a-brick

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 .