Nic

Also bleibt in dieser Hinsicht das Verhalten gleich dem alten Protokoll. Ist es technisch im neuen Protokoll nicht möglich auf das Abschalten eines Funk-Slaves mit Disconnect via Enum-Callback auszulösen ? Oder sieht man die Notwendigkeit nicht, dies in die API einzubauen ? Eine Methode eines nicht mehr erreichbaren Device nur durch eine TimeoutException auflaufen zu lassen ist m.E. zu hart. Es wäre praktischer, in der Implementation auf ein Disconnect so früh wie möglich reagieren zu können, um den funktionellen Kontext dieses nicht mehr erreichbaren Devices en bloc abzuschalten. Z.B. möchte ich für den User im GUI den Teil dieses Devices komplett disablen, um weitere Funktionsaufrufe zu unterbinden. Nicht immer schaltet man bewußt den Funk-Slave ab, dies kann ganz unerwartet geschehen, weil die Energieversorgung oder die Funkverbindung (zu weite Entf., störende Wände etc.) ausfällt.

Wie würde das neue Protokoll auf die Situation reagieren, wenn ein Funk-Slave -egal ob via Chibi oder WIFI - abgeschaltet wird, also keine direkte Kabel-Verbindung vorliegt ? Wird dann auch der Enum-Calbback ausgelöst ? Erkenne ich das Disconnect ? Muss ich mich als Entw. darum kümmern, das Brick-Objekt am IPConn abzumelden, zu lösen bzw. die Instanz zu destroyen ? Oder wird die Referenz zum IPConn durch das Destroy des Objektes gelöst ? Was passiert bei Neustart des gleichen wireless Brick-Objektes am Stack ?

http://de.blog.tinkerforge.com/ Das sieht schon mal gut aus Besonders die 4x4cm. Hmhh, das nächste Weihnachten wird für uns teuer: GPS, OptoIO... Wird der QuadRelay auch mit Steck-Verbinder kommen ? Und wieso ist man bei den (zumindest für mich) praktischeren Schraubanschlüssen wie bei den IOs nicht geblieben ?

Kann ich nur zustimmen, so ein Schnittstellen-Bricklet fehlt noch und wäre universell einsetzbar.

Was meinst du mit laut ? Wenn mein DualRelay nicht klick macht, würde ich was vermissen... Da wird es noch das Quad-Relay geben, vielleicht ist das auch brauchbar für dich. Besonders gefällt mir bei den neuen Ind-Bricklet der 4x4cm-Formfaktor.

Worauf hatte der Thread-Eröffner extra hingewiesen !? Ev. mal den ersten Beitrag genau lesen. Also ist Dein Ansatz keine Alternative. Habt ihr mal darüber nachgedacht, dass man ev. so mit einem schicken WIFI oder Chibi-Funk-Extension u.U. einen Stack betreiben möchte, an dem ein RS232-Bricklet den Anschluß jeder beliebigen RS232-Hardware zuließe...Vielleicht gibt es das eine oder andere Sensor-C3POxyz-Exoten-Teil, das nur über den üblichen RS232 verfügt. Nicht alles kann als Bricklet-Klon erwartet werden. Und nicht immer möchte/oder kann man weitere Treiber und Frameworks zumergen. Und dann ? wie kommen die RS232-Signale in die Anwendung ?

Bei Deinem Ansatz fehlt mir ein Soft-oder Hardware-Adapter von RS-232 > Net, also etwas was die RS-232 Signale umwandelt fürs Network. Der PC hat keinen COM-Port, sondern ev. nur ein Netzwerk-Anschluß. Die o.g. Hardware Teile wie z.B. RFID-Reader, die ich universell in die TF-Applkation einbinden möchte, haben aber i.d.R. nur einen serial-Port. Anders gefragt wo ist bei Deinem Ansatz der Ersatz für ein echtes RS-232-Bricklet ?

Interessant, und wie würde ich dann die RS232-Hardware (wie z.b. der o.g. RF-ID-Leser) anschliessen bzw. einbinden und programmatisch in einer TF-Anwendung ansprechen ?

Mögliche Alternative: http://www.tinkerunity.org/forum/index.php/topic,951.msg6659.html#msg6659 Aber bisher hat das noch kein User so anwenden können. Da ist jede Menge Forschungsarbeit nötig.

http://www.tinkerforge.com/doc/Hardware/Bricks/Stepper_Brick.html Mindestspannung ab 8V ! Nochmals, dass ist erstaunlich. Im Brick-Viewer müsste eig. der UnderVoltage-Callback http://www.tinkerforge.com/doc/Software/Bricks/Stepper_Brick_Java.html#BrickStepper::setMinimumVoltage__i auslösen, solange die Schwellspannung von 8,5V nicht auf einen anderen Wert eingestellt wurde. Natürlich, z.B. in Java: http://www.tinkerforge.com/doc/Software/Bricks/Stepper_Brick_Java.html#BrickStepper::setMotorCurrent__i Decay: http://www.tinkerforge.com/doc/Software/Bricks/Stepper_Brick_Java.html#BrickStepper::setDecay__i Precondition für Decay: setSyncRect auf true: http://www.tinkerforge.com/doc/Software/Bricks/Stepper_Brick_Java.html#BrickStepper::setSyncRect__boolean Interressant, eine Stage in Schrittmotoraufl. für die Materialprüfung. Hätte ein Hubmagnet oder Aktuator http://www.a-drive.de/produkte_aktuatoren.php#idea nicht auch gereicht ?

Ich würde Dezember um Weihnachten und Sylvester eher empfehlen, dann haben wir ev. mehr Zeit für die eine oder andere Anpassung/FW-Upgrades etc. Was bedeudeten die Funktionen ? Ist das eine Implementation von uns oder eine aus der neuen API ? Was beduetet das für die Extensions ? Bleiben die davon unbeteiligt ? Beschreibt eindeutig den Typ des Bricks oder Bricklets ?

Ev. interressant für die Rasp- und/oder Basic-Anhängerschaft hier im Forum. Vielleicht lässt sich das mal in Zukunft mit TF-Teilen mergen. http://www.golem.de/news/elternkompatibel-tinybasic-one-fuer-raspberry-pi-1210-95381.html

RS232 Befehle zu senden und empfangen würde auch mich interessieren. Wie würde das auf Seite der Implementation aussehen. Welche API Calls gibt es dafür ?

Röntgenstrahler-Dioden, wie bitte, wo gibt es denn sowas ?

Ganz so abwegig ist das nicht ! Ich habe mir oft genug zusätzliche Lötpunkte/Stifte auf den Bricks gewünscht, um extern 5 V einspeisen zu können, jetzt mal unabhängig wegen irgendeiner Extension. Wie war das nochmal Tinker=Bastelware ?! Um nicht immer die USB-Buchse zu nötigen, und weil die praktischerweise immer frei bleiben sollte wg. diverser FW-Upgrade-Orgien , habe ich mir eine Alternative geschaffen, um extern 5V anzulegen; wenn auch sehr umständlich und aufwendig über die BoardToBoard-Connectoren. Dazu fällt mir eine Idee für eine neue Brick-Platine ein: so ein Experimentier-Board mit freigelegten Pins zum Einspeisen eigener Lösungen wie Lipos usw. ein BreakIn-Brick...

Wenn ich neue Funktionalität anfordere, bin für Update-Orgien bereit und helfe gerne mit um das Problem aus der Welt zu schaffen. Aber man könnte als Kunde schon erwarten wenn eine aktuelle Lieferung ins Haus kommt, diese eine Major-Version hat die stabil und lauffähig ist. Wenn ich unbedingt die neuesten Feature haben möchte, muß ich zwangsläufig upgraden. So was kenne ich nicht, ich benutze immer noch mein altes Handy und habe damit weniger Stress Und autom.Update oder verselbstständige, eigenmächtige Betriebssysteme oder Software sind mir ein Graus...

D.h. erst übers Upgarde der FW kann ich das DualDisplay an allen Ports benutzen. Übrigens das mitbestellte AnalogOut zeigt das gleiche Verhalten. Sorry, aber bei frisch bestellter Ware sehe ich das nicht so recht ein. Die Upgrade Orgien von Bricks und Bricklet sind m.E. in letzter Zeit zu häufig.

Die bei der Bestellung (16.10.2012) gültige FW auf Master und DualRelay. Die Nummern habe ich jetzt hier nicht. Mittlerweile habe ich den Master auf die 1.4.4 upgegraded, das DualRelay bisher ohne Upgrade.

Gilt das ev. auch für die anderen Bricklets ? Ich habe vor einer Woche einen neuen Master plus DualRelay erhalten, das Bricklet lässt sich aber nur an Port B und D betreiben, ansonsten wird im Viewer nur der Master angezeigt. Und was sind NOPs ?

@brium-brium Ich kann nicht so recht glauben, daß die Spannung bei 3,8 V eingestellt war. Gem.Spezifikation benötigt der Stepper-Brick extern mindestens 8 V. Das Piepen lässt sich entweder über die Decay-Function sehr gut reduzieren - ich stelle i.d.R. 62000 ein- und/oder indem die Stromstärke soweit reduziert wird, daß die Last mit dem Schlitten ausreichend bewegt werden kann. Die Load capacity von 8 bzw 3kg sind Grenzwerte und erfordern max.zulässigen Strom am Motor. Du musst also prüfen ob für die Last, die du bewegen möchtest, nicht eine geringere Stromstärke ausreichend ist. Bei Erhöhung der Spannung nimmt die Lautstärke des Pfeifen auch zu. Ebenso die Schrittauflösung von Voll, zu Halb oder Viertel oder Achtelschritt haben einen Einfluß darauf. Die Sachen von Standa machen einen guten Eindruck, darf man erfahren wozu du die Stage einsetzt ?

Du sollst die WIFi Ext. nicht anschließen, also der Master-Brick mit dem IO4 alleine und die Ext.Type auf None setzen, warum sollte es dann mit der WIFI zu tun haben !? Ansonsten scheint die Ext.Pinne vom Master-Brick auf den Typ RS485 dauerhaft gesetzt zu sein, ich hatte das Problem mit RS und Chibi, Abhilfe schaffte die alte FW 1.1.7. Im Anschluß upgrade auf neuere FW 1.4x or whatever.

Hast Du mal versucht die Master-Extension vom Master-Brick zu löschen, also weder RS485, WIFI oder Chibi im Master-Brick zu hinterlegen. Ext.Type also None. Geht es dann mit Master und IO4 ? Hatte vorkurzem ähnliches Problem (http://www.tinkerunity.org/forum/index.php/topic,929.0.html), eine RS485 war noch weiterhin gültig im Eeprom obwohl eine Chibi am Master angesteckt war.

Zu 1): Wenn ich für die Master-Chibi-Adresse statt 0 eine 1 vergebe, geht das problemlos. Komisch ich dachte eine 0 als Master-Adresse wäre legitim. Zu 2): Geht auch mit dem o.g. Workaround weiterhin nicht, alle Bugfixes auch im Zusammenhang mit WIFI und/oder RS485 haben nichts bewirkt: http://www.tinkerunity.org/forum/index.php/topic,715.msg4598.html#msg4598 Ich kann einen bestimmten Slave nur dann verbinden und kommunizieren, wenn die Slave-Liste im Master-Chibi entsprechend angepasst wird, d.h. alle Slaves, die nicht gebraucht werden, aus der Liste entf.

Ich habe immer noch Probleme mit den Chibi-Ext. Im bestehenden Funknetz von 3 Chibi-Slaves - im Master-Chibi wurde dazu als Slave-Adressen 1,2,3 hinterlegt - möchte ich einen 4. hinzufügen. 1) Doppelbelegung der Slave-Adresse Um diesen 4.Empfänger mal schnell zu testen, habe ich als Adresse statt der 4, die 1 im Slave angegeben, also quasi doppelt belegt. Alle anderen 3 sind aber nicht in Betrieb. Trotzdem bekomme ich keine Verbindung zw. Master und Slave. Zumindest im BrickViewer nicht zu sehen. Wenn ich mich recht erinnere, sah man aber den Empfangspegel des Master-Chibis bei ca. 39dBm im BrickV; war der Slave aber ausgeschaltet bleib dieser Wert bei 0. Warum sehe den Slave nicht, sondern erst wenn ich alle Slaves einschalte und dem 4. und neuen Chibi-Empf. die Adresse 4 vergebe ? Gibt es hier ein Darstellungsproblem im BrickViewer ? Werden die Slave-Adressen im Master-Chibi mit der Uid zusammen abgelegt, sodaß ein weiterer Slave, mit der gleichen Adresse abgelehnt wird ? 2) Uraltes Problem, ich hatte das auch hier im Forum seit April gemeldet und langsam wird mir das zu bunt beim Betrieb von 5 Slaves. Wenn eines der Slaves (aus der im Master-Chibi hinterlegten Liste) nicht eingschaltet ist, sind alle nachfolgenden der Liste nicht erreichbar. Soll heißen wenn ich nur den 4.Slave (Add.4) benutzen möchte, muss ich alle anderen von 1-3 einschalten. Ist das so gewollt ? Ich möchte die Empfänger in versch.Situationen einsetzen können, manchmal benutze ich nur 2+3, oft aber nur 1+4, nur alleine 3 kann auch sein. Master-FW 1.4.4, BrickD, BrickV auf aktuelle Version.

Maybe that could be an alternative, slightly massiv and strong, but who cares... http://nodna.de/MicroRAX