photron

Du hast da zwei Bugs gefunden: - Beim Start des Counter wurde der From Wert nicht angezeigt. - Beim Entfernen der führenden Nullen wurde auch die letzte Null entfernt, so dass beim Counter Wert Null nichts angezeigt wurde. Beides ist in Plugin Version 2.0.2 korrigiert. Danke für den Hinweis!

Go to the RED Brick Network Settings tab in Brick Viewer. Click the Scan button to get an up-to-date list of WIFI networks. This should clear any chached information on the RED Brick. Pick the one you want, enter its key and click the Connect button.

Das RED Brick braucht einen für den Allwinner SoC angepassten Kernel. Dezeit verwenden wir den Kernel des Linux Sunxi Projekts: http://linux-sunxi.org/Linux_Kernel Dessen Stable Version basiert derzeit auf dem Mainline Kernel 3.4. So wie ich das verstehe wird diese Stable Version aber nicht mehr weiterentwickelt, sondern die Linux Sunxi Entwickler arbeiten daran, die Allwinner SoC Änderungen in den Mainline Kernel zu bringen: http://linux-sunxi.org/Linux_mainlining_effort Da ist schon viel passiert, aber auch noch einiges zu tun. Auf längere Sicht werden wir wohl auf einen neueren Mainline Kernel für das RED Brick umsteigen können. Das wird aber nicht kurzfristig passieren und auch auf unserer Seite einiges an Arbeit bedeuten. Unsere RED Brick Anpassungen und RED Brick spezifischen Treiber müssen dann auf einen neue Kernelversion portiert werden. Der nächste Kernel für den RED Brick wird also eher ein 4.x als ein 3.x Kernel werden.

Aufgrund der Art und Weise wie wir derzeit das Image bauen und RED Brick spezifische Änderungen am Kernel und Debian vornehmen ist es im Moment nicht möglich ein laufendes Images per apt-get auf eine neuere Image Version zu aktualisieren. Das mag sich in Zukunft ändern, kurzfristig gibt es dafür aber keine Pläne, sorry.

Ich habe gerade mal versucht deinen Aufbau nachzustellen: Master Stack: - Step-Down Power Supply (versorgt von 12V Labornetzteil) - Master Brick (HW 2.1, FW 2.3.1, ohne Bricklets, per USB am PC angeschlossen) - RS485 Extension (38400 Baud) Slave Stack: - Master Brick (HW 2.1, FW 2.3.1, ohne Bricklets, versorgt vom 5V Ausgang der Step-Down Power Supply am Master Stack) - Master Brick (mit 2 PTC Bricklets) - RS485 Extension (38400 Baud) Ich schau mir den Temperatur Graphen eines PTC Bricklets im Brick Viewer an und stecke den USB Stecker am Slave Stack ab und wieder an. Der Graphen setzt dabei für 15 Sekunden aus läuft dann wie erwartet weiter. Sprich ich kann deine 2 Minuten nicht reproduzieren. Du sprichst selbst Modbus, hast also nur Master Bricks als Modbus Salves im RS485 Bus. Hast du mal versucht stattdessen einen Master Brick als Modbus Master zu verwenden und das System so zu verwenden wie es gedacht ist?

Ich sehe nicht warum das mit der HashMap nicht funktionieren sollte. Hast du mal eine Hashtable statt einer HashMap getestet? Du solltest hier definitiv einen thread-safen Container nehmen, da der Temperature Callback von einem internen Thread der IPConnection aufgerufen wird. Wann gibst du den die HashMap über die entrySet() Methode aus? Laut Dokumentation ist der Iterator des Sets das du von entrySet() bekommst ungültig sobald die HashMap geändert wird: http://docs.oracle.com/javase/7/docs/api/java/util/HashMap.html#entrySet() Sprich, wenn während der Ausgabe der HashMap ein Temperature Callback die Map ändert kommt da irgendwas beim Iterator heraus. Versuch es mal mit clone(), bin mir aber nicht sicher ob das hilft: for (Entry<String, BrickletWert> entry: stackManager.getBrickletWertlist().clone().entrySet()) { ... } Ansonsten muss du den Zugriff auf die HashMap manuell synchronizen, damit entweder der Temperature Callback Daten einfügen kann, oder du die Werte ausgibst, aber nicht beides gleichzeitig, oder verschachtelt passieren kann.

Tritt es auch auf, wenn du die beiden Master Bricks im 2er Stack vertauscht, also den oberen zum untern machst und umgekehrt (natürlich mit Bricklet am oberen)? Sprich, ist es die Position im Stack, oder betrifft das nur einen ganz bestimmten Master Brick? Tritt das Problem denn jetzt auch bei den 1er Stacks auf, wenn du einen Master Brick mit Bricklets hinzusteckst? Welche Bricklets hast du denn am oberen Master Brick, wenn das Problem auftritt? Und was ist eigentlich mit den 3er Stacks? Warum tritt das Problem dort nicht auf? Was macht den Unterschied, hast du da andere Bricklets dran, oder macht die Step-Down Power Supply da den Unterschied? Worauf ich hinaus will: Wird das Problem durch die Anordnung oder Art der Bricks und Bricklets im Stack verursacht, oder durch einen ganz bestimmten Brick oder Bricklet?

from tinkerforge.ip_connection import Error try: ... except Error as e: if e.value == Error.TIMEOUT: print "timeout error" else: print "other error"

Unsere Dokumentation deckt primär die Verwendung des Systems ab. Zusätzliche ist dokumentiert wie die Firmwares und Plugins kompiliert werden können, wie die Stack und Bricklet Stecker belegt sind und wie das TCP/IP und Modbus Protokoll aussieht: http://www.tinkerforge.com/de/doc/Software/Firmwares_And_Plugins.html http://www.tinkerforge.com/de/doc/Technical_Data.html http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html http://www.tinkerforge.com/de/doc/Low_Level_Protocols/Modbus.html Wie die Firmwares und Plugins intern funktionieren und zusammenspielen ist nicht dokumentiert. Wenn du selbst Firmwares und Plugins schreiben willst muss du dir das leider selbst aneignen. Der Source Code, die Schaltpläne und Layouts sind alle auf GitHub verfügbar. Ansonsten kannst du hier Fragen stellen und wir werden versuchen dir weiterzuhelfen.

Ist eine HashMap ist nicht thread-safe. Versuch mal eine ConcurrentHashMap zu verwenden.

Du kannst den Brick Daemon Service jederzeit neustarten, dass einzige was dabei passieren kann ist, dass kurzzeitig Anfragen oder Antworten verloren gehen. Von welcher Brick Daemon Version sprechen wie hier? Dass das mit Windows-Login oder Logoff zusammenfällt ist verdächtig, könnte aber auch zufällig sein. Hast du mal im Geräte Manager nachgesehen ob der Master Brick noch aufgeführt ist nachdem der Brick Daemon per Enumerate-Disconnected Callback behauptet hat der Master Brick wäre abgesteckt worden? Möglicherweise hat sich Brick Daemon das Abstecken des Stacks eingebildet bzw. sich von Windows in die Irre führen lassen. Wenn das der Fall ist dann könnte ein Neustart des Brick Daemon Services helfen. Danach sollte sich der Stack wieder melden wenn dein Programm ein Enumerate auslöst, oder du im Brick Viewer Disconnect gefolgt von Connect klickst, da das Connect im Brick Viewer ein Enumerate auslöst.

Das spricht erstmal nichts dagegen, dass dieser Aufbau so funktionieren müsste. Etwas ungewöhnlich ist die Art die zweite Reihe der Stacks zu versorgen schon, aber das sollte ohne Probleme funktionieren. Da bleibt mir nur mehr Fragen zu stellen: Die 5,1V sind am USB Anschluss des versorgten Master Bricks gemessen? Wie hast du die gemessen? Du sagtest, dass alle Master Bricks die gleiche Firmware Version haben. Welche Firmware Version? Welche Hardware Version haben die Master Bricks? Wenn du die Stromversorgung des problematischen Stack anschließt dann leuchten die vier blauen LEDs am Master Brick auf. Daran kannst du erkennen, dass der Master Brick gestartet wurde. Leuchten diese LEDs nochmals im Betrieb auf, vielleicht so 20 Sekunden bevor die RS485 Kommunikation wieder funktioniert? Sprich der Master Brick startet sich selbst neu und dann funktioniert es wieder? Was passiert, wenn du in die funktionierenden 1er Stacks noch einen Master Brick dazu steckst? Tritt dann bei diesen das Problem auch auf? Was passiert, wenn du den problematischen 2er Stack mit einer Step-Down Power Supply unterm Stack versorgst, statt über den 5V Ausgang einer externen Step-Down Power Supply?

Step-Down Power Supply ist genau zu Stromversorgung eines Stacks gedacht. Ich fragte so genau nach wegen dem DC Brick, weil das potentiell auch funktionieren könnte unter bestimmten Bedingungen, aber möglicherweise hier die Ursache hätte sein könnte. Nochmal zurück zum Aufbau: Die beiden 3er Stacks habe also jeweils eine Step-Down Power Supply. Der problematische 2er Stack hängt mit seinem USB Anschluss am grünen 5V Ausgang einer dieser Step-Down Power Supplies. Oder wie speist du die 5V da ein? An welcher Step-Down Power Supply hängen dann die beiden 1er Stacks die ohne Probleme funktionieren? Heißt "einzeln" ohne den zweiten Master Brick, oder auch ohne Bricklets? Das hört sich nach einem Stromversorgungsproblem an, wobei mir nicht klar ist warum das die RS485 Kommunikation in dieser Art und Weise beeinflussen sollte. Wie werden die Step-Down Power Supplies versorgt? Alle vom gleichen oder von verschiedenen Netzteilen? Welche Ausgangsspannung und Ausgangsleistung haben die Netzteile?

Welche Abhängigkeiten benötigt werden kann dir z.B. apt-get sagen: apt-get install -s mplayer2 Das -s sorgt dafür, das apt-get die Installation simuliert, also nur sagt was es tun würde, ohne es wirklich zu tun. Dabei wird auch ausgegeben welche Pakete zusätzlich installiert würde.

Du möchtest also mit 3x4 Touch Pad die Funktion des Rotary Potis ändern. Wenn die Helligkeitstaste gedrückt wurde soll ab dann das Poti die Helligkeit einstellen. Wenn die Farbetaste gedrückt wurde soll ab dann das Poti die Farbe einstellen. Das kannst du so lösen: MODE_BRIGHTNESS = 1 MODE_COLOR = 2 def cb_position(self, position): if self.mode == MODE_BRIGHTNESS: self.set_brightness(position + 150) elif self.mode == MODE_COLOR: self.set_color(position + 150) Du hast eine mode Variable die auf MODE_BRIGHTNESS oder MODE_COLOR gesetzt ist. Dein Programm reagiert auf das Drücken der Helligkeits- und Farbetaste und setzt dann mode auf MODE_BRIGHTNESS oder MODE_COLOR. In der cb_position() Funktion wird dann abhängig von mode deine set_brightness() oder set_color() Funktion aufgerufen die dann Helligkeit und Farbe abhängig von der aktuellen Position des Potis einstellen.

Du versorgst den problematischen Stack also über den DC Brick Motor Ausgang mit 5,1V. Wie hast du den DC Brick eingestellt (Velocity, PWM Frequency, Drive Mode, Acceleration) und mit welcher Spannung versorgst du den DC Brick Input Anschluss, damit da am Ende 5,1V am Motoranschluss herauskommen? Aus einem USB Anschluss kommen normalerweise glatte 5V. Beim DC Brick kannst du 5V am Motoranschluss aber eigentlich nur durch PWM erreichen. Es kann sein, dass ein Brick das nicht gut verträgt.

Von deiner Beschreibung des Programms her sollte das funktionieren. Standardmäßig ist die Debounce Period (siehe set_debounce_period) auf 100ms gestellt. Wenn der Endschalter also weniger als 100ms gedrückt ist kann es passieren, dass das nicht als Interrupt angesehen wird. Andere Möglichkeit wäre, dass der Endschalter oder die Verkabelung mechanisch oder elektrisch nicht in Ordnung ist und einen Wackelkontakt hat. Dadurch kann der Endschalter dann gedrückt werden, ohne dass das elektrisch bei der IO-16 ankommt.

Die cb_position() Funktion im Rotaty Poti Callback ist nicht dazu da, um von dir aufgerufen zu werden, sondern um von den Bindings aufgerufen zu werden, wenn ein Position Callback von Bricklet eintrifft. Du hast also keine Kontrolle darüber wann die cb_position() Funktion aufgerufen wird. Wenn du die aktuelle Position abfragen willst kannst du einfach die get_position() Funktion aufrufen, statt den Position Callback zu verwenden, wie in diesem Beispiel: http://www.tinkerforge.com/de/doc/Software/Bricklets/RotaryPoti_Bricklet_Python.html#simple

Versuch mal den untersten Master Brick des problematischen Stacks auszutauschen, um zu sehen ob es an diesem speziellen Brick liegt. Versuch mal den problematischen Stack anders mit Strom zu versorgen, also nicht über einen DC Brick, um zu sehen ob das bei diesem speziellen Stack ein Problem macht. Verusch mal den Aufbau zu verkleinern. Tritt das Problem auch auf, wenn du mit dem problematischen Stack alleine sprichst ohne die anderen Stacks im Bus? Tritt das Problem auch auf, wenn du den problematischen Stack auf Master Brick und RS485 Extension verkleinerst? Bezüglich der Sequence Number meinte ich, ob dir der Stack immer erst wieder bei einer bestimmten Sequence Number antwortet. Also erst wenn du mit er Sequence Number z.B. bei 123 angekommen bist.

Ist an dem Stack der länger braucht irgendetwas anders als an den anderen Stacks? Andere Master Brick Firmware, andere Bricks oder Bricklets im Stack? Mit welcher Baudrate kommunizierst du? Welche Sequence Number hat die erste Antwort die du bekommst? Ist es immer die gleiche Sequence Number?

Du kannst die Packages auf dem PC herunter laden, auf den RED Brick kopieren und dann dort installieren. Hier ist die Liste: libaacs0 libasn1-8-heimdal libass5 libbluray1 libbs2b0 libcdio-cdda1 libcdio-paranoia1 libcdio13 libdv4 libdvdnav4 libdvdread4 libenca0 libfaad2 libfribidi0 libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhx509-5-heimdal libkrb5-26-heimdal libldb1 liblircclient0 liblua5.2-0 libmpg123-0 libntdb1 libpostproc52 libquvi-scripts libquvi7 libroken18-heimdal libsmbclient libtalloc2 libtdb1 libtevent0 libvdpau1 libwbclient0 libwind0-heimdal mplayer2 python-talloc samba-libs Diese kannst du für Debian jessie armhf hier herunterladen (<PACKAGE> durch den Package Namen ersetzen): https://packages.debian.org/jessie/armhf/<PACKAGE>/download Und dann auf dem RED Brick mit folgendem Befehl jedes Package einzeln installieren: sudo dpkg -i <PACKAGE> Einfacher ist es aber wenn der RED Brick selbst direkt Internetverbinding hat. Eigentlich kommt dafür nur QEMU in Frage. Das Problem ist QEMU kann zwar ARM emulieren, aber der A10s SoC ist nicht in der QEMU Machine Liste für ARM. Ich habe andere ARM SoCs probiert aber es bootet nicht.

Du kannst VLC nachinstallieren, ich empfehle aber mplayer zum Testen. Am einfachsten ist es wenn der RED Brick eine Internet Verbindung hat und ein Display angeschlossen ist. RED Brick per USB am PC anschließen und im RED Brick Console Tab im Brick Viewer per apt-get mplayer installieren. sudo apt-get update sudo apt-get install mplayer2 Dann mplayer so starten. DISPLAY=:0 mplayer tv:// Wenn alles klappe sollte das Kamerabild auf dem Display angezeigt werden.

Eigentlich sollte eine Logitech Pro 9000 direkt funktionieren. Der uvcvideo Treiber ist vorhanden und damit solle auch eine Logitech Pro 9000 funktionieren. Ich habs gerade mit einer No-Name Webcam probiert und die wird ohne Problem gefunden. Beziehungsweise mal anders: Warum denkst du, dass du erst einen extra Treiber installieren musst?

Das installieren von qt5-default deinstalliert wirklich libsunxi-mali-x11 und xserver-xorg-video-sunximali. Bedingt durch einen Konflikt zwischen libsunxi-mali-x11 und libegl1-mesa-drivers. Das sollte lösbar sein.

Ist das die ApplicationException, die du selbst in refreshCameraList() wirfst, wenn videoDevices.Count == 0 ist?