Bricklet-Daten auf Brick autark auslesen (low-level)

Hallo zusammen,

 

bin gerade dabei ein einfaches Projekt umzusetzen, in dem ein Stepper Brick von einem Joystick rudimentär bedient werden soll, ohne angeschlossenen Master Brick und ohne USB-Verbindung (da der Brick schwer erreichbar sein wird).

 

Mir ist es bisher recht problemlos gelungen die original Firmware mit einigen geänderten Standardwerten neu zu kompilieren und im brickv zu testen.

Im nächsten Schritt wollte ich die main.c um erste Aktionen wie stepper_enable() usw. erweitern um den angeschlossenen Motor direkt autark steuern zu können.

 

Beim Stöbern im Code suche ich aber bisher vergeblich nach den Funktionen um die Bricklet-Daten auszulesen. Ich finde nur bricklet_read_plugin() usw. die wohl eher fürs Flashen/Verifizieren gedacht sind? Aber womit bekomme ich z.B. die Positionsdaten eines Joystick-Bricklets?

 

Ich hatte mir das so vorgestellt:

Nach der Initialisierung überprüft der Stepper-Brick endlos die einkommenden Daten vom Joystick-Bricklet. Wird der Joystick geklickt, möchte ich stepper_enable() aufrufen, beim Loslassen stepper_disable().

Mit der Richtung des Joystick (oben/unten) will ich schrittweise (je nach Zykluszeit?) fahren, solange der Joystick weit genug (>x) ausgelenkt ist.

 

Hättet ihr ein paar Tipps wie ich diese low-level Funktionen realisieren kann oder wo ich die benötigten Funktionen zum Auslesen des Bricklet finde?

 

Ach ja, noch eine kleine Frage: Dient der in der main.c aufgerufenen Task lediglich einer Art Watchdogfunktion oder hat er noch eine tiefere Bedeutung?

 

Entschuldigt die etwas "dummen" Fragen aber meine C-intensive Zeit ist schon eine Weile her =)

 

Vielen Dank!

Hi,

 

die Bricks laden den Code (das Plugin) der Bricklets. So muss kein Brick alle Bricklets kennen. Das ist auch der Grund warum du im Code des Bricks nichts dazu findest. Guck dir mal den Code des Joystick Bricklets an. Dazu wirst du dir noch die Brickllet-lib ansehen müssen.

 

Grüße

Danke für die schnelle Antwort!

 

Ok, soweit ich dich und den Code verstehe passiert folgendes:

main ruft brick_init() auf, dieses wiederum bricklet_init(). Während dem Bricklet-Input wird über die Funktion "i2c_eeprom_master_read_plugin" der Code (plugin) des bricklets ausgelesen und über "bricklet_write_asc_to_flash" in den Speicher geschrieben.

D.h. am Speicherort von ba (bricklet api), bs (settings) und bc (context) finde ich jeweils die Daten.

 

Aber sind dem Brick jetzt die Funktionen is_pressed(...), position_from_analog_value_x(...) bzw. _y(...) bekannt und können aufgerufen werden? Die Return-Werte dieser Funktionen scheinen ja jeweils in den BrickContext geschrieben zu werden, aber wie kann ich diesen auf dem Stepper-Brick auslesen?

 

Oder ist es dieser context der über das Auslesen des Plugins eingelesen wurde?

Das Drücken des Joystick wird ja scheinbar von selbst durch den tick-task upgedated, die Analogwerte muss ich mir ja bei Bedarf holen vermute ich? Nur ist mir noch nicht ganz klar wie ...

 

Hättest du noch ein paar Tipps für mich oder gar ein kurzes Code-Schnipsel zum Auslesen von einem Analogwert z.B.? Von da an dürfte ich durch experimentieren mein simples Programm hoffentlich hinbekommen ...

 

Tut mir Leid wegen der vielen Fragen und ich weiß low-level-Programmierung ist nicht wirklich für Tinkerforge-Anfänger wie mich gedacht, aber für mein Projekt würde ich gerne vom Master bzw. einem brickd unabhängig sein und die eigentliche Aufgabe ist ja sehr einfach, mir fehlt es nur ein bisschen an den low-level-Grundlagen.

 

Es ist vermutlich am einfachsten, wenn du das Joystick Bricklet selbst ausliest (anstatt über das Bricklet Plugin zu gehen).

 

Du findest in der config.h die Definitionen der einzelnen Bricklet ports:

#define BRICKLET_A_ADDRESS 84
#define BRICKLET_A_ADC_CHANNEL 12

#define BRICKLET_A_PIN_1_AD   {1 << 12, PIOC, ID_PIOC, PIO_INPUT, PIO_DEFAULT}
#define BRICKLET_A_PIN_2_DA   {1 << 25, PIOA, ID_PIOA, PIO_INPUT, PIO_DEFAULT}
#define BRICKLET_A_PIN_3_PWM  {1 << 0, PIOC, ID_PIOC, PIO_INPUT, PIO_DEFAULT}
#define BRICKLET_A_PIN_4_IO   {1 << 4, PIOC, ID_PIOC, PIO_INPUT, PIO_DEFAULT}
#define BRICKLET_A_PIN_SELECT {1 << 8, PIOC, ID_PIOC, PIO_OUTPUT_0, PIO_DEFAULT}
..

 

Um die analogen Werte des Joysticks auszulesen, musst du zuerst den adc aktivieren "adc_channel_enable(BRICKLET_X_ADDRESS) und du kannst die Werte mit adc_channel_get_data(BRICKLET_X_ADDRESS) auslesen.

 

Der Joystick hat allerdings zwei Achsen, D.h. du musst zwischen den einzelnen Achsen umschalten, das geht über PIN_3 und PIN_4. Dabei unbedingt darauf achten, dass immer nur einer der beiden Pinne auf high ist. PIN_3 ist die X-Achse und PIN_4 die Y-Achse. Über PIN_2 kannst du den Button abfragen.

 

Am besten baust du die Abfrage vermutlich in die tick_task und die adc Initialisierung in die stepper_init. Für den Joystick würde ich immer ein Achse auslesen, PIN_3 und PIN_4 auf low stellen, eine Tick warten, einen der Pinne auf high stellen, einen Tick warten und dann die andere Achse auslesen usw.

 

Zum initialen Konfigurieren der Pinne benötigst du PIO_Configure, für das setzen auf high/low PIO_Set und PIO_Get und für das auslesen vom Button PIO_Get.

 

Desweiteren solltest du in der brick_init in init.c den bircklet_init() Aufruf auskommentieren, damit das Joystick Bricklet Plugin nicht zusätzlich ausgeführt wird (sonst schaltet das Plugin zwischen den Achsen hin und her).

 

 

Ich hoffe das hilft. Der Übergang von der Kommunikation mit dem PC zum On Device Programming ist leider nicht so einfach, sonst hätten wir schon längst eine low-level API dafür fertig .

Vieln Dank für die Hinweise!

Habe es so umgesetzt wie vorgeschlagen und meinen Code im Tick-Task der stepper.c integriert.

Es funktioniert das Auslesen des Buttons über PIO_Get und cih kann Pins high und low setzen über PIO_Set und PIO_Clear, aber ich bekomme aber keine vernünftigen Werte aus dem ADC channel. Die sollten ja zwischen 0 und 4095 sein?

 

Angelehnt an die Funktion "position_from_analog_value_x(...)" in der joystick.c sieht meine Funktion jetzt z.B. so aus (aber ohne die zusätzliche Addition beim temp-Wert haute auch nicht hin... mir ist nicht so ganz klar wozu die gut ist):

 

temp = (int32_t)adc_channel_get_data(BRICKLET_A_ADC_CHANNEL) + (MAX_ADC_VALUE / MAX_JOYSTICK_POSITION)/2;
joystick_position_y = MAX_JOYSTICK_POSITION/2 - SCALE(temp, 0, MAX_ADC_VALUE, 0, MAX_JOYSTICK_POSITION);

 

Den Motor würde ich dann so ansteuern:

 

if(joystick_position_y > MAX_JOYSTICK_POSITION/3) {  
    stepper_direction = STEPPER_DIRECTION_FORWARD;
    stepper_make_step();
}
if(joystick_position_y < -MAX_JOYSTICK_POSITION/3) {   
    stepper_direction = STEPPER_DIRECTION_BACKWARD;
    stepper_make_step();
}

 

Der Motor bewegt sich auch, aber immer nur "backward" egal in welcher Position der Joystick steht. Das spräche aber für zu große eingelesene Werte...

 

Vielleicht fällt dir ja mein fehler auf?

Im Anhang wäre auch meine komplette, modifizierte stepper.c soweit...

 

Neben deinem Vorschlag hab ichs eben auch mit der ADC-Channel-Adresse statt der Bricklet-Adresse probiert, das erschien mir richtiger oder nicht?

adc_channel_enable(BRICKLET_A_ADC_CHANNEL)

adc_channel_get_data(BRICKLET_A_ADC_CHANNEL)

 

Mein größtes Problem ist aber noch das Folgende:

Der Tick-Task läuft scheinbar nur bei bestehender USB-Verbindung durch.

Wenn ich den Stepper-Brick nur über externe Stromversorgung ohne USB betreibe, rührt sich nichts mehr. Er wird ja scheinbar ohne USB als "stack participant" eingestellt...

Muss ich den Brick für den autarken Betrieb dann als Master setzen? Das Definieren von BRICK_CAN_BE_MASTER als 1 bringt mir aber an anderen Stellen Probleme...

 

EDIT: Datentypen hatten noch nicht gepasst, habe die stepper.c nochmal aktualisiert.

adc_channel_get_data() gibt uint16 zurück, für die Position (+-) rechne ich in int32 um...

 

EDIT2: Nochmal mit durchgängig uint16 probiert und Rohdaten. Ich lese wohl grundsätzlich FFFF also 65535 ein, weiß aber nicht woran das liegen könnte.

Schreibt das Bricklet keine Daten in den ADC channel?

config.h

stepper.c

Nochmal zum USB-Problem:

Kann ich den Brick überhaupt ohne zusätzliche 5V-Versorgung (über Stack oder USB) betreiben? Holt er sich aus der externen Versorgung für den Motor (bei mir 24V) die 5V-Versorgung für seinen Chip etc. oder muss ich ihm zwingend noch 5V auf den Stack-Pins bzw. per miniUSB füttern?

Ich will den Brick ja eigentlich völlig alleine ohne Stack oder per USB angeschlossenem Gerät betreiben...

Da er in der Firmware ohne USB-Verbindung als "stack participant" eingestellt wird, weiß ich nur nicht wie ich ihn dazu bewege, sich selbst zu versorgen und als quasi-Master zu agieren.

 

Zum Auslesen der Analogwerte:

Soweit ich das aus dem Schaltplan des Joystick bricklets sehe, schalten ja die Pins 3 und 4 die y- bzw. x-Spur des Joysticks auf den Pin 1.

Muss ich diesen Pin auch gesondert per PIO_Get auslesen oder macht das "adc_channel_get_data(...)" bereits?

Welchen "channel" muss ich der Funktion denn übergeben? Ich habs mit beiden probiert,e rhalte aber bei beiden keine vernüftigen Werte...

- BRICKLET_A_ADC_CHANNEL (84)

- BRICKLET_A_ADDRESS (12)

Das Initialisieren des Channels mittels "adc_channel_enable(BRICKLET_A_ADDRESS)" sollte ja quasi schon die Verbindung zum Pin 1 herstellen um dessen Wert als 12bit-Digitalwert in den Speicher (BRICKLET_A_ADC_CHANNEL?) schreiben zu können.

Irgendwo ist da noch der Wurm drin. Da es aber über den BrickV problemlos funktioniert, liegt das Problem sehr wahrscheinlich an meinem Code...

Muss ich vielleicht doch das bricklet initialisieren damit ich Daten im ADC-Channel bekomme?

 

Ich hoffe ich bekomme das noch irgendwie hin, sonst müsste ich zur Not doch auf einen Master-Brick ausweichen. Aber würde dieser von der externen Spannung am Stepper versorgt werden oder müsste ich auch noch über USB oder ein PowerSupply Brick zusätzlich einspeisen?

Soweit ich das weiß ist die externe Spannung vom Rest des Bricks/Stacks getrennt. Das heißt du brauchst von woanders noch deine 5V (entweder USB oder Stack)

Ok, danke für den Hinweis. Das ist so explizit nirgends beschrieben, oder?

Jetzt hängt ein Step-Down Power Supply unter dem Stepper Brick und er läuft auch ohne USB-Verbindung.

 

Nur das Auslesen der ADC-Daten will noch nicht richtig funktionieren.

Komme da einfach nicht weiter.

Habs auch probiert mit:

adc_channel_get_data_unfiltered(BRICKLET_A_ADC_CHANNEL)

 

Ich vermute, ich mache grundsätzlich etwas falsch, nur was?

Genrell mache ich folgendes (siehe Source-Code weiter oben):

Schritt 1: PIN3 setzen für X-Achse (PIO_Set)

Schritt 2: ADC auslesen und dann PIN3 und PIN4 rücksetzen (PIO_Clear)

Schritt 3: PIN4 setzen für Y-Achse (PIO_Set)

Schritt 4: ADC auslesen und dann PIN3 und PIN4 rücksetzen (PIO_Clear)

Schritt 5: Schrittzähler zurücksetzen

 

Gelesen wird der Wert ja aus folgendem Register des SAM3:

 RoReg ADC_CDR[16];   /**< \brief (Adc Offset: 0x50) Channel Data Register */

 

Entweder werden keine Werte dort periodisch hineingeschrieben oder ich mache etwas anderes falsch?

Wenn jemand noch Ideen hat, wäre für jeden Hinweis dankbar...

 

Wofür ist der PIN1 gut? Laut Schaltplan wird dort drauf die aktive Spur des Joystick geschrieben. Muss ich den auch irgendwie auslesen damit ich die ADC-Werte bekomme?

 

Da fehlt die Konfiguration der X/Y-Pinne auf Output:

 

...
Pin pins_bricklet_a[] = {PINS_BRICKLET_A};
pins_bricklet_a[0].type = PIO_INPUT;
pins_bricklet_a[1].type = PIO_INPUT;
pins_bricklet_a[2].type = PIO_OUTPUT_1;
pins_bricklet_a[3].type = PIO_OUTPUT_0;
...

Der Übergang von der Kommunikation mit dem PC zum On Device Programming ist leider nicht so einfach, sonst hätten wir schon längst eine low-level API dafür fertig

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.

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..

 

Das halte ich auch für eine gute Idee. An den grundlegenden Programmierkenntnisse mangelt es den Tinkerforge-Kunden ja nicht, sie müssen so oder so programmieren.

Die zusätzlichen Kenntnisse für die Verwendung der Bricks und Bricklets low-level sind ja auch nicht schrecklich kompliziert wenn man eben wüsste was man alles beachten muss, also welche Pins wofür da sind, wo Daten liegen die wie ausgelesen werden können, etc.

 

Den Hinweis mit der Pin-Konfiguration probiere ich gleich heute Abend aus!

Ich dachte eben dass ein PIO_Set den Pin bereits durch das HIGH-Setzen als Output-Pin benutzt (Inputs kann ich ja schlecht manipulieren), aber das ist eben eine Kleinigkeit die mich schon von alleine viel weiterbringt, wenn sie irgendwo stehen würde.

Das würde euch ja auch etwas den mühsamen Support im Forum sparen.

Ich kann versuchen da etwas im Wiki zu schreiben wenn alles klappt.

 

Zur Frage "was die Kunden wollen" hier als Beispiel meine ersten zwei kleinen Projekte mit Tinkerforge und wofür ich diese Umstände mit der low-levlel-Steuerung des Stepper Bricks mache:

 

1) Ich habe eine Heimkinoleinwand mit motorisierter Maskierung gebaut: http://mulb.org/node/1084.

Im ersten Schritt soll die Maskierung über den Joystick und Schrittmotor steuerbar sein (rauf/runter).

Im zweiten Schritt will ich das Ambient Light Bricklet, das in der Unterkante der Maskierung eingebaut ist, dazu verwenden, selbstständig den Rand des beleuchteten Bildes zu erkennen und den Schrittmotor im Runterfahren passend anzuhalten.

Ein dritter Schritt wäre der Leinwand über die WLAN-Extension bereits zu sagen, welches Format das Bild haben wird und den Schrittmotor so anzusteuern (werde ich aber vermutl. nicht realisieren).

 

Hier sieht man schon dass es keinen Sinn macht eine dauerhafte USB-Verbindung zu haben, es sei denn ich Verwende einen ebenfalls eingebauten RaspberryPi, das erscheint mir für die sehr einfache Aufgabe aber Overkill.

 

2) Mein nächstes Projekt das jetzt parallel startet wird ein Filmkran mit motorisiertem Follow-Focus für das Filmen mit einer DSLR. Dazu werde ich ebenfalls einen Stepper (mit einem Motor über Zahnriemen oder Zahnkranz am Objektiv) sowie ein Linear Poti Bricklet und wieder low-level Programmierung um mobil zu sein und mit der Kamera den Fokus sehr genau ziehen zu können ohne eine mechanische Verbindung zur Kamera zu haben.

Auch hier wäre im nächsten Schritt dann eine Ansteuerung des Fokus über ein Tablet oder Handy möglich, was dann aber wohl doch ein High-Level-Konzept benötigt (wegen der Verbindung zur Andrroid- oder iOS-Software).

 

Sollte meine low-level-Versuche mit Erfolg gekrönt sein, kann ich natürlich gerne über die Projekte hier im Forum und über die Realisierung im Wiki berichten.

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 ?

Welchen Motor würdest Du für ein Follow-Focus System verwenden ?

 

Ich verwende wie schon bei der Leinwand recht klein bauende Schrittmotoren mit 1,8° Schrittwinkel und um die 4-5 Ncm Drehmoment. Nema17-Moteren z.B.

Ich hab noch ein paar gebrauchte aus der Bucht hier herumliegen.

Für einen FollowFocus würde sich ein Servo zwar besser eignen, weil ich dann wirklich einen bestimmten Winkel=Fokusentfernung geregelt anfahren kann, aber über den Schrittmotor und eine Übersetzung dürfte das schon ausreichend genau klappen. Ich hab einfach noch einen Stepper Brick übrig, das bietet sich also an.

 

Das High-Level-Konzept hat halt immer den Nachteil, dass ich neben dem PowerSupply und dem Stepper Brick eben noch zumindest eine Art Rechner mit USB-Verbindung bzw. sogar noch einen MasterBrick und WLAN-Extension unterbringen müsste. Das braucht natürlich mehr Platz, der Programmieraufwand ist ggf. größer,  die Latenzzeiten steigen, etc. aber flexibler ist man dann natürlich schon und kann komplexere Dinge realisieren.

Für einen Roboter, eine Wetterstation oder eine CNC-Fräse würde ich jetzt nicht unbedingt low-level programmieren, aber für eine simple vor/zurück-Steuerung eines einzelnen Motors finde ich es recht sinnlos einen kleinen Rechner irgendwie verbauen zu müssen und den Dämon drauf laufen zu lassen oder den Stapel um Master und WLAN aufstocken zu müssen. Von den zusätzlichen Kosten ganz abgesehen.

 

Auch wenn die Low-Level-API oder eine genauere Beschreibung noch auf sich warten lassen, muss ich aber sagen dass ich wirklich beeindruckt bin was so wenige Leute auf die Beine gestellt haben, v.a. wenn man sich mal die Menge an Code im Repository anschaut, den schnellen Support im Forum, die mitlerweile echt große Vielfalt an Bausteinen etc. Weiter so!

 

Ich verwende wie schon bei der Leinwand recht klein bauende Schrittmotoren mit 1,8° Schrittwinkel und um die 4-5 Ncm Drehmoment. Nema17-Moteren

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. ?

Die Leinwand selbst ist nicht motorisiert, wiegt ja alles in Allem so an die 40kg. Dafür bräuchte ich schon große Kaliber (Garagentormotor oder sowas) oder einen entsprechenden Seilzug. Dann hätte ich aber die Decke abhängen müssen um das unsichtbar unterzubringen. Aber da reden wir dann über ca. 20Nm, nicht mehr Ncm.

Die Leinwand wird von Magneten an der Decke gehalten und bei Bedarf manuell runtergeklappt. Nur die schwarze Maskierung vom oberen Bildrand ist motorisiert (IKEA Tupplur Rollo). Selbst dafür habe ich schon eine kleine Übersetzung gebraucht, fahre den Motor aber auch im Achtelschrittbetrieb, da hat er nicht soviel Dampf läuft da aber angenehm ruhig.

Hallo zusammen,

ich komme je eher aus der Ecke der Wetterdatenaufschreiber... auch hier wäre ein autarkes Model denkbar: Master + Temp./Humidity/Barometer/LCD Bricklet. Werte messen und anzeigen. Das sollte auch ohne Rechner gehen.

Ich weiß .... bei der Perle kosten so Teile unter 10€.... aber ist halt nix eigenes. Für mich wäre so ein Teil einfach mal so als eigenständiges Kontrollmodul zu verstehen.......

Nur die schwarze Maskierung vom oberen Bildrand ist motorisiert (IKEA Tupplur Rollo). Selbst dafür habe ich schon eine kleine Übersetzung

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.

 

Wetterdatenaufschreiber... auch hier wäre ein autarkes Model denkbar: Master + Temp./Humidity/Barometer/LCD Bricklet. Werte messen und anzeigen. Das sollte auch ohne Rechner gehen.

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 

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.

 

Beim FollowFocus werde ich keine direkte Verbindung zum Objektiv herstellen, sondern über einen Zahnriemen. Je nach Objektivdurchmesser ergibt sich da schon eine recht große Übersetzung, da wird die kleinste Drehung von 1,8° beim Ritzel nur 0,x° am Objektiv ausmachen.

Das ist auf jeden Fall genau genug. Beim Ruck muss ich mir was einfallen lassen. Bei längeren Schrittweiten kann man ja über Rampen fahren, ansonsten kommts am ehesten auf das verwendete Objektiv an. Da sind die üblichen Consumer-Objektive nicht sehr geeignet (kleiner Drehwinkel am Fokusring, schlecht gedämpft), aber es gibt ja (und ich habe) durchaus gut gedämpfte manuelle Objektive mit langem Fokusweg (von Samyang oder Voigtländer z.B.), damit dürfte das schon klappen.

Aber mal sehen, ich werde berichten wie es läuft 

Beim FollowFocus werde ich keine direkte Verbindung zum Objektiv herstellen

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

Der Antrieb wird parallel zur Kamera montiert, mit der Welle in gleicher Blickrichtung wie das Objektiv.

Auch eine Montage unter der Kamera wäre denkbar, da ist man mit einem Zahnriemen ja flexibel.

Fürs erste verwende ich diesen Makroschlitten: http://www.enjoyyourcamera.com/Makrozubehoer/Makro-Einstellschlitten/Stereo-Einstellschlitten-LP-02-Verstellweg-24cm::3734.html

Auf einer Schraube meine DSLR, auf der anderen ein Gehäuse mit Motor, Stepdown-PowerSupply und Stepper Brick.

Je nach Objektiv lassen sich dann Motorritzel und Fokusring passend zueinander ausrichten (sowohl seitlicher Abstand als auch nach vorne, Stichwort Parallelogramm).

Ich werde die ganze Anordnung also nie aufs Bild bekommen... vielleicht kann man sich das noch nicht so gut visuell vorstellen, aber bald gibts dann mehr dazu.

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

Ja genau, um das Ritzel und den Fokusring ein stinknormaler Zahnriemen aus der Bucht mit ca. 10-12mm Breite. Die Zähne sollten natürlich zum Ritzel passen, auf seiten der Kamera muss ich noch schauen ob ich da ebenfalls einen Zahnkranz am Objektiv montiere für optimalen Kraftschluss oder darauf verzichte. Das hängt hauptsächlich von der Spannung des Riemens und der Oberfläche des Fokusrings am Objektiv ab, ob da etwas verrutschen könnte.

 

Aber wird sind weit vom Threadthema ab... leider bin ich gestern nicht mehr dazu gekommen den Code nochmal auszuprobieren, aber heute Abend dürfte es klappen.

Wenn das so schonmal funktioniert, werde ich das ähnlich mit dem Setup für den FollowFocus probieren, also PowerSupply und Stepper durch 12V-Bleiakku gespeist, dazu ein Linear Poti und einen Schalter um dem Brick die Endlage des Fokus mitzuteilen und damit quasi das Poti bei jedem Objektiv auf den Fokusweg kalibrieren und den vollen Verfahrbereich für den Fokus nutzen zu können.

 

Da stellt sich mir nun erneut die Frage welche Pins ich beim Linear Poti sowie beim I/O4-Bricklet setzen/auslesen muss um an die Werte zu kommen. zur not schaue ich mir da den Schaltplan an, aber wenn borg das spontan parat hat, wäre ich dankbar

Beim I/O4 würde ich mal vermuten alle vier Pins mit PIO_Get bekommen zu können wenn ich sie als Input konfiguriert habe?

Beim Linear Poti die Werte wohl auch mit dem ADC-Channel, aber muss ich noch Output-Pins setzen? Welche Genauigkeit hat das Poti, 12 oder gar 16bit?

 

Diese Fragen führen wieder zu Nics berechtigtem Wunsch nach einer Art Übersicht/Architekturbeschreibung auf hardwarenaher Ebene...

Man kann sich wohl alles aus Schaltplänen und Quellcode herauslesen, das ist aber schon immer mühsam und nicht für jeden leicht verständlich.