tf_archiv

wie gesagt ich bin mir nicht sicher. wenn du nur den stepperbrick nimmst, brauchst du keinen master brick. Bei allem anderen bin ich auch gerade etwas ratlos.

über den master oder über den stepper brick?

Ist mir gerade noch eingefallen, mit der Steuerung über den Brick, hast du halt die zusätzliche Freiheit, zu sagen, dass du den Schlitten mal schneller und mal langsamer bewegst.

Moin Moin, wie tuefekci schon erklärt hat mittels io4 und einem Klinkerauslöser. Bei google gibt es einige diy Anleitungen dafür. Oder du kaufst die einen und bearbeitest ihn entsprechend.

Hallo! Also erstmal danke für die schnelle Rückmeldung! Bei der Kamera handelt es sich um eine Canon EOS 7D mit einer Fernbedienung für die Auslösung. Wenn die Kamera aber von den Bricks ausgelöst werden kann wäre das die perfekte Lösung. Für die Synchronität: kann man den Stepper Brick nicht einfach auf die in der Fernbedienung eingestellte Auslösefrequenz einstellen und fertig? OK sicherlich wird es dann noch ein Problem geben beides zeitgleich zu starten... Inwiefern kann man denn die Kamera mithilfe der Bricks auslösen lassen? Die Kabel sollten kein allzu großes Problem darstellen. die könnte man in einer Schlauchleitung oder ähnlichem mitfahren lassen. oder die Bricks kommen einfach mit auf den Schlitten. Also wäre alles nur mit einem Stepper-Brick machbar oder wofür könnte ein Master-Brick noch von Vorteil sein?

Also ganz ohne Programmierung wird Dein Projekt m.E. nicht gehen: Von der Firma Canon soll es ein sog. SDK (Softw.Development Kit) geben, mit dem man eigene Programme zum Steuern einer EOS schreiben kann. Laut http://dickchiang.blogspot.com/2008/01/programming-with-canon-digital-camera.html soll es im SDK auch C# Klassen geben. Diese könnte man ev. in einem C# Programm zum Steuern des Schrittmotors einbinden. Dafür bräuchte man eine 2.USB Verbindung zur Kamera. Alternative: Wenn es nur darum geht die Kamera auszulösen - d.h. Zeit/Blende manuell einstellen - könnte man einen billigen Kabelauslöser http://www.enjoyyourcamera.com/Fernausloeser/Fernausloeser-fuer-Canon/Spiralkabel-Fernausloeser-Quenox-fuer-Canon-RS-80N3::4935.html zweckentfremden und die Drähte an den IO4 Bricklet verbinden. Vorher aber prüfen ob die Drähte schon Spannung haben, wenn das Kabel an der Kamera hängt, ansonsten einen Optokoppler dazwischen.

Die Idee ist gut. Je nach Dolly Setup könnte es aber mit dem Kabel Probleme geben. Es ist halt die Frage was er unter Dolly versteht.

Wenn es eine Spiegelreflex ist sollte sie einen klinker eingang für die fernauslösung besitzen dann einfach nen günstigen auslöser bersorgen und per IO4 schalten

Hallo Alex, also das ganze müsste mit einem Masterbrick einem Stepper Brick, einer passenden Energiequelle und einem Schrittmotor machbar sein. Evtl. kann man sich sogar den Masterbrick sparen. Die Frage ist halt wie man das ganze synchron bekommt. Am besten wäre es natürlich wenn die Kamera von den Bricks ausgelöst wird. Also kommt es jetzt auf die Kamera an. Was hast du denn für eine? Gruß Marc

Hallo! Ich möchte einen Dolly für Zeitrafferaufnahmen bauen. Mich würde interessieren ob es möglich ist mit den angebotenen Komponenten eine Steuerung für einen batteriebetriebenen Motor zu bauen der sich langsam und konstant bewegt, und in einstellbaren Abständen anhält in denen die Kamera auslöst. Dies ist insbesondere für Nachtaufnahmen wichtig, da länger belichtet wird und die Bilder bei durchgehender Fahrt unscharf würden. Ich habe selber noch keine Ahnung von Programmierung (außer ein bischen Delphi ^^) und würde mich freuen wenn ich Vorschläge für eine Realisierung des Bauprojektes bekommen könnte. Gruß Alex Block

Ich glaube, dass das den beiden Entwicklern schwer fallen könnte, den Zeitpunkt genauer zu bestimmen. Die kommen nämlich gerade nicht hinterher :-) Aber wie sie hier schreiben: http://de.blog.tinkerforge.com/ wollen sie in nächster Zeit die Entwicklung vorantreiben.

Hallo, vielen Dank - kann man späteren Zeitpunkt noch etwas präzisieren? THX

Zurzeit ist immer eine Verbindung zum Computer (dem Daemon) notwendig. Wie bereits geschrieben wurde folgt zu einem späteren Zeitpunkt noch eine API ("On Device Programming Interface"), welche eine Programmierung der Devices bzw. deren Firmware zulässt, welche zur Ausführung keine Verbindung zum PC benötigt.

Hallo, vielleicht habe ich es vor lauter Begeisterung überlesen... (Hier fand ich es auch missverständlich: http://forum.tinkerforge.com/de/topic/47-tinkerforge-team:-missverstaendnisse) Ist immer eine Verbindung zum Computer notwendig? (oder nur beim Programmieren?) Mein Projekt: Ich möchte zwei bis drei Servos steuern. Knopfdruck (gedrückt halten): Servo 01 fährt von 01_A nach 01_B Servo 02 bleibt auf 02_A Knopf wird losgelassen: Servo 01 fährt von 01_B zurück nach 01_A Servo 02 fährt von 02_A nach 02_B und zurück nach 02_A Servo 3 soll über einen Poti angesteuert werden und zwischen zwei einstellbaren Maximalwerten positioniert werden können. Da das Ganze auch "outdoor" genutzt werden soll, bleibt die Frage: Ist immer eine USB-Verbindung notwendig oder nur beim Programmieren? Ich dachte sonst ich würde mit folgender Hardware hinkommen: - Servo Brick - IO4 Bricklet - Rotary Poti Bricklet D A N K E, Barkeeper

Die CNC Fräse ist aus Aluprofilen von MayTec zusammengebaut: http://www.maytec.org/mainframe.htm Es gibt leider keine Konstruktionspläne oder ähnliches. Dazu kommt, dass die Materialien vermutlich teurer sind als eine fertige Einsteiger-CNC-Fräse. Zum Thema Source Code: Wir haben leider im Moment nur Code der elementare Formen abfahren kann, keinen gcode Parser. Ich sehe 3 Möglichkeiten eine CNC Fräse mit Stepper Bricks zu steuern: 1. Einen gcode Parser schreiben der gcode in Befehler für Stepper Bricks umsetzt oder Linux EMC anpassen das es Stepper Bricks ansprechen kann. Bei dieser Möglichkeit ist die Geschwindigkeit der CNC Fräse durch die Latenz von USB begrenzt. 2. Auf jeden Stepper Brick ein Debug Brick setzen und eine kleine C firmware schreiben die serielle Befehle umsetzt auf den Treiber IC auf dem Stepper Brick. So könnte man die Stepper Bricks direkt mit Linux EMC ansprechen (Das sollte schnell gehen, vielleicht 10 Minuten wenn die Entwicklungsumgebung etc. aufgesetzt ist). 3. Eine C firmware für die Stepper Bricks schreiben die gcode parsen kann. Damit könnte man eine Präzision erreichen die jede existierende Hobby CNC Fräse schlägt, welche Linux EMC nutzt. Leider ist dies auch die Möglichkeit mit dem meisten Aufwand. Falls das jemand vor hat, würde ich empfehlen mit 2. anzufangen um überhaupt etwas zum laufen zu bekommen und dann mit 3. weiterzumachen. So kann man immer auf die funktionierende Lösung zugreifen wenn nötig. Soweit ich weiß hat RepRap einen gcode Parser der auf Arduinos laufen kann, das könnte ein guter Startpunkt sein. Ich bin definitiv daran interessiert über Fortschritte zu hören wenn sich da jemand dran macht und würde auch mithelfen falls es größere Probleme gibt. Grüße, Olaf

Was würde mich sehr interessieren. Danke!

Danke schonmal für deine sehr ausführliche Antwort. Die Frage mit der Reaktionszeit ist ausreichend beantwortet. Bzgl. der Durchsichtigkeit bin ich mir aber nicht sicher, ob ich deine Antwort richtig verstehe oder ob ich meine Frage unglücklich ausgedrückt habe: Ich wollte kein Brick zum USB-Hosten verwenden. Dass das (noch??) nicht geht, weiß ich, war da auch schon über deinen Thread gestolpert. Es ging mir dabei darum, ob ich einfach zwei Stacks an meinen Rechner anschließen kann und immer noch alles so erkannt wird, als ob es ein Stack wäre. Ich vermute, dass das ohne Probleme funktioniert. Ich geh jetzt auch einfach mal davon aus, dass ich zwei Stacks an meinen Rechner anschließen kann und beide unabhängig voneinander mit getrennten Code betreiben kann? Insgesamt ist also Folgendes möglich: - Zwei Stacks an einen Rechner und sie mit einem gemeinsamen Code betreiben, genauso wie wenn es ein Stack wäre. - Zwei Stacks an einem Rechner und sie unabhängig voneinander mit getrenntem Code betreiben Korrekt? Danke nochmal für deine Mühe.

Bezüglich Reaktionszeit ein Kommentar aus dem englischen Forum von Olaf Lüke: "First of all: The Number of messages you can send to Bricks solely depends on the implementation of the USB stack from the operating system you use. The Bricks themself could handle 100khz and more. I just made this small test on my PC (linux 3.0.0-13): http://pastebin.com/NrKmWhn6 The output was 9.4246690273. Which means the roundtrip time (a message is send from your program to the Brick Daemon, over USB to the Brick, the Brick answers to the Brick Daemon and it sends the answer back to your program) takes about 1ms. This means your feedback loop over USB is perhaps possible if you only use one Brick. If you have a Stack of Bricks with many connected Bricklets, they all have to share the same USB connection. Over a wireless connection such a feedback loop is definitely not possible. The latency is just too high. But, as Bastian already said, we intend to release an Encoder Bricklet that would solve your problem. " Die Bricks selbst können also mit 100 kHz arbeiten. Die (Gesamt-)Reaktionszeit beträgt etwa 1 Millisekunde, wenn man die Verbindungen vom PC (Brick daemon) bis zum Brick und zurück betrachtet. Der Flaschenhals hängt von mehreren Faktoren ab: - Performance des PCs - Qualität der Datensignale - Performance der Schnittstellen Es kommen bei Verwendung von WLAN und komplexeren Aufbauen eine Menge Probleme bezüglich der Datenübertragung zusammen - ab irgendeinem Punkt der Komplexität funktioniert kein Aufbau mehr. Thema Durchlässigkeit: Ein Brick von heute kann niemals USB hosten - ein Brick funktioniert nicht als USB-Hub, sondern z. B. wie ein USB-Thermometer. Die Frage hab ich schon mal im Thema "USB-Relais" gestellt. Ich hätte so einen USB-Hub auch gerne - das würde unzählige weitere Möglichkeiten öffnen. :-) Alternativ gibt es beispielsweise USB-Ethernet-Server zu kaufen, mit welchen Entfernungen von 50 (oder 100? weiss ich grad nicht) Metern (ohne Ethernet-Range-Extender, z. B. ein Hub) laut Ethernet-RFC möglich sind. Strom muss am Ziel dann aber doch in irgendeiner Weise verfügbar sein. Du hast interessante Fragen, für die es heute schon Antworten gibt, die aber übermorgen anders sein können... Olaf, Basti, was meint Ihr? Pascal.

Ich hoffe, dass die Antworten nicht irgendwo steht und ich sie übersehen habe. Wisst ihr was über die Reaktions- /Verzögerungszeit der Bricks? Angenommen, ich habe einer 8er Stack Bricks. Der oberste ist ein DC-Brick, der Vor-Unterste ist ein Master-Brick. Alle Bricks dazwischen haben nur Sensoren(-Bricklets) angeschlossen. Die angeschlossenen DC-Motoren reagieren auf Basis der von den Sensoren gemessenen Werte. Gibt es dann gravierende Verzögerungen? Oder liegen die im kleinen Millisekundenbereich bzw. drunter und sind vernachlässigbar? (Angenommen, dass durch den C-Code keine ernsthafte Verzögerung verursacht wird.) Zusammengefasst: Wo liegt der Flaschenhals in Sachen Reaktionsgeschwindigkeit? Edit: Noch eine Frage: Pro Stack kann man bis zu 8 Bricks zusammenschließen. Ist das auch die maximal verwaltbare Anzahl von Bricks (pro USB-Anschluss)? Oder ist es z.B. möglich, dass eins der 8 Bricks ein W-Lan Modul ist und ich so zwei Stacks je 8 Bricks (Je 7 + 1 W-Lan) an einem USB-Anschluss verwalten kann? Gilt die "Durchsichtigkeit" der Verbindungen auch über USB-Grenzen hinweg? Kann ich also mehrere Stacks per USB an den Rechner anschließen und sie werden genauso verwaltet, als wären sie alle zusammen ein Stack an einem Anschluss? Danke für die Antworten.

Alles was du in deinem ersten Absatz geschrieben hast ist korrekt, bis auf: Wir nutzen 3.3V an der Stelle und I2C zur Erkennung statt SPI. Das EEPROM würdest du mit 5V zerstören. Zur EMV und VDE Sache muss Bastian was schreiben, dazu kann ich nichts sagen.

Welches EEPROM? Meinst du das M24C64? Wenn ich direkt Pin 7 & 8 aus dem Stecker nehmen würde, würde ich ja den M24C64 umgehen, die Relais sollten doch 5V können... laut euren Fotos habt ihr das 105H3F, das ist lt. Datenblatt 5V.

Hallo, super Sache hier, teilweise nicht neu die Idee(n) aber das Spannende hier, wie ich finde, ist die Bauform=Größe der einzelnen Module. Mich interessiert aktuell das Dual-Relay-Board. Ich will dieses losgelöst vom Rest der hier angebotenen Module verwenden, sehe ich das im Schema richtig, dass es ein "simples" TTL-Signal ist welches die Relais auslöst? D.h. Pin 7 & 8 am Connector "einfach 5V drauf und fertig"? sehe ich es weiterhin richtig das der SPI-Bus "nur" für die Erkennung des Bricks verwendet wird nicht jedoch für dessen eigentliche Steuerung (siehe Frage vorher)? Spannungs-/Stromfestigkeit, ich habe mir die Fotos angesehen, die Leiterbahnen von den Relais zu den Schraubklemmen erscheint mir etwas "dünn" - welche Stärke haben die und werden EMV & VDE etc. eingehalten? Das einzige "Manko" was ich erkennen kann aus meiner Sicht sind fehlende Sicherungen auf der "Hoch-Volt-Seite" sprich an den Ausgängen der Relais. Wobei die ein Platzproblem darstellen, mit dem ich auch am kämpfen war/bin. Hintergrund des Ganzen: Ich will damit eine Rollosteuerung aufbauen, meine bisherigen Pläne dafür sahen in etwa die gleiche Platinegröße vor, allerdings mit o.g. Sicherung und beide Relais waren Platinenseitig schon gegeneinander verriegelbar. (Für Zwischenstop der Rollos, kann ja aber hier mit einer Drahtbrücke erfolgen). Bei Interesse kann ich auch gern meine Pläne online zur Verfügung stellen bzw. Euch damit Ihr ein entsprechendes Modul bauen könntet. Grüße Fly

Zu den Powersupplies: Brauchbarer wäre zwar eine Antwort von jemandem, der das missverstanden hat, aber trotzdem: Ich finde, dass das insgesamt deutlich aus den Dokumentationen etc. hervorgeht. Aber vielleicht liest nicht jeder alles durch sondern bestellt nach dem bekannten Prinzip, dass alles ja auch noch ein Netzteil haben muss. Vielleicht lässt sich das Problem lösen, indem ihr im Shop zu den entsprechenden anderen Bricks (im Wesentlichen beim Master-Brick) je einen Satz mit der ausdrücklichen Information dazuschreibt, dass das Powersupply nicht unbedingt notwendig ist. In der Shop-Beschreibung vom Master-Brick steht das nämlich nicht, da kauft man sonst vielleicht aus Angst, dass am Ende was fehlt, vielleicht lieber gleich ein Powersupply dazu.

Hallo The_Real_Black! Du siehst das absolut richtig. Der Vollständigkeit halber noch eine Erklärung. Die Powersupply _brauchst_ du wenn du eine Stack baust und der Master des Stacks nicht genug Strom liefern kann um alle Bricks/Bricklets des Stacks mit 5V zu versorgen. (Versorgung des Stacks über die USB Verbindung des Masters) Die von USB spezifizierten max 500mA können z.B. recht schnell überschritten werden, wenn jemand mehrere LCD Displays mit Hintergrundbeleuchtung benutzen möchte. Für die meisten Fälle ist da aber keine Stromversorgung notwendig, da die USB Verbindung genug Strom liefert. Wirklich benötigen tut man die Powersupply wenn die Master Extensions draußen sind. Dann muss so nen Funk Stack ja irgendwie versorgt werden. Das Feature, dass du für Treiber Bricks einspeisen kannst, und dir so Verkabelung sparst, kannst du natürlich immer nutzen. Grüße Bastian

Hallo Bastian, ich hatte den Powersupply Brick bereits im Warenkorb bis ich nochmal die Dokumentation gelesen habe. Die Frage ist ab wann wird man den Powersupply benötigen? Aus der Doku heraus würde ich sagen, dass ich bei meiner nächsten Bestellung zu den 2 Stepper oder DC Bricks einen Powersupply dazubestelle damit ich nicht die einzelnen Bricks verkabeln muss. Ansonsten müsste ich an beide Bricks jeweils eine eigene "Stromleitung" ziehen oder? Happy Coding The_Real_Black