Nic

Willst du Servos steuern ? Dann sollte ein Servo-Brick passender sein, ansonsten mal ev. unter http://www.stepperonline.com/ oder servocity, da gibt es schon fertige Sets mit Getriebe und Servo, ist aber teuer... http://www.servocity.com/

Seit der Migration auf Protokoll v2 habe ich meinen zentralen Chibi-Master hardwareseitig von V1 auf V2-Platine gewechselt. Alle übrigen Chibi-Stacks haben weiterhin den alten M1.0. Wenn ich flashe, bleibt die Chibi-Extension immer mit dem Master-Brick verbunden. Seit ich aber den Master 2.0 benutze wird nach dem Bootloader von Win7 "USB device not recognize" gemeldet und ich bekomme für den Flash-Process keinen COM-Port im Brick-Viewer angeboten. Restart des Rechners ändert nichts. Erst wenn ich die Chibi-Extension vom Master trenne, kann ich diesen flashen. Und anschl. wieder mit der Extension verb. Mit den alten M1.0 gab es da nie Probleme.

Das Angebot an kompakten und leistungsstarken 5V Akku-Packs scheint unerschöpflich und das möchte ich ausnutzen für eine kleine Motoranwendung mittels Stepper-Brick. Dazu sollen 5V/max.2A auf 9V und max. 500mA hochgeregelt werden. Ist Euch ein bezahlbares, fertiges Modul bekannt, das solche Leistung bietet ?

Welchen Zahnriemen verwendest Du ? Meinst Du zw. Ritzel und Focusring ?

Wenn die Motor/Riemen Anordnung großzügig vom Objektiv entfernt ist, könnte bei Weitwinkel der Antrieb mit aufs Bild.

@Borgel Bei der Chibi und RS485 Extension könnte ich aushelfen, was brauchst Du genau ?

@luxor Das wäre prima, dann hätten wir im Forum ein Anschauungsobjekt, und kommen im Thema mal etwas weiter. @Borgel Hast Du auch mal was für den Master und die Extensions erstellt ? Ev. würde ich die Kühlung mal beiseite lassen, nicht jeder braucht sowas, ansonsten wird es zu kompliziert, und das Interesse hierzu im Forum lässt ev. nach.

Ja, ich sehe auf den Biilder deiner Website ein Motorritzel und das Zahnrad auf der Maskierungsrolle. Na wenn es reicht... Für das FocusFollow wird der Nema17 m.E. aber zu groß um nahe genug am Objektiv zu sein. Und ohne Getriebe-Box dürfte auch bei 1/8 Schritt die Drehbewegung zu ruckelig sein, sowas sieht man im LiveView sofort. Wenn ich das richtig überblicke, sind solche simplen Werteerfassungen und Wiedergaben durchaus häufig bei den Usern. Immerhin ist so ein TF-System beliebig änderbar, da ist alles aus einem Guss von Perle eine Sackgasse

In der Tat da hat Borgel ganze Arbeit geleistet. Sag mal luxor, hättest Du die Möglichkeit so ein Prototypen im Lasercut zu erstellen ?

Nema17 ohne Getriebe ? Sowas reicht dir für die Leinwand, sind die 4-5Ncm nicht ein bissl mager für das Gewicht der Leinwand, Lagerreibung etc. ?

Schönen Dank für die Einblicke in Deine Projekte, sehr interessante Sachen hast Du da vor. Da gibt es sicher das eine oder andere Teil, das hier in der Community für Inspirationen sorgen dürfte. Ich bin auch eher ein Freund von LowLevel-Programmierung, aber ev. ist die High-Level-Ecke erstmal nicht so stressig, da Du ohnehin planst, ein Tablet oder Android zu verwenden. So würde ich auch eher zu einer Anbindung an den Host-PC/Android tendieren. Mittels der WiFi Extension auf einen oder mehreren Satelliten/Stacks bist Du auch sehr mobil. Für solche einfachen Steuerungen finde ich Deine Lösungsweg aber sinnvoller als die HighLevel-Programm. Wozu für den simplen Motorantrieb den Umweg über den Host-PC... Ich würde ev. aber den Antrieb noch mit Endlagenschaltern absichern, IO4 mit Hallsensor/Gabellichtschranken oder den DistanceIR... Achso ein Photograph http://davidhunt.ie/?p=2641 hat mal einen RaspPi komplett in den BatteryPack seiner DSLR eingebaut soviel zum Thema overkill Aber egal wie erfolgreich Deine Versuche im LowLevel-Prog waren/sind/werden auf alle Fälle Deine Projekte hier ins Wiki stellen. Welchen Motor würdest Du für ein Follow-Focus System verwenden ?

Der Thread ist sehr interessant und hurz scheint hier Pionierarbeit zu leisten, trotzdem bleibt das Thema für mich mehr als kryptisch. Und das liegt nicht nur an C-Kenntnissen Könnte man beim Thema OnDevice-Programming ev. ähnlich verfahren wie bei der Einführung des V2 Protokolls und uns Usern einen Überblick über die Architektur, Verarbeitungslogik etc. zu vermitteln. Anschließend könnte man eine Diskussion zum Thema anstoßen und ev. gemeinsam eine API vorantrieben ?! Was möchten die Kunden , was ist technisch möglich etc.. Ansonsten bleibt ein zusammenhangloser Eindruck von Tick-Tacks, ADC, Plugins, PINS etc. :o Für ein Research habe ich keine Zeit und Nerven, und der Austausch mit anderen Usern, führt zu nix oder endet in Spekulationen oder Mutmaßungen weil einfach zu wenig über die Interna in der Community bekannt ist.

@photron Mir ist das im Zuge der Migration auf das neue V2 Protokoll aufgefallen. M.W. war das vorher nicht. Nach dem vielen Flashen von Bricks und Bricklets vor 2 Wo. war das i.d.R. so. Mit der aktuellsten BrickV hab ich es noch nicht probiert.

Weiß nicht ob das mit Deinem Problem zu tun hat, aber wenn ich ein Reset ausgelöst hatte (z.B. nach dem Flashen) so blieb oft der Brick-Viewer Inhalt leer. Erst nach 2x drücken des Connect/Verbinden-Buttons wurde die Liste im Viewer aktualisiert.

Oh, ja mit dem C64, das waren sehr produktive Zeiten, aber auch schon der VC20 ist mir immer noch sehr gut in Erinnerung. Allerdings waren die Möglichkeiten von Hardware-Ansteurungen damals noch sehr bescheiden. Da waren die Herausforderungen mehr bei den Datenträgern von Cassette bzw. 51/4-Floppy, die waren sehr unzuverlässig... Aber besten Dank an Zero und halt uns auf dem laufenden.

Sag mal Zero213, könntest Du mal bitte etwas mehr zu diesem Projekt erzählen welche Erfahrungen Du mit der DC-Fräse so gemacht hast, wie gestaltest Du das mit der Positionsbestimmung bzw. steuerung. Geht das so einfach wie mit Schrittmotoren ? Und wie genau ist das im Endeffekt ? Ist das Einsparpotenzial wirklich höher als mit Schrittmotoren ? Sorry, aber Dein Beitrag suggeriert mir (und nicht nur mir) ein bissl, ob das mit DC-Motoren so einfach von der Hand geht und was man damit letztendlich gewinnt.

Jo, sowas kann er dann ausprobieren, wenn er schon einige Fräsen gebaut hat...

Hier hat sich ein User schonmal damit auseinander gesetzt, ev. würde ich ihm an deiner Stelle eine PM schicken und Erfahrungen austauschen. So eine Fräse macht man nicht mal soeben nebenher, sondern erfordert Erfahrung und Planung. http://www.tinkerunity.org/forum/index.php/topic,863.0.html

Wenn es um exakte Positionssteuerung gehen soll, empfehle ich Schrittmotoren. Einen Schrittgeber oder Encoder gibt es als Bricklet/Brick (noch) nicht und macht - wie Arnim schon erwähnte - bei einem DC keinen Sinn. Alles andere produziert graue Haare Und Schrittmotoren müssen nicht teuer sein, in der "Bucht" mal angeln gehen oder z.B: http://www.stepperonline.com

Nö, kann ich bei mir zumindest unter Win nicht bestätigen. Da wird die Kamera u.a. sogar über WUSB zeitnah zum Stepper angesprochen.

Interessant. Ist das eine Anordnung fürs Focus-Stacking ? Welche Software läuft auf dem PC um die Kamera anzusprechen ? Ev. hab ichs übersehen, aber warum muss die Kamera am USB-Port im laufenden Betrieb des Steppers abgezogen bzw. angeschlossen werden ? Alternativ würde ich die Kamera nur mal mit Akku betreiben.

Ah, jetzt hab ich es auch, macht einen Unterschied, ob man die Unit BrickStepper im Projekt eingebunden hat oder nicht. Wenn ich BrickStepper weglasse, kann ich overload als Schlüsselwort bei den Abl. stehenlassen.

Komisch, wenn ich overload weglasse oder durch reintroduce tausche, gibt es keine Fehler mehr, mit TArray0To2OfUInt8 komme ich da anschließend überhaupt nicht in Konflikt.

Ich bekomme unter Delphi 7 bei der Migration auf das neue Prot.V2 die o.g. Fehlermeldung. In den Ableitungen dürfen m.E. die abstrakten Methoden (aus TDevice) nicht das Schlüsselwort overload bekommen. Es müsste reintroduce sein.

In Delphi bin ich einiges gewohnt, aber die Socket-Untiefen eher weniger, aber ev. hilft das http://forum.delphi-treff.de/archive/index.php/t-18615.html Beispiel für das Setzen der Property TCP_NODELAY mittels setsockopt auf einem Socket in Delphi: http://www.delphipraxis.net/161942-wie-tclientsocket-einer-dll-verwenden.html