Nic

Vorher weißt du wenn Du nicht davorstehst, in welche Richtung du gegensteuern musst ? Wäre da zumindest ein 2.Hall nicht notwendig, sozusagen wie beim Encoder die Phasenverschiebung die Richtungsinfo gibt. Bei der Skizze kann man nicht so gut sehen ob die Hydraulikzylinder direkt gegenüber oder diametral stehen ?

Die max. mögliche Distanz des Line Bricklet liegt nur bis zu 10mm. Also recht nah zum Target, da sollte Lichteinwirkung nicht so stören. Ansonsten etwas abblenden. Wenn es nur um Linienerkennung gehen muss sollte Lichteinwirkung nicht eine so große Rolle spielen zumal der Demonstrator indoor betrieben wird, bei Distanzmessung stimme ich dir zu. Wenn ich Deine Bilder richtig deute ist der Tisch in seiner Mitte am Kardan "aufgehängt" ?! Dann hast Du nicht nur in der Vertikalen einen Hub sondern musst auch die Seitwärtsbewegung und die Bewegung quasi in Z-Achse (also auf die Sensoren zu) beachten, dann würde ich ev. eher zu mehreren Sensoren tendieren, wenn die Ausgleichs-Bewegung recht flott ist. Der Hall braucht einen gewissen Mindestabstand je nach Feldstärke des Magneten damit er "schaltet". Ev. auf das Magnetfeld der Motoren achten damit diese nicht den Hall stören.

Verstehe, aber die 3 oder mehrachsigen IMUs so bei Sparkfun etc. kosten auch schon ab 20 Euros, allerdings braucht es dafür I2C oder SPI Bus und das ist bei der TF-Archtektur nicht offen. Ev. lässt sich das mit 2 Line Bricklets jeweils an der Hydraulik lösen die erst dann ein Signal liefern wenn Linien eines Zieltargets (am Wackeltisch ) deckungsgleich sind. Das dürfte aber nur bei kleinen Hub gehen.

Da würde ich eher zum IMU Brick tendieren. In der Vergangenheit wurden hier im Forum sogar Projekte zur Stabilisierung für Kameras vorgestellt.

Noch eine kleine Randnotiz: VirtualBox kann sogar ein VMDK-Image aus VMWare ausführen, das o.g. Localhost Problem der Bricks tritt dabei nicht mehr auf .

@TF: Habt ihr schon einen Favouriten für die Linux-Distro ? Ev. kann man sich mal eine VM anlegen und damit warm werden . Manjaro soll z.B. besonders benutzerfreundlich sein und die Netbook edition ideal für kleine Display: http://www.heise.de/open/artikel/Anwenderfreundliches-Arch-Linux-Manjaro-Linux-0-8-9-2122579.html

Was ist damit gemeint ? Touchpad ? Soll das ein TFT-Display mit Touchscreen http://www.reichelt.de/Touchdisplays/FAYTECH-T7-SW/3/index.html?&ACTION=3&LA=2&ARTICLE=87444&GROUPID=6219&artnr=FAYTECH+T7+SW sein, der per HDMI am RED angeschlossen werden könnte, allerdings werden die Touch-Signale i.d.R. via USB oder Seriell an den PC übertragen. Diesbezgl. bin ich nicht der Experte, aber wie sieht es in der Praxis aus ? Wenn erstmal die WIFI-Ext. aus SPI-Treiber Gründen erstmal nicht ansteht, wie sicher ist die WIFI Komptabilität der Sticks, die es auf dem Markt gibt. Es muss zumindest eine Möglichkeit der Kommunikation zw. dezentralen Stacks geben.

Bei den von Elro bzw. Intertechno wie oft muss man da das Signal wiederholen damit es der Gong "behält" ?

Möchte einen Funk-Gong http://www.conrad.de/ce/de/product/552517/Funk-Gong-Weiss-80-m-433-MHz mit dem RemoteSwitch auslösen. Bei der Anlernmethode gem. Anleitung http://www.produktinfo.conrad.com/datenblaetter/550000-574999/552517-an-01-ml-FUNK_GONG_de_en_fr_nl.pdf kann mittels RemoteSwitch Einschaltimpuls tatsächlich der Gong ausgelöst werden, aber nur solange man die Anlerntaste des Gongs durchdrückt. Auch wenn ich die Repeats verlängere, kann sich der Gong den RemoteSwitch Impuls nicht "merken". Woran liegt es ? Gibt es noch einen Trick 17 ?

FlyingDoc, ev. blöde Frage, aber auf dem ersten Bild, rechts oben, welches Brick ist das obere Teil ? Gut möglich ist es umgedreht aufgesteckt, aber dann verstehe ich nicht warum ich beim Master auf den USB-Port schauen kann

Du hast meine Frage falsch verstanden, diese bezog sich auf den Aufwand, das EncoderBricklet unbedingt so zu modifizieren, dass du eine höhere Auflös. als die 24 Steps bekommst. Die Bricklets werden nur relativ niedrige Freq. auslesen können, also nur niedrige Drehzahlen unterstützen. Aber dann frage ich mich wozu noch einen Encoder. Benutzt du keinen Schrittmotor ?

Ich benutze meine TF-Projekte fast ausschließlich Offroad, und habe die Einfachheit der Chibi gegenüber der WIFI Ext sehr geschätzt. Weiteren Vorteil sehe ich in der Sicherheit eines Chibi Netzes gegenüber WLAN. Für eine große Reichweite bin ich durchaus bereit einen höheren Preis zu bezahlen. Offroad noch mit einer Richtantenne für WIFI rumlaufen zu müssen ist unpraktikabel. Joergs Vorschlag eine Extension mit variablem Funkmodul ist gut und bietet Flexibilität. Ist schon richtig für banale Datenerfassung wie z.B. Temperatursensoren wäre ein neues Chibi ev. oversized und teuer, das gilt aber auch für die WIFI-Ext. und erst recht für den RED Brick. Aber für eine solche banale bidi-Kommunikation könnte man aber genauso gut das RemoteBricklet so anpassen, das dieser von sich aus senden kann und zwar an ein 2.RemoteSwitch. Mir war so in Erinnerung das borg das mal vorgeschlagen hatte. Wenn es für Tinkerforge zu hohe Entwicklungskosten bedeutet, eine völlig neue Chibi-Ext. herzustellen, dann macht alternativ eine begrenzte Neuauflage der alten Chibi. Wenn ich mir die Resonanz der letzten 24 Monate anschaue, wurde die Funk-Erweiterung sehr oft nachgefragt. Wenn ihr Euch trotzdem nicht sicher seit ob Nachfrage besteht, macht einfach mal eine Poll/Umfrage.

Dim, wenn dir die Garantie egal ist und du Profi in E-Technik bist einfach selber ausprobieren Aber auch hier gilt eine Grenzfrequenz analog zum DI4 zu beachten, theor. 1kHZ da alle 1ms das Bricklet ausgewertet wird, aber in der Praxis würde ich eher von den gesicherten 250Hz ausgehen. Ist den der Aufwand gerechtfertigt, macht es Sinn bei so niedrigen Drehzahlen einen Encoder zu benutzen ?

Damit liegst du weit über der theoretischen übertragungsrate der TF-Bricks via USB, also 1ms. Bei den gemütlichen 100 steps/sec könntest Du auf den Encoder aber auch verzichten. Wieso brauchst Du diesen Closed Loop ?

Mal was ganz anderes, aber es gehört zum OnDevice Thema, und wir haben das doch etwas übersehen. Aus aktuellem Anlass (Die Threads zu Encoder etc.) zur Klarheit nochmals nachgefragt: Wir hatten vor Monaten darüber disskutiert wie zumindest nur Steuersignale direkt an Bricks/Bricklets übertragen und dort weiterverarbeitet werden könnten (http://www.tinkerunity.org/forum/index.php/topic,1219.msg7466.html#msg7466) und damit nicht den "langen" und zeitkritischen Umweg über USB an den Host PC zu gehen. In wieweit ließe sich das mit dem RED managen ? Beispielsweise Events von Endlagenschalter direkt ans Stepper-Brick, Encoder Signale direkt am Brick ausgewertet etc...

Tom, über Synchronität von TF-HW bitte hierzu aufmerksam folgendes Lesen: http://www.tinkerunity.org/forum/index.php/topic,1427.msg9136.html#msg9136.

Wenn Du 4 Eingänge detektieren möchtest, würde ich eher zum IO4 Bricklet tendieren. Den RotaryEncoder sozusagen "aufbohren" dürfte die Garantie auflösen u.U. auch zu einer Anpassung der Firmware führen. Aber da alle TF Bausteine über USB zum Host kommunizieren, gibt es Grenzbereiche zu beachten siehe den Post von TomF. Noch eine Bitte: Diese Forum ist für alle und alle Branchen gedacht, der eine oder andere Fachausdruck (Differenzial Encoder, PPM, Closed Loop oder CPR aus Nachbar Thread dürfte nicht der Mehrheit bekannt sein und bevor wir uns die Finger wundgoogeln bitte den Sachverhalt je nach Problematik so detailliert und einfach beschreiben, ansonsten ist die Chance auf Feedback doch sehr gering.

Gut möglich, im Link, den ich Dir angegeben hatte, werden max. und fehlerfrei 250Hz genannt. Tom, warum brauchst Du überhaupt den Encoder ? Schrittmotoren sind i.d.R. recht genau in ihrer Positionierung wenn man auf vernünftige Beschleunigungs- und Bremsrampen achtet.

Hier in diesem C# Beispiel einer WindowsForm wird GUI sicher gearbeitet, und AuronX Empfehlungen quasi exakt abgebildet: http://www.tinkerforge.com/de/doc/Kits/HardwareHacking/RemoteSwitchGUI_CSharp.html#schritt-5-alles-zusammen

Oh, prima und danke. 0.9 Schritt ist noch besser. Und gutes Sortiment in beiden Shops, da finde ich noch mehr

Nun, ich habe keine Haustiere noch weiß ich adhoc was ein EVG ist. Ich würde empfehlen uns Ahnungslosen mehr Hintergrund-Material mitzugeben ansonsten wird das Feedback fürs Topic bescheiden ausfallen. Spontan zum Thema Dimmen fällt mir nur das RemoteBricklet ein, http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Remote_Switch.html#remote-switch-bricklet je nach Empfänger-Typ wird auch Dimmen unterstützt. Vielleicht lässt sich hierüber die Terariumbeleuchtung geschickter steuern.

Danke Tom. Der Vexta ist übrigens auch nur eine Kundenanfertigung http://forum.orientalmotor.com/viewtopic.php?f=3&t=526 So ein Motor mit N17 und 2,4A ist schon schwer zu bekommen Aber lass gut sein. Aber erzähl mal später wie Deine Erfahrungen mit DI4 und dem Encoder sind. So Fallstricke etc. Das dürfte hier im Forum nicht nur mich interessieren

Nicht schlecht für die kleine Nema Größe 17 und 2.4A/Phase ziemlich stark. Gibt es so ein Teil überhaupt für Endkunden bei Appl.M ? Wenn ich mich am HT17-068 orientiere hat der 8 Litzen, wie schließt Du die am Stepper Brick an ?

Tom, falls Du daran noch nicht gedacht hast, beachte den Grenzwert für die maximale erkennbare Frequenz des DI4: http://www.tinkerunity.org/forum/index.php/topic,1786.msg12342.html#msg12342 Nur so aus Interesse welchen Schrittmotor+Encoder verwendest Du ?

Es muss nicht unbedingt am DC liegen. Funktioniert der Master standalone via USB ? D.h. wird er im Viewer dargestellt ? Wie sieht es mit der Stromversorgung via PowerSupply aus ? Hängt aber am external DC-IN nochmals eine Stromquelle ? Ist der Stack bestehend zumindest aus PowerSupply, Master, WIFI einwandfrei einsatzbereit ? Gibt es alternativ noch ein weiteres Brick, dass man an den Master anschließen könnte um zu prüfen ob die Board2Board-Connectoren defekt sind. Während DC und Master Brick verbunden sind, hängt dann am DC schon ein Verbraucher/Last ?