Nic

Dürfte das nicht etwas riskant sein von der Logikspannung des Stack zu zehren, nicht das die Stack-Kommunikation etwa zusammenbricht oder angeschlossene Bricks oder Bricklets unterversorgt werden. Sicherer sollte das Power Supply sein und den dortigen 5V out (wie für Raspi).

Ja, aber bei meinem Test bleibt der Stepper an seiner letzten Position stehen und er wird nicht abgeschaltet. Hast Du mal geschaut was die Callbacks OnNewState, OnAllData etc. kurz vor dem Abschalten zurückgeben ? Verstehe ich das richtig, dass du nur vermutest, es könne mit Überhitzung zu tun haben ? Mit den Logs würde ich mich an Deiner Stelle an photron wenden, der hat mit sowas eine ganz gute Nase Sieht mir danach aus dass die Verbindung des Bricks im Stack logisch wegbricht, bleiben die anderen Bricks/Bricklet weiterhin nach Ausfall des Steppers arbeitsfähig ? Fällt dieser auch dann aus wenn du den Stack nur auf Step-Down, Master, Stepper reduzierst ? Oder die Reihenfolge vertauschen, ist es immer der 1.oder2.Stepper im Stack ? Systematisch vorgehen, ansonsten ist die Fehlersuche und Support unwahrscheinlich. Alternativ einen 12V Akku als Stromquelle f. den StepDown ausprobieren. Und beschreibe mal genauer und detaillierter den Aufbau des Stacks und seiner unbekannten Bestandteile wie Netzteil (max.Strom/Leistung), Schrittmotoren (Typ)... Welche Stromstärke ist bei den anderen beiden Steppern, die anscheinend weiter funktionieren oder nicht ? Du schreibst "mein Stepper", aber in der Fußzeile nennst du aber weitere 2 Stepper, wie verhalten die sich ?

Not so easy to find http://www.tinkerforge.com/en/doc/Technical_Data.html#bricklet-connector But if y mean the shielded cable have a look under "more views" https://www.tinkerforge.com/en/shop/accessories/cable/bricklet-cable-shielded-100cm.html

Ok und danke, Unex. Ich kann das noch ergänzen, um Eigenversuch im Freien. Dazu habe aus einer Funksteckdose 440 von Elro die Hauptplatine mit Empfänger ausgebaut und modifiziert. Die Pl. arbeitet intern mit 24V DC ist aber auch noch 12V tolerant. Das Steuerrelais habe ich gegen einen 12V Typen getauscht. Das Auslösen geht weiterhin prima mit der Fernbed. oder RemoteSwitch-Bricklet. Im Freien ohne Hindernisse erreichen ich max. 70m, ist aber stark Richtungsabhängig zum Empfänger. Dieses Max. scheint aber vom Hersteller Elro fix zu sein, d.h. es macht keinen Unterschied ob man mittels FB, RemoteSwitch oder alternativ einen 0815 Sender am Arduino auslöst.

Habe das mal selbst ausprobiert. Der Motor hat noch ein Planetengetriebe vorgeschaltet, und trägt im Haltezustand etwa 1kg im Abst. von 12cm zur Achse. Den Strom von etwa 400mA musste ich so hoch einstellen, dass die Achse die Last gerade noch halten kann und nicht nachgibt. Nach etwa 1 Std. waren die Kühlrippen vom Stepper immer noch "Handwarm" und der Brick weiterhin enabled. Allerdings habe ich im Stack nicht den gleichen Umfang an weiteren Bausteinen wie o.g.

Danke Raphael, also so eine Art Dongle um schneller ins WIFI zu kommen, d.h. ich bräuchte aber trotzdem ein WIFI-Ext. um via TCPIP zu kommunizieren ?

Im Datenblatt der Hardware wird das WIFI/Bluetooth Pairing erwähnt, wozu ist das nützlich ?

@borg Well, from the customer perspective it brings me nothing if a system (OS + TF stuff) can reach "theoretically" the limits of 1000msg/sec and 1 bricklet on 1 brick as the only USB stuff in a system isnt really typical. A lot of people have asked about how fast and reliable they can expect acquisition of data eg. detect encoder or scan signal if its fall or rise. I assume it could be more interesting to complement discussion by your mentioned and committed benchmark of 250hz. BTW, can y give some examples in practice from last couple of month and known projects of customers where the limit of 1000msg was reached on a regular basis ?

https://github.com/Tinkerforge/nfc-rfid-bricklet

Solarmodul > Laderegler > Akku > StepDown > Stack... ? Und welchen Stack willst Du 5 y betreiben ?

Should I remove my comments and hints to prevent any confusion on customer side ? I added links to mining the internals/explanation easier: http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem

"Einen hab ich noch" den kann Unex gerne in seine Liste aufnehmen. Mit diesem Montagekleber hatte ich gute Ergebnisse auch zwecks Eingießen: http://www.modulor.de/Klebstoff-Klebeband/Klebstoffe/Montageklebstoffe/Weicon-Flex-Bond.html Ist weniger gesundheitsschädlich, billiger, muss nicht genau gemischt werden, da 1 Komponente, ist UV-stabil und witterungsbeständig, lösungsmittelfrei und bleibt restelastisch. Kann ggf. nach Aushärtung vorsichtig abgeschält werden.

Trotzdem ein guter Gedanke und dann sind wir schon beim Internet der Dinge/Internet of things oder ? Aber mit GSM wäre mir der Spaß zu teuer, IoT ist aber sicher ein Weg in Richtung Zukunft

Remember 1000 msg/sec is a benchmark in theory, normally an operating system has to handle callbacks, events etc. from other connected hardware devices, too. TF mentioned in this matter a max frequency of around 250Hz or at least 125Hz if a robust or reliable application is needed. http://www.tinkerunity.org/forum/index.php/topic,2253.msg14892.html#msg14892

Was meinst du mit ? Ein GSM Modul mit SIM-Karte ? Oh die sind auch recht teuer.

Für Dauerbetrieb über Monate und länger sind die TF Teile m.E. nicht geeignet, außer man schließt passende Versorgungsbatterien 12v (Auto, Solar; Camping etc.) an und/oder schließt an einen Pufferakku noch ein Solarmodul. Klar mein Vorschlag war auch mehr ironisch gemeint, da für autarke Messwerterfassung viel zu teuer. Kann ich mir überhaupt nicht vorstellen, dass sowas in den nächsten 2+ Jahren auch nur annährungsweise realisiert werden könnte. Ich tippe die Jungs haben mit dem RED finanz- und -technisch erstmal gut zutun.

Also ich habe mit dem RemoteSwitch keine Probleme. Mittlerweile scheint aber eins der ELRO Steckdosen seinen Geist aufzugeben und reagiert sehr unzuverlässig auf Schaltimpulse egal ob vom RemoteSwitch oder der Fernbedienung. Es wird dir ggf. nichts anderes übrig bleiben zumindest den Master und RemoteSwitch auszubauen und ggf. das Bricklet an allen Ports von A-D anzuschliessen oder du hast nochmals ein 2.Paar übrig das du so aufstellt wie dein Aufbau im Normalbetrieb um zu prüfen ob irgendeine Störquelle im Weg ist.

Quatsch Der Verbrauch liegt bei 10mA gegenüber den 110/23mA der WIFI-Ext. Gibt es schon: der RemoteBricklet hat einen Transceiver Baustein damit könnte der RemoteSwitch auch empfangen. Nun ja, dann sind wir u.U. wieder beim OnDevice-Programming wie es ursprünglich konzipiert war. Für einen Standalone-Betrieb mit Senden von div. Sensor-Daten müsste der Master entsprechende API liefern, oder ? Es sei wir lösen es mit dem RED-Brick

Ja wie hoch ist die Last ? Entspricht sie der Leistung des Motors bei der genannten Stromstärke ? Was passiert wenn keine Last auf die Motorwelle im Betrieb wirkt ? Schaltet der Stepper Brick weiterhin ab ? Kann es sein das die 250 mA ev. zu niedrig kalkuliert sind bzw. der Motor zu leistungsschwach für diese Dauerlast ist ? U.U. dem Stepper Brick eine höhere Stromstärke spendieren als ursprünglich angenommen. Ev. Getriebe bzw. Motorbremse oder stärkeren Motor verwenden, dann klappt das auch mit sparsamen 250 mA

Also ich kann mir darunter nix vorstellen, geht es etwas genauer. D.h. es reicht bis zum Bäcker in der Nachbarschaft oder nur ins Wohnzimmer ? Und unter welchen Bedingungen gilt Deine Angabe zur Reichweite ? In/Outdoor, Hindernisse wie Wände etc... Wäre prima so eine Angabe, insbesondere weil in den Spezifikationen nichts angegeben wurde.

Wäre das nicht einfacher http://www.watterott.com/de/RPi-Display

Oders anderes gesagt, damit werden Frequenzen von max. 125Hz zuverlässig vom TF-System unterstützt. Ich hatte diesbezgl. TomF in einem anderen Thread bei der Abfrage von Encoder-Daten und dem DI4 eine max. möglich Frequenz von max 250Hz http://www.tinkerunity.org/forum/index.php/topic,1786.msg12342.html#msg12342 angegeben. Können wir die 125Hz also generell als Benchmark für alle Bricklets betrachten ? Oder habe ich hier einen denkfehler und gilt dies nicht für alle Bricklets zur Frequenzerfassung ?

Hmh, die Austrittspupille vom Okular dürfte zu klein sein, deshalb ist die Projektion wie durch Schlüsselloch Hast Du das Optische System berechnet oder erstmal so pii mal Auge ? Ansonsten bist du auf dem richtigen Weg.

2 Hall pro Hubachse, parallel zur Hubrichtung angeordnet. Damit bekommst Du 2 Signale pro Achse aber zeitversetzt, welcher Sensor sich zuerst meldet bestimmt die Richtung. PS: Schau dir mal den ADXL330 von Segor als preisliche Alternative an und lies dir das ct Projekt mal genau durch: http://www.heise.de/ct/artikel/Shake-rattle-n-roll-292164.html Wenn ich es richtig lese gibt das Beschleunigungsboard die Achsen als Analog Werte zurück.

Hey FlyingDoc, sieht gut aus ! Wird das virtuelle Bild scharf abgebildet ? Wie haste das nun mit der Optik gelöst