photron

Bindings: C/C++ 2.0.9, C# 2.0.9, Delphi 2.0.11, Java 2.0.10, Python 2.0.9, Ruby 2.0.9, Shell 2.0.1, VB.NET 2.0.5 Race Condition zwischen Disconnect Probe Thread und disconnect() Funktion verhindert [alle] Interne Typen wie Socket, Thread, Mutex und so weiter sind nicht mehr öffentlicher Teil von ip_connection.h [C/C++] Exit Code 1 wird jetzt für Keyboard Interrupt verwendet [shell] Download: C/C++, C#, Delphi, Java, Python, Ruby, Shell, VB.NET

Wenn du Extension 0 nicht auf WIFI konfigurieren kannst, dann besteht da ein Problem in der I2C Kommunikation zwischen Master Brick und dem EEPROM auf der WIFI Extension. Extension 1 wäre eine zweite Extension, die oben auf der ersten drauf steckt. Da du da keine hast ist das okay, dass da ein Fehler auftritt. Hast du da sonst noch was im Stack? Nimm mal nur den Master Brick mit WIFI Extension an USB und versuch nochmal auf WIFI zu konfigurieren. Wenn das nicht geht kannst du mal versuchen die WIFI Extension zu hotpluggen. Also erst Master Brick an USB und dann erst WIFI Extension oben drauf, dabei darf sich der Master Brick nicht neustarten, also kein Blinkenlights der 4 LEDs. Wenn dann die WIFI Extension noch nicht geht und auch das Konfigurieren auf WIFI nicht geht, dann bleibt noch einen anderen Master Brick zu testen, falls du noch einen weiteren hast. Zum Barometer: Ich habe mal einen Abschnitt in der Dokumentation darüber hinzugefügt: http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Barometer.html#luftdruck-verstehen

Erstmal zu Barometer: Das misst den Luftdruck auf deiner aktuellen Höhe. Wetterdienste geben den aber auf Meereshöhe umgerechnet an. Bei 490m höhe und sagen wir mal 22°C sind 964,4 mbar dann 1019,94 mbar auf Meereshöhe. Das passt dann zu der DWD Wetterstation. Hier der Umrechner: http://rechneronline.de/barometer/ Zur WIFI Extension: Wenn alles funktioniert solltest du auf dem Tab des Master Bricks die Einstellungen für die WIFI Extension sehen. Wenn das nicht der Fall ist kann es sein, dass die WIFI Extension nicht als WIFI Extension markiert ist. Das sollte eigentlich nicht passieren, da wir das hier beim Testen einstellen. Du kannst das aber selbst machen. Auf dem Tab des Master Bricks ist oben rechts ein Configure Knopf. Der ruft einen Dialog auf, in dem du bei Type WIFI statt None wählst und dann Save klickst. Dann einmal den Master Brick resetten. Jetzt sollte die WIFI Extension auftauchen.

Ich habe die Firmware und Plugins Seite überarbeitet. Ich denke ich habe dabei alle Hinweise in diesem Thread sowie Loetkolbens Fragenliste berücksichtigt. Das ganze ist jetzt detaillierter und sollte einfacher/besser verständlich sein. Die benötigen Tools (GCC für ARM, CMake und make) gibts für 32 und 64 bit Linux, Windows, Mac OS X. Für den Compiler gibt es Linux und Windows Installer in 32 bit. Ein 64 bit Windows hat keine Probleme mit 32 bit Programmen und unter 64 bit Linux muss man nur die 32 bit Support Lib installieren. Für Mac OS X bietet CodeSourcery selbst keinen Installer für den Compiler. Es gibt Anleitungen wie man sich den dann selbst aus dem Source kompilieren kann.

The Ethernet Extension supports PoE and the parts required for PoE make up a good fraction of the price. We're planning to offer a version of the Ethernet Extension without PoE support. This one will be cheaper, but we don't have a price or a date for it yet.

Das wäre auch meine erste Frage, ob das Problem weg geht, wenn du dieses aktive Kabel weglässt, bzw den problematischen Master Brick mal so anschließt, wie den der keine Probleme macht. Ansonsten kannst du dir mal für Brick Daemon das Windows Event Log ansehen. Seit neustem liegt dafür für vereinfachten Zugang brickd eine eventlog.exe bei. Diese kannst du starten und bekommst dann alle Warnings und Errors von brickd angezeigt. Vielleicht passt da zeitlich was mit deinem Problem zusammen. Mit "File > Save ..." kannst du das Log in eine Datei speichern.

Einfacher und wiederverwendbarer als das in die Bindings einzubauen wäre es daraus ein eigenes Tool zu machen, das man zwischen Programm und Stack schaltet. Diese könnte dann die Pakete durchschleust und dabei mitschneiden und auch wiederholen.

Gilt das auch für eine Lsg. als Website mit PHP-Bindings ? Ja. Ganz grundsätzlich unterstützt die WIFI Extension 15 Sockets. Damit kann sie 15 TCP/IP Verbindungen zu gleichen Zeit bedienen. Ob du dann damit 15 gleichzeitig laufenden C# Programme bedienst, die ihre Verbindungen alle offen halten, oder 15 gleichzeitige Webseitenaufrufe die mit PHP kurz eine Verbindung aufbauen, einen Wert abfragen und dann die Verbindung wieder schließen, spielt da keine Rolle.

Ich gemeint sind gleichzeitig Verbindungen. Das sind 15, siehe Technische Spezifikation. Es können also alle 9 interessierten Personen gleichzeitig das abfragenden Programm laufen haben.

Okay, Ethernet und Chibi können nicht im gleichen Stack verwendet werden, da die beide über SPI angebunden werden. In der Dokumentation stand allerdings, dass das funktionieren würde. Das war falsch und ist jetzt korrigiert, sorry. Was aber funktioniert ist zwischen Ethernet und Chibi Master eine RS485 Strecke zu setzen. Das habe ich gerade getestet.

Funktioniert denn Ethernet alleine, also ohne Chibi?

Bindings: Shell 2.0.0 Initial Version Download: Shell Blog Entry

Bindings: Shell 2.0.0 Initiale Version Download: Shell Blogeintrag

Die Shell Bindings sind nun veröffentlicht.

The shell bindings are now released.

Dann fehlt dir make an sich noch, gut möglich das weder Eclipse noch der Code Sourcery Installer das mitbringen. Das GnuWin32 Projekt beinhaltet eine make Version für Windows, die kannst du hier finden: http://gnuwin32.sourceforge.net/packages/make.htm Am einfachsten nimmst du den "Complete package, except sources" Download. Standardmäßig installiert der make nach "C:\Programme\GnuWin32\bin". Wenn der Installer diesen Ordner nicht schon zum PATH hinzufügt musst du das noch händisch tun. Dann sollte Eclipse make finden. Ich denke dann hast du alle Tools zusammen.

Nein, dass kann nicht richtig sein. cmake und make haben verschiedene Aufgaben. cmake erzeugt das Makefile das make dann verarbeitet. make -C C:/Users/admin/Desktop/eclipse/workspace/master/build all Das würde Sinn ergeben: -C sagt make es soll zuerst mal in das angegebene Verzeichnis wechseln und dort das Target all im dortigen Makefile erfüllen. Mit cmake ergibt das keinen Sinn. Es gibt auch in cmake eine -C Option aber dies erwartet eine Cache-Datei, was das build Verzeichnis aber nicht ist. Auch ist all kein Verzeichnis. Du solltest also erstmal das "Build Command" von cmake auf make zurückstellen. Die sonstigen Fehler sind Folgefehler von diesem Problem.

Hast du im Fahrtenregler + Servo Brick Fall den Motor und den Brick über die gleiche oder über verschiedene Spannungsquellen versorgt?

Der zweite GDB Trace zeigt ein Deadlock. Da war eine Race Condition zwischen der disconnect() Funktion und dem Disconnect Probe Thread die du da getroffen hast. In den angehängten C Bindings ist das Problem behoben und du solltest es mit diesen nicht mehr schaffen können, dass dein Programm beim Beenden hängt. Da es ohne Motor zu funktionieren scheint, muss das Problem des hängenden Stacks ja mit dem Motor direkt oder indirekt zusammenhängen. Dazu fallen mit verschiedenen Dinge ein: 1) Es könnte wie gesagt mit der Stromversorgung zusammenhängen. Der Motor zieht beim Anfahren mit voller Beschleunigung viel mehr Strom also die 80-200mA die du angibst. Dadurch bricht die Versorgungsspannung ein und der Stack verträgt das nicht. Hierzu könntest du testen den Stack und den Motor nicht aus der gleichen Quelle zu versorgen. Dann kann der Motor den Stack nicht mehr über die Stromversorgung beeinflussen. Dabei dann das Voltage/Current an die Versorgung des Motors hängen, damit die Callbacks weiter kommen. Ja, ich weiss ich beharre stark auf diesem Gedanken Eine andere Art von Last (z.B. eine Lampe) ist potentiell auch ein guter Test. 2) Du sagst, dass Problem tritt häufiger wenn du die Beschleunigung auf Maximum stellst. Geht das Problem dann weg, wenn du die Beschleunigung deutlich unter Maximum stellst? 3) Du hast den Motor 20cm vom Stack entfernt liegen. Macht es einen Unterschied wenn du den Motor deutlich weiter weg (1-2m) legst? tinkerforge_c_bindings_2_0_8_74953a5547502075cede11c872b82dad8d10639e.zip

Dann hast du auch gesehen, dass die Genauigkeit mit DGPS bei diesem Modul laut Datenblatt bloß von 3,0m auf 2,5m steigt. Was schon etwas komisch ist. Die Firmware, die auf unserem FGPMMOPA6H Modul ist, hat DGPS nicht aktiviert und auf dem Bricklet ist Pin 14 nicht angeschlossen.

Dazu ein paar Fragen: Welche Mac OS Version ist das? Hilft es den Refresh Knopf neben der Auswahlbox für die Schnittstelle zu drücken? Wenn der Brick im Bootloader ist und du ihn per USB ansteckst sollte im /dev Verzeichnis ein neuer Eintrag auftauchen. Der Brick Viewer erwartet, dass dieser Eintrag mit "tty." anfängt. Typischerweise heißt er "tty.usbmodemfd121", wobei sich die Nummer ändern kann. Taucht der Brick bei dir vielleicht unter einem anderen Namen auf, den brickv nicht erwartet?

Brick Daemon 2.0.6 Workaround struct packing bug in MinGW GCC 4.7 Add simple event log viewer tool for Windows Prohibit starting a second instance on Windows Check for USB device additions/removals changes on SIGUSR1 Ignore SIGPIPE and handle socket write errors properly Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.6 Struct-Packing-Bug in MinGW GCC 4.7 umgangen Einfaches Event-Log-Viewer Tool für Windows hinzugefügt Start einer zweiten Instanz auf Windows wird verhindert Liste der USB Geräte wird bei SIGUSR1 aktualisiert SIGPIPE wird ignoriert und Socket-Schreibfehler werden behandelt Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

1a) Diese Burst-Verhalten hört sich ja schon nach WIFI Problem an. Hast du dir die WIFI Kommunikation mal in Wireshark angesehen, um zu sehen ob die per WIFI auch so eingehen und nicht irgendwie in den C Bindings verlangsamt wird, wobei ich gerade nicht wüsste wie das passieren sollte, aber wer weiss. 2a) Hast du mal ohne Motor dran getestet? Hast du mal eine andere Stromversorgung ausprobiert? Vielleicht packt dein Akku den Anfahrtsstrom des Motors nicht und die Spannung bricht dadurch so sehr ein, dass das den Stack beeinflusst. 3) Ich meinte, dass dein Steuerprogramm dauerhaft in dc_enable() hängt. Das sollte nicht passieren, falls dem so ist sieht das nach einem Bug aus. Selbst wenn der Stack nicht reagiert sollten Getter und Setter mit Response Expected nach 2,5sec (oder auf was du den Timeout gestellt hast) returnen. Setter ohne Response Expected sollte direkt returnen. Daher meine Frage nach einem Backtrace aller Threads in diesem Fall, da es in dem einen Backtrace zu dem Problem so aussieht als würde da jemand dauerhaft auf dem socket_mutex hocken, was nicht sein darf.

Bindings: Java 2.0.9 Avoid ConcurrentModificationException in listener handling by using CopyOnWriteArrayList Download: Java