Nic

Ok, aber melde Dich ev. auch früher wenn ich schon vorab ein paar Maße vom Chibi/RS-485/Master bestimmen kann.

Sorry Fabian, dass ich mich nochmals ein bringe, aber du solltest dann dazu schreiben warum und was du davon nicht geeignet findest, und wie man es ev. verbessern könnte. Edit: Huppsala, haste ja gemacht unter http://www.tinkerunity.org/forum/index.php/topic,1445.msg9313.html#msg9313

Das bringt mich gerade auf die Idee, ob die 5V am Ausgang vom StepDown via Firmware-Anpassung eigentlich programmmierbar ein- oder ausschalten lassen könnte ? Oder zumindest in zukünftige StepUp/Down Supply schaltbar gestalten könnte, ohne dass man für sowas unbedingt ein Bricklet anschließen müsste ?

JavaLaurence, thanks for your feedback. If you cannot follow or understand the translation of German Threads, dont hesitate to ask inside this thread in English or send a PM. I assume that in most cases they answer in English, too; otherwise other users will help.

Der Link funktioniert nicht, sorry

Das hat er nicht gefragt ! Wat jetzt Ostern ? Oder weißt Du mehr als wir

Weiß ich doch, wollte nur mal den Schnappschuß nochmal anschauen , da stellt sich für mich die Frage warum hier im Forum gar nicht das weibl. Geschlecht vetreten ist... Sind die Themen zu langweilig Auch dem kann geholfen werden... http://www.die-glocke.de/lokalnachrichten/kreisguetersloh/Tinkerforge-Module-erfuellen-Wuensche-856c691b-6221-420b-af04-4474119f0981-ds

Dem kann geholfen werden... http://en.blog.tinkerforge.com/2012/3/8/chip-award-2012-product-of-the-year Die junge Dame rechts im Bild gehört (leider) nicht zum Team und photron is auch nich drauf.

In the German forum we have a discussion about the future of OnDevice Programming. Maybe your follow it by translating it, but it would be nice to give us your feedback, too. TF suggests 2 opportunities, I try to summarize it, but If you have questions please ask TF: 1) On Device API in C: similar as Arduino API Pros: Performance, near to hardware Cons: Not very user friendly language, hard to code, TF means they have to rewritten the firmware Most users are hobbyist and would be more familiar with Phyton 2) On Device in Phyton: There exists at least an open source projects to deploy a light version of a Phyton Interpreter on chip (http://code.google.com/p/python-on-a-chip/). Pros: easy language, reuse of exsting bindings, developing on desktop, deploy same stuff on chip Cons: disadvantages of interpreter, limit of source code size Some users suggests to combine it with a new Brick with memory capacity. Dont hesitate and give us your feedback !

Das ist in der Tat schnell erreicht, dann sollte ein Parallel-Betrieb von embedded und Host-PC BrickD möglich bleiben.

C ist sicher der Königsweg, aber ich habe neben Familie und Beruf kaum die Nerven und Zeit mich um so eine anspruchsvolle Hochsprache für die hardwarenahe Programm. rumzuschlagen. Tinkerforge Sachen empfehlen sich für das schnelle Prototyping, da ist eine relativ einfache verständliche Umgeb, wie durch Phyton eine vernünftige Ergänzung. Ich sehe dort die letzte News ist datiert Ende Sep.2011, wird das Project überhaupt noch weiter gepflegt ? Die "Hardcore" Entwicklung in C ist doch jetzt schon möglich wenn auch mit viel Aufwand und Pionierarbeit. Was heißt das jetzt genau: ist der BrickD damit in der BrickCPU ? Ich hätte keinen "direkten" Zugriff auf die Hardwarepins, aber wie würde ein Direktanschluss und -auswertung zB. des Joystick am Stepper aussehen ?

Aus dem Bauch heraus eher Phyton zu Beginn: damit alle etwas davon haben. Und um sich schnell in die Materie einzuarbeiten und Ergebnisse zu erzielen. Auch wenn die API in C so idiotensicher wie möglich wäre, ist C doch eher was für Gurus. Allerdings wäre es doch ein Ko für Phyton wenn die Performance weit unter der von C liege. Ansonsten schließe ich mich dem Tenor an, die Beispiele in der Doku zu konkretisieren und ergänzen, insbesondere bei so anspruchsvollen Teilen wie z.B. das IMU. "Banale" Bricklets wie IO, Relay muss das nicht unbedingt sein. Ansonsten vielleicht die Doku noch um Elektronik-Tips ergänzen, dazu ist das Defizit im Vergleich zu Programmier-Skills wesentlich größer.

Sieht gut aus, Klasse. Ich würde es nicht unbedingt unter diesem Begriff publizieren - obwohl völlig richtig - ist diese Method eher unter dem Begriff Focus-Stacking (http://en.wikipedia.org/wiki/Focus_stacking) bekannt. Die Idee einen alten Scanner quasi zu hacken gar nicht so schlecht. Hast Du da noch Endlagenschalter ?

Um welches USB Kabel geht es hier genau ? USB-A auf Mini-B ? Also zum Anschluss des Stacks an den Host-PC ?! 20cm Kabel wäre gut, und in einigen Fällen ggf sogar noch etwas kürzer z.B. zum Direktbetrieb am 5V Akku. Ideal wäre der USB-Stecker gewinkelt, sonst macht sich die starre Form des Steckers bemerkbar. Gar nicht so schlecht, Unmengen an externen 5V-Akkus liefern nur Micro-USB-Stecker-Anschluss, hinzu kommen die Tablets für den Androiden und Windos auch nur noch Micro-USB (Buchsen) verfügen. Vielleicht kann man hier geschickte Adapter/Kabel-Kombinationen anbieten.

@webster7567 Was verwendest Du für die Kameraaufhängung/halterung ? Ist das DIY oder gekauft ? Der extra-Riemenantrieb am Objektiv wozu ist der nötig ?

Wie Arcane beschrieben so habe ich es auch verstanden, ich würde eher tippen sowas lässt eher über einen ganz neuen Brick für 2 oder mehrere Stepper besser lösen. Da lässt sich das Synchronisieren oder individuelle Anfahren versch. Motoren technologisch besser steuern.

Bekomme neuerdings diesen Fehler im Log des Viewers gemeldet, siehe Attachment. Konstellation Master-Chibi(Master v2) und Slave-Stack(Master v1). Io4 lässt sich trotzdem benutzen. Weiterhin wird im Viewer 2.0.2 nicht mehr die Liste autom. refresht, wenn auf dem Master v2 im Viewer ein SW-Reset ausgelöst wird. Es erscheint nur dieser Brick, erst nach Disconnect/Connect wird die komplette Liste wieder angezeigt. Ist alles nicht so dramatisch, aber der Ordnung halber hier hingewiesen.

Müsste das bei erstmal nur 2 Triggern mit der aktuellen FW nicht jetzt schon möglich sein, den Monoflop mit einem Pin auf High zu setzen (deactiv Magnetfeld), der nach xms wieder autom. auf low zurücksetzt, um dann die Kamera auszulösen. Wenn ich mich nicht irre, ist das ev. nur eine Sache der richtigen Verdrahtung über passende Optokoppler/Inverter ?! Vielleicht hat jemand von den Elektronik-Gurus einen Vorschlag.

Wozu, was wäre der Vorteil zur ersten Fassung vom Chibi ? Für uns als Kunden ergibt sich damit erstmal ein (preislicher) Nachteil.

Hmmh, luxor, wie und wieviele Kameras willst Du denn auslösen, wieso im 1ms Raster ?

Mir ist das ein Rätsel warum hier die frühere Chibi-Extenstion unerwähnt bleibt http://www.tinkerforge.com/doc/Hardware/Master_Extensions/Chibi_Extension.html#chibi-extension. Im Gegensatz zur aktuellen WIFI-Ext kostete die Chibi nur fast die Hälfte, knapp 29,- Euro. Der Stromverbrauch ist mit 10mA deutlich geringer als die 110 mA vom WIFI. Weitere Daten: http://de.blog.tinkerforge.com/2012/3/30/chibi-extension-faehigkeiten Reichweite höher als beim WIFI laut: http://en.blog.tinkerforge.com/2012/2/29/chibi-extension Der Datendurchsatz dürfte schlechter als beim WIFI sein. Für simple Klimadaten Erfassung reicht das Chibi durchaus. Wozu hier ein WLAN-Netz aufspannen. Ich benutze ausschl. diverse Chibi-Stacks (Master+Chibi-Ext.+Bricklets) versorgt mit einem 5V-Akkupack und gut is. Für eine Neuauflage der Chibi-Extension bin ich durchaus zu haben, für meine Zwecke sind mir die WIFi schlichtweg oversized und zu teuer.

Huch, das war auch nicht sooo ernst gemeint Passte nur gut zum Topic.

Ob man damit auch ein Gehäuse basteln könnte http://www.golem.de/news/3doodler-3d-drucker-mit-handbetrieb-1302-97678.html

Und ich dachte ich bin hier der Einzige :'(, der Chibi-Ext. benutzt... PS: Mit der Einschränkung Mv2+Chibi-Ext. kann ich leben, auch wenn es es beim Flashen ein bissl umständlich ist, solange man es weiß...

hmmh, du meinst sicher das hier: http://www.tinkerunity.org/forum/index.php/topic,1371.msg8919.html#msg8919 Da schreibt aber The_Real_Black nix von einer Extension, d.h. mein genannter Fehler ist abhängig von Master v2 und Extension oder gilt das für alle Stacks mit Mv2 ?