photron

I tested with this function matlab_example_threshold() import com.tinkerforge.IPConnection; import com.tinkerforge.BrickletVoltageCurrent; ipcon = IPConnection(); % Create IP connection vc = BrickletVoltageCurrent('XYZ', ipcon); % Create device object set(vc) end and got this output >> matlab_example_threshold APIVersion Class Configuration Current CurrentCallbackPeriod CurrentCallbackThreshold DebouncePeriod Identity Power PowerCallbackPeriod PowerCallbackThreshold ResponseExpectedAll: [ on | off ] Voltage VoltageCallbackPeriod VoltageCallbackThreshold PowerReachedCallback: string -or- function handle -or- cell array VoltageReachedCallback: string -or- function handle -or- cell array VoltageCallback: string -or- function handle -or- cell array CurrentReachedCallback: string -or- function handle -or- cell array CurrentCallback: string -or- function handle -or- cell array PowerCallback: string -or- function handle -or- cell array ButtonDownFcn: string -or- function handle -or- cell array Children Clipping: [ {on} | off ] CreateFcn: string -or- function handle -or- cell array DeleteFcn: string -or- function handle -or- cell array BusyAction: [ {queue} | cancel ] HandleVisibility: [ {on} | callback | off ] HitTest: [ {on} | off ] Interruptible: [ {on} | off ] Parent Selected: [ on | off ] SelectionHighlight: [ {on} | off ] Tag UIContextMenu UserData Visible: [ {on} | off ] Did you install the bindings according to the documentation? http://www.tinkerforge.com/en/doc/Software/API_Bindings_MATLAB.html#matlab Also make sure to use the Tinkerforge.jar from the MATLAB bindings zip file. The Tinkerforge.jar from the Java bindings will probably not work. What MATLAB version are you using?

Keine Sorge! Die 60mA sind für ein Pixel, das Weiss mit voller Helligkeit (RGB = 255,555,255) anzeigt. Sprich die 9A kommen nur dann zum tragen, wenn alle 150 LEDs Weiss mit voller Helligkeit anzeigen. Das ist aber nicht der Normalfall. Normal sind eher Farbmuster bei denen nicht alle LEDs an sind und auch nicht mit voller Helligkeit, daher reicht in 99% der Fälle das 8A Netzteil völlig aus.

While creating Brick Viewer 2.3.1 for Mac OS X, I noticed that the Data Logger dialog wont show up after clicking the "Data Logger" button. I need to click the "Updates / Flashing" button as well to make both dialogs show up. I tried to debug the problem, but with no success. I found that the problem only occurs if I start Brick Viewer from the Finder or the Application folder. But if I start it from a terminal like this /Applications/Brickv.app/Contents/MacOS/brickv then the problem is gone and the Data Logger dialog shows up immediately. Because the problem now also occurs with Brick Viewer 2.3.0, I believe that Brick Viewer itself is not directly at fault but the Mac OS X version (10.11 / El Captian) or our Macbook here has a problem. Could the Mac users out there test this and report if you have this problem as well?

Beim Erstellen von Brick Viewer 2.3.1 für Mac OS X ist mir aufgefallen, dass der Data Logger Dialog nicht direkt angezeigt wird, wenn man den "Data Logger" Button klickt. Erst wenn man auch den "Updates / Flashing" Button klickt tauchen beide Dialog auf. Ich habe versucht das Problem zu ergründen, allerdings nicht sehr erfolgreich. Was ich herausbekommen habe ist, dass das Problem nur auftritt, wenn Brick Viewer aus dem Finder oder dem Applications Ordner heraus gestartet wird. Starte ich Brick Viewer allerdings vom Terminal aus mittels /Applications/Brickv.app/Contents/MacOS/brickv dann tritt das Problem nicht auf und der Data Logger Dialog wird sofort beim Button Klick angezeigt. Da das Problem jetzt auch auftritt, wenn ich Brick Viewer 2.3.0 testet, glaube ich, dass es nichts direkt mit Brick Viewer selbst zu tun hat sondern mit der Mac OS X Version (10.11 / El Captian) oder unserem Macbook hier. Könnten die Mac User unter euch das bitte mal testen und berichten, ob ihr dieses Problem auch haben?

Mit Brick Viewer Version 2.3.1 und Brick Logger Version 2.0.2 kannst du jetzt auch dein eigenes Zeitformat mittels strftime Syntax einstellen.

Brick Logger 2.0.2 Add millisecond interval support Add custom strftime format Downloads: Windows, Linux, Mac OS X, RED Brick

Brick Viewer 2.3.1 Add millisecond interval support for data logger Add custom strftime format for data logger Improve UI font selection on Mac OS X 10.11 Sign Brickv.app on Mac OS X to silence the Gate Keeper Downloads: Windows, Linux, Mac OS X

Brick Logger 2.0.2 Unterstützung für Millisekunden Intervalle hinzugefügt Eigene Zeitstempelformate können jetzt über strftime definiert werden Downloads: Windows, Linux, Mac OS X, RED Brick

Brick Viewer 2.3.1 Unterstützung für Millisekunden Intervalle dem Data Logger hinzugefügt Eigen Data Logger Zeitstempelformate können jetzt über strftime definiert werden GUI Schrift für Mac OS X 10.11 verbessert Brickv.app für Mac OS X ist jetzt signiert Downloads: Windows, Linux, Mac OS X

In der Gewichtsberechnung war in der Tat eine Invertierung drin. Dadurch musste man IN+ und IN- vertauschst anschließen, um das richtige Gewicht zu bekommen. Das Problem ist in Load Cell Plugin Version 2.0.1 jetzt behoben und die Dokumentation über die Anschlussbelegung jetzt korrekt. Danke an euch beide für den Hinweis!

Plugin: Load Cell Bricklet 2.0.1 Fix inversion in weight calculation Download: Load Cell Bricklet If you swapped the signal wires of the load cell to compensate for this problem then you need to swap them back now.

Plugin: Load Cell Bricklet 2.0.1 Invertierung in der Gewichtsberechnung korrigiert Download: Load Cell Bricklet Falls die Signalleitungen der Wägezelle vertauscht angeschlossen wurden, um diese Problem zu beheben, so müssen sie jetzt zurückgetauscht werden.

Programme werden immer als User tf gestartet. Es gibt keine direkt Option ein Programm als root zu starten. Du versucht wahrscheinlich einen Port < 1024 zu binden. Das benötigt root Rechte. Die einfachste Lösung wäre es einen Port über 1024 zu verwenden, dann brauchst du keine root Rechte mehr. Wenn es unbedingt ein Port < 1024 sein muss, dann kannst du dein Programm aus einem Shell-Skript so als root starten #!/bin/sh echo tf | sudo -S mono server.exe Dein Programm muss dann als Shell anstatt als C# Programm hochgeladen werden.

Okay dann nehme ich die abgewandelten Packages erstmal so für die nächste Image Version mit auf.

Du musst noch pm-utils installieren: sudo apt-get install pm-utils Und dann nochmal sudo dpkg -i brickd_linux_latest_armhf.deb Dann sollte es funktionieren.

Hast du auf dem Raspberry Pi den Brick Daemon installiert? http://www.tinkerforge.com/de/doc/Embedded/Raspberry_Pi.html#raspbian-armhf

Die openHab Dokumentation https://my.openhab.org/docs spricht von "webapps/static" was wahrscheinliche "/usr/share/openhab/webapps/static" meint.

short vs int: remotecontrol hat recht, da ist uns was durcheinander geraten. Das hätte schon immer int sein müssen. In der Doku ist das schon korrigiert. In den Bindings wird das mit der nächsten Release auch int werden. Die häufigste Ursache für eine TimeoutException ist, dass du nicht die UID deines Bricklets verwendest und daruch keine Antwort erhältst.

Ich nehme an du meinst es2_info gibt diesen Fehler aus. Ich habe mir das gerade kurz angesehen aber ich kann nicht wirklich was dazu finden warum eglInitialize() fehlschlägt. Kannst du das noch mal mit einem frischen RED Brick Image testen?

Port bleibt 4223.

Du meinst, wenn du das USB Kabel zu RED Brick abziehst, dann verschwindet er aus Brick Viewer? Dein Brick Viewer ist wahrscheinlich mit Brick Daemon an localhost verbunden. Über Brick Daemon hast du die Verbindung zum RED Brick über USB. Wenn du USB abziehst ist die Verbindung dann natürlich weg. Um die Ethernet Verbindung zum RED Brick zu nutzen musst du dessen IP Adresse oder Hostnamen als Host im Brick Viewer Setup Tab anstatt localhost angeben.

Okay, nächster Versuch. Beim ersten mal hatte ich die Debian Packages nicht exakt genug nachgebaut. libegl1-mesa_2-1.1-1_armhf.deb libgles1-mesa_2-1.1-1_armhf.deb libgles2-mesa_2-1.1-1_armhf.deb libsunxi-mali-x11_1.1-1_armhf.deb

Okay, ich denke ich habe das Problem gefunden. Das sunxi-mali Makefile installiert den Treiber ins falsche Verzeichnis. Zumindest muss es auf dem RED Brick in ein anderes Verzeichnis damit es2gears es benutzt. Ich habe vier Debian Packages angehängt. Installier die mal bitte alle mittels "sudo dpkg -i <package-file>" auf dem RED Brick (Reihenfolge ist egal). Danach sollte es2gears deutlich schneller laufen. Teste das dann auch mal bitte mit deinem richtigen OpenGL Programm, nicht das ich da jetzt bloß es2gears verbessert habe. Edit: Das entspricht übrigens dem was im Wiki Eintrag steht. Das sunxi-mali Makefile installiert die Dateien nach /usr/lib/. Die EGL/GLES Debian Packages, die Dateien gleichen Namens beinhalten installieren diese nach /usr/lib/arm-linux-gnueabihf/ was Vorrang vor /usr/lib/ zu haben scheint. Daher werden im Wiki Eintrag die EGL/GLES Debian aus /usr/lib/arm-linux-gnueabihf/ wegbewegt. Die angehängten Debian Packges ersetzen die original Debian Dateien mit denen aus sunxi-mali. libegl1-mesa_2-1.1-1_armhf.deb libgles1-mesa_2-1.1-1_armhf.deb libgles2-mesa_2-1.1-1_armhf.deb libsunxi-mali-x11_1.1-1_armhf.deb

Port muss 4223 sein.

Der Brick Daemon Installer richtet brickd.exe als Windows Service ein und startet diesen. Der Brick Daemon Läuft also schon automatisch im Hintergrund. Du musst brickd.exe also nicht von Hand starten und solltest es auch nicht. Aber was ist dein eigentliches Problem, dass sich dazu gebracht hat zu versuchen brickd.exe von Hand zu starten? Wenn du das GUI Programm suchst, dann musst du Brick Viewer installieren.