Nic

Sorry, aber wenn ich mir die Dimensionen und Massen vorstelle, die da bewegt werden sollen, vermute ich spontan, der Motor ist mit 2A und den (theoretisch) erreichbaren Haltemoment von 3Nm unterdimensioniert. Und die Schnecke an der Antriebswelle scheint ohne große Übersetzung an die Abtriebswelle das Moment weiterzugeben. Das Moment wird bei Microschritt bzw. höherer Drehzahl geringer. Für den optimalen Wert sind immer die Leistungskurven der Datenblätter hilfreich. Ich hoffe mal das Motorwellenende ist noch mit einem Kugellager gesichert. Es fehlt auch die Angabe der verwendeten Spannung.

Ja, was solche marginalen Dinge angeht wie eine TVersion auch in C# etc., d.h. wenn strukturell, typmässig die Bindings zw. den Sprachen sich angleichen. Ev. gilt das auch für Out-Parameter, m.E. etwas unhandlich. Andereseits kann jeder sein "Werk" auf GitHub oder hier ins Forum stellen, dass dann in Gemeinschaftsarbeit weitergepflegt wird. Wenn ich mich recht erinnere war das auch mal Dein Vorschlag

Das hört sich alles ganz toll an, man möge aber beachten, das die Bindings mehr die "Rohmasse" sind um eine API auf Low-Level zur HW bereitzustellen. Die Java/Pascal/C#-Bindings müssen dann auch noch harmonisch auf diversen Betriebssystemen Linux/Mac/Win bzw. Frameworks laufen. Da würde ich mit OOP etwas später eingreifen bzw. gibt es keinen Grund der dagegen spricht, sich seinen individuellen, komfortableren Framework selbst um die Bindings zu stricken. So eine eigene Klasse/Enum der die Konstanten vorhält ist doch nun wirklich schnell geschrieben.

Achso, ich gebe die IP des Ethernet-Adapters ein, dann geht es, prima. So kann ich auch leben Besten Dank für den Support, macht einen ordentlichen Eindruck das Linux Mint.

Ok hab die 386er installiert, macht aber leider keinen Unterschied: 2014-01-28 17:21:41.252338 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized) 2014-01-28 17:24:56.840644 <I> <event|event_posix.c:56> Received SIGTERM 2014-01-28 17:24:56.843266 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped 2014-01-28 17:24:57.666483 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 d1 started (daemonized) 2014-01-28 17:25:43.714787 <I> <event|event_posix.c:56> Received SIGTERM 2014-01-28 17:25:43.715163 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped 2014-01-28 17:26:10.046376 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 d1 started (daemonized) 2014-01-28 17:27:22.907076 <E> <usb|usb.c:462> Could not get product string descriptor for USB device (bus: 2, device: 5): LIBUSB_ERROR_TIMEOUT (-7) 2014-01-28 17:27:22.907484 <W> <usb|usb.c:134> Ignoring USB device (bus: 2, device: 5) due to an error 2014-01-28 17:27:47.786948 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1) 2014-01-28 17:27:49.827485 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer 2014-01-28 17:27:50.493746 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1) 2014-01-28 17:27:51.809221 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer 2014-01-28 17:27:52.512658 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1) 2014-01-28 17:27:53.368523 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer 2014-01-28 17:27:54.033496 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1) 2014-01-28 17:27:54.684388 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer 2014-01-28 17:27:55.302781 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1) 2014-01-28 17:27:55.996481 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer 2014-01-28 17:27:59.343869 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1) 2014-01-28 17:28:01.270628 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer Wenn ich den BrickD Win-Service im Host alternativ ansprechen würde, was müsste ich im Linux-BrickV (bei Host) innerhalb der VM einstellen ?

Mit dem Acer Notebook bekomme ich von der VM und lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 16d0:063d MCS Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub less /var/log/brickd.log liefert 2014-01-24 20:58:21.357996 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized) 2014-01-24 20:58:37.087027 <I> <event|event_posix.c:56> Received SIGTERM 2014-01-24 20:58:37.087337 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped 2014-01-24 20:58:37.205487 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized) 2014-01-24 20:58:46.524644 <I> <event|event_posix.c:56> Received SIGTERM 2014-01-24 20:58:46.524952 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped 2014-01-24 20:58:46.642851 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized) 2014-01-24 21:07:29.623794 <I> <event|event_posix.c:56> Received SIGTERM 2014-01-24 21:07:29.624567 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped 2014-01-24 21:51:28.316948 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized) 2014-01-25 17:21:50.310211 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized) 2014-01-25 17:24:26.523655 <E> <usb|usb_stack.c:278> Could not reset USB device (bus: 2, device: 4): LIBUSB_ERROR_NOT_FOUND (-5) 2014-01-25 17:24:26.523787 <W> <usb|usb.c:134> Ignoring USB device (bus: 2, device: 4) due to an error 2014-01-25 17:24:53.016590 <I> <event|event_posix.c:56> Received SIGTERM 2014-01-25 17:24:53.016820 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped 2014-01-26 12:46:47.685704 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized) 2014-01-26 12:46:49.676619 <E> <usb|usb.c:462> Could not get product string descriptor for USB device (bus: 2, device: 4): LIBUSB_ERROR_TIMEOUT (-7) 2014-01-26 12:46:49.676716 <W> <usb|usb.c:134> Ignoring USB device (bus: 2, device: 4) due to an error 2014-01-26 11:58:19.597320 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1) 2014-01-26 11:58:24.559746 <I> <network|client.c:74> Client (socket: 16, peer: 127.0.0.1) disconnected by peer 2014-01-26 11:58:25.217027 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1) 2014-01-26 12:00:18.249378 <I> <network|client.c:74> Client (socket: 16, peer: 127.0.0.1) disconnected by peer 2014-01-26 12:04:13.392488 <I> <event|event_posix.c:56> Received SIGTERM 2014-01-26 12:04:13.397809 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped 2014-01-26 12:07:16.359836 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized)

...was dann auch für alle anderen Bricks Stepper, Servo, DC zwecks FW Flashen bedeutet ? Mir ist immer noch nicht klar was das bedeutet, wenn ich die FW auf einem USB-Stick habe, der alternativ am USB-Host vom RED steckt ? Die FW könnte nicht autom. vom RED detektiert und an den passenden Brick gerootet werden ? Aber dann müsste der RED den Brick selber in den Bootloader schalten, was auch per SPI nicht geht ? @AuronX: Der Erase müsste auch nach draußen geführt werden. Um den Brick in den BoLoader Modus zu bringen.

Normalerweise nicht. Ich nehme an du hast brickd über das .deb Packet installiert, dann läuft der als root und sollte keine Probleme haben auf die USB Geräte zuzugreifen. Ich meinte, ob zur Laufzeit dem Linux-System über Rechtevergabe an den BrickV der direkte Zugriff an ein bestimmtes USB-Device erlaubt wird. Ich hoffe Du meinst das Download-Paket von TF, dann ja, es mussten aber noch einige Dependencies für den BrickV via Internet während der Install. nachgeladen werden. Mit den Linux eigenen Begrifflichkeiten bin ich nicht bewandert, ich bin schon froh, dass ich soweit gekommen bin Ja. Ja, also zumindest über die Toolbar-Leiste des VMWare Players, rechts oben. Dort werden alle relevante HW des Host eingeblendet und lassen sich connecten.

Die TF Software (BrickD bzw. -Viewer) wurden komplett installiert. Anschl. die VM restartet, Master-Brick durchgereicht (Disconnect from Host), letzteres wurde im Host System überprüft. Dort wurden keine Bricks mehr dargestellt. Auch mehrmaliges Einbinden, Connect und Disconnect, Restart der VM haben keine Änderung gebracht. Ich hatte testweise alle Schritte auf einem 2.PC durchgeführt aber auch dort alles ok bis auf das kein Brick angezeigt wurde. In beiden VMs wird ein MCS-Master-Brick durchgereicht. Verbinde ich beide PC (A+B) über WLAN-Router, kann ich einen Brick-Stapel von (A) wenigstens via IP-Angabe im Viewer von (B) sehen und benutzen. Ich bin kein Linux-Experte, kann es an speziellen, lokalen Rechten für USB-Devices in Linux liegen ?

Hallo, ich habe mir auf dem Host-PC (Win7x64) eine VMWare mit der aktuellen Linux Mint 16 XFCE eingerichtet. Installation von BrickD und Viewer war ohne Probleme. Im Host werden die Bricks im Viewer einwandfrei dargestellt, nicht aber im Linux System. Obwohl der Master-Brick vom Host an die VM erfolgreich durchgereicht wird, gibt es im Viewer keine Anzeige von Bricks und Bricklets. Allerdings auch keine Fehlermeldungen. Any ideas ? Gruß, Nic

Hmh, erstmal wichtiger wäre den Stack nicht immer zu demontieren, wenn geflasht wird. Gut möglich dass so ein embedded System später irgendwo schwer zugänglich verbaut ist. Über das "wie die FW den Devices zugeführt wird", wäre ich nicht so wählerisch.

Es gibt sogar einen "Mechanical Kit", also die Frames, Schrauben, Lager etc. ohne Elektronik ohne Servos zu 65$. Ev. ließe sich so ein Kit ins TF-Sortiment mitaufnehmen ??

Wenn es ich es noch richtig in Erinnerung habe, durch das OS-eigene USB-Pooling. Aber sind die 1000/sec dann eher ein Benchmark in der Theorie ? Ja, aber nur aufgrund der o.g. Prämisse. SPI würde aber für die Zukunft u.U. mehr Performance nach oben hin möglich machen, oder zumindest zuverlässiger als USB die 1000/sec Benchmark treffen ?

Sehr interessant , u.U. inspirierend fürs nächste Roboter-Hacking http://www.golem.de/news/roboter-uarm-der-industrieroboter-fuer-den-schreibtisch-1401-104084.html

Zum Thema Callbacks heißt es für PHP und beispielsweise den Temperature-Bricklet unter http://www.tinkerforge.com/de/doc/Software/Bricklets/Temperature_Bricklet_PHP.html#callbacks Die Beispiele für Callbacks in PHP sehen vernünftig aus, warum wird hier aber trotzdem davon abgeraten ? Wenn das mit Callbacks schlechter funktioniert als "teueres" Polling mit Getter-Funktionen, dann sollte ein Hinweis in die Doku rein "vom Benutzen der Callbacks in PHP ist abzuraten, weil... usw" oder bitte von den PHP Experten genauere Erklärungen, ansonsten wirkt das u.U. hier für Unsicherheiten. Edit: Hab es jetzt erst gesehen, damit hat man erstmal eine Vorstellung. Ich würde es ev. als Randnotiz in die Doku aufnehmen, solange die PHP-Bind. noch nicht redesigned sind.

Beim RasPi werden die Bricks/Bricklets direkt am USB Port angeschlossen, also werden die 1000/sec (theoretisch) je nach Host-Betriebssystem-"Bremsen" erreicht. Beim RED-Brick erfolgt aber die Kommunikation zw. Host-PC und Bricks/Bricklets über die Board2Board-Connectoren bzw. über das SPI-Interf. wozu aber noch die Treiber geschrieben werden müssen, d.h. die 1000/sec sollten dann im Idealfall auch praktisch erreicht werden !? Es dann zusammen 3 Varianten des OnDevice-Progr. möglich: 1) C-Coding direct auf den 32-Bit ARMs der Bricks wie schon einige Freaks in der Vergangenheit gemeldet haben 2) Hochsprachen auf dem raspPi, Kommun. via USB 3) Hochsprachen auf dem RED, Kommun. via SPI

Das kann versch. Ursachen haben, erstmal mit dieser todo Liste überprüfen: http://www.tinkerforge.com/de/doc/FAQ.html#faq

batti, worauf beziehst du dich in dem letzten Satz ? Meinst Du das andere Topic ?

Ja, BiDi ist nötig, allein um von Temperatursensoren Messwerte zu erhalten, die z.B. die Wetterstation erreicht.

RX/TX würde mir erstmal reichen, aber ich bräuchte das zeitgleich zum Stack-Betrieb, solange es kein RS232-Bricklet gibt.

Heißt das entweder nur GPIO oder nur Stack-SPI ansprechbar ? Aber nie beides gleichzeitig verwendbar in meiner Anwendung ? Wäre das für die RS232 auch möglich, ev. wäre eine RS232 universeller als GPIOs ? Hmh, alternativ könnte man einen USB-RS232 von FTDI in den USB-Host stecken, aber da könnte schon ein WIFI-Stick stecken, was mich zur letzte Frage treibt: Wieviel Strom liefert der USB-Host max, den Standard von 500mA ?

Hmh, aber das ist nicht der Hintergrund für die Probleme der alten Chibi-Ext. oder Bremse für deren Neuauflage? Bzw. es dürfte der Grund sein warum aus einem RemoteSwitch-Bricklet kein vollwertiges "Chibi" machen könnte ?

RED V1: * Könnte der USB-Host und HDMI-Port jeweils als Mini-USB bzw. Mini-HDMI ausgelegt werden, damit u.a. eine RS-232 da noch raufpasst (vorausgesetzt der Chip unterstützt das ? * Andere entfernte Funk-Stacks, mit denen im Verbund kabellos kommuniziert werden soll, können wir alternativ über einen WIFI-Stick im USB-Host lösen ? * Anschluss der Bricklets: Also wie immer über die Bricks, wobei der Master quasi nur als Bricklet-Hub fungiert ?

Aha, verstehe, darum werden die Extensions nicht unterstützt. Der Master ist in V1+2 arbeitslos Ok, ansonsten haben wir keine Möglichkeit der kabellosen Übertragung zu verteilten Stacks. PS: Lötkolben meint das hier http://www.elv.de/controller.aspx?cid=758&detail=10&detail2=31

Ok und nicht ok, dann hatte ich es bisher falsch verstanden. Selbst in Variante 1 dachte ich werden alle Bricks/Bricklets und Ext. nahtlos wie im PC Betrieb wie wir es jetzt haben unterstützt. Also hat der Master-Brick in Variante 1+2 eine andere Arbeitsweise als unter V3. V3 wäre quasi: am "RaspPi" sind die Bricks per USB angeschlossen und kommunizieren darüber ? In V1+2 geht es über Board2Board also SPI ?