photron

Brick Viewer 2.1.0 Support für Authentifizierung hinzugefügt Konfiguration für Authentifizierung für Ethernet und WIFI Extension zum Master Brick Plugin hinzugefügt Konfiguration für WebSockets für Ethernet Extension zum Master Brick Plugin hinzugefügt Temperaturmittelwert Bug im Barometer Bricklet Plugin korrigiert Dual Button Bricklet links/rechts Vertauschung korrigiert Langzeit-Speicherverbrauch gesenkt durch Entfernen von unabsichtlichen Referenzen auf bereits entfernte Brick/Bricklet Tabs Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.1.0 Add authentication support Add authentication configuration for Ethernet and WIFI Extension to Master Brick plugin Add WebSocket configuration for Ethernet Extension to Master Brick plugin Fix temperature averaging bug in Barometer Bricklet plugin Fix Dual Button Bricklet left/right permutation Reduce long-term memory usage by properly removing widgets on device disconnect Downloads: Windows, Linux, Mac OS X

Bindings: C/C++ 2.1.0, C# 2.1.0, Delphi 2.1.0, Java 2.1.0, JavaScript 2.0.0, LabVIEW 2.1.0, Mathematica 2.1.0, Perl 2.1.0, PHP 2.1.0, Python 2.1.0, Ruby 2.1.0, Shell 2.1.0, VB.NET 2.1.0 Support für Authentifizierung zur IPConnection und Master Brick API hinzugefügt [alle] Erste JavaScript Bindings Release [JavaScript] Endian-Behandlung funktioniert nun ohne das eigentliche Endian des Hosts zu kennen [C/C++] Receive-Thread wird beim Socket-Shutdown durch die Gegenseite beendet um zu vermeiden den Disconnected Callback mehrfach auszulösen [C#] TDeviceBase Klasse als leere Basisklasse für alle Devices hinzugefügt [Delphi] TinkerforgeListener und DeviceListener Interface als Basis für alle Listener hinzugefügt [Java] HTML-Sonderzeichen in JavaDoc werden escapet [Java] Interne IPConnection Locks sind jetzt normale Member der Klasseninstanz [Perl] Brick and Bricklet Klassen sind jetzt ordentliche Unterklassen der Device Klasse [Perl] Die auto_reconnect Option wird nicht mehr fälschlicherweise in der set_timeout Funktion überschrieben [Perl] Socket-Shutdown wird jetzt im Receive-Thread richtig behandelt [Ruby] Download: C/C++, C#, Delphi, Java, JavaScript, LabVIEW, Mathematica, Perl, PHP, Python, Ruby, Shell, VB.NET

Bindings: C/C++ 2.1.0, C# 2.1.0, Delphi 2.1.0, Java 2.1.0, JavaScript 2.0.0, LabVIEW 2.1.0, Mathematica 2.1.0, Perl 2.1.0, PHP 2.1.0, Python 2.1.0, Ruby 2.1.0, Shell 2.1.0, VB.NET 2.1.0 Add authentication support to IPConnection and Master Brick API [all] Initial JavaScript bindings release [JavaScript] Rewrite endian handling logic to work without detecting the actual host endian [C/C++] Exit receive thread on socket shutdown by peer to avoid triggering multiple disconnected callbacks [C#] Add TDeviceBase class as empty base class for all devices [Delphi] Add TinkerforgeListener and DeviceListener as base interfaces for all listeners [Java] Escape special HTML characters in JavaDoc [Java] Make IPConnection locks proper members of the class instance [Perl] Make Brick and Bricklet classes proper subclasses of Device [Perl] Don't overwrite auto_reconnect option in set_timeout function [Perl] Properly handle socket shutdown in receive thread [Ruby] Download: C/C++, C#, Delphi, Java, JavaScript, LabVIEW, Mathematica, Perl, PHP, Python, Ruby, Shell, VB.NET

Die Parameter für setLEDState() sind nicht LED-Index und LED-Zustand, sondern Linke-LED-Zustand und Rechte-LED-Zustand. if( x % 2 == 0 ) { dualbutton.setLEDState(BrickletDualButton.LED_STATE_ON, BrickletDualButton.LED_STATE_OFF); } else { dualbutton.setLEDState(BrickletDualButton.LED_STATE_OFF, BrickletDualButton.LED_STATE_ON); }

Ah, this script is from a PC magazine. This information was missing in your German post. As stated in the other thread, you're just missing the pytz module. On Debian/Ubuntu you can install it like this: sudo apt-get install python-tz

Dein Python kennt kein pytz Modul. Unter Debian/Ubuntu musst du dafür das python-tz Package installieren. sudo apt-get install python-tz Das Script ist zumindest nicht von uns.

Zu den UIDs: Das sind BASE58 kodierte 32-Bit Zahlen. Die größte UID ist also 7xwQ9g (4294967295). Die werden von uns aufsteigend an die Bricklets vergeben, wobei sichergestellt wird, dass wir keine UID zweimal vergeben. Die UID muss im System eindeutig sein, sonst funktioniert das Zustellen der Nachrichten nicht richtig, da die UID als Adresse verwendet wird. Wenn du also manuell die UID der Bricklets über den Brick Viewer änderst, dann muss du darauf achten, dass diese in deinem System eindeutig und nicht doppelt vergeben sind. Die UID der Bricks wird von uns nicht vergeben, sondern in der Firmware aus der 128-Bit UID des Mikrocontrollers abgeleitet. Eine Brick UID ist typischerweise 6-stellige in BASE58, daher verwenden wir für die Bricklets 3-stellige UIDs um hier Überschneidungen zu verhindern.

According to M-Bus spec you need to detected if the device consumes current (11-20mA, means "0") or not (< 1.5mA, means "1"). In principal you could use a Voltage/Current Bricklet or Industrial Dual 0-20mA Bricklet to measure the current consumption of an M-Bus slave interface. But this is limited by the sampling frequency that the Bricklets can achieve. Due to the nature of our communication protocol this is limited to 250Hz. This is probably too low to sample the M-Bus bits. So you probably can't use Bricklets to read data from an M-Bus device.

Ich hab mich jetzt einige Tage mit diesem Problem beschäftigt und komme zu dem Schluss, dass ich weder wirklich rauskriege was das eigentliche Problem ist noch wie es zu beheben ist. Ich habe auch auf PerlMonks nachgefragt ohne da zu einem schlüssigen Ergebnis zu kommen. Dabei ist mir aber auch noch ein anderes Problem mir Auto-Reconnect aufgefallen, das jetzt in Version 2.0.2 der Perl Bindings behoben ist. Dein eigentliches Problem besteht aber leider noch. Ich habe aber festgestellt, dass es nur mit Strawberry Perl und Active State Perl auftritt, aber Cygwin Perl nicht betroffen ist und die Bindings damit einwandfrei funktionieren. Die Empfehlung für Windows ist also bis auf Weiteres Cygwin Perl zu verwenden.

Bindings: Perl 2.0.2 Use better markup in inline documentation Rework socket sharing between threads to fix (auto-re)connection handling Download: Perl

Bindings: Perl 2.0.2 Passenderes Markup in Inline-Dokumentation verwendet Socket-Sharing zwischen Threads überarbeitet um Probleme mit dem (Auto-Re)connection Handling zu korrigieren Download: Perl

Nice! This send queue feature will be part of the next release.

Weitere 8 Bricks können oben auf die Ethernet Extension aufgesteckt werden. Die Ethernet Extension muss nicht das oberste Element im Stack sein, sondern nur über dem untersten Master Brick sein. Das Gehäuse hat keinen Platz für eine Step-Down Power Supply. Diese müsste ganz im den Stack sein. Das Kit ist darauf ausgelegt per PoE versorgt zu werden.

That's interesting: 2014-03-17 23:15:37.098579 <E> <network|client.c:255> Could not send response to client (socket: 15, peer: 192.168.1.116), disconnecting it: EAGAIN (11) This means that brickd cannot send data to the socket. This only happens if you reconnect brickv while the the Bricks are connected. Brickv requests an enumerate on connect. If no Bricks are connected then there is no enumerate response. If you connect a Brick it sends enumerate responses for its stack only. But if you reconnect Brickv while all the Bricks are connected then all Bricks send their enumerate response at once resulting in a burst. This could explain the problem you're seeing there. I've added a send queue to brickd to deal with this situation. I attached an .deb package for armhf, assuming that the right things for the Odroid. If you didn't install from a package you can find the source code on GitHub: https://github.com/Tinkerforge/brickd Could you test this version to see if it fixes your problem? brickd-2.1.0-dfef064fc11f415b926aa82ba77f6f63a8c7b375_armhf.deb

Did you try apt-get -f install as suggested?

Ich hab das Problem in einem kleinen Script reproduziert: use strict; use warnings; use threads; use IO::Socket::INET; my $s = IO::Socket::INET->new(PeerAddr => 'localhost', PeerPort => 4223, Proto => 'tcp') or die "error: $@"; print "create t1\n"; my $t1 = threads->create(sub { my ($r) = @_; my $data = ''; print "in t1\n"; # this intentionally blocks. if this line is removed the problem vanishes $r->recv($data, 64); print "recv done\n"; }, $s); print "create t2\n"; my $t2 = threads->create(sub { print "in t2\n"; # problem: this is never printed }, 0); print "done\n"; # problem: this is never printed, as threads->create never returns $t1->join(); $t2->join(); Unter Windows getestet mit Strawberry und Active Perl 5.18.2. Bei beiden hängt der threads->create() für t2, bedingt durch den Aufruf von recv() in t1. Nach meinem Verständnis tue ich das nichts Böses und das sollte funktionieren. Unter Linux tut es das auch und wenn ich nach Multithreaded Socket-Handling in Perl suche finde ich Beispiele die genau so, oder ähnlich funktionieren. Mir ist noch nicht klar was da das Problem ist.

So, if you have brickv connected to brickd before you connect any Bricks then it works. But If you try to connect brickv to brickd while there are already Bricks connected to USB then it doesn't work. Odroid U3 can run XUbuntu 13.10 or Android 4.x according to their website. I assume you're using XUbuntu. Are you running brickv on the Odroid U3 if the problem occurs? If yes you might be affected by this bug in PyQwt. You can check your PyQwt version like this: apt-cache show python-qwt5-qt4 If it's older than 5.2.1~cvs20091107+dfsg-6+b3build2.1 you should probably update it. You can also test if the problem doesn't occur if you run brickv on a different computer than the Odroid U3, for example your Macbook, while the Bricks are still connected to the Odroid U3. This all assumes that the problem is related to the PC you run brickv on. If that's not the case and the problem is only related to the PC brickd is running on then I'm following a red herring here

Ich hab das gerade getestet und in der Tat ist da ein Problem in den Perl Bindings. Was aber nur Windows zu betreffen scheint, unter Linux tritt es nicht auf. IPConnection.connect() bleibt intern beim Erzeugen eines Threads hängen. Wobei es aber vorher zwei andere Threads erfolgreich erzeugt hat. Wenn ich den Code für den dritten Thread entferne, dann hängt nachher der set_state() Aufruf intern beim Schreiben auf den Socket. Das sind zwei Dinge von denen ich behauptet hätte sie würden niemals hängen können. Muss ich genauer anschauen was das ist. Kann ich dir ad-hoc leider keine Lösung für anbieten, sorry. Wir hatten die Perl Bindings auf Windows getestet, wohl allerdings nicht gut genug Ich hab das mit Strawberry Perl 5.18.2.1 getestet. Welche Perl Distribution/Version verwendet du?

Yes, too long or too low quality USB cables might result in broken/flaky USB communication. That's something to check too. But this should not stop brickd from accepting TCP/IP connection attempts from brickv.

If brickv fails to connect to brickd then this might be a problem in brickd itself. Assuming that you mean that brickv is really complaining about connection problems with a message box. There is known problem like this related to the number of connected Bricks. Are you using the latest version of brickd and the firmwares on the Bricks? What operating system are you using on the PC? Does it matter which of the Bricks you connect as third one that will then trigger the problem? Does this only happen with one of them? What USB cables are you using? Is the problem related to a specific cable? Could you take a look at the brickd log file? On Windows you can use eventlog.exe from the brickd installation directory. eventlog.exe allows to store the log to file. On Linux and Mac the log file is stored in /var/log/brickd.log. Could you attach the log file here on a post, so I can have a look at it?

Die Ausführungszeit für GetTouchState ist nicht anhängig vom aktuellen Zustand der Elektroden. Ich vermute das eigentliche Problem steckt wo anders. Was meinst du mit "wenn der Sensor anspricht"? Wenn du eine der Elektroden berührst? Wenn das Problem auftritt, läuft es danach normal weiter oder ist das System dann dauerhaft aus dem Tritt? Wie hast du das Bricklet am Brick angeschlossen (Kabellänge, geschirmt oder nicht)? Wie ist der Brick an dem es hängt angeschlossen (USB, WLAN, etc)?

Der RS485 Bus kennt keine Reihenfolge wie sie deine Skizze darstellt. Der Bus ist in dem Sinne nicht linear. Es wird nur zwischen RS485 Master und RS485 Slaves unterschieden. Daher spielt es keine Rolle an welchem RS485 Slave du den Chibi Master betreibst. Du kannst also nach dem "letzen" RS485 Knoten auf einen weiteren RS485 Knoten "abzweigen".

Ich hab die Basisversion für solche Änderungsangaben jetzt von 1.0.0 auf 2.0.0 angehoben. Dadurch fällt dann auch der out Parameter Hinweis weg.

Robin, I tested this before posting here about RC1. I used a Raspberry Pi here running Raspbian and it worked without problems. The first problem you mentioned is expected if you don't have pm-utils already installed. This is because dpkg doesn't do any dependency handling for your, that's what apt-get is for. dpkg only tells you what dependencies are missing and you have to install them manually. The second error is unexpected and I didn't encounter it during testing. Also this dosen't look to me as dpkg is rejecting the installation because the hardware might not support suspend. pm-utils is just a bunch of scripts that allow to forward suspend/resume events. I think the pm-utils dependency will stay as it is, because your second problem looks like an apt-get hiccup to me and not like a general problem. Anyway, thanks for testing