photron

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

pluto, das ist viel schwerer als du dir das vorstellst und von der Komplexität nicht vergleichbar mit den Bindings-Generatoren. Du schlägst im Prinzip vor C/C++, C#, Delphi, Java, Perl, PHP, Python, Ruby, Shell und VB.NET Compiler zu schreiben die Code erzeugen, der auf dem Brick direkt ausgeführt werden kann. Die technischen Details der exakten Ausführung diese Unterfangens sollen hier mal unter den Tisch fallen. Für C gibt es das schon, so schreiben wir ja die Firmwares, aber für alle anderen Sprachen ist das sehr sehr viel Aufwand, wenn es überhaupt sinnvoll möglich ist. Da ist es viel einfacher und überschaubarer ein RED Brick nach jetzigem Plan zu machen, auf dem man dann all die existierende Infrastruktur für alle unterstützten Sprachen einfach weiter nutzen kann.

Authentication The original plan for authentication in Protocol 2.0 was to have a pre-shared key that the user and the Brick know. This would be used to sign all messages send between Brick and user. Both sides verify that the messages are correctly signed. This way an attacker can neither claim to be a user nor to be a Brick. The problem with this plan is the complexity it adds to the Brick. Due to the way it works it would have to be directly integrated in the already very complex WIFI Extension logic. That's why we didn't do this yet. A simpler option would be to do authentication per-connection, were the user has to prove that he knows the pre-shared key. There are basically two options how to do this: Only for WebSockets The user's pre-shared key is send to the WebSocket server (Ethernet/WIFI Extension or Brick Daemon) as part of the WebSocket handshake during the connection process. Then the WebSocket server can compare it to its stored pre-shared key. If it matches then the connection attempt is accepted and the connection is authenticated. Otherwise the connection attempt is aborted. Before WebSockets can be used the user has to configure the pre-shared key of the WebSocket server. And in the JavaScript bindings the connect() function gets a third parameter that takes the pre-shared key to be include in the WebSocket handshake. For all communication By default authentication would be disabled to be compatible with the current system. If authentication is enabled then all TCP/IP connections to the TCP/IP server (Ethernet/WIFI Extension or Brick Daemon) start in unauthenticated state and all incoming and outgoing messages are thrown away until the user authenticates. For this the IPConnection of all bindings will get a authenticate() function that takes the pre-shared key, does the authentication process and proves to the TCP/IP server that the user knows the pre-shared key. This is done using a signing mechanism that avoids sending the pre-shared key over the wire. After this the connection is in authenticated state and all messages on this connection are handled as they are now. Because this type of authentication would be disabled by default WebSockets would also be disabled by default as we don't want to release something that is easily attacked by a malicious website in the default configuration. Any opinions, suggestions, questions?

It'll just connect to localhost:4280 to connect to the brickd on your PC. And even if you change the port then it can just probe all ports.

Not any browser running anywhere, but YOUR browser running on YOUR PC. I could make you open a website that I control and have it mess with your stack connected to your PC. I don't need external access to your network I just need you to open my website. In fact we will do exactly that. We plan to create an online version of Brick Viewer. You will be able to open brickv.com and it will be able to access your stack connected to your PC and provide the same features a locally installed Brick Viewer has. All this without installing any files to your PC, you just loaded a website with some JavaScript code that is executed in your browser.

Equinox, your browser is executing the JavaScript code. Your browser has access to your local network and any brickd running there. No direct connection from the Internet to your local 4280 port necessary.

No. An external party/attacker cannot access your stack, assuming you didn't expose port 4223 to the Internet. But with WebSocket support in brickd any website you open in your browser can access your stack via the brickd WebSocket, even if the WebSocket is only reachable from your PC. So any website out there that you open in your browser can access your stack, even if you didn't expose port 4280 to the Internet. The problem here is that you're basically running untrusted code from external sources in your browser. That's why there is so much sand-boxing in modern browsers. That's also the reason why WebSockets in the browser cannot connect to normal sockets. Otherwise any website could access all services on your local network via your browser. So, a malicious webserver cannot attack your stack directly, but it can deliver you a website that can do this.

Loetkolben, the new requirement for pm-utils is intended. It's part of the fix for the problem that brickd fails to talk to USB devices after a suspend on Linux and Mac OS X. There is a thread about this in the German board: http://www.tinkerunity.org/forum/index.php/topic,2169.0.html

Im englischen Thread gibt es jetzt einen brickd mit WebSocket Support und eine aktualisierte Version der Bindings die auch im Browser funktionieren.

Here's Brick Daemon 2.1.0 RC1 that accepts WebSocket connections on port 4280: Windows, Linux (amd64, i386, armhf), Mac OS X And here's also an updated version of the JavaScript bindings that includes the browser version of the bindings and examples for them. tinkerforge_javascript_bindings_2_0_0_rc1.zip Just put an example HTML file and the Tinkerforge.js file from the browser subdirectory in the ZIP in the same directory and open the HTML file in your browser. This was tested and works in the latest versions of Chrome/Chromium, Firefox and Internet Explorer. Other browsers that support the current WebSocket version should work as well.

Ah, the documentation of the Servo Brick is outdated in that point, sorry. The minimum limit used to be 2000µs, but it was lowered to 1µs quite a while ago. Seems that we missed to update the documentation about this. I fixed this now, thanks for finding this one. About modifying the firmware: You can certainly modify the firmware to bit-bang a PWM signal on any pin of an I/O Bricklet. But that's no that easy to do, because things like this don't match well with the internal task scheduling of the Bricks. In this system you cannot have an endless loop that just sits there and generates a PWM signal, assuming you want the rest of the system to work as before, such as other Bricklets on the same Brick, stack and USB communication etc. In contrast the Servo Brick is designed for this and uses dedicated hardware units for PWM signal generation. That allows to integrate the signal generation nicely with the task scheduling system.

Here's an example for PWM generation with the Servo Brick: #include <stdio.h> #include "ip_connection.h" #include "brick_servo.h" #define HOST "localhost" #define PORT 4223 #define UID "6dKCNw" // Change to your UID // Due to the internal clock dividing mechanism of the Servo Brick not all // arbitrary PWM frequency values can be achieved. For example, the upper most // three available PWM frequency values are 1MHz, 500kHz and 250kHz. The steps // are coarser on the high frequency end and much finer on the low end. You can // set any value here between 15Hz and 1MHz and the Servo Brick will try to // match it as closely as possible. #define PWM_FREQUENCY 175000 // in Hz [15Hz to 1MHz] #define PWM_DUTY_CYCLE 20 // in % [0% to 100%] int main() { // Create IP connection IPConnection ipcon; ipcon_create(&ipcon); // Create device object Servo servo; servo_create(&servo, UID, &ipcon); // Connect to brickd if(ipcon_connect(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not connect\n"); exit(1); } // Don't use device before ipcon is connected // Set degree range to 0-100, this will allow to // set the PWM duty cycle in 1% steps servo_set_degree(&servo, 0, 0, 100); // Set PWM frequency (1-65535µs == 1MHz-15Hz) int period = 1000000 / PWM_FREQUENCY; if (period < 1) { period = 1; // 1MHz } else if (period > 65535) { period = 65535; // ~15Hz } servo_set_pulse_width(&servo, 0, 0, period); servo_set_period(&servo, 0, period); // Fast acceleration and full speed servo_set_acceleration(&servo, 0, 65535); servo_set_velocity(&servo, 0, 65535); // Set PWM duty cycle (0-100 %) int position = PWM_DUTY_CYCLE; if (position < 0) { position = 0; } else if (position > 100) { position = 100; } servo_set_position(&servo, 0, position); // Enable PWM signal servo_enable(&servo, 0); printf("Press key to exit\n"); getchar(); ipcon_destroy(&ipcon); // Calls ipcon_disconnect internally } The Servo Brick can generate PWM frequencies up to 1MHz. Why do you think it's 500Hz, were did you get that information? Yes, the power for the PWM signal is taken from the USB connection. The black power connector on the Servo Brick is for powering the servo motors. So you don't need it if you just want to use the PWM signal only. Here's and other example of using an IO-4 Bricklet for 3.3V PWM generation. In this example the whole timing is done from the PC and is affected by the jitter of the operating system scheduler and is limited by the USB speed. #include <stdio.h> #include <sys/time.h> #include "ip_connection.h" #include "bricklet_io4.h" #define HOST "localhost" #define PORT 4223 #define UID "hf4" // Change to your UID #define PWM_FREQUENCY 100 // Hz #define PWM_DUTY_CYCLE 20 // 0% to 100% uint64_t microseconds(void) { struct timeval tv; gettimeofday(&tv, NULL); return tv.tv_sec * 1000000 + tv.tv_usec; } // have to use busy waiting here, using usleep() is not accurate enough void delay(uint64_t ms) { uint64_t last = microseconds(); uint64_t now = last; while (now < last + ms) { now = microseconds(); continue; } } int main() { // Create IP connection IPConnection ipcon; ipcon_create(&ipcon); // Create device object IO4 io; io4_create(&io, UID, &ipcon); // Connect to brickd if(ipcon_connect(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not connect\n"); exit(1); } // Don't use device before ipcon is connected // Set pin 0 to output low io4_set_configuration(&io, 1 << 0, 'o', false); int high_time = ((1000000 * PWM_DUTY_CYCLE) / 100) / PWM_FREQUENCY; int low_time = ((1000000 * (100 - PWM_DUTY_CYCLE)) / 100) / PWM_FREQUENCY; for (; { io4_set_value(&io, 1 << 0); delay(high_time); io4_set_value(&io, 0 << 0); delay(low_time); } printf("Press key to exit\n"); getchar(); ipcon_destroy(&ipcon); // Calls ipcon_disconnect internally } I can achieve a somewhat stable PWM signal with up to 100Hz with this. If I go any higher then the duty cycle isn't stable anymore and starts to jump between 10% and 40% for this example. So this approach is limited by the 1000 messages per second USB can transfer to the Brick and the scheduling of the operating system. In contrast the Servo Brick can generate much more stable PWM signals with much higher frequencies because all the timing is done on the Servo Brick and is not affected by USB or the operating system of the controlling PC. Depending on your requirements on frequency and stability of the PWM signal you might be able to use one of the I/O Bricklets. If your PWM frequency should be below 100Hz and doesn't have to be that stable it might work out. Otherwise I still suggest a Servo Brick, even if it's a little bit expensive if you just use it as a single channel PWM generator

Your required PWM signal can very easily be created by a Servo Brick. The PWM signal of the Servo Brick has a fixed output voltage of 5V. If that works for the control interface of your pump then I suggest a Servo Brick for this purpose. Regarding the PWM label on the Breakout Bricklet: This is basically a mislabeling, there is no usable PWM signal on that pin.

Ist jetzt released. Danke für den Hinweis und den Test.

Bindings: PHP 2.0.13 Fix passing $userData parameter to callbacks Download: PHP

Bindings: PHP 2.0.13 Übergabe des $userData Parameters an Callbacks korrigiert Download: PHP

The Servo Brick can generate 7 PWM signals, but you cannot drive a load directly with them, as they are designed as control signals only. The DC Brick can generate 1 PWM signal with enough power to drive a load. The Digital I/O and AnalogOut Bricklets don't have hardware support for generating PWM signals. You could manually generate a PWM signal, but this has some disadvantages compared to the Servo and DC Brick. The Digital I/O and AnalogOut Bricklets are limited in their switching frequency and precision due to the speed and possible jitter in the communication between the PC and the Bricklets. So the correct approach depends on the actual interface of your pump. Can you provide more information about it?