WLan Extension mit 2 Master -> TimeoutException

[gagahhag]

Ich habe mir einen Stack mit 2 Master Bricks und einer WLAN Extension gebaut. Die 2 Master benutze ich, damit ich 5 Bricklets anschliessen kann.

 

Das Problem, welches ich jetzt habe ist, dass die Kommunikation über WLAN extrem langsam ist; d.h. ich kriege immer eine TimeoutException, wenn ich z.B. versuche ein CallbackPeriod zu setzen.

 

Der ganze Stack per USB verbunden funktioniert super und ohne Problem (auch über Netzwerk mittels Raspberry Pi; nur eben nicht über WLAN.

 

Kann es sein, dass die WLAN Extension direkt auf den untersten Master gesteckt werden muss? Ebenfalls sind die Master 2 unterschiedliche HW Versionen (1.1/2.0) aber beide haben die gleiche Firmware.

 

Ich werde mal versuche, ob die Kommunikation mit nur 1 Master besser ist aber vielleicht kann das jemand meinen Stack mal nachbauen und ausprobieren?

[gagahhag]

So, habe noch ein bisschen rumgetestet und bemerkt, dass ich wahrscheinlich irgend etwas noch nicht richtig begriffen habe (oder es wirkling ein Bug ist).

 

Wenn ich ein neue Verbindung zum Stack aufbaue (über WLAN) und anschliessend bei der IPConnection ein EnumerateLister hinzufüge, wird dieser sofort aufgerufen. Ich brauche keinen Aufruf von ipCon.enumerate() mehr. Ist das so gewollt?

 

Ich habe mal das Beispiel von http://www.tinkerforge.com/en/doc/Software/IPConnection_Java.html#ipcon-java ausprobiert mit dem selben Ergebnis, dass alle Bricks und Bricklets 2x ausgegeben werden.

 

Den ganzen Stack per USB angeschlossen und das gleiche Programm (Verbindung auf localhost) führt jedoch zum erwarteten Ergebnis. Alle Bricks und Bricklets werden nur 1x ausgegeben. Ich denke, so sollte es auch über WLAN sein?

 

[borg]

Das ist soweit richtig. Das Enumerate kommt einmal wenn das erste mal eine Verbindung zum PC aufgebaut wird und das zweite mal wenn du es explizit anfragst.

 

Das Äquivalent wenn du dein Programm über USB betreibst ist wenn du den Stack erst anschließt wenn das Programm schon gestartet ist. Dann bekommst du auch das initiale Enumerate und dann noch eins wenn du es triggerst.

[gagahhag]

Ok, ich habe jetzt angenommen, dass es keine Rolle spielt, ob ich per USB oder per WLAN verbinde. Zitat aus der WLAN Extension Dokumentation: "From the programming perspective this is completely transparent..."; Oder aber ich habe ein Verständnisproblem von WLAN vs. USB.

 

Das connect() verbindet dann mal auf den Deamon (USB: brickd, WLAN: whatever), soweit so gut, da passiert ja noch nicht viel. Wenn ich aber ein EnumerateListener hinzufüge, löst dies bei WLAN sofort ein enumerate() aus, bei USB aber nicht? Für mich tönt das nicht ganz logisch.

 

Vielleicht kann mich da jemand etwas erleuchten.

[AuronX]

Das ist ein Verständnisproblem zwischen TF und (mindestens) mir und dir. Wurde schonmal thematisiert.

 

Ich halte es auch für falsch bei der Verbindung zum WiFi-Brickd ein enumerate zu erhalten. Aus der Perspektive vom Brick ist aber das Anstecken eines USB-Kabels und das Herstellen der WLAN-Verbindung offenbar das gleiche, weswegen ein Enumerate kommt.

 

Ich halte es für falsch und finde, dass es geändert werden sollte, aber das ist nur meine Meinung.

 

edit: http://www.tinkerunity.org/forum/index.php/topic,1559.0.html

Das ist der Thread mit der ersten Diskussion zum Thema. Auf mein Argument, dass das Verhalten ur aus Sicht des Bricks und nicht aus Sicht der Bindings gleich ist wurde soweit ich das überflogen habe kein Bezug mehr genommen.

[photron]

Das Hinzufügen des EnumerateListener löst kein Enumerate aus. Das sieht für dich nur so aus, weil das zeitlich bei dir gerade in der passenden Reihenfolge passiert, das ist aber nicht kausal zusammenhängend.

 

Es gibt 3 Gründe die eine Enumerate verursachen.

 

1) Du erzwingst es durch einen enumerate() Aufruf. Dann ist der enumerateType == AVAILABLE im EnumerateListener Aufruf.

 

2) Der Stack hat eine neue Verbindung aufgebaut. Dann sendet er von sich aus einen Enumerate Callback mit enumerateType == CONNECTED. Damit kann den Programm mitbekommen, ob ein Stack im laufenden Betrieb neugestartet ist/wurde. Bei WIFI führt dass dazu das du direkt nach dem Verbindungsaufbau ein Enumerate bekommst.

 

3) Der Stack wurde von USB getrennt, Dann sendet brickd von sich aus einen Enumerate Callback mit enumerateType == DISCONNECTED.

[AuronX]

2) Der Stack hat eine neue Verbindung aufgebaut. Dann sendet er von sich aus einen Enumerate Callback mit enumerateType == CONNECTED. Damit kann den Programm mitbekommen, ob ein Stack im laufenden Betrieb neugestartet ist/wurde. Bei WIFI führt dass dazu das du direkt nach dem Verbindungsaufbau ein Enumerate bekommst.

 

Halte ich noch immer für falsch, da es für mich noch immer nicht transparent ist, ob ich zu einer WiFi-Extension oder zu einem Software-brickd verbinde. Ich kann gerne einmal den Rechner mit einem Brickd neustarten, bezweifle aber, dass dieser bei der Neuverbindung ein enumerate senden wird.

Versteht doch einfach, dass diese Unterschiede existieren. Es ist nicht transparent.

[Loetkolben]

Hallo zusammen,

 

schoen das ihr an mich denkt: [TCP/IP] Hilfe: Antwortpaket von USB Bricklet und WLAN Bricklet unterschiedlich! Warum?

 

Ich habe mittlerweile "verstanden" wie man den Hasen erlegt und parse in meinem Fall alle Pakete die vom USB oder WLAN Brick kommen.

 

Vielleicht sollte Tinkerforge mal eine Zeichnung (Ablaufplan) machen und die Kommunikation in einfachen Worten erklaeren, denn ein Bild sagt mehr als 1000 Worte.    Das alles dokumentiert ist glaube ich, aber man braucht lange bis man es verstanden hat.

 

Zum Thema: USB und WLAN Stacks haben den gleichen Kommunikationsablauf, aber als User "springt" man zu unterschiedlichen Zeitpunkten in die Kommunikation ein.

 

Der Loetkolben

[gagahhag]

Habe gerade nocheinmal etwas komisches in diesem Zusammenhang entdeckt.

 

Aufbau des Stacks wie gehabt: 2 Master, 1 WLAN Extension (zuoberst). Am 1. Master habe ich 4 Bricklets, am 2. Master 1 Bricklet.

 

Jetzt verbinde ich per WLAN und das darauf kommende Enumate-Event bringt mir nur die Brick/lets des 1. Master. Der EnumerateListener wird also 5x aufgerufen. Vom 2. Master weiss ich aber bis jetzt noch nichts!

 

Wenn ich jetzt aber das enumerate() forciere, werden alle Brick/lets vom 1. Master UND diejenigen vom 2. Master aufgerufen. EnumerateListener wird 7x aufgerufen.

 

Nach den Erklärungen von vorhin hätte ich jetzt erwartet, dass auch beim ersten Enumerate ALLE angeschlossenen Brick/lets gemeldet werden.

 

Habe ich da wieder etwas falsch verstanden?

[gagahhag]

Habe noch ein bisschen getestet. Diesmal nur mit einem Stack aus 2 Master (ohne Bricklets). Ich habe dabei die IPConnection-Demo etwas abgewandelt um das Verhalten zu testen:

 

import java.util.Scanner;

import com.tinkerforge.IPConnection;

public class Test {
    private static final String host = "localhost";
    private static final int port = 4223;

    // Note: To make the example code cleaner we do not handle exceptions. Exceptions you
    //       might normally want to catch are described in the documentation
    public static void main(String args[]) throws Exception {
        // Create connection and connect to brickd
        IPConnection ipcon = new IPConnection();
        ipcon.connect(host, port);

        // Register enumerate listener and print incoming information
        ipcon.addEnumerateListener(new IPConnection.EnumerateListener() {
            {
            	System.out.println("Added EnumerateListener");
            }
        	
        	public void enumerate(String uid, String connectedUid, char position,
                                  short[] hardwareVersion, short[] firmwareVersion,
                                  int deviceIdentifier, short enumerationType) {
                
            	if(enumerationType == IPConnection.ENUMERATION_TYPE_CONNECTED) {
                	System.out.println("UID: [" + uid + "] connected");
                } else if(enumerationType == IPConnection.ENUMERATION_TYPE_AVAILABLE) {
                	System.out.println("UID: [" + uid + "] available");
                } else if(enumerationType == IPConnection.ENUMERATION_TYPE_DISCONNECTED) {
                	System.out.println("UID: [" + uid + "] disconnected");
                }
            	
            }
        });
        
        System.out.println("Plug in USB and press Any Key\n");
        new Scanner(System.in).nextLine();
        
        System.out.println("\nEnumerate #1:");
        ipcon.enumerate();

        new Scanner(System.in).nextLine();
        
        System.out.println("\nEnumerate #2:");
        ipcon.enumerate();
        
        System.out.print("Press Any Key\n");
	new Scanner(System.in).nextLine();
        ipcon.disconnect();
    }
}

 

Der Output ist dabei wie oben beschrieben, dass beim Verbinden per USB nach dem Verbinden zu brickd der EnumerateListener aufgerufen wird; EnumerateType CONNECTED. Das komische dabei ist, dass der erste Master 2x gemeldet wird. Das sollte so nicht sein, oder?

 

Output:

Added EnumerateListener
Plug in USB and press Any Key

UID: [6rjyf7] connected
UID: [6rjyf7] connected
UID: [68xGay] connected


Enumerate #1:
UID: [6rjyf7] available
UID: [68xGay] available


Enumerate #2:
Press Any Key
UID: [6rjyf7] available
UID: [68xGay] available

 

Das gleiche Spiel ohne geänderten Code (nur Host wurde angepasse), sieht der Output folgendermassen aus:

 

Added EnumerateListener
Plug in USB and press Any Key

UID: [6rjyf7] connected


Enumerate #1:
UID: [6rjyf7] available
UID: [68xGay] connected
UID: [68xGay] available


Enumerate #2:
Press Any Key
UID: [6rjyf7] available
UID: [68xGay] available

 

Ich hätte jetzt nach dieser Diskussion den gleichen Output erwartet. Es scheint, dass das Verhalten mittels brickd oder WLAN nicht das gleiche ist und sollte IMHO angepasst werden.

[borg]

Das doppelte "connected" im ersten Output kann ich hier nicht reproduzieren, ansonsten ist das so wie ichs erwarten würde.

 

Ganz allgemein zum Enumerate: Wenn ein Enumerate mit "ipcon.enumerate()" getriggert wird, bekommst du von jedem zu erreichendem Gerät eine Enumerierung. Das wird soweit garantiert. Es kann aber jederzeit sein, dass du eine Enumeration-Nachrich bekommst die du nicht getriggert hast. Zum Beispiel weil ein neues Brick verbunden wurde oder auch weil ein anderes Programm eine Enumerierung getriggert hat (z.B. der Brick Viewer).

 

D.h. ein Programm welches die Enumerates nutzt sollte immer damit klar kommen können spontane Enumerate-Callbacks zu zu bekommen.

[gagahhag]

D.h. ein Programm welches die Enumerates nutzt sollte immer damit klar kommen können spontane Enumerate-Callbacks zu zu bekommen.

 

Da gebe ich dir voll und ganz recht und stellt insofern kein Problem dar. Ich persönlich (und anscheinend auch andere) finde das ganze Verhalten etwas 'undurchsichtig'.

 

Soweit so gut, ich werde mich damit abfinden können.