startproblem: no ip-connection...

[MacDuff]

zum ersten Mal seit 20 jahren wieder gelötet -- das hardware hacking kit. schön sieht's nicht aus, aber es funktioniert soweit: via brickviewer kann ich die funkdosen schalten.

beim ansprechen über ein kleines perl-skript scheint aber die ip-connection nicht zustande zu kommen. (abfrage per get_connection_state()). es tut sich erst etwas, wenn ich den usb-stecker rausziehe und wieder einstecke.

daemon läuft. os = windows 7.

kann mich da jemand auf die richtige spur setzen?

danke sehr,

macduff

[borg]

Kannst du dein Perl Script hier posten? Ansonsten ist es schwierig etwas dazu zu sagen .

[MacDuff]

das ist im grunde das beispielprogramm von euch. wenn ich das so aufrufe, stoppt es mit der ausgabe:

"connectionstate a priori: " 0

 

 

skript:

 

#!/usr/bin/perl 

 

use lib './';

use Tinkerforge::IPConnection;

use Tinkerforge::BrickletIndustrialQuadRelay;

 

use constant HOST => 'localhost';

use constant PORT => 4223;

use constant UID => 'ifJ';

 

my $ipcon = IPConnection->new();

my $connectState = $ipcon->get_connection_state();

print "\nconnection state a priori: ".$connectState;

my $iqr = BrickletIndustrialQuadRelay->new(&UID, $ipcon); # Create device object

$ipcon->connect(&HOST, &PORT); # Connect to brickd

print "\nconnection state a posteriori".$connectState;

 

#Turn relays alternating on/off for 10 times with 1000ms delay

for (my $i = 0; $i < 10; $i++)

{

    sleep(1);

    $iqr->set_value(1);

   

    sleep(1);

    $iqr->set_value(2);

 

    sleep(1);

    $iqr->set_value(4);

 

    sleep(1);

    $iqr->set_value(;

}

 

print "\nPress any key to exit...\n";

<STDIN>;

$ipcon->disconnect();

[borg]

der connection state ist 0 weil du get_connection_state aufrufst bevor du connect aufrufst. Zu dem Zeitpunkt ist die Verbindung noch nicht hergestellt.

 

Warum die Relais nicht schalten weiß ich allerdings nicht. Ist die UID korrekt?

[MacDuff]

laut brickv ist die UID des QuadRelay "ifJ". dass zunächst der state = 0 ist, ist klar. ich weiß nur nicht, warum es dann nicht weiterläuft. verkabelung?

na, ohne trouble wär's ja auch halb so lustig. seufz.

macduff

 

 

 

[photron]

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?

[MacDuff]

ah, ok. aber schön, dass sich jemand drum kümmert. guter support.

ich benutze die Padre IDE mit Strawberry Perl 5.14.2.1.

ist jetzt nicht dringend, aber sagt ihr bescheid, wenn's dann funktioniert?

danke,

macduff

[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.

[MacDuff]

da kann ich leider nichts dazu beitragen. ich komm von actionscript/flash und bin noch ziemlich neu in Perl

danke

PS: das wär übrigens cool, wenn TF AS3 unterstützen könnte... ist eine mächtige sprache und ein grafisches interface inkl multimedia ist schnell gebaut...

[photron]

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.

[MacDuff]

ok. seltsam. aber wundern tut einen ja nix.

das cygwin perl hole ich mir.

habe allerdings heute nachmittag wohl meinen masterbrick zerschossen, der wurde recht warm an der weiß markierten ecke, während ich mit der ethernet extension hantierte. kann's nicht mehr genau nachvollziehen. jedenfalls ist der brick jetzt tot, kein LED, und die tricks mit erase-taste drücken und USB einstecken habe ich schon probiert - half nichts.

danke jedenfalls für die perl-nachforschungen.

macduff

[Gast Robin]

Vielleicht ist der Brick nur im Bootloader Modus. Hast du schon im brickv unter Updates / Flashing gekuckt oder im Geräte Manager?

[MacDuff]

ja -- im brickviewer ist nichts zu sehen vom masterbrick, im gerätemanager auch nicht...

ich fürchte, der ist hinüber.

 

 

[kreaktiv]

Der Master arbeitet im Bootloader Modus nicht wenn der EtherBrick drauf ist! Also trenn den Master mal ab.

Habe ich auch erfahren müssen.

Ev. einen Hinweis beim Beschrieb der FirmwareUpDate währe gut.

[MacDuff]

die hatte ich schon getrennt. allein der masterbrick hängt dran, wenn ich knöpfchen drücke und usb einstecke.

beim flashversuch im brickviewer heißt es: "no brick in bootloader found". ist auch nichts im device manager vom brick zu sehen, kein LED blinkt, nichts...

jedenfalls danke für die lösungsvorschläge.

 

macduff