Nic

Die JS-Bindings von Tinkerforge verwende ich serverseitig in einer node.js Anwendung ohne Probleme, allerdings erstmal nur sehr banal. Callback-Werte des AnalogIn wird direkt an ein Display http://www.yoctopuce.com/EN/products/usb-displays/yocto-minidisplay von yoctopuce ausgegeben. Wofür sich die WebWorker innerhalb einer TF-Projektes ideal verwenden erschließt sich im Moment zwar nicht ganz, aber für langweilige Statusausgaben könnte ich mir vorstellen das zu verwenden.

Das klingt ob du mit der Materie dich schon lange beschäftigst, bist aber neu hier, oder ? Warum soll das aufwändig sein ? Wieso ich dachte du wolltest das über RS232 Protokoll machen, also doch nicht ?! Wenn ich den Breakout richtig verstanden habe, ist dieser nur zum Abgreifen der Datenleitungen gedacht aber nicht um Kommandos an die Brick CPU zu senden. Oder mag mich jemand korrigieren ? BTW Die neuen Bricklets dürften in den nächsten 1-3 Wo u.U. rauswachsen, dann hast du ein ganz "frisches" Teil als Lösung

Aha danke, Raphael. Und die Tinkerforge Bindings lassen sich dann auch innerhalb dieser WebWorkers serverseitig verwenden ?

Diese WebWorker kenne ich so noch nicht, klingt aber sehr interessant. Lässt sich das Prinzip der WebWorker auch für eine serverseitige node.js Anwendung einsetzen, oder muss ich da was beachten ?

Hmh, interessant beide "Welten" könnte man so zusammenbringen, indem der Arduino an die USB-Host-Buchse des RED angeschlossen wird. Dann müsste sogar das uploaden und deployen von Sketches auf den Arduino klappen wofür ja eig. nur ein serielle Schn. verwendet wird. Die USB-Buchse eines Bricks arbeitet quasi nur als Client und ist kein USB-Host.

Link ? Techn.Spec...? Toll Na und, wozu dieser Hinweis ? Lass die Dinger dran, und mach die Kommunikation mittels serielle Schn. ?! Warum sonst über RS485 ? Wird das dann nicht komplizierter ? PS: Hast du mal im Forum unter dem Begriff "RS485" gesucht, also das was ich da finde... http://www.tinkerunity.org/forum/index.php/topic,3073.msg19202.html#msg19202 http://www.tinkerunity.org/forum/index.php/topic,2599.msg16917.html#msg16917 Die Extension ist eig. mehr gedacht um versch. TF-Stacks kabelgebunden miteinander kommunizieren zu lassen.

Wenn ich mich recht erinnere hat ein Arduino UNO an Board nur: UART, SPI, TWI (I2C). Alles andere muss zusteckt werden über Shields. Robin meinte u.U. dass du die RS485 mit der RS232 bzw. UART verwechselt hast. Wenn ich nur Arduino lese wüsste ich nicht welcher Platinen-Typ nun genau gemeint ist. Beschreibe deine Hardware und was du erreichen möchtest so genau wie möglich ansonsten wird das hier ein Ratespiel wofür es meist kein Feedback gibt Mir ist bisher auch nur bekannt die Kommunikation zw. einem PC und dem Arduino über die serielle Schn. zu gestalten, ev. mal danach googeln, z.B.: http://maheo.eu/463-bidirektionale-serielle-kommunikation-zwischen-arduino-und-pc.php

Sorry ich meinte das nur ganz generell, eine mögliche Erweiterung/Anpassung in den JS-Bindings für Webworkers.

Oh, sehr interessant. Besten Dank, mchott. Webworkers http://www.w3schools.com/html/html5_webworkers.asp kannte ich noch nicht. Aber im Prinzip besser als die ständige Anbindung zum GUI, und wenn ich es richtig verstanden habe, durchaus geeignet im Falle der asynch. Brick-Callbacks z.B. mit w.onmessage = function(event){ document.getElementById("result").innerHTML = event.data; };

Das wäre prima, welches Teil würde auf den Nema 17 Motor passen ? Kauf den Schrittmotor OHNE aufgeflanschtes Getriebe, bei der Chinaware wäre ich mir nicht sicher, ob die sich so einfach auseinander nehmen lässt. Verkauft diese Firma auch an Privatleute ?

Lässt sich die Geschwindigkeit nicht auch ermitteln aus Raddrehzahl und -umfang ?

Ein sehr interressanter Bericht zur Lagebestimmung von Fzg unter http://mechlab-engineering.de/2014/03/tinkerforge-imu-zur-lageerkennung-von-fahrzeugen/

Wieso ich dachte die Preise sind bekannt ? Es reicht auch grob wohin der Preis geht, dann haben wir hier eine gewisse Vorstellung von den Gesamtkosten. Ich habs später gesehen, dass die Getriebe einzeln gibt, allerdings werde ich aus den Angaben nicht schlau. Das muss natürlich auf dem Schrittmotor passen und adaptierbar sein. Schrittmotoren werden i.d.R. in der Bauform Nema 16,17,23 etc. gehandelt: https://de.wikipedia.org/wiki/Schrittmotor#Baugr.C3.B6.C3.9Fe Vielleicht machst du den Thread im Projekt-Forum http://www.tinkerunity.org/forum/index.php/board,3.0.html neu auf und berichtest über deine Fortschritte quasi als Blog.

Prima, danke. Aber welchen hast Du genommen ? Das sind alles DC-Motoren... Und den Motor willst du an den Stepper-Brick anschließen ? Gib mal so eine grobe Hausnummer für den Preis deines 1:3900 Getriebes an.

Zugegeben die Infos sind "etwas" versteckt, und nicht immer so beschrieben, dass sofort der Groschen fällt: http://www.tinkerforge.com/de/doc/Kits/WeatherStation/Construction_REDBrick.html#starter-kit-weather-station-construction-red-brick Power-Supply weglassen, und nur (von unten nach oben) RED-Master-Ethernet und die Stromversorgung ausschließlich über USB (-Netzteil) am RED. Alternativ bietet sich an eine Ethernet mit integrierter PoE Stromversorgung.

Aha, du möchtest den Timer zumindest im LCD Bricklet haben damit dieser von sich aus den Callb. auslöst. Das alleine wäre sicher noch möglich, und da du fit in C Programmierung bist könntest du die Firmware (openSource) auch gleich selber anpassen. Dann noch schnell die Bindings etc. Einige Pioniere haben das wohl schon geschafft, z.B. Status LED ein/ausschalten. Ich persönlich möchte meine Zeit und Nerven schonen, und mache solche Dinge dann lieber im RED. Wenn es nicht Topsecret ist gib doch einfach mal einen Link vom Getriebehersteller an, wo wir Forenteilnehmer uns das auch mal genauer anschauen können. Du kannst davon ausgehen, dass nicht nur ich von einer DIY Astronachführung träumen

Damit ist eigentlich schon gesagt wo dieser Puffer oder Message Queue hingehört: Zum Raspi/RED oder den HostPC, denn nur dort kannst du die TF-Bausteine auch registrieren wie du es schon machst: Und dieser Vorgang ist nur in deiner Application möglich. Sowas kann der LCD bzw. alle Bricklets nicht. Du möchtest dir den ganzen Aufwand der Timer-Implem. und Logik der Abarbeitung sparen durch einen Automatismus angesiedelt im LCD. Das wird es nicht geben bzw. die Hardware gibt das nicht her. Und genau für solche Zwecke wurde der RED konzipiert um quasi das "OnDevice-Programming" mittels beliebiger Sprache zu ermöglichen. Aber du machst das schon mit einem Raspi, der RED ist aber wesentlich kompakter. Sei mir nicht böse wenn ich nochmal nachfrage aber die Astro-Nachführung interessiert mich schon sehr, darum nochmal die Frage um was für ein Getriebe mit 1:3900 handelt es sich ?

Wo gibt es denn sowas für Schrittmotoren ? Du willst das also noch vor den Getriebemotor spannen ? Wie stellst du dir das vor ? Bzw. wo "lebt" dieses Object ? Das LCD ist erstmal dumm und kennt die anderen Bricklets gar nicht. Grundsätzlich sind die Callb. dafür da, veränderten Status oder Zustandswerte im Bricklet/Bricks an den HostPC zu liefern. Das was du möchtest ist ein Timer in deiner Anwendung, der periodisch die Werte ermittelt, puffert und in einer bestimmten Logik im LCD ausgibt. Wenn ichs richtig verstehe sind mit Sensorik beliebige Bricklets gemeint, die hängen alle an Bricks, die wiederum mit dem HostPC kommunizieren. Welche Sensoren ermittelt werden, musst du aber in deiner Software selbst programmieren. Ich kann mit nicht vorstellen, dass das sonst nur durch API Anpassung im LCD machbar wäre.

Welche Sensoren ? ich dachte du baust eine Astro-Nachführung ? Soviele Sensoren braucht die nicht Also du möchtest in einem zentralen Timerevent alle Werte der Sensoren getten ? Nein wieso, muss es es auch nicht. Warum ist das ein Problem ?

So ganz habe ich es nicht verstanden: Welcher Baustein/Objekt/Klasse soll den Callb. auslösen ? Ich bin nicht der c++ Profi, aber es dürfte auch in dieser Progr.sprache möglich sein, eigene Timer festzulegen die periodisch etwas tun, also unabh. von der TF-API. Andererseits ist es immer günstiger die Callb. der Bricks zu nutzen statt zu pollen, und z.B. die Stepper.ReachedPosition http://www.tinkerforge.com/de/doc/Software/Bricks/Stepper_Brick_C.html#STEPPER_CALLBACK_POSITION_REACHED zu nutzen wenn der Motor eine gewünschte Position erreicht, im Callb.-Handler des Steppers würde ich dann den Text in den LCD schreiben.

Warum geht das beim LCD20x4 ? Wird es dann versch., ladbare Schriften (-Größen) geben oder haben wir dann den vollen Zeichenbereich zum Rendern von was auch immer ? Ist wieder auch die direkte Zeilen/Spaltenaddressierung wie beim LCD20x4.WriteLine möglich ? Sehr praktisch wäre das Dimmen der OLED-Lichtstärke so wie beim Segm.4x7 Bricklet...

So so da sind schon wieder neue Bricklets in Arbeit: https://github.com/Tinkerforge/oled-128x64-bricklet Werden die OLED-Bricklet kleiner oder gleich der typischen Brick-Form von 4x4cm bleiben ? Habt ihr ev. daran gedacht auch 2 oder 4 Taster-Eingänge am Bricklet zu ermöglichen, also wie beim LCD20x4 ?

Du brauchst zwecks Netzwerkanbindung nicht unbedingt die Ethernet-Ext. Bei Platzproblemen würde ich eher einen WLAN-Stick an den USB Port stecken und die Wetterstation (LAN-)kabellos betreiben.

Wenn der RED zum DesktopPC via USB verbunden ist, gibt es noch die Möglichkeit über die Console im BrickV zu arbeiten: http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#console-tab-konsole-fernsteuerung Ja z.B via Putty, aber benötigt Netzwerkverbindung zum RED, also Ethernet-Ext oder WLAN-Stick aus dem Shop oder von hier http://www.tinkerunity.org/wiki/index.php/DE/RED_USB. Dann ist sogar Fernwartung möglich z.B. via VNC (tightvncserver) oder via RDP von Win (xrdp). Noch eleganter, da Insellösung Wetterstation, den RED Stack abschließend als AccessPoint festlegen: http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#wlan-access-point

Scheint mir auch so, also die Bindings liefern dieses Feature noch nicht, zumindest die C# und Delphi Src sind noch nicht angepasst. Also (noch) nicht verwendbar mit der API ...