AuronX

Kommt jetzt noch ein bisschen drauf an, ob du WPF oder WinForms nutzt. Im Wesentlichen sind folgende Schritte zu erledigen: 1. Alle Daten die du anzeigen willst am besten in einer kleinen Klasse kapseln etwa: class MyModel { public string UID { get; private set; } //...mehr properties zum anzeigen... public MyModel(string uid, /* mehr parameter für mehr properties */) { UID = uid; //und der Rest } } 2. Im Callback aus den erhaltenen Informationen eine solche Klasse erstellen und zur ListView hinzufügen, dabei beachten, dass das ganze im GUI-Thread erfolgen muss, google stichworte dazu: WinForms Invoke oder WPF Invoke 3. Im ListView konfigurieren wie die Model-Elemente angezeigt werden sollen, auch hier ist das ganze WinForms/WPF-abhängig P.S.: Ein WPF-Beispiel für einen anderen Anwendungsfall findest du hier: https://github.com/NobodysNightmare/TwitchURLGrabber/tree/master/TwitchURLGrabber (hat nix mit TF zu tun, aber das ist meine erste in WPF realisierte ListView ^^)

Nur damit ich das jetzt auch für immer in meinem Kopf habe: Ich mache rohe Messungen, schreibe diese in die Liste für meinen normalen Mittelwert. Wenn ich diese Liste voll habe, dann berechne ich den Mittelwert und schreibe diesen Mittelwert in die Liste für den gleitenden Mittelwert? Also der gleitende Mittelwert ist über Mittelwerte gemittelt, während der normale Mittelwert über Rohdaten gemittelt wurde? Falls ja habe ich es verstanden ^^ Dachte der gleitende würde direkt über den Rohdaten gebildet. edit: Meine Formulierung ist komisch... mit "ich mache rohe Messungen" meine ich "das Bricklet macht rohe Messungen" ^^

... Wonach wird entschieden, ob der Luftdruck mittels gleitendem Mittelwert oder nicht-gleitendem Mittelwert ausgegeben wird? (also was bekomme ich zurück, wenn ich GetAirPressure aufrufe?) Und bedeutet die Nutzung des nicht-gleitenden Mittelwertes, dass ich immer 10 Messungen lang auf das Ergebnis warten muss? Und wann ist es sinnvoll einen nicht-gleitenden Mittelwert einzusetzen?

Ich kenne da jemanden der das schonmal angefangen hat ^^ Jemand... http://www.tinkerunity.org/forum/index.php/topic,1574.0.html Ist aber ziemlich unvollständig, aber möglicherweise reicht es dir zum Üben ^^ Weil meine Scherze manchmal nicht so gut ankommen: Dieser jemand bin ich... Hab aber schon nen paar Tage nicht mehr dran gearbeitet... müsste ich eigentlich mal wieder ^^

Ich würde es vermutlich so machen: unabhängige Komponenten - Datenbank - Webserver - Kontrollprogramm Web-Server - Dient als Nutzeroberfläche - Schreibt SOLL-Werte in eine Datenbank (Zieltemperatur usw) wahlweise: - Liest IST-Daten direkt - oder Liest IST-Daten auch aus Datenbank Kontrollprogramm - Hat ständige Verbindung zu Bricks - regelt Temperatur, Licht usw - holt sich regelmäßig die aktuellen SOLL-Werte aus der Datenbank optional: - Schreibt IST-Werte in Datenbank Die IST-Werte in der DB zu haben ist natürlich nett, weil man auch den Verlauf im Nachhinein einsehen kann.

Allerdings erfolgt das durch die Software, nicht unmittelbar durch die Hardware.

Halte ich noch immer für falsch, da es für mich noch immer nicht transparent ist, ob ich zu einer WiFi-Extension oder zu einem Software-brickd verbinde. Ich kann gerne einmal den Rechner mit einem Brickd neustarten, bezweifle aber, dass dieser bei der Neuverbindung ein enumerate senden wird. Versteht doch einfach, dass diese Unterschiede existieren. Es ist nicht transparent.

Das ist ein Verständnisproblem zwischen TF und (mindestens) mir und dir. Wurde schonmal thematisiert. Ich halte es auch für falsch bei der Verbindung zum WiFi-Brickd ein enumerate zu erhalten. Aus der Perspektive vom Brick ist aber das Anstecken eines USB-Kabels und das Herstellen der WLAN-Verbindung offenbar das gleiche, weswegen ein Enumerate kommt. Ich halte es für falsch und finde, dass es geändert werden sollte, aber das ist nur meine Meinung. edit: http://www.tinkerunity.org/forum/index.php/topic,1559.0.html Das ist der Thread mit der ersten Diskussion zum Thema. Auf mein Argument, dass das Verhalten ur aus Sicht des Bricks und nicht aus Sicht der Bindings gleich ist wurde soweit ich das überflogen habe kein Bezug mehr genommen.

Möglich ist das auf jeden Fall. Es hängt letztlich davon ab, ob du es in Software gießen kannst, aber das sollte machbar sein. Beispielsweise könntest du dir pro IP eine Konfiguration speichern und beim Herstellen der Verbindung alle Bricks/Bricklets enumerieren, wenn keines davon doppelt vorkommt oder du immer alles an den gleichen Anschluss anschließt, dann geht das sogar vollautomatisch (lies das als: du kannst es so programmieren, dass es vollautomatisch sein wird). Ein Punkt den ich in diesem Thread noch nicht gefunden habe ist die Ausfallsicherheit. Da weiß ich jetzt natürlich auch nicht wie es um deine LOGO bestellt ist, aber solche Dinge solltest du im Design auf jeden Fall berücksichtigen. Beispiel: Heizer wird eingeschaltet, um die Temperatur zu erhöhen -> WLAN fällt aus -> Terrarium enthält Grillfleisch Tinkerforge sieht hier bereits einige Schutzmaßnahmen vor, du kannst beispielsweise ein Relay automatisch ausschalten lassen wenn es mehr als x Sekunden nicht mehr angesprochen wurde. (Diese Sicherheitsbedenken sollten unabhängig von der Entscheidung TF/Siemens in deinem Kopf schwirren )

Falls du am Ende nciht noch auf etwas anderes hinaus willst noch folgendern Tipp, wie es außerdem funktioniert: Nutze den Position-Callback des Servobricks. Wenn der servo4 Position 9000 erreicht, lasse ihn zur -9000 fahren und umgekehrt. Aber halt immer im Position-Callback. Dadurch sparst du dir die eigenen Sleep()-Aufrufe. Damit das richtig funktioniert, musst du allerdings "sinnvolle" Werte bei der Velocity setzen, das heißt Werte die dein Servo schafft.

Ich weiß jetzt nicht was deine Anforderungen sind... mit 4 leicht entladenen AA-Batterien und zwei Stückchen Draht schaffst du es mit dem geringsten Materialaufwand, allerdings bleibst du nur für kurze Zeit im richtigen Spannungsbereich. Wenn es längerfristig klappen soll, dann brauchst du wenigstens eine Vorrichtung, die dir die Spannung stabil hält... da wäre eine Step-Down gut geeignet, ist dir diese zu schwer? zu teuer? zu groß?

Da muss ich widersprechen, habe gerade (stromlos) meinen Stecker einmal bewusst falsch herum aufgesteckt...

@Nic: TBD steht je nach Kontext für "to be done" oder "to be determined". Muss also noch bestimmt werden.

Ich würde mcih auch über eine Erklärung freuen. Habe gerade in die Änderungen für die neue Firmware geschaut und weitestgehend Bahnhof gelesen Beim Initialisieren wird der 4. Button kurzzeitig anders eingestellt (default statt Pull-Down und output statt input) und dann ziemlich lange (1 Sekunde) gewartet, bevor er wieder normal konfiguriert wird (glaube ich). Aber ich habe sowas von viel zu wenig Ahnung von diesen hardware-nahen Geschichten, um wirklich zu verstehen warum das hilft

So wie ich das verstanden habe war die Step-Down nur eine "Kompatibilitäts"-Maßnahme von TF. Weil sie schreiben halt dran "funzt mit RaspPi" und dann kommt einer mit ner alten Revision und beschwert sich ^^

Minimum ist dir recht egal, weil das nur regelt ab wann der Undervolt-Callback ausgespuckt wird. Output-Voltage sollte bei deinem Servo dranstehen was er verträgt (möglicherweise nur im Datenblatt), üblicherweise gilt dort auch je mehr Spannung desto schneller bewegt er sich, aber zugelassen ist er nur für eine bestimmte Maximalspannung. edit: Ich konnte mich gerade nicht mehr an meine Einstellungen erinnern, aber ein kurzes googling durch diverse RC-Foren sagt mir, dass Servos "normalerweise" mit 5V betrieben werden und einige auch auf mehr ausgelegt sind. edit2: Meine Erinnerung sagt mir übrigens, dass ein einzelner meiner Servos zum Teil 400mA gezogen hat... wegen Stromaufnahme und so ^^

Wieso hat eigentlich niemand die Geile ASCII-Art gelobt mit der Loeti hier Netzwerke gezeichnet hat? Sieht richtig schick aus @gagahhag: Spätestens seit Windows 7 kannst du mit vielen WLAN-Chips neben deiner aktuellen Verbindung ein eigenes WLAN aufspannen. Das ist dann zwar noch immer kein Brick-to-Brick von TF, könnte aber genau dein Problem lösen, weil es ohne zusätzliche Hardware funktioniert. Dazu mal zwei Links: http://msdn.microsoft.com/en-us/library/windows/desktop/dd815243(v=vs.85).aspx http://www.wi-fiplanet.com/tutorials/article.php/3849841/How-to-Create-Wireless-Hosted-Networks-in-Windows-7.htm Meistens wird dir auch noch erklärt, wie du dann beide WLANs miteinander bridgen kannst, aber das brauchst/willst du hier ja eigentlich gar nicht. Dir sollte es reichen, das eigene WLAN aufzuspannen.

Wir weichen langsam vom Thema ab, aber beim Baumarkt suche ich gewöhnlich nach den von Nic aufgezählten Werkstoffen... Kunststoff würde ich online kaufen. Vielleicht hier: http://www.amazon.de/Polycarbonat-Platte-farblos-600-transparent/dp/B009MMECYM/ref=sr_1_2?ie=UTF8&qid=1367657040&sr=8-2&keywords=pmma (andere Größen siehe unten) Ich sehe ein, dass es den im Baumarkt bei Holz usw. gibt, aber definitiv ist der niemals Teil des Angebots das TF hier aufziehen wird (oder habe ich übersehen, dass das alles Einzelanfertigungen werden?) Insofern möchte ich den vergleich unterschiedlicher Obstsorten unterstellen. P.S.: Zum Thema "bohren ist wirklich leicht": Kann schon sein, ich habe nur meine Meinung kundgetan. Zum Selbstbohren würde ich mir das Zeug irgendwo besorgen und drin rumbohren, von TF erwarte ich vorgebohrtes P.P.S.: Bei den Verschnittresten im Baumarkt kann man auch kleine Holzstücke bekommen (sofern deine Kantenlänge von "100" in Zentimetern gemeint war; ich habe schon hübsche 100x100mm Platten bei den Resten gesehen)

Spannungen messen ist der ungefährliche Teil bei Multimetern Hier ein Link mit Bild zum Messen der Spannung: http://elinux.org/R-Pi_Troubleshooting#Troubleshooting_power_problems TP1 und TP2 sind gut zu erkennen. Du stellst dein Multimeter erst auf das Messen einer Gleichstromspannung ein und legst den Wertebereich fest. Wie im Bild zu sehen sollte da bei den meisten Multimetern 20V passen, da du ja 5V messen willst. (2000mV wäre zu wenig, 200V zu viel)

@pluto: Tatsächlich läuft es ziemlich stark auf den erwähnten Thread hinaus... Beliebige Sprachen zu unterstützen wird kaum zu bewältigen sein, wenn man nun darüber diskutiert welche Sprache man unterstützen will landet man im genannten Thread. Neu wäre jetzt allerdings die Idee, dass man den Code per TCP auf die Bricks bringen kann. Das könnte vielleicht auf die eine oder andere möglich sein... obwohl ich da auch nochmal Security-bedenken anbringen wollte... Ich befürchte übrigens, dass es bei einem neuen Brick an dieser Stelle enden würde... TF produziert in deutlich geringeren Stückzahlen...

@nic: Lass es mich anders formulieren... ich möchte nicht bohren. Warum ist das relevant? Wenn ich bohren wollte, dann fände ich im Baumarkt meines Vertrauens und in diversen Onlineshops eine geeignete Platte. Die Löcher würde ich reinmachen wie ich sie brauche. Auf jeden Fall würde ich das nicht bei Tinkerforge einkaufen. Da ich nicht bohren will brauche ich also etwas das ein geeignetes Lochmaß hat. Deswegen kaufe ich das auch gerne hier. P.S.: Ich hab gar keinen Raspberry Pi

http://www.tinkerforge.com/de/doc/Software/Bricks/DC_Brick_CSharp.html#BrickDC::EmergencyShutdown__BrickDC

Da muss ich klar sagen, dass mir das zu wenig wäre. Ich möchte nur noch schrauben, aber nicht bohren. Wegen des Verbiegens: Was passiert bei weniger Löchern (wie von Löti vorgeschlagen)? Das sollte doch helfen oder? Da aber auch mir viele Löcher lieber wären noch ein unkonventioneller Vorschlag: Wäre es (insbesondere im Sinne eines effizienten Herstellungsprozesses) möglich die Hälfte der Löcher von oben und die andere Hälfte von unten zu lasern? Also beispielsweise erst jedes zweite Loch lasern, dann Platte umdrehen und den Rest machen? Ich könnte mir vorstellen, dass die dabei entstehenden Spannungen sich ausgleichen (oder die Platte explodiert). Viele Grüße Jan

Korrekt, immer ein Master bei mehr als einem Brick und der Master muss unten sein.