Nic

Sorry, ich muss nochmal nachfragen ob auch dieser Servo mit Gearbox problemlos am Servo-Brick läuft: http://www.servocity.com/html/spg785a-5_0_servo_gearbox.html Im Video wird davon gesprochen, dass der Servo ein PositionFeedback über Potentiometer eingebaut hat und somit ein ClosedLoop System darstellt. Gibt es dabei beim Servo-Brick etwas zu beachten ? Speziellere Ansteuerung als bei einem ohne PositionFeedback ? Gibt es ev. sowas Vergleichbares bei einem Hersteller oder Händler in Germany ?

Das ist alter Hut und wurde nicht dem aktuellen Stand angepasst, das wurde aus dem Viewer entfernt wg. dem hier: http://de.blog.tinkerforge.com/2012/4/29/stepper-brick-update Das Decay kann man nur noch über die API einstellen und steuern.

Damit ist meine Frage beantwortet http://www.tinkerunity.org/forum/index.php/topic,676.msg4176.html#msg4176

Also Servos mit der Zusatzbezeichnung "Digital" dürfen nicht verwendet werden ? Oder gilt das nur für die von Robbe ?

Servos sind bei mir Neuland, drum frag ich nach, lässt sich dieser an den Servo-Brick anschließen: http://www.modellbau-seidel.de/index.php?firma=Robbe-Modellsport&best=F1333&name=Futaba-Servo-S3010

Da muss ich dir recht geben http://www.hy-line.de/firmengruppe/hy-line-computer-components/hersteller/nextwindow/ Allerdings trifft das m.E. nur zu auf die einfachste Touchscreen-Bedienbarkeit zu. Für Multitouch bedarf es eigener Treiber. Schließen die Standard-HID-(Maustreiber) die Kalibrierung mit ein ??

Hmmh, die Lochrasterplatinen dachte ich erstmal nur als tragendes Gerüst. Entweder man steckt über das ganze zum Schluß ein Alu-Viereck-Profil oder schraubt noch Abdeckplatten aus Kunststoff/Alu auf.

Lochrasterplatten finde ich schon mal gar nicht schlecht. Aber warum nicht gleich in einer festen Größe als Boden- und Deckplatte, daran wird der Stack angeschraubt und per Winkel 4 Seitenwände zum Abdecken.

Zur Gehäuse-Problematik habe ich einen eignen Thread aufgemacht, wäre ev. besser dort weiter zu diskutieren: http://www.tinkerunity.org/forum/index.php/topic,761.0.html

Ich nehme mal borgs Kommentar, um hier mal ein neues Thema zwecks Diskussion, Erfahrungsaustausch etc. zu eröffnen, das wie ich finde, recht stiefmütterlich bisher behandelt wurde: passende Gehäuse für die TF-Bricks und Bricklets. Mit den Gehäusen von Conrad und Co war ich bisher nicht zufrieden, die sind zu schmal, zu hoch oder nur rechteckiger Form. M.W. gibt es kein geartetes Gehäuse-System, das der Stabelbarkeit der TF-Platinen entgegen kommen würde. Welche Vorschläge, Wünsche oder Ideen für passende Gehäuse für die Bricks fallen Euch ein oder wie habt Ihr das Housing-Problem bisher gelöst ?

I.d.R. sprechen die meisten von TF-Projekte oder Lösungen, die meist nur stationär zuhause benutzt werden. Was ist aber wenn man das Projekt mobil also unterwegs mit auf Reisen mitnehmen möchte und in den Bergen oder in der Natur einsetzen möchte. Ein angeschlossenes Netbook ist mir zu kloppig, und die Bedienung über Tastatur oder Maus ist einfach zu umständlich. Wenn es darum geht ein Prozess zu starten, stoppen oder Parameter zu ändern, wäre ein TabletPC oder Touchscreen hilfreicher. Den RaspPi könnte man genausogut in die Gerätschaft integrieren. Der Strom-Verbrauch ist sehr niedrig. So wie ich das sehe, ist die einzige Unbekannte das HID und Treiber passend zum RaspPi.

@chariowalda Lies mal bitte mein neues Topic zum RaspPi, vielleicht hast du ein paar Tips für mich: http://www.tinkerunity.org/forum/index.php/topic,757.msg5047.html#msg5047

Sorry für die ev. dämlichen Fragen, aber ich bin in Sachen Rasp (noch) keine Leuchte. Nehmen wir an ich programmiere in FreePascal eine Anwendung mit GUI zum Steuern der TF-Teile für die Zielplatform Linux. Welche Linux-Distribution wird auf dem RaspPi unterstützt ? Und welche Eingabe-Geräte kann ich an den Rasp anschließen ? Würde auch ein Touchscreen unterstützt ? Bzw. welche Monitore kann man dort anschließen ? Das ganze Packet aus Rasp, Display und TF-Teile (über Funk) soll mobil sein. Würde es machbar sein über ein billiges Android Tablet via Wifi den RAspPi zu steuern ?

@chariowalda Das wäre prima, dann kommen wir hoffentlich hier zu einem guten Ende und die Sache ist schnell vom Tisch. PS: Möchte nicht indiskret sein, wozu brauchst Du 10 RaspPis ?

Richtig, habe ich auch gesehen. Und wenn das TF ändern sollte, bitte auch gleich den Fehler bei der Timebase Funktion: Die Zeitdehnung (Timebase) bei Rampenfahrten NICHT zu berücksichtigen wenn Acc bzw Deacc gleich 0 sind. http://www.tinkerunity.org/forum/index.php/topic,214.msg4988.html#msg4988

Habe das Maximum ermittelt und komme bis auf 897,5 Lux. Bei direkter Sonneneinstrahlung komme ich etwa auf 880 mit LED Lenser P5 oder Blitzgerät direkt über Sensor erreiche die 897,5 Lux. Dies ist aber nicht aquivalent zu der Tabelle aus http://en.wikipedia.org/wiki/Lux Dieser Link wurde aber in der Doku zum AmbientLight angegeben. http://www.tinkerforge.com/doc/Hardware/Bricklets/Ambient_Light.html#ambient-light-bricklet Wie ist dann das Verhältnis zw. beiden Messbereichen

Komisch, bei mir sind alle Versionen gleich wie bei dir. Danke, trotzdem.

Welche Version steht auf deinem Ambient Bricklet ?

Was hat das mit dem Topic Thema zutun ? Nun gebe ich extra einen Hinweis die Diskussion auszulagern ! Ein Paradebeispiel dafür wie "gründlich" hier im Forum die Beiträge (wenn überhaupt) gelesen und reflektiert werden.

@TF TThread.CurrentThread gibt es erst seit Delphi2009. Ersatzweise kann man aber auch Windows.GetCurrentThreadId <> callbackThread/receiveThread.ThreadId ähnlich wie im FPC Teil setzen. Wäre schön wenn diese beiden Zeilen angepasst werden könnten und die Callbacks unter protected wandern. Ansonsten kann ich die Bindings ohne Anpassungen nicht unter meine Kapselung legen.

Jungs, macht bitte einen eignen Thread für die PHP-Diskussionen auf.

Meine Anwendung lässt sich prima mit den neuen Bindings kompilieren und ausführen. Einziger Showstopper: TThread.CurrentThread im IpConnection.Destroy ist in Delphi 7 unbekannt. PS: Wieso hast du statt den Out-Parameter nicht Records verwendet ?

+1 Nur eine Kleinigkeit: Die Callbacks z.b. im Brickstepper sind unter private deklariert, somit sind sie für den Nachfahren unsichtbar und können nicht überschrieben bzw. erweitert werden. Ich habe z.B. in meiner Ableitung folgendes: function TBrickStepperEx.CallbackPositionReached(data:TBaseArray): Integer; begin result := inherited CallbackPositionReached(data); ... end; Die Callbacks habe ich beim Vorfahren ins protected geshifted, um dann in der Ableitung zu überschreiben: function CallbackPositionReached(data:TBaseArray): Integer; override;

@borg Sind Acc und Deacc. = 0 wird trotzdem die Timebase für die Rampen berücksichtigt. Das ist Unsinn. Es sollte möglich sein, auch eine Kombination von z.B. 8000/8616 (Velo/Timebase) einzustellen ohne die Beschleunigung abzuwarten. Kannst du nachstellen indem man einmal 10/15 bzw. 1000/1500 als MaxVelo/Timebase einstellt. Sieht man auch am Stepper State sehr schön.

Was brütest du denn aus Ich würde das ev. genauer beschreiben, welche Tiere und warum die Ausfallsicherheit so wichtig ist. Ev. fällt dann der Groschen und man sieht die Wichtigkeit des Watchdog-Features. http://de.wikipedia.org/wiki/Watchdog Bis jetzt habe ich den Eindruck, daß man sich nix darunter vorstellen kann, deshalb das laue Feedback.