borg

Kickstarter Projekte erstellen können nur Amis und Briten:

You did add a 4m long antenna (the LCD20x4 Bricklet). It is possible that the long cable increased the inductive load problems. But you could easily try that out by disconnecting the long cable (at the stack, not at the LCD). Do the problems disappear then? Edit: A watchdog could indeed have helped in your scenario.

There is: http://www.tinkerforge.com/en/doc/Software/IPConnection_Java.html#IPConnection::setTimeout__i

Schwer zu sagen, ich kenne mich mit SEGGER JLINK nicht aus. Hast du schonmal am Command Set und Protocol Version rumgespielt?

Dann kann ich ja mal gleich die nächste Frage stellen. Wir haben uns unter anderem einen neuen Controller für den Laser Cutter gekauft, da dieser schneiden und gravieren gleichzeitig kann. Würdet ihr die Wetterstation lieber komplett "blank" haben von außen oder etwas draufgraviert? Innen hatten wir vor die einzelnen Löcher mit einer Beschriftung zu versehen.

1hz should not be enough to overload anything, what do you mean with aggressively polling?

If you reset a stack by hand (power on/off or reset button) or if you call the reset function, it will reassociate. If your stack resets because of EMI problems caused by the long cable, anything might happen (it possibly doesn't restart correctly and the WIFI module is in a broken state). You may need to power it off in that case, so the WIFI module can completely reset itself. How many Bricklet ports do you have for how many Bricklets? From an EMI perspective it would make sense to use a single Master Brick for the LCD20x4 Bricklet, since all Bricklets on a Master use the same I2C bus.

Den Aufbau hab ich hier quasi auch: PC -> Gigabit Cisco Switch -> FritzBox -> Stack. Ich denke der Switch und der Router sind für die Probleme hier nicht relevant. So wie ich das sehe passiert folgendes: Das WIFI Modul auf der WIFI Extension arbeitet mit delayed ACKs (http://en.wikipedia.org/wiki/TCP_delayed_acknowledgment). Ist in dem Screenshot auch zu sehen, dort gibt es ganz viele Nachrichten vom PC (77 Byte) und dann werden die alle mit einem ACK beantwortet. Nun scheint es aber so zu sein, dass der PC nach einer Zeit aufhört zu senden wenn er kein ACK bekommen hat. Das WIFI Modul sendet aber erst das delayed ACK wenn der Buffer voll ist (1500 Byte). Da gibt es ein Timeout von 200ms (d.h. wenn der Buffer nach 200ms nicht voll ist, sendet das WIFI Modul trotzdem das delayed ACK). Da lagst du mit deinem "5hz ruckeln" schon sehr gut . Interessant ist jetzt: Wenn der Stack Nachrichten zum zurücksenden hat (damals die Reached Nachrichten vom Servo), dann wird das ACK auch schon frühzeitig zusammen mit diesen Nachrichten rausgeschickt. Daher gab es das 5hz ruckeln dort nicht. Ich denke damit ist die Problematik ziemlich gut verstanden, es ist eine Mischung aus dem 200ms Timeout und der Anzahl der Nachrichten die das Betriebssystem schickt bevor es erstmal aufgibt wenn kein ACK kommt. Das Verhalten wird hier vermutlich von OS zu OS unterschiedlich sein. Falls hier jemand weiß wie man sowas für gewöhnlich löst oder umgeht: Immer raus damit . Ich bin mir nicht sicher ob wir die 200ms Timeout auf dem WIFI Modul verringern können. Dokumentiert ist da nichts, werde aber am Montag den Hersteller fragen.

Also es ist definitiv so, dass die Daten zum Teil gebündelt bei der WIFI Extension ankommen, hier meine Debug Ausgabe: poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll [31, 9, 77, e4, b, 4, 50, 0, 0, fd, 2, poll 31, 9, 77, e4, b, 4, 60, 0, 5, 3, fd, poll 31, 9, 77, e4, b, 4, 70, 0, 1, 2a, 3, poll 31, 9, 77, e4, b, 4, 80, 0, 4, d6, fc, poll 31, 9, 77, e4, b, 4, 90, 0, 0, 2a, 3, poll 31, 9, 77, e4, b, 4, a0, 0, 5, d6, fc, poll 31, 9, 77, e4, b, 4, b0, 0, 1, 57, 3, poll 31, 9, 77, e4, b, 4, c0, 0, 4, a9, fc, poll 31, 9, 77, e4, b, 4, d0, 0, 0, 57, 3, poll 31, 9, 77, e4, b, 4, e0, 0, 5, a9, fc, poll 31, 9, 77, e4, b, 4, f0, 0, 1, 84, 3, poll 31, 9, 77, e4, b, 4, 10, 0, 4, 7c, fc, poll 31, 9, 77, e4, b, 4, 20, 0, 0, 84, 3, poll 31, 9, 77, e4, b, 4, 30, 0, 5, 7c, fc, ] poll Die "polls" sind im 1ms takt und wenn Daten da sind, werden sie mit ausgegeben. "[" und "]" geben ein einzelnes TCP/IP Paket an. Da ist also eine ganz Zeit nichts und dann auf einmal kommt 14x setPosition. Im Anhang das ganze nochmal in Wireshark. Dort sieht man die ganzen setPosition (die 77 Byte großen Pakete). Die gehen also eine ganz Zeit lang einzeln durch und dann auf einmal kommt ein Paket der Größe 209 wo die besagte Vielzahl an setPositions drin ist (siehst du auch unten im Payload, dort ist mehrfach 31 09 77.. drin). D.h. die Pakete werden wirklich so vom Betriebssytem losgeschickt. Jetzt muss ich dir allerdings recht geben: Wenn ich die Wi-Fi Strecke extern aufbaue von PC nach PC und dann über USB kommuniziere hab ich diesen Effekt nicht. Die Frage ist also: Was macht die WIFI Extension, das dazu führt, dass das PC Betriebssystem mehrer Nachrichten in ein Paket zusammen schnürt?

Also ich kompiliere in Eclipse auch einfach über das Makefile. Ich hab mal ein paar Screenshots von der Konfiguration angehängt. Ansonsten könnte auch dieser Thread interessant sein: http://www.tinkerunity.org/forum/index.php?topic=1171.0

Ich denke du rufst da einfach so viele Setter auf, dass das Betriebssystem die in ein großes Paket bündelt. Dadurch kommen die Daten dann immer so schubweise an. Du musst also eigentlich sicherstellen, dass das setzen einer Position schon ausgeführt wurde wenn du die neue rausschickst. Das geht z.B. in dem du ReponseExpected aktivierst für setPosition: ((BrickServo)device).setResponseExpected(BrickServo.FUNCTION_SET_POSITION, true); In Zeile 91 in DeviceItem.java. Da gibt es vermutlich eine bessere Stelle für . Dann siehst du auch, dass die Queue vollläuft und du eigentlich zuviele Nachrichten schickst. Ich glaube ich würde versuchen die setPosition Aufrufe auf ein 10ms Intervall zu minimieren. Ich versuche nochmal herauszufinden ab wo genau die Messages schubweise durchgehen, aber ich bezweifle das es etwas ist was wir beeinflussen können .

Das muss es nicht, sieht aber hübscher aus so . Ah ja, da haben wir auch lange dran rumprobiert. Die Raspberry Pi Ausbaustufe ist das Problem. Das ist auf den Fotos jetzt nicht zu sehen, aber du kannst neben dem Master ein DC Jack Adapter anbringen, unter dem Master eine Step-Down Power Supply. dann den Master per USB mit dem Raspberry PI verbinden, die Wetterstation von außen über den DC Jack mit Strom versorgen und das Rapsberry Pi über den grünen Stecker der Step-Down mit Strom versorgen. Der RPi sitzt dabei unter dem LCD20x4. Für alles das sind Bohrungen usw vorgesehen. Das ist eine der schönsten Ausbaustufen, da die Wetterstation dort autonom ist man sie von außen einfach mit einem Notebook Netzteil oder so versorgen kann, was man vermutlich rumliegen hat. Allerdings ist in dieser Ausbaustufe die komplette rechte Seite mit Leiterplatten belegt. Die einzige freie stelle ist da, wo das Aufhängeloch ist. Dafür mussten die Abstandshalter dann außerhalb gesetzt werden .

Soooo, ich konnte das reproduzieren. Konnte den schuldigen auch ausfindig machen: Das Servo Brick. Oder spezifischer: Die VelocityReached und PositionReached Callbacks des Servo Bricks. Du hattest in dem Testprogramm die Velocity aufs Maximum gesetzt und dann mehrere Servos in sehr kurzen Abständen mit kleinen Positionsveränderungen gesteuert. Dadurch war bei jedem setzen eines Stellwerts immer sofort die neue Position und die volle Velocity erreicht. D.h. es gab für jedes Servo quasi immer zwei Nachrichten die zu senden waren. Dadurch haben sich Stück für Stück Nachrichten im Ringbuffer aufgestaut, bis er voll war. Danach haben sie sich dann im Buffer der WIFI Extension aufgestaut, bis er voll war. Und dann passiert etwas böses: Das WIFI Modul nimmt die TCP/IP Pakete an, schreibt soviel in den Buffer wie er kann und schmeißt den Rest weg. An der Stelle hab ich dann verloren, sobald ich diese Daten abarbeite lese ich Schrott und dann tritt das Verhalten auf was du beschrieben hast. Lösung für dein spezifisches Problem: VelocityReached und PositionReached Callbacks an/abschaltbar machen. Ich hab mal eine Servo Brick Firmware angehägt bei der die Callbacks anschaltbar sind, Default ist aus. Damit kann ich mit deinem Testprogramm keine Probleme mehr erzeugen. Wenn das bei dir funktioniert würde ich das auch noch für die *Reached Callbacks von DC und Stepper Brick implementieren. Das stand übrigens sowieso schon auf der TODO Liste . brick_servo_firmware_2_0_1-beta1.bin

Oh, auf dem Bild fehlt in der Tat entweder die Batterie oder ein erklärender Text. du musst die Batterie an VIN und GND anschließen. Der positive Pol der Batterie (+) geht an VIN und der negative Pol (-) geht an GND.

Das ist ja ulkig, warum sollte er denn "localhost" nicht resolven können? Hast du schonmal probiert "127.0.0.1" anstatt "localhost" zu nehmen?

In der Grundausbaustufe wird der Temperatursensor vom Barometer genommen. Wir haben aber Platz in der Wetterstation für 3 Master Bricks (oder 2 Master + 1 WIFI oder 2 Master + 1 Ethernet, etc). D.h. da gibt es sehr viele mögliche Ausbaustufen, von denen wir auch einige mit entsprechenden Schritt-für-Schritt Anleitungen darstellen werden. PMMA lässt sich ungefähr so behandeln wie Holz, dadurch ist es sehr einfach neue Löcher o.ä. hinzuzufügen. Zum Beispiel um schöne große Knöpfe auf die Linke Seite der Wetterstation anzubringen, zum durchschalten der Modi (macht mehr Spass als die kleinen Knöpfe am LCD20x4 ). Und so weiter, es wird da sehr viele mögliche Ausbaustufen geben! @Lötkolben: Master um 90° drehen damit das USB Kabel unten rausgeht sollte gehen. So wie er im Foto angebracht ist kann man eine WIFI Extension drauf setzen und die Antenne geht exakt rechts raus und nach oben weg, das sieht dann schick aus .

Ich würde folgenden Hardwareaufbau machen: Aufbau Steuerung: 1x Laptop + Master + 2x Joystick Bricklet über USB Aufbau Regelung: 1x Raspberry PI + USB WLAN Stick + Step-Down Power Supply + Master + Servo Brick + 2x Analog In Und folgenden Aufbau für die Software: Programm Steuerung: Läuft auf Laptop. Es nimmt die Befehle der Joysticks entgegen und wandelt sie in High Level Anweisungen um (z.B.: Fahre mit 10km/h nach rechts). Diese Anweisung wird über einen Socket über WLAN an Programm Regelung welches auf Aufbau Regelung läuft geschickt. Programm Regelung: Läuft auf dem Raspberry Pi. Hier übersetzt du die High Level Anweisungen die vom Programm Steuerung kommen. Des weiteren kannst du dich hier jetzt austoben bzgl. der Regelung und Notausmaßnahmen. Wenn du Ein Arduino verwenden willst würde der Aufbau prinzipiell gleich aussehen, du müsstest dann irgendwie das Arduino mit dem RPI verbinden und auf am Laptop ein weiteres Arduino mit dem Laptop.

Du musst ws2_32.lib noch zu den Abhängigkeiten hinzufügen, dritter Absatz hier: http://www.tinkerforge.com/de/doc/Software/API_Bindings_C.html#visual-studio

Steht da nur "Fehler beim erstellen"? Oder auch irgendein Grund für den Fehler? "Dieses Projekt ist veraltet": Das heißt, dass das Erstellen des Projekts nicht geklappt hat und er nur eine alte früher kompilierte Version starten kann.

Alternativ auf "Auto update all Bricklets" klicken im Update Tab .

Hast du die Firmware schon aktualisiert? Ich vermute das es noch mit einer v1 Firmware ausgeliefert wurde.

Wenn du in dem Testprogramm die UID durch die des Bricklets ausgetauscht hast und der Brick Daemon läuft (was er tut wenn der Brick Viewer funktioniert), dann musst du nur das Programm auf dem PC starten .

Es geht nicht darum zu gucken ob das eine Alternative wäre, es geht darum zu gucken ob es sich anders verhält. Wenn es sich genauso verhält wie die WIFI Extension werden wir da an der WIFI Extension keine Konfigurationen finden um die Aussetzer zu beheben.

Naja, für den Fall müsstest du dann den Getter aufrufen. Alternativ kannst du in regler auch eine globale variable oder eine Klassenvariable setzen: class X: value = 0 def regler(self, x): self.value = x

Ah, die gibts auf github: https://github.com/Tinkerforge/dc-brick/tags