Jump to content

startproblem: no ip-connection...


MacDuff

Recommended Posts

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

Link zu diesem Kommentar
Share on other sites

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(8);

}

 

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

<STDIN>;

$ipcon->disconnect();

Link zu diesem Kommentar
Share on other sites

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?

Link zu diesem Kommentar
Share on other sites

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.

Link zu diesem Kommentar
Share on other sites

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.

Link zu diesem Kommentar
Share on other sites

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

Link zu diesem Kommentar
Share on other sites

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

Link zu diesem Kommentar
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...