photron

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

Bindings: Java 2.0.9 CopyOnWriteArrayList zur Vermeidung von ConcurrentModificationExceptions in der Listener-Behandlung verwendet Download: Java

Ich versuche mal den aktuellen Status zusammenzufassen und noch einige Fragen zu stellen: 1) Du rufst dc_set_velocity() im position Callback des Rotary Potis auf um mit dem Poti die Geschwindigkeit des Motors zu steuern. Wenn du am Poti drehst kommt es vor, dass die IP Connection "hängt" und keine Callbacks mehr ausliefert. Dazu zwei Fragen: 1a) Wie erkennst du das keine Callbacks mehr ausgeliefert werden? Du drehst am Poti, die Motorgeschwindigkeit bleibt aber unverändert? Und du siehst auch die Ausgabe vom printf im position Callback nicht? 1b) Tritt das nur auf wenn du am Poti drehst, oder passiert das auch wenn der Motor nur unverändert vor sich hin läuft? 2) Das Problem tritt häufiger auf wenn der Motor schneller dreht. Dazu auch eine Frage: 2a) Kann das ein EMV Problem sein und der Motor stört den Stack? 3) Was ist mit dem dc_disable() nach dem Enter-Drücken, hängt der immer noch? 4) Der Segfault in deinem Testprogramm war eine Problem mit der Initialisierung im Programm und kein Problem in den Bindings selbst.

Wir haben es aufgegeben zeitliche Angaben zu machen wann neue Produkte herauskommen werden. Es hat sich heraus gestellt, dass wir aus verschiedensten Gründe die gesetzten Termine doch immer wieder verschieben mussten. Die verschiedenen neuen Bricklets sind gerade in der Phase der Konzept- und Prototyp-Entwicklung. Sie werden dann in absehbarer Zeit nach und nach veröffentlicht werden. Habt also etwas Geduld mit uns

Der TEA6420 sieht gut aus. Laut Datenblatt kannst du damit 5 Stereo Eingänge nach belieben auf 4 Stereo Ausgänge verteilen. Gesteuert wird der über I2C, dass heißt du brauchst noch einen Mikrocontroller zum Steuern da dran.

Sind das Anpassungen speziell für dein Projekt, oder sind das Anpassungen für Solaris? Bei letzterem wäre ich daran interessiert diese ins offizielle git zu übernehmen Es war einiges...ich muss mal schauen ob ich den Mitschnitt vom compile noch finde...grob gesagt brauchte man dbus und openusb (da es libusb nicht gibt). Das hört sich nach Arbeit an. Ich nehme mal an das dbus für Hotplug ist. Wie gesagt wäre ich daran interessiert das in die offizielle brickd Codebase aufzunehmen, wenn da nichts dagegen spricht. Da müsste man dann hingehen und wie schon für Hotplug und andere Dinge auch für USB noch einen Abstraktions-Layer einziehen und dann mit libusb und openusb implementieren.

Um auch was zum Topic zu sagen: Hauptsächlich Ubuntu. Zusätzlich ein Windows im Dual-Boot zum Spielen. Zu Linux bin ich vor Jahren im Zuge von Open Source Software-Entwicklung gekommen. Es programmiert sich einfach leichter/schöner/einfacher/etc unter Linux. Auch macht einem ordentliches Package Management das leben leichter Für Cross-Platform Entwicklung dann noch Windows in VM unter Ubuntu.

Sind das Anpassungen speziell für dein Projekt, oder sind das Anpassungen für Solaris? Bei letzterem wäre ich daran interessiert diese ins offizielle git zu übernehmen

Die Bindings speichern den originale Hostnamen als String und verwenden den beim Reconnect. Wenn da ein Caching-Problem beim Auflösen existiert, wüsste ich nicht wie wir das auf der Ebene der Bindings verbessern sollten.

AuronX, deine Erklärung ist vollständig richtig so. Das ist auch in allen Bindungs so, außer PHP, weil das keine Threads hat und eh etwas abweicht. Verbindungsverlust wird an Fehlern beim Schreiben/Lesen des Sockets erkannt. Wenn Auto-Reconnect erlaubt ist (set_auto_reconnect(true)), dann versucht der Callback-Thread nach dem Ausliefern des Diconnected-Callbacks die Verbindung wieder aufzubauen. Dies tut er solange bis eines der folgenden Ereignisse eintritt: a) die Verbindung wurde wieder aufgebaut b) disconnect() wurde aufgerufen, Auto-Reconnect wird abgebrochen c) set_auto_reconnect(false) wurde aufgerufen, Auto-Reconnect wird abgebrochen Es gibt da keine zeitliche Beschränkung, und set_timeout() hat damit nichts zu tun.

Plugins: Voltage/Current Bricklet 2.0.3 Fix voltage and power reached callbacks, were send as current reached callback before Download Plugin: Voltage/Current Bricklet 2.0.3

Plugins: Voltage/Current Bricklet 2.0.3 Voltage und Power Reached Callbacks funktionieren wieder, wurden zuvor fälschlicherweise als Current Reached Callback versandt Download Plugin: Voltage/Current Bricklet 2.0.3

Für einen Stapel wird immer ein Master Brick als unterster Brick benötigt.

Generell gilt, dass du die Kommunikation aus dem Tritt bringen kannst, wenn z.B. in den Headern der Pakete falsche Daten stehen. Das Problem hatten wir ja schon Das die IP Connection "hängt" und keine Callbacks mehr ausliefert, kann daran liegen, dass der Receive Thread nicht mehr richtig funktioniert und keine Callback-Pakete mehr empfängt; oder daran, dass du den Callback Thread in einer deiner Callback-Funktionen blockierst, das gibt dein Testprogramm allerdings nicht her. Dass dc_set_velocity ohne Response-Expected E_OK sagt ist zu erwarten, da E_OK bei Settern ohne Response-Expected soviel heißt wie: ich bin die Anfrage über den Socket losgeworden, mehr nicht. Die beiden Stacktraces im ersten Post sehen normal aus. Dass das dc_disable() beidem Beenden allerdings im ipcon_send_request() ewig auf den socket_mutex wartet ist verdächtig. Wobei da Zeile 1525 nicht passt, es müsste 1523 sein, hast du da vielleicht lokale Änderungen in ip_connection.c, oder verwendest doch nicht die aktuelle Version? Interessant wäre hier ein voller Stacktrace aller Thread um zu sehen, wer da gerade auf dem socket_mutex sitzt. Das du nach dem ipcon_connect() eine sleep(1) brauchst um einen Segfault zu vermeiden ist verdächtig. Eigentlich sollte ipcon_connect() nicht auf das Starten des Receive und des Callback Thread warten müssen. Diese sind nicht an der Initialisierung globaler Datenstrukturen beteiligt. Soll heißen, selbst wenn die beiden Thread nie starten solltest du im schlimmsten Fall einfach keine Antworten auf Getter und keine Callbacks bekommen, aber keinen Segfault. Hast du dir male neben GDB Traces angesehen was Valgrind zu deinem Programm meint.

Das ist komisch. Hast du mal versucht, das Bricklet neu zu flashen?

Geany kannst du an der Stelle nicht mit Visual Studio vergleichen. Visual Studio gibt es ja in verschiedenen Varianten für verschiedene Programmiersprachen wie C++, C#, Visual Basic, etc. Für diese Sprachen bietet es dann auch vollständige Unterstützung im Sinne von Projektverwaltung, Compiler/Debugger Integration etc. Das alles bietet Geany so nicht. Geany ist in dem Sinne nur ein Editor und nicht mit einem Compiler/Debugger integriert und hat daher auch keine Einstellungen dafür. Damit unter C++ #include funktioniert musst du ja die C/C++ Bindings entweder in das gleiche Verzeichnis wie deinen Code packen oder in ein Verzeichnis in dem Visual Studio nachschaut wenn es #include auflöst. Das funktioniert in Python mit import ähnlich. Im ZIP der Python Bindings befindet sich im source Unterordner ein tinkerforge Ordner, den kannst du einfach in den gleichen Ordner wie dein Python Script packen, dann findet Python den. Oder du kannst das tinkerforge.egg installieren, dann findet Python das auch. Details gibts dazu hier: http://www.tinkerforge.com/de/doc/Software/API_Bindings_Python.html#api-bindings-python Das hat im Übrigen nichts mit Geany zu tun, sondern rein mit Python. Die Python Bindings müssen sich einfach nur an einer Stelle befinden an der Python sie findet. Dann kannst du die Beispiele, die sich auch im ZIP befinden in einem Terminal ausführen. In Geany kannst du ein neues Python Script erstellen. Geany muss dazu nichts darüber wissen wo die Python Bindings sind.

Geany ist ja eher ein Editor und keine volle Entwicklungsumgebung. Die Projektverwaltung die Geany bietet ist sehr einfach gehalten. Mir ist dein Problem nicht klar. Du kannst da in Geany nichts einbinden in dem Sinne. Geany erlaubt dir nur einen Satz an irgendwelchen Dateien als ein Projekt zu definieren und es bietet einen einfachen Mechanismus um aus dem GUI heraus Dinge wie make aufzurufen. Geany ist ein guter Editor (ist mein Standardeditor), aber keine vollständige Entwicklungsumgebung für eine spezielle Programmiersprache. Um welche Programmiersprache geht es denn überhaupt?