AuronX

Hierzu auch als Referenz: https://github.com/Tinkerforge/generators/pull/32

Wenn du weißt wie groß dein Stack ist, dann kannst du zählen. Vollkommen generisch geht es aber leider nicht, weil aufgrund des System-Designs keine Komponente weiß wie viele Komponenten es insgesamt gibt. @The_Real_Black: Die Position ist inzwischen bestimmbar. Hilft aber nicht bei der Vollständigkeitsprüfung, oder?

Ich wage die These aufzustellen, dass gerade Hobbybastler es sich leisten können lange zu warten, aber es sich nicht leisten können viel zu bezahlen. Das macht sowas schon interessant, ist aber natürlich nichts wenn du viel fertigen willst ^^

Also ist der Trick, dass du langsam genug bist um die Schwächen der DC-Motoren ausgleichen zu können, richtig? ^^

Im Zweifel müssten also beide Parteien dafür sorgen, dass regelmäßig Daten über die Leitung gehen. Die Gegenseite könnte dann auf einen Timeout warten um die Verbindung zu beenden. Schade... ich hatte gehofft es reicht das Ganze halbseitig zu implementieren ^^

@HTTP Server Methode: Das würde ich für den passiven Teil so empfehlen. Also beispielsweise wenn der PC immer an den Stack sendet, dass der Stack dann reseted wenn er nix mehr vom PC hört (für x Sekunden). Theoretisch muss der PC auch nur dann Pings senden wenn sonst nix anderes über die Leitung ging. Zum Thema sendall: Mein Vorgehen war dieses: PC <-- Kabel --> Router <--- WLAN ---> Laptop Laptop als Server, PC als Client. Am Laptop WLAN deaktiviert. Jetzt wird auf dem Laptop sofort der Socket geschlossen (logisch, denn das Betriebssystem bekommt ja das abschalten des Netzwerkadapters mit). Auf dem PC dauert es eine Weile (zwischen 5 und 20 Sekunden) bis er schließlich eine Exception wirft. Das ganze unter Windows. Mich wundert es aber, dass dein TCP Stack es offenbar einfach permanent weiterversucht die Daten loszuwerden (bis es dann irgendwann nach 30 Minuten mal wirklich klappt), statt einfach zu melden, dass die versendeten Pakete nicht mehr zugestellt werden konnten (Abbruch). Umgebung ist bei mir wie gesagt pur Windows, sowohl Client und Server habe ich jeweils in Python 2.7 und C# ausprobiert. edit: Ich habe grad nochmal ein wenig im Internet gesucht, aber ich finde keinen Weg einen Linux oder sonst einen TCP-Stack so zu konfigurieren wie du es beschreibst. Überall lese ich, dass der TCP-Stack nachdem er auf einige ACKs vergeblich wartet der Anwendung mitteilt, dass die Verbindung kaputt ist. Sowohl unter Windows, wie auch unter Linux... Finde das äußerst spannend ^^

Da wir hier von einem Ping über TCP sprechen (korrekt?) würde ich sagen, dass ein einzelner Timeout reichen sollte, um eine Trennung zu erkennen. Immerhin hat ja TCP schon genügend Retransmission-Logik, um einzelne Pakete neu zu übertragen. @Lötkolben: "Normale" Pings laufen über ICMP, auch wenn ich kein Experte dieses Protokolls bin, bin ich mir recht sicher, dass es dort keine automatische Neuübertragung von Paketen gibt. Deswegen würde man dort erst nach einigen Timeouts sagen "jetzt ist die Verbindung kaputt". @automatischer Ping: Würde ich optional aktivierbar machen und den Intervall beim Aktivieren übergeben lassen. Bei kritischen Anwendungen möchte man zeitnah über einen Disconnect informiert werden, um beispielsweise über eine zweite Sicherheitsebene eine Abschaltung oder ähnliches zu veranlassen. Bei anderen Anwendungen wäre das nur unnötiger Traffic und einmal in der Minute reicht völlig. Was mir noch nicht klar ist: Du (borg) schreibst, dass auf beiden Seiten nicht bemerkt wird, wenn du das Kabel ziehst. Auf der Seite mit conn.recv kann ich das auch nachvollziehen, aber warum sollte man bei s.sendall nichts mitbekommen? Das hätte ich anders erwartet, werde das aber gleich nochmal testen bevor ich mich hier zu weit aus dem Fenster lehne ^^ edit: Meine erste Quelle im Internet gibt mir recht, aber leider funktioniert das Beispiel von borg auch genau so wie er es beschreibt... ich würde erwarten, dass sendall kaputt geht wenn die verbindung abbricht. Habe es gerade nochmal probiert und diesmal etwas länger gewartet. Nach einigen Sekunden wird beim sendall doch ein Fehler geworfen, also alles gut und so wie erwartet. Dementsprechend: Sobald man den Ping über die normale TCP-Verbindung mitlaufen lässt, wird der Port automatisch geschlossen wenn beim Senden etwas schiefgeht. Ob ein oder mehrmals pingen ist also gar nciht unbedingt die Frage. Man muss sich jetzt nur überlegen welche der beiden Parteien aktiv sein soll und welche passiv. Also senden die Bindings regelmäßig einen Ping und die Extension erwartet diesen oder ist es umgekehrt? Die passive Seite muss dann natürlich trotzdem einen Timeout definieren, ab dem sie die Verbindung als tot betrachtet.

Fairerweise hier noch der Verweis auf jemanden der offenbar nur mit DC-Motoren auch gute Ergebnisse erzielt hat: http://www.tinkerunity.org/forum/index.php/topic,1351.0.html

Also ich hatte schonmal "Problemberichte" gelesen, dass wenn man das USB-Kabel nicht am untersten ELement anschließt, dann die unteren Bricks nicht sichtbar sind und nur alles oberhalb des USB-Kabels. Denke also ein Zerlegen sollte nicht nötig sein. Im Bootloader-Modus ist ja eh nur nen COM-Port da und sonst nix. Ich vermute also es geht. Eine Garantie kann dir aber nur TF geben ^^

The latest C# Bindings should include an accessor for the UID

Ich denke die Klassiker sind Temperatur- und Humidity-Bricklet in Kombination mit dem LCD-Bricklet. Ansonsten sind so ziemlich alle Bricklets für unterschiedliche Zwecke im Einsatz. IO4 und IO16 werden oft genutzt um fremde Hardware anzusteuern, z.B. Funkfernbedienungen usw.

Üblicherweise würde ich einen Pull Request auf Github vorschlagen. Aber wenn Git und Github bisher neu für dich sind wird sich TF sicherlich auch hier über deine Änderungen freuen. LG Jan

Ich hoffe ja in mehreren Punkten auf das Ultraschall-Bricklet. Das steht am Ende der TImeline, bin schon bekannt wenn es dazu mehr Details gibt ^^

Beendest du zwischendurch die IPConnection oder hälst du sie aufrecht?

Ich habe mal ein ähnliches Experiment mit ner Wii-Fernbedienung gemacht. Die hat ja auch Beschleunigungssensoren und ich habe mich gefragt ob ich aus Beschleunigung und Zeit eine Geschwindigkeit errechnen kann. Wie borg schon schreibt: Kannst du vergessen. Du bekommst nichtmal annähernd gute Ergebnisse. Das IMU (und die Wii-FB) ist nur zur Lagebestimmung und Momentanbeschleunigung wirklich gut geeignet.

Sollte es eigentlich nicht geben. Die minimale und maximale Länge eines WPA2-PSK sind spezifiziert und wenn ich behaupte mein Gerät kann WPA2-PSK, dann hat es damit auch klarzukommen. Dass bei TF die Keys auf 50 zeichen begrenzt sind ist also schlicht ein Fehler. Ich will nicht sagen, dass sowas nicht vorkommt, aber es ist denke ich der falsche Ansatz demjenigen die Schuld zu geben der ein langes und dennoch vollkommen standardkonformes Passwort nutzt.

Mal schaun, ich denke wenn borg soweit ist wird er es üblicherweise auch recht schnell veröffentlichen. Aber schonmal als Teaser: Du wirst dann auch dein Master-Brick mit einer neuen Firmware flashen müssen. Wenn dort eine Funktion hinzugefügt wird, dann wird das notwendig.

Glückwunsch zu einem sicheren WLAN-PSK @borg: Ich war gerade am Tippen und beim Absenden sah ich dann deine Nachricht ^^ Ich würde genau das gleiche Vorgehen vorschlagen. Bisherigen Setter lassen und einen neuen Setter für lange PSK's hinzufügen.

@borg: Konntet ihr das Problem inzwischen nachvollziehen, indem ihr keine Callbacks nutzt? Bzw. an andere: Ist das Problem "behoben", wenn ihr (regelmäßig auftretende) Callbacks nutzt?

Das finde ich spannend Borgel, kannst du noch ein paar mehr Details verraten: - In welchem Bereich hast du gemessen (insbesondere max RPM. würde mich interessieren) - Gab es bei hohen RPM irgendwann Messprobleme? Ich würde erwarten, dass du bei deinem Aufbau nicht mehr als 1000 RPM messen kannst... (wohlgemerkt mit TF-Hardware) (dummer Rechenfehler, siehe unten; Minuten sind was anderes als Sekunden!!!!)

@batti: Und wenn die Pads nur auf einer Seite (die interne Seite, also da wo das Bricklet-Kabel ist) angebracht sind? Dann könnte man ja immerhin ein Kabel anlöten und in die Steckerbuchse auf der anderen Seite stecken. Dann müsste man schon im gleichen Stecker zwei Kabel einfädeln damit es Rauch gibt, sehe ich das richtig?

Okay, wollte es auch nur mal anmerken bevor es untergeht ^^ Ansonsten hat die Migration meiner Stacks auf 2.0 übrigens reibungslos funktioniert Gute Arbeit!

Hallo, habe gerade angefangen mir das 2.0-Zeug herunterzuladen. Betriebsystem: Windows 8 Da ich den brickd auf meinem Laptop nur gelegentlich nutze habe ich im Setup den Haken bei Register Service entfernt. Allerdings scheint sich der brickd nicht in einem Konsolenmodus starten zu lassen, die Installation als Service ist also zwingend. Ist es vorgesehen den brickd anders zu starten als als Service? Falls nein: Warum lasst ihr (=TF) mir im Setup die Wahl? P.S.: Warum fordert das Setup einen Neustart bei Installation als Service? (Der Service läuft ja nach der Installation sogar)

Ich kenne den Fix von borg nicht, deswegen kann ich mich auch durchaus täuschen, aber da das Fehlverhalten das du beschreibst ganz arg vom Timing abzuhängen scheint würde ich das Threading definitiv nochmal untersuchen. (Außer borg sagt, dass der Buffer Overflow auch ganz bestimmtes Timing o.ä. vorrausgesetzt hat) eine Frage noch an TF (oder Kenner der Firmware): Gibt es noch Möglichkeiten den Stack abzuschießen indem man kaputte Pakete sendet oder wurde der Code in 2.0 dahingehend (hoffentlich) vollständig abgedichtet? Ich weiß, dass sowas in den 1.x Versionen durchaus mal vorkommen konnte mit falschen Paketen den Stack zu zerschießen.

Dein Stack kann ja (wenn die Bindings korrekt im Multithreading funktionieren) eigentlich keinen Unterschied merken, aus wie vielen Threads er angesprochen wird. Mein Tipp wäre, dass möglicherweise die Bindings nicht thread-safe sind und dem Stack dadurch irgendwann Müll schicken woraufhin dieser einen Neustart durchführt. Ist aber wild ins Blaue geraten. Hilfreich zur Unterstützung/Widerlegung dieser Theorie wäre es, wenn du einen TCP-Dump o.ä. von der Session erzeugen könntest. Dann wäre es möglich nachzuvollziehen welche Pakete wann geflogen sind. (eigentlich ein dummer Vorschlag... ich habe gar kein Tool um die Daten effizient untersuchen zu können )