AuronX

Ah, dann solltest du deinen Brick noch flashen/updaten. Am einfachsten an deinen Arbeitsplatzrechner anschließen, beide Taster gleichzeitig drücken und im Brick-Viewer flashen* * Das war gerade die Kurzversion, es gibt auch eine echte Anleitung dazu hier in der Doku.

Da das hier kürzlich schonmal Thema war: Meines Wissens bin ich der erste, der beim Anschließen eines ESC diese Probleme hatte, zumindest wurde nach meinem Fehler die Doku aktualisiert und darauf hingewiesen in bestimmten Fällen auch Masse abzuklemmen. Bei mir sind halt (wenn ich mich recht entsinne) kurzzeitig 2A durch einen Anschluss des Servo-Brick gegangen. Habe zwar schnell abgeschaltet, aber danach war ein Ausgang des Bricks hinüber ^^ Also immer brav nach Doku arbeiten So, jetzt hat der alte Mann seine Geschichte erzählt

Also ich finde das etwas eng... Du liegst halt bei no load bei ~1.2A pro DC, im schlechtesten Fall bei ~20A! Also mir wäre das zu heiß... ich kann mir auch nciht vorstellen, dass das beim Anfahren unter 5A bleiben soll... Ein ESC hingegen würde das locker aushalten und ein Servo-Brick reicht um theoretisch 6 Räder alleine anzusteuern (auch wenn du dann 6 ESC bräuchtest )

Ich habe gerade meinen Master geupdated und ne Minute lang draufgestarrt, nur um das nachzuvollziehen ^^ Also meiner blinkt nicht ^^ (Genauso wie deiner normalerweise wohl auch ^^)

Ich bin mir fast sicher das schonmal gelesen zu haben, finde es aber in der einschlägigen Tabelle gerade nicht: http://www.tinkerforge.com/de/doc/Software/Bricklets/Temperature_Bricklet_TCPIP.html#Temperature.set_temperature_callback_threshold Beim Reached-Callback und den Optionen Inside und Outside: Muss ich das als min < x < max oder als min <= x <= max lesen? ich werde vermutlich gleich noch den Source-Code eines Bricklet dazu bemühen, aber es sollte auch dokumentiert sein (Falls ich nicht einfach nur blind bin).

Tatsächlich habe ich schon überlegt die Bricklets zu generieren... aber das wird nicht gut gehen. Ich weiß nicht so recht, ob es sich lohnt die Bindings einzubinden, nur um einen Stapel wohl dokumentierter ints zu erhalten. ... Ha, Idee! In diesem Pull Request habe ich einen Generator für ein DeviceIdentifier-enum gebaut. Dieses enum werde ich nutzen! Viele Grüße Jan P.S.: Habe jetzt auf Decorators umgestellt und dem AmbientLightBricklet direkt noch den Analog-Wert spendiert. P.P.S: Mir ist grad aufgefallen, sobald die Reached-Callbacks unterstützt werden sind ja ganz viele Bricklets feature-mäßig abgedeckt

Ich würde eher vom SingleValueDevice abgehen wollen und den Decorator umsetzen. Das Device ist nicht flexibel genug, was passiert bei mehr als einem Wert? Was wenn ich ein Device habe das mehr kann (Bricks) UND außerdem noch einen Wert mit Callbacks usw. anbietet. Aber falls dir das mit dem Decorator gar nciht gefällt sag es mir bitte

Du kannst schauen welche Devices vor dem "Knopfdrücken" (egal ob lokal oder remote) vorhanden sind und welches Gerät danach neu ist. Bestimmt kann man da unter Linux auch drei Kommandos aneinanderreihen um das automatisch zu finden (grep, diff oder so... Mein Liebling ist cat... hihi Katzen...) Viel Spaß beim Löten!

Puzzlebarkeit finde ich gut. Mir fällt auch gerade nicht ein warum es ein Nachteil sein könnte das zu haben...

Zu der Wiederverwendbarkeit in den "einfachen" Bricklets: Ich habe gerade mal ein AmbientLight-Bricklet auf Grundlage einer neuen Basisklasse implementiert. Sagt mal ob das cool ist (also insbesondere wie die Subklasse dann implementiert wird). Viele Grüße Jan P.S.: Das Konzept "Callback" werde ich auch noch versuchen etwas wiederverwendbarer zu machen... Nachtrag: Ich habe gerade eben noch ein Barometer-Bricklet auf Grundlage des Decorator-Pattern erstellt. Ich glaube das ist bisher meine liebste Variante. Sie ist sehr mächtig und trotzdem recht übersichtlich. Schaut es euch mal an, wenn es keine Gegenstimmen gibt werde ich das existierende Temperature-Bricklet und das AmbientLight-Bricklet auch auf dieser Grundlage bauen.

Der untere Prototyp von Loetkolben ist ungefähr das was ich mir als kleine Bastelplattform vorstelle: Eine "Reihe" Bricks + Bricklets. Finde ich gut. Was ich nicht erkenne: Wie viele Bricklets kriege ich jetzt bestenfalls bei Loetis Löchern auf die kleine Platte? 2 oder 4? Die große Platte die ihr schon probehalber geschnitten habt ist natürlich auch cool, wäre aber für viele meiner Gedanken überdimensioniert. Für größere Aufbauten wird es aber sicherlich geeignet sein.

Ich bin erstmal total begeistert, dass das Feedback so positiv ist @The_Real_Black: Was die Wiederverwendbarkeit innerhalb der Bricklets angeht habe ich auch schon hin und her überlegt. Das Problem ist, dass auch die "einfachen" Bricklets sich dann in Details unterscheiden können. Ich denke Unterschiede wie int, uint und short kriege ich noch über Templates beseitigt... Aber was ist mit unterschiedlichen Callbacks usw.? Wegen Randomize/SetNewValue: Lässt sich denke ich so umsetzen, hier bin ich mir noch unsicher ob es eine gute Idee ist das im "Tick" zu machen oder ob es davon unabhängig sein sollte. Glaube aber schon, dass es okay ist. Eine andere Möglichkeit wäre es den Setter für den Wert auch public zu machen und dann kann es von außen auf dem Device gesetzt werden. Macht aber vieles unbequemer glaube ich... Danke euch

Zusammenfassend: Sie wird an alle geschickt die zum Zeitpunkt des eintreffens verbunden sind. In Beispiel 2 ist das nur zufällig niemand. In einer RFC-Style-Doku würdest du dazu etwas in der Art lesen: Clients MUST NOT rely on receiving only responses they have requested. (so oder so ähnlich) @Loeti: Da ich nicht glaube, dass du Zeit (oder gar Lust) dazu hast vollständige Bindings im Alleingang zu implementieren wäre vermutlich mein bester Rat an dich abzuwarten bis TF die Shell-Bindings veröffentlicht hat. Die sind ja dann quasi genau für dich gemacht. Da solltest du auch frühzeitig anfangen TF zu bitten Feedback geben zu dürfen Das Protokoll ist roh eben nicht so lecker wie die gekochten Bindings

So hat es photron beschrieben, wenn es so läuft, dann ist alles "normal". Ah, das (begrenzter Speicher) ist eine sinnvolle Erklärung für das Kaputtgehen der Routingtabelle. Dementsprechend sollten Bindings grundsätzlich damit umgehen können. Btw. ist eigentlich in der Doku vermerkt, dass man auch Pakete kriegen kann die man nicht gefordert hat? Das wäre noch was ^^ Sollte wie immer nur da stehen, dann weiß man es. Dennoch: Kann im (Software-)Brickd die Routing-Tabelle auch kaputtgehen? (abgesehen von Programmierfehlern) P.S.: Oh mein Gott TF, beeilt euch mit den Shell-Bindings

Hallo, einfach um mal darauf aufmerksam zu machen: https://github.com/NobodysNightmare/TFStackEmulator Quasi seit gestern Abend arbeite ich an einem Stückchen Software das per TCP ansprechbar ist und so tut als wäre es ein Brick-Stack. Das heißt man kann mit beliebigen Bindings (oder auch dem Brickv) eine Verbindung dazu aufbauen. Wozu das ganze? Naja, eigentlich wollte ich mich nur noch weiter mit dem TF-Protokoll vertraut machen und rumprogrammieren. Aber wenn das ganze etwas umfangreicher wird könnte es tatsächlich auch anderen Leuten etwas nützen, weil sie ohne die echte Hardware ihre Programme und Tools testen können. Was kann es schon? Der aktuelle Stand ist eher knapp, das Wesentliche: - Eine Klasse zur Simulation des Stacks - Eine Klasse um den so einen Stack per TCP verfügbar zu machen - Ein Bricklet: Temperatur (unterstützt GetTemperature, den TemperatureCallback und Enumerate) - Ein Testprogramm das einen Stack mit zwei Bricklets startet (auf Port 4224) - ein wenig Architektur drumherum Das ganze ist recht modular angelegt, aber der Code ist durchaus noch durchwachsen. Clean Code mischt sich mit hacky Code Was habe ich vor? Mein Fancy-Ziel ist es ein paar Standard-Bricklets zu implementieren und dann ein per Datei konfigurierbares Programm dafür zu schreiben. In der Art: <stack> <brick type="master" uid="myu1d"> <someMoreConfig /> </brick> <bricklet type="temperature" uid="myu2d"> <range min="20.0" max="24.0" /> </bricklet> </stack> Für einige Bricks würde sich vermutlich auch eine Visualisierung des aktuellen Zustands anbieten, ich glaube da kann man sich noch tausend Dinge ausdenken Falls euch das nicht alles zu langweilig klingt höre ich gerne noch mehr verrückte Ideen oder Feedback

Das gilt ja quasi auch für alle Anwender oberhalb von TCP/IP ^^ Aber eben nicht auf TCP/IP-Ebene, weil da hat sich ja alles geändert ^^ Was ich mich gerade noch frage: Diese Pakete die da übrig waren: Warst du wirklich verbunden während die Antwort kam oder hast du dich verbunden nachdem die Antwort kam? Für den Fall, dass die Pakete nur dann kommen wenn man "zufällig" zur gleichen Zeit verbunden ist, würde ich das by-Design Argument so unterschreiben kurze Planänderung: Ich schließe ich Loeti an und frage doch nochmal nach dem "Warum?". Also warum ist es sinnvoll dann zu broadcasten? Falls aber die Nachrichten einfach später an den nächstbesten der sich verbindet zugestellt wird, würde ich es allgemein nicht verstehen.

There is a preliminary Description for the weatherstation online: http://www.tinkerforge.com/en/doc/Kits/WeatherStation/WeatherStation.html (in case you missed it )

Verdammt. Das habe ich übersehen, sorry. Sogar mit Begründung Ganz genau. Ist eigentlich nur Spielerei, aber ich habe gerade Spaß daran gefunden Ich werde nochmal mehr dazu schreiben, wenn ich glaube, dass es für jemanden nützlich sein könnte. Dass JavaLaurence was macht habe ich noch nciht mitbekommen, da muss ich glatt mal ins englische Forum wandern ^^ Vielen Dank Jan

Ich habe zwei weitere Dinge entdeckt (weil ich gerade selbst die Brick-Seite implementiere): 1. Es wird nicht klar dokumentiert, dass alle Callbacks die SequenceNumber 0 haben müssen. Es gibt einen Beispiel-Callback in der TCP-Doku, mir war aber erst durch lesen des Quellcode klar, dass Callbacks zwingend Sequence-Number 0 haben müssen. Der Zweck dessen ist mir ebenfalls nicht klar. 2. Wenn bei einem Setter ResponseExpected auf 1 gesetzt wird, was wird dann als Antwort erwartet? Eine exakte Kopie des Paketes? Oder nur der gleiche Paketheader mit leerem Payload?

Btw. ich finde das neue Protokoll cool. Aber es ist sicherlich nicht darauf optimiert mittels Shell-Scripten implementiert zu werden... dennoch spannend, dass es offenbar möglich ist Ansonsten glaube ich, dass einige deiner Probleme nicht spezifisch für das Protokoll 2.0 sind, sondern eher auf zum Teil neues Verhalten im brickd (unabhängig vom Protokoll) zurückzuführen sind.

Benutzt du auf den anderen PCs (die die mit dem IO4 interagieren) die Funktion set_configuration? Falls ja: Setzt du dabei das ResponseExpected-Flag? Falls auch hier ja: Wartest du auch ab bis dir die Antwort geschickt wird? Ich vermute du hast das Flag gesetzt obwohl du es lieber gar nciht gesetzt haben willst.

Schon alleine dafür ein fettes +1 Obwohl bei mir immer die Bandbreite zum Problem wurde wenn plötzlich alle mitspielen wollten ^^ Aber ist der cronjob mit 5 Minuten nicht etwas arg selten falls es mal heißer wird?

Farben finde ich gut, falls das geht (im Sinne von: preiswert verfügbar). @flashen: Also ich schau dabei nie auf die Knöpfe sondern drücke einfach nur beides gleichzeitig ^^

Ich würde vermuten, dass ein serieller Port unter linux so aussehen kann edit: Und wie sich herausstellt, ist diese Vermutung falsch! Bei mir (Windows) habe ich an diese Stelle COM1 geschrieben ^^ Das mit python-serial und argparse habe ich schon wieder vergessen, sorry. Bei mir war argparse glaube ich vor-installiert (mit python zusammen), serial musste ich mir im Netz suchen... da lobe ich mir das gute alte apt-get

Gute Ideen werden fix umgesetzt ^^ Ich melde auch Bedarf an, nachdem meine Spanplatten die ich extra für TF gekauft habe noch immer unbearbeitet (ohne Löcher) herumliegen und die meisten meiner Bricks noch immer im Lieferkarton wohnen Da sieht euer Prototyp schon richtig lecker aus!