AuronX

Du kannst den Stack enumerieren. Die IPConnection hat einen Enumerate-Callback, siehe auch hier: http://www.tinkerforge.com/doc/Software/IPConnection_Java.html#ipcon-java Den bool isNew kannst du auch als isConnected oder so lesen. Das heißt der Callback wird ja immer gerufen, wenn etwas angesteckt/abgezogen wird oder wenn du per Hand enumerieren lässt. Beim abziehen ist der Wert falsch, beim Enumerieren per Hand oder beim Anstecken ists true.

Mir fällt auf den ersten Blick nur auf, dass du im set_position Werte außerhalb des Bereichs von set_degree übergibst (-18k bis +18k statt -9k bis +9k). Aber das sollte dein Servo-Brick nicht killen...

Eigentlich geht das. Es gibt fertige Links, falls du nur den Source verteilen willst oder du kannst auch kompilierte Pakete hochladen, also etwa eine zip-datei o.ä.

Deja vu? Ich meine mich zu erinnern vor ein paar Tagen gelesen zu haben, dass sie "morgen" (also einen Tag nach "vor ein paar Tagen") wieder da sein sollten...

Ist das ein Unterschied zu den C#-Bindings oder habe ich das falsch im Kopf? Ich würde denken in den C#-Bindings geht der Callback-Thread sofort fort, kann mich aber auch täuschen.

@doertom: Vielleicht schiebst du diese Frage lieber in eigenen Thread, sonst geht es hier mit Python und C# durcheinander.

Kurzer Hinweis, ind er Doku unter: http://www.tinkerforge.com/doc/Downloads.html#brick-firmwares-and-bricklet-plugins Steht noch, dass man die Bricks mittels SAM-BA flashen kann, ich vermute das sollte auch durch Brickv ersetzt werden

Ich glaube das soll noch im Rahmen der on-device-API dokumentiert werden. Ich würde bisher auch nur die existierenden Plugins anschauen um das rauszubekommen ^^

Ich denke den internen Zustand auf null zu stellen ist das einzig sinnvolle. Du kannst keine guten Annahmen über die reale Geschwindigkeit treffen, also ist es am Besten anzunehmen, dass der Motor danach steht (auch wenn das durch Leerlauf-Rollen falsch sein könnte). Null ist zumindest die wahrscheinlichste Annahme UND am wenigsten fehleranfällig.

Disclaimer: Ich habe noch nie ein Plugin geschrieben und habe nur Forenwissen was das konkret angeht. Ich denke das sollte im Plugin machbar sein, für eine offizielle TF-API muss man natürlich schaun, dass es auch "allgemein" nutzbar ist. Aber mindestens ein eigenes Plugin nur für dich wäre wohl auf jeden Fall möglich. Es passiert ja nicht sehr viel Magie, man muss sich zwei Startwerte für den Counter merken und halt gerade immer einen Counter runterzählen und bei 0 öffnen bzw. schließen. Du bist gerade dabei mich dafür zu motivieren das erste Mal ein eigenes TF-Plugin zu schreiben und das obwohl ich C wie die Pest hasse

Das heißt sozusagen, dass du mindestens zwei Zeiten brauchst, richtig? HIGH ...80 ms (etwas mehr als 75ms ^^)... LOW ...5 min... --> wieder von vorn bzw. für bulb dann villt eher sowas wie HIGH ...60 min... LOW ...1 min... --> wieder von vorn Letzteres ist jetzt frei erfunden um Nachts mehrere Bilder von einem sich bewegenden Sternenhimmel zu machen ^^

Gefällt mir gut, hast du auch schön ausführlich beschrieben. Versteck dich schnell sonst kommt der Fabian und bittet dich es ins Wiki zu stellen Ne Spaß, ist wirklich toll und würde das Wiki sicherlich bereichern. Ich würde auch gerne Bilder sehen wie du es am Ende verbaust, vielleicht kriege ich da noch eine gute Idee mit auf den Weg wie man sowas am geschicktesten versteckt ohne es in Beton zu gießen ^^ (Beton ist auch nicht so gut zur Revision geeignet)

Also ich denke der Raspberry Pi wäre eigentlich DIE Empfehlung für dich. Allerdings ist der halt kaum evrfügbar, wenn du heute interesse bekundest wird es knapp mit August. Auf eBay gibt es auch Angebote, etwas teurer aber dafür heute und nicht morgen. Leider kann ich noch nicht auf eigene Erfahrungen mit dem Pi zurückgreifen.

Ah okay, dein eigener Code liegt grundsätzlich an der falschen Stelle (würde ich sagen). Tatsächlich kannst du zunächst die Program-Klasse so lassen wie sie dir von Visual Studio erzeugt wird. Dein eigener Code sollte besser in die Klasse Form1 wandern (rechtsklick auf Form1 im Solution Explorer und dort "View Code"). (Die Klasse Form1 darfst du auch gerne nach MainWindow o.ä. umbenennen, das ist aber nicht soooo wichtig ^^) Grundlegend sollte das so aussehen: - Instanz-variablen für deine Brick(let)s und die IPConnection - Im Konstruktor der Form (nach InitializeComponents) die Instanzvariablen initialisieren (ipcon = new ... und ipcon.AddDevice(...)) - Beim Schließen der Form kannst du sowas machen wie ipcon.destroy Woher weißt du wann die Form geschlossen wird? Dazu im Solution Explorer die Form Doppelklicken, du solltest jetzt eine Vorschau davon sehen, auf properties gehen (Eigenschaften), dort kannst du dir Events anzeigen lassen, eines davon heißt closing. Dieses Event wird gerufen sobald sich die Form schließt. Ein Doppelklick darauf sollte reichen, damit dir automatisch eine Methode erzeugt wird die beim Schließen gerufen wird. Dort kann jetzt dein "aufräum-code" rein. Grundsätzlich solltest du dir vermutlich auch ein bis zwei Einstiegshilfen in WinForms suchen... etwa die hier (sehr kurz): http://msdn.microsoft.com/en-us/library/360kwx3z(v=vs.90).aspx

Dann hast du eine static class. Von dieser können mit new keine neuen Instanzen angelegt werden. Das heißt alle Variablen und Methoden der Klasse brauchen auch das static-Schlüsselwort. Ich weiß allerdings nicht ob du wirklich eine statische Klasse haben willst. Die Lösung ist es entweder überall static dazuzuschreiben (in dieser Klasse) oder eben es vom class zu entfernen. Aus dem Bauch heraus würde ich sagen versuch es nicht-statisch, ist i.d.R. die richtige Lösung auch wenn statisch "erstmal einfacher (und hauptsache es läuft)" aussieht. Poste gerne Code-Ausschnitte und sage was du wissen willst. Wir können nur kurz schreiben warum es nicht geht, aber ich kann mir auch Zeit nehmen und grundsätzliche Hinweise zum Code schreiben. Ist aber einfacher wenn man eine "Diskussionsgrundlage" hat

Die idee beim embedded-board war diese: Auf dem board läuft direkt der brickd und das board ist z.B. per USB mit dem Stack verbunden. Jetzt kannst du existierende Technologie nutzen um das Board in dein normales Netzwerk zu integrieren, beispielsweise durch einen WLAN-Stick. Dann hätte deine Kamera (genauer das board) eine IP, die du als Host z.B. im brickv angeben kannst. Theoretisch könntest du die Kommunikation durch die Luft auch durch dein Steuerprogramm machen das lokal auf dem embedded-gerät läuft, kommt auf deinen Anwendungsfall an. Da wäre es dann auch möglich, dass du per UMTS von der Kamera aus die Verbindung zu einem "Master-PC" aufbaust. @macdiverone/TF: Ich lese ja hier nur mit und abwechselnd denke ich "da hat x aber verdammt recht" ^^ TF verstehe ich, weil sie nur gute Qualität liefern wollen, das ist löblich. Macdiver (und die anderen) verstehe ich, weil er Tinkerforge ansurft und denkt "das ist drahtlos", da hat er es auch treffend gesagt, wer böses wollte könnte da vermutlich sogar rechtlich gegen vorgehen, zum Glück sind bisher alle ganz lieb ^^ Wenn es beim Chibi nur ein SOftware-problem wäre sähe ich kein Problem es "unfertig" auszuliefern (mit deutlichem Hinweis auf das Risiko), weil es ja patchbar wäre. Bei Hardware-Problemen wäre ich auch eher vorsichtig, ist schon ne Zwickmühle...

Was heißt das genau ? Das Brick führt ja für alle angeschlossenen Bricklets das Event jede Millisekunde aus und viele andere Sachen. Das heißt du musst definieren wie lange diese Tätigkeit dauern darf, weil deine Zeit ja insgesamt begrenzt ist. Das wäre ein Problem wenn du jeden Tick eine komplexe Berechnung machen möchtest, weil diese möglicherweise länger dauern würde als die 100 µs. Ich denke aber im aktuellen Fall spielt es aber keine Rolle.

Uh cool, das habe ich tatsächlich übersehen ^^

Ich bin ja auch nur Laie, aber mir würde nur die naive Variante einfallen. Also nciht lachen, ich stelle sie mal vor (kombiniert so das was ich hier gelesen habe ^^): Du nutzt für die "Festnetzversorgung" ein Netzteil das dir aus den 230V Wechselstrom wenige Volt Gleichstrom macht. Auf der anderen Seite hast du jetzt deinen Solar-Akku. Das beides ist jetzt Gleichstrom und die Spannung nicht tödlich, das ist gut, weil damit dürfen Leute wie du und ich spielen. Jetzt kannst du das beides per Diode oder wie auch immer verschalten. Am Ende hast du also eine niedervolt-gleichstromquelle die zwischen Fest und Solar wechselt. Jetzt kannst du da einen Wechselrichter dranbaumeln, also etwas wo kleiner Gleichstrom reingeht und großer Wechselstrom rauskommt. Die Fragen die übrig bleiben: - Wie teuer ist das - Wie schlecht ist der Wirkungsgrad dadurch (Wechsel->Gleich->Wechsel) - Lohnt es sich noch ^^

Hast du bereits gesehen, dass die Perioden der Servo-Bricks inzwischen auch kürzer eingestellt werden können? (neue Firmware) Bezüglich der asynchronität würde ich denke, dass es dir helfen sollte wenn du deine Servos "in Ruhe" konfigurieren kannst und dann mit einem einzigen Befehl starten könntest: servo.EnableMany(bitMask); Leider gibt es eine solche API-Funktion nicht, aber möglicherweise würde es ja hinzugefügt werden wenn bedarf besteht und dem nichts entgegenspricht.

Ich wollte gerade das limits-include raussuchen, bin dann aber hierüber gestolpert: http://stackoverflow.com/questions/3233054/error-int32-max-was-not-declared-in-this-scope Zitat: "C++ implementations should define these macros only when __STDC_LIMIT_MACROS is defined before is included". So try: #define __STDC_LIMIT_MACROS #include <stdint.h>

vielleicht sogar noch immer lohnen würde? @TF: Do it

Na das hat doch schon große Ähnlichkeit zu den Flugsimulatoren die ich kenne ^^ Sieht gut aus!

läuft!

blog.tinkerforge.com leitet jetzt aufs englische Blog, gut so ^^ Wenn ich auf android den Link auf eurer Seite anklicke, lande ich noch immer auf None.blog.tinkerforge.com und da gibt es nix ^^ Also entweder den Code finden der das None.blog produziert. Oder einfach hacken und None.blog auf en.blog umleiten lassen