borg

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 . Edit: Veraltete Firmware entfernt.

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

bricklib/utility/init.c:24:24: fatal error: pio/pio_it.h: No such file or directory Mmmmmh, in Zeile 24 steht aber eigentlich #include "bricklib/drivers/pio/pio_it.h" und nicht #include "pio/pio_it.h" Ich denke er versucht einfach den Ordner "pio/" direkt im Hauptverzeichnis zu finden, er müsste aber in "briclib/drivers/pio" suchen. Welche IDE verwendest du denn? Kann man da irgendwas bzgl. Include-Pfaden einstellen? Edit: Im Zusammenhang mit dem anderen Thread vermute ich, dass du v1.x.y Branches mit v2 Branches mischt (also bricklib v1 und master v2 oder umgekehrt). Du musst bei beiden die v1.x.y Branches nehmen: https://github.com/Tinkerforge/master-brick/tree/v1.x.y https://github.com/Tinkerforge/bricklib/tree/v1.x.y Ich würde allerdings empfehlen auf v2 umzusteigen, v1 wird nicht mehr mit neuen Features erweitert werden!

Was du probieren könntest ist der Aufbau: PC -> WLAN -> PC -> USB -> Bricks Also sprich: Der Brick Daemon läuft auf einem PC wo der Brick direkt per USB angeschlossen ist und die Kommunikation läuft über Wi-Fi von einem anderen PC aus. Verhält es sich in dem Fall anders? Bzgl. eines Checks wegen der Geschwindigkeit steht zumindest nichts im Datenblatt des Moduls. Ich könnte dir aber eine Firmware machen in dem ich die "Transmit Rate" auf einen festen Wert setze.

Echt interessant, du scheinst da ja wirklich eine störungsreiche Umgebung zu haben . Ich gucke mal ob wir das nicht schaltbar in die Firmware eingebaut bekommen.

Ich denke die beste Lösung für so ein Projekt ist es, ein kleines Embedded Board (Raspberry PI, BeagleBoard o.ä.) mit auf die Seilkamera zu bringen und die eigentliche Regelung machen zu lassen. D.h. du schickst eine "High-Level Anweisung" per Wi-Fi an das Embedded Board (fahre 10m nach links mit 20km/h) und das Embedded Board macht die eigentliche Regelung. Eine Regelung über Wi-Fi wird nie Echtzeitanforderungen genügen, also nie eine definierte minimale Paketlaufzeit haben. Welche Verbindungsart theoretisch am stabilsten sein könnte kommt sicherlich auf das verwendete Equipment an. Wenn ein AP mit sehr hoher Sendeleistung verwendet wird, kann es denke ich durchaus sein dass eine Verbindung stabiler ist als direkt AdHoc.

http://download.tinkerforge.com/firmwares/

Also geplant ist sowas, das wird aber noch lange dauern. Ist relativ weit hinten in der Neue-Hardware-Liste. Im Moment tendieren wir aber dazu ein NFC-Bricklet zu machen, das scheint sich ja jetzt in Mobiltelefonen durchzusetzen usw. Vielleicht wäre NFC für ein Zugangssystem auch besser geeignet. Das ist auf Sicherheit ausgelegt und man könnte dann auch Zugang über Handys erlauben: http://www.fakir.it/aktuelles/detail/items/unterschied-rfid-und-nfc-eine-kurze-erklaerung.html

Unser Standardport ist 4223, nicht 4222 .

Do you have a screenshot of the behavior?

Da gibt es mehrere Möglichkeiten, ich würde es einfach mit einem großen Blob Lötzinn versuchen, den ich immer hin und her schwenke. Das kommt ein bisschen drauf an was du an der anderen Seite dranmachen willst. Wenn dein Taster auch einfach Pinne hat könntest du z.B. Jumper Kabel nehmen: http://nodna.de/Jumper-Kabel-F-F-gecrimpt-mit-Pingehaeuse-10-Stk Ansonsten gibt es auch passende Stecker dafür: http://webshop.schneider-consulting.it/25-Stueck-Pinheader-Buchsenstecker-Raster-254mm-zweireihig-6-polig (muss man aber selbst crimpen). Oder wenn du einfach nur ein Kabel anlöten willst, was du wieder an- und abstecken kannst, würde ich einfach eine 2x3 Buchsenleiste nehmen und dort Käbelchen anlöten: http://www.elmotex.de/steckverbinder/stiftleisten-und--buchsen/bl-2x3-g8-rm254.php (Sorry für die unterschiedlichen Shops, sind die ersten Google Treffer)

Die haben 3,5mm Abstand, füge ich hinzu. Das ist nicht mehr aktuell - oder? Ab Version 1.2 hat das LCD doch kleine Taster + Lötpunkte. Hö? Die Lötpunkte sind dafür da um eine Stiftleiste einzulöten: https://www.tinkerforge.com/de/shop/right-angle-pin-header-2x3.html Das soll die Doku an der Stelle beschreiben .

In gewisser Weise hängt es damit natürlich zusammen. Ein System welches nur dafür da wäre IO16 Werte über eine RS485 Verbindung auszulesen könnte sicherlich schneller sein. Ich müsste mal zwei Stack mit unserem Logic Analyzer verkabeln um herauszufinden wo genau wieviel Zeit verloren geht.

Das sollte nicht passieren. Welche Version hat die Master Brick Firmware?