batti

Dieser Bug bezieht sich nur auf den Code der WIFI V2. WIFI V1 arbeitet intern komplett anders. Das Problem sollte bei der V1 nicht vorkommen.

Sorry Reinhard, die WIFI Extensions Version 2 und Version 1 nutzen komplett unterschiedliche Software. Der gefundene Bug bezieht sich nur auf Version 2.

Hallo Reinhard, das mit dem response expected gilt für alle unsere Produkte unabhängig von Extensions. Du kannst das auch mit einer WIFI V1 nutzen.

Hi mrpmorris, I guess you mean some kind of sensor fusion. For that our IMU Brick (accelerometer, magnetometer and gyroscope) is often used by our customers. Best regards, Bastian

Ebenfalls eine Neuigkeit von uns dazu. Wir haben eben die WIFI 2.0 Firmware in Version 2.0.3 veröffentlicht. In der Tat gab es noch einen "Bug", der auftreten konnte, wenn mehr Nachrichten aufgetauscht werden sollten, als die WIFI Extension schaffte. Hier der Changelog zur Firmware: Ein-/Ausgangs-Buffergrößen vergrößert Halte TCP Transfers bevor die Buffer überlaufen (Nachrichten werden beim Sender gebuffert) Testet bitte ab jetzt mit der neuen Firmware. Es sieht momentan danach aus, als ober das Masder Programm genau diesen Fehler auslösen konnte. In dem Programm wurden sehr viele Nachrichten zum Stellen von RGB LEDs (LED Strip Bricklet) generiert. Das Reinweb Problem könnte ähnlich sein. Bei WIFI kann die Empfangs/Sendequalität stark schwanken, so dass mal mehr und mal weniger Nachrichten durchgehen. Da der Bug nun hoffentlich gefixt ist sollte es so sein, dass auf Anwendercode-Seite die noch nicht verschickten Nachrichten (Funktiosaufrufe) gespeichert werden und nach und nach verschickt werden. Dadurch stauen sich Nachrichten auf. Das Problem der aufstauenden Nachrichten kann eigentlich nur durch "Set'ter" erzeugt werden, da diese keine Antwort erwarten. Es können also prinzipiell beliebig viele Set'ter pro Sekunde aufgerufen werden, was das System überfordert. Die Nachrichten sammeln sich dann im TCP Buffer. Das Problem lösen kann man durch den "set response expected" Mechanismus, bei dem jeder Setter auch eine Antwort vom System erwartet. Dann bekommt man auch mit (über Timeout), wenn eine Nachricht nicht beim System angekommen ist. Es werden dann aber auch doppelt so viele Nachrichten ausgetauscht (Set-Nachricht hin, Antwort zurück).

Ja, wäre es. Allerdings haben wir Designs bei dem nicht so viel Platz ist (z.B. RED Brick). Wir versuchen Standardbauteile einzusetzen, die wir dann in größerer Stückzahl abnehmen.

Die Drossel ist für den Bestücker nicht ganz einfach anzulöten. Wir vermuten, dass die nicht richtig angelötet war, so dass sie bei unserem Flashen und Testen noch draufsaß, danach aber irgendwann abgeflogen ist. So einen Fall hatten wir schonmal, daher sind wir recht schnell darauf gekommen. Haben die restlichen Master Bricks kontrolliert und konnten zum Glück aber keine weiteren Bricks mit Problemen feststellen. Bei einer Produktion von über 1000 Master Bricks, zwei Fälle mit diesem Problem ist fürchte ich "im Rahmen". Wir werden dennoch zukünftig mehr darauf achten. EXPO meinte dann auch, dass da ggf. die Drossel fehlte. Er hat uns den Brick zugeschickt und ich konnte das hier bestätigen. Damit ggf. (ich hoffe nicht das es auftritt) andere ebenfalls auf dieses Problem hingewiesen werden, haben wir hier die Ursache dokumentiert.

Wir konnten das Problem ausfindig machen. In der USB Datenleitung sitzt unter anderem eine kleine Drossel (auf der Unterseite der Leiterkarte). Wenn diese fehlt, wird der Brick noch per USB mit Strom versorgt (LEDs leuchten etc.) aber er kann mir dem Rechner nicht kommunizieren.

Wichtig ist, dass die Treiber aktuell sind. Direkte Anforderungen an das USB Kabel gibt es nicht. Ein Master Brick alleine sollte eigentlich mit jedem Mini-USB Kabel funktionieren. Bei minderwertigen Kabeln treten Probleme mit höheren Lasten (=Strömen) auf. Wurde schon versucht das Brick neu zu flashen?

Hallo, solange der Brick eine Firmware besitzt und mit Strom versorgt wird sollte die blaue LED neben der USB Buchse leuchten. Die vier LEDs an der Seite machen beim Starten des Master Bricks einmal ein "Lauflicht" und gehen dann aus. Das ist soweit in Ordnung, solange die blaue LED neben der USB Buchse leuchtet. Ggf. ist es ein Treiber Problem bei einer USB 3.0 Schnittstelle? Siehe: http://www.tinkerforge.com/de/doc/FAQ.html#eines-meiner-bricks-wird-im-brick-viewer-nicht-angezeigt

Hallo Yvo, du hast damit recht, dass eine Verwechselungsgefahr prinzipiell besteht. Die Männchen/Weibchen Lösung wäre sehr schön, steht in der Praxis aber nicht zur Verfügung, da es diese Stecker nicht gibt (in dem Stecksystem). In einer Zukünftigen Variante wird der Ausgang über eine Diode getrennt sein, so dass bei einer Verwechselung nicht zurück gespeist wird. Viele Grüße, Bastian

Masder: Die Anzahl der Verbindungen auszulesen ist wirklich nur über die Webseite möglich. So etwas hat die 1.0er Version nicht. Bin heute noch nicht dazu gekommen deinen Code mal laufen zu lassen. Sah auf dem ersten Blick nichts böses im Code. Baue das morgen mal auf. Reinweb: Das ist interessant. Die einfachste Erklärung ist, dass die Verbindung tot ist. Der Frage ist warum. Könnte daran liegen, dass das WLAN gestört ist (außer Reichweite o.ä.) und dass das auto-reconnect nicht funktioniert. Alternativ hat sich der Stapel neugestartet. Mach mal bitte folgendes: 1. Kurz vorm disconnect ruf mal ein getter auf. Ich würde vermuten, dass dieser ein Timeout bekommt. Wenn ja ist die Verbindung tot. 2. Ruf mal bei der Initialisierung einen Setter auf und setze irgendwas auf einen nicht default Wert. Rufe diesen Wert nach dem neuen connect mal ab. Ist dieser wieder auf default -> neugestartet. Ist dieser auf dem alten Wert -> nicht neugestartet. p.s.: Wir hätten diesen Thread für euch beide mal spalten sollen. Ich glaube ihr habt sehr unterschiedliche Probleme.

Korrekt

Zitat aus der Dokumentation (Tabelle): "Maximale Anzahl gleichzeitiger Verbindungen 10" "ipcon.disconnect();" Reset des Master Bricks, der die WIFI Extension nutzt führt dazu, dass die WIFI Extension neu initialisiert wird. Dabei werden alle zuvor bestehenden Verbindungen "gelöscht". Dies ist auch die einzige Möglichkeit alle Verbindungen zu löschen. Richtige Vorgehensweise ist jede Verbindung auch irgendwann zu schließen. Sind die Callbacks denn noch konfiguriert? Am besten du schreibst dir ein kleines Programm, was den Zustand der Callbacks abruft. Dieses Programm rufst du auf, wenn der Stack wieder in diesem Zustand ist. Dann gibt es zwei Möglichkeiten: 1) Die Callbacks sind noch wie gewünscht konfiguriert. Wäre sehr komisch, kann ich mir nicht so recht vorstellen. 2) Die Callbacks sind nicht mehr konfiguriert. Hier wird es interessant. Entweder ein anderes Programm hat die Callbacks umkonfiguriert (deaktiviert) oder der Stapel wurde/hat sich neu gestartet. Masder dein Programm versuche ich gleich hier mal laufen zu lassen.

Das das so viele Fragen generiert, damit habe ich nicht gerechnet. Der Treiber besitzt eine interne Clock mit der er zum Beispiel Microstepping macht. Die Clock wird auch genutzt um zu definieren, wann zwischen dem Silentmodus (leise) und dem "normalen Modus" (mehr Kraft) umgeschaltet werden soll. Diese Schwelle kann von euch definiert werden. Als Referenz dient aber die interne Clock. Diese ist aber recht ungenau und z.B. temperaturabhängig. Damit die Schaltschwelle auch wirklich eingehalten wird und nicht immer anders ist nutzen wir jetzt als Referenz eine externe Clock.

Hallo Lars, wie liest du das Accelerometer Bricklet denn aus? (per Getter oder per Callback?) Du kannst eigentlich sehr schön mit dem Brick Viewer testen. Ggf. ist es ein Problem mit dem WIFI Empfang? VG, Bastian

Hallo Fabian, was schaltest du denn mit der IO-16? Idee: Falsche Spannungen? Problem mit Überspannung? Induktive Last o.ä.? VG, Bastian

Hallo developer, ich glaube wir hatten selten ein Projekt was sich so hinzog. Entschuldigt dies bitte. Die Entwicklung des Silent Steppers lief bis vor kurzen etwas "nebenbei". Die Software für den Silent Stepper Brick steht jetzt soweit. Olaf hat die letzte Woche da viel implementiert. Wir mussten aber nochmal einen neuen Prototypen bestellen, da wir nun doch eine externe Clock benutzen wollen. Die Leiterkarten dafür wurden heute an uns verschickt. Wenn alles gut läuft haben wir Ende der Woche einen neuen Prototypen. Den Testen wir danach noch ein wenig und dann sollte es endlich dazu kommen, dass wir das Ding in die Produktion geben. Zeitliche Horizont ist dabei 1 1/2 bis 2 Monate ab jetzt (1-2 Wochen Testen, 4 Wochen Leiterkartenlieferzeit, 1-2 Wochen Produktion).

Noch ein Nachtrag zu dem Connection kram. Im Gegensatz zu dem Brick Daemon, der prinzipiell unendlich viele Verbindungen halten kann, haben Ethernet Extension und WIFI Extension nur begrenzt viele Verbindungen. D.h. wenn euer Code mehr Verbindungen aufmachen will als möglich, werden irgendwann Verbindungen geblockt. Symptom ist dann, dass der Stapel nicht mehr "erreichbar" ist.

Masder, bitte schicke mir doch einmal deinen vollständigen (=lauffähigen) Code mit dem du testest.

Hallo Masder, Danke für den Code. Das sieht ja alles sehr harmlos aus (bzgl. Callback Perioden etc.). Mit diesem Code kannst du bei dir Probleme erzeugen? Wie sehen diese aus? Womit muss ich testen (HW aufbau)?

Okay... Warten wir mal ab

Hallo Loetkolben, nein, das ist prinzipiell egal. Elektrisch ist das egal. Wir hatten mal einen Fall, wo es Probleme mit den Stapel-Kontakten gab, wo es einen Unterschied machte wo die Extension steckt.

Ok, Danke!

Hallo reinweb, jetzt habe ich dich auch erkannt. Besser wäre es, wenn du uns irgendein Beispiel nennst bei dem es sich bei dir halbwegs reproduzierbar aufhängt. Ich kann dir irgendein Beispiel programmieren, befürchte/glaube/hoffe aber, dass das durchlaufen wird. Dann sind wir genauso schlau wie vorher. Wie steht das im Verhältnis zu deinem Post? Ein LED Strip Bricklet ist bei deinem Wunschbeispiel ja nicht dabei. Deine Beschreibung von "1000 Varianten" hilft uns nicht dabei konkret eine Lösung zu finden. Was bei der WIFI Extension Problematisch sein kann, ist wenn man das System sehr viele Callbacks generieren lässt, die die WIFI Extension in der Zeit nicht verschicken kann (z.B. wegen schlechter Verbindung).