FAQ

Spielen Sie einfach das letzte Firmware Update ein.

Schließen Sie ein Terminalprogramm wie putty an. Starten Sie den Controller über die Reset-Taste. Der Controller startet ein Initialsetup.

Geben Sie die Daten vom Typenschild Ihres Controllers ein. Anschließend bootet der Controller neu.

In der NVS Partition ihres Controllers sind einige Einstellungen wie die Seriennummer hinterlegt. Wird diese Partition gelöscht oder ist für die Firmware nicht lesbar, so fragt die Firmware die Daten einmalig ab.

Kontrollieren Sie zunächst, dass der Controller und der Schwarm mit dem selben wifi-Netzwerk verbunden sind:

• Ist WLAN eingeschaltet?
• Stimmen SSID und Passwort?
• Können die Statusseiten der Controller vom PC aufgerufen werden?

Verwenden Sie beim ftSwarmRS die RS485-Schnittstelle?

• Steht die Schwarmkommunikation bei allen Controllern auf RS485?
• Ist die Verkabelung zwischen den Controllern in Ordnung? Sind alle Kabel angeschlossen? Haben Sie A/B vertauscht? Haben sie eine Schleife gebaut?
• Haben Sie am ersten und letzten Controller den Jumper für den Abschlusswiderstand gesetzt?

Bei einigen älteren Firmwareversionen hatten manche User Probleme mit der Arduino IDE 2.0.

Wenn Sie einen SSID-Scan am PC laufen lassen, sehen Sie für jeden Controller eine eigene SSID, z.B. ftSwarm4711.
Ignorieren Sie diese SSID. Es ist ein Bug von espressif.

Die ESP32-Prozessoren verwenden einen Watchdog, um (fast-)Endlosschleifen zu erkennen und abzubrechen.

while (switch->isReleased());
motor->setSpeed(200);

blockiert einen Core bis der Taster geschlossen wird, der Watchdog erkennt dies und bricht das Programm ab. Es ist besser in der loop-Funktion

if (switch->ToggleUp()) motor->setSpeed(200);

zu verwenden. Da die Loop-Funktion immer wieder neu gestartet wird, wird auch das if-Statement regelmäßig ausgeführt. Damit wird der Motor ebenfalls eingeschaltet, wenn der Taster geschlossen wird. Der Watchdog bricht nicht ab, da die loop-Funktion komplett durchlaufen wurde. Die delay-Funktion sorgt ebenfalls dafür, dass der Watchdog das Programm nicht unterbricht.

Die Statusseite zegt den Motor korrekt an, aber der Motor läuft nicht.
Dies ist ein bekanntes Problem, das mit Firmware 0.4.1 gefixt wurde.

Überprüfen Sie die 9V-Stromversorgung. Um die Eingänge zu nutzen, reicht die USB-Stromversorgung nicht aus.

Sie verwenden den Kelda-Controller im AP-Modus und alle anderen Controller im Schwarm verbinden sich auf die Kelda über wifi.

Prüfen Sie, ob die Kelda "waiting on hardware" meldet. (Beim ftSwarmControl sehen Sie dies im Display, beim ftSwarm sind beide LEDs blau.)

Beim Flashen bzw. beim Restart des Controllers, wird der WLAN-Stack neu initialisiert. Wird der Controller neu gestartet, der den AP stellt, so verlieren alle damit verbundenen Controller die Verbindung und können nicht mehr kommunizieren. Die Kelda versucht auf Remote-Hardware zuzugreifen und kann sie nicht mehr ansprechen. Alle Controller im Swarm müssen neu gestartet werden.

Es ist jedoch sinnlos immer alle Controller nach dem Flashen der Kelda zu resetten. Verwenden Sie ein extern bereitgestelltes WLAN oder nutzen Sie einen anderen Controller als Access Point.

Schauen Sie sich folgenden Code an (er funktioniert mit jedem Eingangstyp):

void loop() {

  switch ( local_S1->getToggle() ) {
    case FTSWARM_TOGGLEDOWN:  Serial.println("S1 released."); break;
    case FTSWARM_TOGGLEUP:    Serial.println("S1 pressed."); break;
  }
  
  delay(250);

}

Wenn das Programm läuft, erhalten Sie mit dem Drücken und Loslassen der Taster S1 pressed. und S1 released. Nachrichten. In manchen Fällen, kommt es aber zu zwei aufeinander folgenden S1 pressed. Meldungen, die zugehörige S1 released. Nachricht fehlt.

Der Schwarm prüft aller 25ms die Eingänge. Beim Auslesen von S1 vergleicht die Firmware den neuen Stand (z.B. gedrückt) mit dem vorherigen Zustand (z.B. nicht gerdückt). Dadurch wird der Toggle-Zustand auf FTSWARM_TOGGLEUP gesetzt.

Bleibt der Taster gedrückt, so prüft die loop-Funktion spätestens nach 250ms den Zustand und gibt auf der seriellen Konsole S1 pressed aus. local_S1->getToggle() setzt dabei den Status des Eingangs auf FTSWARM_NOTOGGLE. Beim nächsten Durchlauf der loop ist der Zustand local_S1->getToggle() und es wird nichts ausgegeben.

Nachdem der Taster losgelassen wurde, ändert sich der Zustand zu FTSWARM_TOGGLEDOWN. Auf der Konsole wird S1 released ausgegeben.

Wird der Taster, nachdem er gedrückt wurde (Ausgabe S1 pressed.), innerhalb der 250ms losgelassen und erneut gedrückt, so ändert sich der Zustand des Tasters während dem delay zweimal. Am Ende der 250ms steht der Taster auf FTSWARM_TOGGLEUP.

Damit wird zum zweitem Mal in Folge S1 pressed. ausgegeben.