TF Protocol 2.0 Beta

Einstein · December 29, 2012 at 17:38

Das Problem hatte ich auch. Geh mal unter configure extension type und bestätige nur das was schon da steht. Danach kannst du auch nen master konfigurieren. Ich hab bisher nur noch nicht rausgefunden an was das liegt.

thunderbird · December 29, 2012 at 17:50

Danke!

Das hat geklappt. Hmm da scheint dann noch irgendwie nen Fehler drin zu sein.

thunderbird · December 30, 2012 at 11:29

Hallo borg,

ich habe das mal mit setResponseExpected getestet. Ich habe aber setResponseExpectedAll genutzt weil ich sicher gehen wollte, dass es bei allen Funktionen so ist. Leider kann ich keine Änderung feststellen. Ich kann einfach einen beliebigen Sensor nehmen und einen Callback anhängen ohne das ich eine Exception bekomme, obwohl der Sensor garnicht angeschlossen ist.

Nutze ich aber

temp.setResponseExpected(BrickletTemperature.FUNCTION_SET_TEMPERATURE_CALLBACK_PERIOD, true);

bekomme ich eine Exception da schein irgendwas in der Funktion setResponseExpectedAll nicht ganz ok zu sein.

Setter erwarten Standardmäßig auch in neuen Protokoll keine Antwort, man kann es aber anstellen. Ist allerdings anscheinen noch nicht dokumentiert .

Alle Devices haben die folgenden 3 Funktionen:
public void setResponseExpected(byte functionId, boolean responseExpected);
public boolean getResponseExpected(byte functionId);
public void setResponseExpectedAll(boolean responseExpected)
d.h. du müsstest
temp_bricklet.setResponseExpected(TemperatureBricklet.SET_TEMPERATURE_CALLBACK_PERIOD, true);
aufrufen können und dann auch einen Timeout bekommen!

Edit: Allerdings bringst du mich da auf eine Idee, vielleicht sollten die CallbackPeriod und CallbackThreshold setter als Standardeinstellung alle responseExpected = true haben. Mit dem Hintergedanken: Die beiden Setter werden meist nur einmal beim starten des Programms aufgerufen und sind nicht relevant für die Performance.

Wenn jemand aus irgendwelchen Grüden die Periode oder den Threshold oft ändern muss, kann er es ja wieder zurück setzen. Mhmhmhmh

thunderbird · December 30, 2012 at 12:15

Ich denke ich habe das Problem gefunden. Wenn ich den Wert der Funktion auf "false" setzte

temp.setResponseExpectedAll(false);

dann läuft es so wie es soll.

Ich denke da sind in der Device Klasse die flag Einträge vertauscht.

Default müsste sein => RESPONSE_EXPECTED_FLAG_FALSE

Ist der Übergabewert true sollte flag => RESPONSE_EXPECTED_FLAG_TRUE sein.

public void setResponseExpectedAll(boolean responseExpected) {
	byte flag = RESPONSE_EXPECTED_FLAG_TRUE;
	if(responseExpected) {
		flag = RESPONSE_EXPECTED_FLAG_FALSE;
	}

Ob das in allen Bindings so ist weiß ich nicht. Das ist JAVA

borg · December 30, 2012 at 12:56

@thunderbird: In der Tat. Das war in den java und in den C# bindings vertauscht!

Wie ist das bzgl. RS485? Wenn ich eine RS485 Extension habe die mit V1 konfiguriert wurde, funktioniert die Konfiguration nicht mehr mit V2? Mh, gucke ich mir auch morgen an.

Viele Dank erstmal für das testen, hat ja schon einige Bugs zum Vorschein gebracht!

thunderbird · December 30, 2012 at 14:05

@borg: Also wenn ich bei einem bestehenden Master - Slave System V1 ein Update auf V2 mache läuft alles problemlos.

Habe ich aber eine ganz neue RS485 und einen MasterBrick mit V2 kann ich die RS485 nicht direkt auf dem "Master Modus" umschalten. Dazu muss ich erst wie Einstein beschrieben hat vorgehen.

Das Problem hatte ich auch. Geh mal unter configure extension type und bestätige nur das was schon da steht. Danach kannst du auch nen master konfigurieren. Ich hab bisher nur noch nicht rausgefunden an was das liegt.

Kein Thema. Die V2 hat für mich einige Vorteile von daher teste ich immer gerne ;-)

Ploby · December 30, 2012 at 17:48

Ich habe das Problem, dass ich mit Brickv 2.0 keine Verbindung zur Masterbrick oder auch Stepperbrick bekomme. Flashen funktioniert aber.

Beim Versuch des Connect kommt folgende Fehlermeldung:

"Please check host, check port and check if the Brick Daemon is running"

Unter DiagnosticReports befindet sich eine Datei "brickd_2012-12-30-180552-imac.crash" mit folgendem Inhalt:

Process: brickd [2064]

Path: /usr/libexec/brickd.app/Contents/MacOS/brickd

Identifier: brickd

Version: 2.0.0

Code Type: X86-64 (Native)

Parent Process: launchd [1]

User ID: 0

Date/Time: 2012-12-30 18:05:52.118 +0100

OS Version: Mac OS X 10.8.2 (12C60)

Report Version: 10

Crashed Thread: 0

Exception Type: EXC_BREAKPOINT (SIGTRAP)

Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:

dyld: launch, loading dependent libraries

Dyld Error Message:

Library not loaded: @executable_path/libusb-1.0.0.dylib

Referenced from: /usr/libexec/brickd.app/Contents/MacOS/brickd

Reason: Incompatible library version: brickd requires version 2.0.0 or later, but libusb-1.0.0.dylib provides version 1.0.0

Binary Images:

0x1078c0000 - 0x1078d1fff com.tinkerforge.brickd (2.0.0) <9A968B48-919F-365B-90E6-E66CA06AA3DA> /usr/libexec/brickd.app/Contents/MacOS/brickd

0x1078da000 - 0x1078e3ff7 libusb-1.0.0.dylib (1) <FF65BAFA-F297-8799-1AE1-0514FB6DA09A> /usr/libexec/brickd.app/Contents/MacOS/libusb-1.0.0.dylib

0x7fff674c0000 - 0x7fff674f493f dyld (210.2.3) <36CAA36E-72BC-3E48-96D9-B96A2DF77730> /usr/lib/dyld

Weiss jemand einen Rat?

borg · December 30, 2012 at 22:25

@Ploby: Kannst du mal -beta1 vom MacOS Brick Daemon probieren? Evtl hab ich einfach beim compilieren gegen die falsche libusb gelinkt (danach sieht es zumindest aus). Ich kann es gerade leider nicht testen.

photron · December 31, 2012 at 00:25

Dyld Error Message:
Library not loaded: @executable_path/libusb-1.0.0.dylib
Referenced from: /usr/libexec/brickd.app/Contents/MacOS/brickd
Reason: Incompatible library version: brickd requires version 2.0.0 or later, but libusb-1.0.0.dylib provides version 1.0.0

Das da steht brickd würde libusb 2.0.0 benötigen verwundert mich, es gibt keine libusb 2.0.0.

borg · December 31, 2012 at 09:41

Das da steht brickd würde libusb 2.0.0 benötigen verwundert mich, es gibt keine libusb 2.0.0.

Das scheint da immer bei einem Versionmismatch zu stehen, wenn du das in google wirfst findest du das häufiger in bugtrackern und es hat immer mit falschen oder nicht korrekt installierten Versionen zu tun.

Ploby · December 31, 2012 at 10:34

Das installieren der brickd v2 beta1 hat geholfen. Vielen Dank!

photron · January 2, 2013 at 11:42

brickd v2 beta3 für Mac OS X kommt jetzt wieder mit der passenden libusb. Unter Windows schreibt brickd jetzt Warnings und Errors ins Event Log.

Einstein · January 3, 2013 at 15:41

Gibts schon was neues bzgl. des WiFi - RS485 Problem?

borg · January 7, 2013 at 00:24

@Einstein: Kommt als nächstes. Hab ein paar Tage an dem IMU/GPS Problem gesessen: http://www.tinkerunity.org/forum/index.php/topic,1258.0.html

borg · January 7, 2013 at 15:52

@borg: Also wenn ich bei einem bestehenden Master - Slave System V1 ein Update auf V2 mache läuft alles problemlos.
Habe ich aber eine ganz neue RS485 und einen MasterBrick mit V2 kann ich die RS485 nicht direkt auf dem "Master Modus" umschalten. Dazu muss ich erst wie Einstein beschrieben hat vorgehen.

Kann ich leider nicht reproduzieren.

borg · January 7, 2013 at 17:16

Gibts schon was neues bzgl. des WiFi - RS485 Problem?

Kann ich leider auch nicht reproduzieren .

Ich hab den gleichen Aufbau nachgestellt. Screenshots von der Konfiguration sind angehängt.

Ich lasse das mal über Nacht laufen bis morgen.

Einstein · January 7, 2013 at 18:18

@borg,

was ich festgestellt hab ist, das es Probleme gibt wenn die Ping zeiten hochgehen.

Ich hatte im AP QOS deaktiviert und aus einem anderen Subnet auf die Wifi Extension zugegriffen. Dabei ist der Effekt zu beobachten das sobald der Ping über 6-9ms hochgeht bekomme ich Timeouts.

Schalt ich meine QOS Policies wieder ein wird der WifiStack am höchsten Priorisiert, löst aber auch nicht immer das Problem.

borg · January 7, 2013 at 18:34

Komisch, wir haben ja intern eigentlich ein 2,5 Sekunden Timeout. Da sollten 6-9ms nichts ausmachen.

borg · January 8, 2013 at 09:18

@Einstein: Kannst du mal probieren die WIFI Extension auf AP zu stellen? Um zu gucken ob dein Router oder QOS etwas damit zu tun haben.

Nun hab ich festgestellt wenn mehr als 1 rs485 client and der wifi extension per rs485 angebunden ist steigt im brickv der timeoutcounter an und es gibt im brickv die probleme (s.o.).

Wie meintest du das? Wenn du den Aufbau wie oben hast und den "leeren" RS485 Stack entfernst funktioniert es?

Einstein · January 8, 2013 at 13:59

@Einstein: Kannst du mal probieren die WIFI Extension auf AP zu stellen? Um zu gucken ob dein Router oder QOS etwas damit zu tun haben.

Sooo ich hab' jetzt noch mehrere Dinge versucht.

Nur Stack mit Wifi und ohne RS485. Klappt Problemlos, egal in welcher konstellation (AP-Modus, Client auf AP mit und ohne QOS).

Sobald ich aber an den Stack per RS485 einen Slave anbinde zeigen sich auch noch keine Phänomene. Diese treten erst auf wenn mehr als 1 Client angehängt ist (bei mir wär es 1 Master (mit Wifi) und 2 Clients).

Ich habe auch mit der Baudrate gespielt (alte FW 1.x ging bei mir ohne Probleme mit 2000000 Baud). Zum testen bin ich runter auf 9600, auch das bringt keine Abhilfe.

Nun hab ich festgestellt wenn mehr als 1 rs485 client and der wifi extension per rs485 angebunden ist steigt im brickv der timeoutcounter an und es gibt im brickv die probleme (s.o.).

Wie meintest du das? Wenn du den Aufbau wie oben hast und den "leeren" RS485 Stack entfernst funktioniert es?

Ich hab auch von allen RS485 Bricks die Bricklets abgezogen. Dann funktioniert kurioser weise alles ohne Timeouts (also auslesen der Daten Stackspannung und Strom).

Ich hoffe das war jetzt nicht zu verwirrend.

borg · January 8, 2013 at 15:38

Echt komisch. Du hast aber bei beiden RS485 Extensions auch die gleichen Einstellungen, ja? Ich hatte schonmal ausversehen in einem Netzwerk eine RS485 Extension mit 1 Stopbit und eine mit 2 Stopbits. Das funktioniert dann auch nur sehr sporadisch.

Wenn es einwandfrei funktioniert sobald du nur einen RS485 Slave hast, kann es ja nicht am AP liegen, denke ich.

Du könntest auch noch einmal Probieren das EEPROM auf allen RS485 Extensions einmal auf Auslieferungszustand zurück zu setzen (im Brick Viewer unten bei "Configure Extension Type" nochmal RS485 auswählen).

Einstein · January 10, 2013 at 22:15

@borg

Ich hab jetzt noch einmal 'ne Runde rumprobiert aber auf Grund von einsetzendem Schneefall kann ich bei meinem Wifi Master auf dem Dach nicht mehr rumspringen und werd das wohl vertagen müssen.

luxor · January 10, 2013 at 22:34

Ich hab jetzt noch einmal 'ne Runde rumprobiert aber auf Grund von einsetzendem Schneefall kann ich bei meinem Wifi Master auf dem Dach nicht mehr rumspringen und werd das wohl vertagen müssen.

Auch mal ein geiler Grund :-D

borg · January 15, 2013 at 17:48

Wir können das neue Protokoll heute leider noch nicht veröffentlichen, wir haben in letzter Minute noch Fehler im USB Code gefunden, an dem ich jetzt schon den ganzen Tag rumdebugge.

Desweiteren wollen wir nochmal die kompletten neuen Enumeration/Connect/Disconnect/ResponseExpected Funktionen in allen Sprachen gründlich durchtesten, da wir dort unerwarteterweise noch Bugs gefunden haben in den C# und Java Bindings.

Loetkolben · January 15, 2013 at 18:07

"unerwarteterweise" ?

Seit ihr nach Berlin umgezogen?

Der Loetkolben

Anmelden

TF Protocol 2.0 Beta

Recommended Posts

Einstein

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Posted Images

thunderbird

thunderbird

thunderbird

borg

thunderbird

Ploby

borg

photron

borg

Ploby

photron

Einstein

borg

borg

borg

Einstein

borg

borg

Einstein

borg

Einstein

luxor

borg

Loetkolben

Join the conversation

Umsehen

Aktivitäten