Blog

Silent Stepper Brick

Heute möchten wir euch von der langen Geschichte der Entwicklung des Silent Stepper Bricks berichten. Bei unserem aktuellen Stepper Brick erzeugt die Steuerung zusammen mit dem Motor, wie bei den meisten Standard-Schrittmotorsteuerungen ebenfalls, Resonanzen, die hörbar sind. Ursache dieser Resonanzen ist die Motorinduktivität verbunden mit einer einfachen Stromregelung. Im Vollschrittbetrieb sind die Geräusche meist am lautesten und werden mit steigenden Mikroschritten (1/4, 1/8,…) leiser. Je nach Anwendung können die Geräusche des Schrittmotors auch trotz Microstepping störend sein. Dies war der Grund für uns, sich mit der Entwicklung einer “leisen” Alternative zu beschäftigen, dem Silent Stepper Brick.

Entwicklung Teil 1

https://www.tinkerforge.com/static/img/_stuff/silent_stepper.jpg

Da es sich um ein Brick handeln sollte, war die Größe des Silent Steppers vorgegeben: 4x4cm. Nach Abzug der notwendigen Fläche für die Stapelstecker, die Anschlüsse und dem Mikrocontroller blieb nur eine geringe Fläche für den eigentlichen Treiber übrig, so dass nur eine integrierte Treiberlösung in Betracht kam. Trinamic bietet mit dem TMC2100 ein Treiber-IC an, welcher verschiedene Stromregelungen unterstützt und einen geräuschlosen Betrieb ermöglicht (Stealth Chop). Der Treiber unterstützt einen maximalen Phasenstrom von bis zu 1,2A (Dauerstrom bei guter Kühlung) und bis zu 256 Mikroschritten. Motoren können somit sehr präzise bewegt werden. Unsere angebotenen Schrittmotoren sind genau für diese Ströme ausgelegt.

Mit dem TMC2100 Treiber begannen wir die Entwicklung unseres Prototypen. Der erste Prototyp hatte Probleme bei höheren Motorgeschwindigkeiten: Irgendwann brach das Drehmoment zusammen und der Motor stoppte schlagartig beim Beschleunigen. Nach längerer Fehlersuche gab es hierfür zwei Gründe:

  1. Unser Layout der Leiterplatte war nicht optimal, so dass wir einen neuen Prototypen entwickeln mussten.

  2. Schrittmotoren besitzen eine Resonanzfrequenz. Wenn man in diese hereingerät, dann bricht das Drehmoment schlagartig zusammen. Man löst dieses Problem indem man schnell über diesen Bereich hinweg beschleunigt. Auf Grund der Probleme mit dem Layout war uns erst nicht klar das wir dort ein ganz normales Phänomen sehen, wir haben lange Zeit gedacht es gibt noch weitere Probleme mit dem Layout o.ä.

Nachdem wir diese Probleme überwunden hatten und die Entwicklung fast zu 100% abgeschlossen war, gab es eine Preisanpassung bei den Treibern: Neben dem TMC2100 gibt es den TMC2130. Dieser Treiber besitzt deutlich mehr Einstellungsmöglichkeiten und viele weitere spannende Features. Als wir mit der Entwicklung begonnen haben war der TMC2130 noch deutlich teurer als der TMC2100. Daher hatten wir uns für den einfacheren TMC2100 entschieden. Da nun aber die beiden Treiber nahezu gleich teuer sind, beschlossen wir den TMC2130 zu nutzen. Damit begann die Entwicklung quasi von vorne.

Der TMC2100 wurde recht simpel über wenige Pins konfiguriert. So gab es auch nur wenig Einstellungsmöglichkeiten. Der TMC2130 verfügt über eine SPI Schnittstelle und erheblich mehr Einstellungsmöglichkeiten. Die Software musste dafür zum großen Teil komplett neu geschrieben werden und es mussten Erfahrungen mit den verschiedenen Einstellungsmöglichkeiten gewonnen werden. Da es sich bei dem Silent Stepper Projekt allgemein um ein niedrig priorisiertes Projekt handelte, führte dies dazu, dass sich das Projekt hinzog. Viele Erfahrungen konnte man auch erst während der Entwicklung gewinnen. So besitzt der TMC2130 zum Beispiel eine interne Clock, mit der die Stromregelung usw. durchgeführt wird. Je nach Anwendung ist diese aber zu ungenau, da sie unter anderem sehr temperaturabhängig ist. Für Anwendungsbereiche die eine höhere Präzision erfordern verfügt der IC über einen externen Takteingang, den wir über den Prozessor mit einem präzisem Taktsignal versorgen. Dafür war natürlich ein weiterer Prototyp notwendig.

EMV Labor

Während der Entwicklung unserer Produkte prüfen wir auch die elektromagnetische Verträglichkeit. Da das Design und die Software einen großen Einfluss darauf haben, kann diese abschließend erst am Ende der Entwicklungsphase durchgeführt werden. So haben zum Beispiel Taktleitungen, Busleitungen usw. einen Einfluss.

Bisher besuchten wir dazu öfters ein EMV Labor. Da Messungen im Labor aber vergleichsweise teuer sind und auch viel Zeit kosten, haben wir uns ein eigenes kleines Labor eingerichtet.

https://www.tinkerforge.com/static/img/_stuff/laboratory1.jpghttps://www.tinkerforge.com/static/img/_stuff/laboratory2.jpg

Dazu nutzen wir einen Rigol DSA815 Spektrumanalyzer, eine TEM Zelle und ein großes Metallgehäuse um den Messaufbau etwas zu schirmen. Mit diesem Aufbau erreicht man längst nicht die Messqualität, die man in einem richtigen EMV Labor erreicht. Man kann aber erkennen, falls es Messwerte gibt, die die zulässigen Grenzwerte überschreiten könnten. Somit können Probleme oftmals schon vor den Tests im EMV Labor erkannt werden.

Der Spektrumanalyzer zeigt für den ausgewählten Frequenzbereich, die jeweils zur Frequenz gehörene Amplitude. Sprich die Stärke der Abstrahlung zu jeder einzelnen Frequenz. Ohne Abschirmung misst man zusätzlich zu der Störausstrahlung des Testobjekts aber auch Radiosender, das GSM Netz, Funkfernbedienungen usw. Mit unserer primitiven Abschirmung werden diese externe Quellen etwas abgeschirmt.

Es kann vorkommen, dass eine Signalleitung, die mit einer bestimmten Frequenz getaktet wird, abstrahlt. Typischerweise sieht man dann Frequenzvielfache dieser Leitung auf dem Spektrumanalyzer. In dem nachfolgenden Foto sind zum Beispiel Vielfache einer Frequenz von 12,8 MHz erkennbar.

https://www.tinkerforge.com/static/img/_stuff/spectrum_peak.jpg

Erkennt man diese Vielfache, dann kann man einfach feststellen wer wohl der Verursacher ist, wenn die Grundfrequenz nur an einer Steller der Schaltung genutzt wird. Über sogenannte Nahfeldsonden, Antennen mit denen man örtlich begrenzt die Abstrahlung messen kann, kann man dann sehr zielgenau die verursachende Leiterbahn lokalisieren. Das Aussenden von Störungen kann verschiedene Gründe haben: Schlechte Leiterbahnführung, zu steile Signalflanken, Masseprobleme usw. Manchmal hat man die Möglichkeit über eine Änderung von Bauteilen die Abstrahlung zu beeinflussen (Beispiel: Serienwiderstand in einer Taktleitung). Oftmals muss aber auch das Layout überarbeitet werden, so dass eine neue Leiterkarte benötigt wird.

Entwicklung Teil 2

Leider nicht ganz ohne Grund haben wir zuvor geschrieben wie wir die Messungen zur Störausstrahlung hier bei uns durchführen. Die Entwicklung des Silent Stepper Bricks war fast vollständig abgeschlossen und wir standen kurz davor die Leiterkarten zu bestellen um die Silent Stepper Bricks noch dieses Jahr produzieren zu können. Als letzten Schritt prüften wir den Silent Stepper hinsichtlich seiner Störausstrahlung. Dazu nutzten wir für erste Tests unser eigenes kleines Labor. Leider sahen die Messergebnisse nicht so aus wie wir es erhofft haben.

Man sah deutlich die Vielfache des Taktsignals (siehe Bild oben). Die Vielfachen waren zwar knapp unter den eingestellten Grenzwert aber das Risiko damit im Labor durchzufallen war uns einfach zu groß. Auch ist unser Anspruch, ein vernünftiges Design zu machen bei dem so welche Peaks nicht vorkommen.

Wir hatten extra einen Serienwiderstand eingeplant um die Flankensteilheit des Taktsignals einstellen zu können, mit der Hoffnung damit die Störaussendung des Signals zu kontrollieren. Leider ließen sich damit die Effekte nicht weit genug reduzieren. Also bestellten wir Leiterkarten für einen weiteren Prototypen. Mit jedem Prototypen vergehen aber mindestens zwei weitere Wochen. Dazu kommt ein Tag, den man zum Aufbau benötigt und dann meist 1/2 - 1 Tag um alle Lötfehler zu finden.

Von den neuen Prototypen bestellten wir direkt zwei Varianten eine mit einer besseren Taktsignal-Leiterbahnführung und mehr Filtermöglichkeiten und eine Variante, die ein ganz anderes Masselagenlayout besitzt. Bei den Prüfungen stellte sich heraus, das unsere Überlegungen zu den Masselagen schon korrekt waren (die Änderungen führten zu einer Verschlechterung) und wir konnten über die neuen Filtermöglichkeiten die Störungen weiter minimieren. Damit ist nun sichergestellt, das wir die notwendigen Grenzwerte locker einhalten.

In Summe haben wir 8 Prototypen für die Entwicklung des Silent Stepper Brick benötigt:

https://www.tinkerforge.com/static/img/_stuff/silent_stepper_brick_8_prototypes.jpg

Wie geht es nun weiter?

Die Leiterkarten werden nun vorbereitet und nächste Woche bestellt. Wegen Weihnachten und Neujahr wird sich die Lieferung der Karten verzögern, so dass wir davon ausgehen Anfang März den Silent Stepper Bricks offiziell vorstellen zu können. Freut euch auf ein tolles Vergleichsvideo zwischen alten und neuem Stepper Brick.

WIFI Extension Firmware 2.0.1

Für die WIFI Extension 2.0 steht ab sofort Firmware Version 2.0.1 zur Verfügung.

Die neue Firmware für die WIFI Extension hat jetzt eine Web-Oberfläche. Über diese kann der Status der WIFI Extension eingesehen werden und die Konfiguration stattfinden (wie im Brick Viewer).

https://www.tinkerforge.com/de/doc/_images/Extensions/extension_wifi2_web_interface_status.jpghttps://www.tinkerforge.com/de/doc/_images/Extensions/extension_wifi2_web_interface_settings.jpg

Zusätzlich gibt es noch einige kleine Bug fixes, z.B. funktionierte der Betrieb im Access Point Modus zusammen mit einer Statischen IP mit der Firmware 2.0.0 nicht korrekt.

Die nächste Firmware Version der WIFI Extension wird eine Mesh-Netzwerk Funktionalität hinzufügen. Ihr dürft also gespannt bleiben!

LED Strip Bricklet jetzt mit Support für RGBW, LPD8806 und APA102

Wir haven soeben die neue Firmware Version 2.0.6 des LED Strip Bricklet veröffentlicht. Ursprünglich hatte das Bricklet nur Unterstützung für WS2801 LEDs. Mehr LEDs wurden im Laufe der Zeit hinzugefügt.

https://www.tinkerforge.com/static/img/_stuff/led_strip_bricklet_11_785.jpg

Das LED Strip Bricklet unterstützt jetzt

  • WS2801,

  • WS2811,

  • WS2812/SK6812/WS2813 (NeoPixel RGB),

  • SK6812RGBW (NeoPixel RGBW),

  • LPD8806 und

  • APA102 (DotStar).

Besonders interessant sind die neuen NeoPixel RGBW und DotStar LEDs. Die ersten haben zusätzlich eine individuell kontrollierbare weiße LEDs und die letzteren gibt mit zusätzlichem Intensitäts-Kanal oder auch als komplett weiße Streifen mit 24 Bit Auflösung pro LED.

Des weiteren haben wir neue API hinzugefügt um das Handhaben von LED Streifen von unterschiedlichen Herstellern zu vereinfachen. Da die Reihenfolge der LEDs im Gehäuse nicht standardisiert ist, müssen einige LEDs in der Reihenfolge RGB, andere in der Reihenfolge BGR oder noch anders angesprochen worden. Es ist jetzt möglich mit der Funktion set_channel_mapping diese Reihenfolge einmalig festzulegen. Nach korrekter Konfiguration können die LEDs dann durchgängig in der Reihenfolge RGB beziehungsweise RGBW angesprochen werden.

https://www.tinkerforge.com/de/doc/_images/Bricklets/bricklet_led_strip_w_reel_600.jpg

Zwei neue Bricklets: CAN und RGB LED

Wir haben zwei neue Bricklets im Programm: Das CAN Bricklet und das RGB LED Bricklet.

https://www.tinkerforge.com/en/doc/_images/Bricklets/bricklet_can_tilted_600.jpg

Mit dem CAN Bricklet ist es möglich Frames eines CAN-Bus zu empfangen und zu senden. CAN wird oft in Autos sowie in industriellen Sensoren und anderen industriellen Bauteilen eingesetzt. Wir planen in Kürze ein Tutorial zum verwenden des CAN Bricklets zusammen mit CANopen Geräten zu veröffentlichen. Das Bricklet hat eine konfigurierbare Baudrate zwischen 10kbit/s und 1Mbit/s. Es ist möglich Filter anzuwenden um nur Frames mit einem spezifischen Identifier zu empfangen.

Das CAN Bricklet ist Verfügbar für 19,99€ inkl. MwSt.

https://www.tinkerforge.com/en/doc/_images/Bricklets/bricklet_rgb_led_tilted_600.jpg

Das RGB LED Bricklet ist mit einer einzelnen einstellbaren RGB LED ausgestattet. Jeder Farbkanal (rot, grün, blau) hat eine Auflösung von 8 bit.

Während des Designs des RGB LED Bricklets hat sich ein etwas peinlicher Fehler eingeschlichen. Wir haben versucht die LED auf einem Bricklet mit einer Breite von 15mm unterzubringen, dies hat leider nicht gepasst. Beim vergrößern der Leiterplatte haben wir es dann ausversehen auf eine Breite von 17,5mm vergrößert. Mit dieser Breite ist das Bricklet nicht in unserem Standard 5mm-Raster, welches alle Bricks und Bricklets haben. Wir werden in Hardware Version 1.1 weitere 2,5mm hinzufügen um eine Breite von 20mm zu erreichen. In der Zwischenzeit ist das RGB LED Bricklet mit Hardware Version 1.0 zum halben Preis bei uns im Shop erhältlich (3,49€ statt 6,99€).

Wir haben lediglich 250 Stück von Hardware Version 1.0 auf Lager. Daher erwarten wir, dass Hardware Version 1.1 mit dem korrekten Lochabstand relativ zügig zur Verfügung stehen wird!

Brick Daemon Beta für Windows 10 IoT Core (Teil 1/2)

Vor einer Weile hat Microsoft Windows 10 IoT Core veröffentlicht, dass auf verschiedenen Embedded Boards, wie z.B. dem Raspberry Pi läuft. Der normale Brick Daemon für Windows läuft allerdings nicht auf Windows 10 IoT Core. Wir haben aber jetzt eine Beta Version des Brick Daemons, die auch auf die auf Windows 10 IoT Core läuft.

Installation

Diese Brick Daemon Version wurde auf einem Raspberry Pi 2 Model B mit den Windows 10 IoT Core Versionen 10.0.10586, 10.0.14295 und 10.0.14376 getestet.

Im Moment kann Brick Daemon für Windows 10 IoT Core nur aus dem Quelltext kompiliert und installiert werden. Dazu muss Visual Studio 2015 für Windows 10 IoT Entwicklung installiert sein. Falls dies noch nicht der Fall ist gibt es hier eine Installationsanleitung von Microsoft dazu.

Als nächstes muss der benötigte Quelltext für Brick Daemon und die daemonlib von GitHub heruntergeladen werden. Der daemonlib Quelltext muss ins src\daemonlib Verzeichnis im Brick Daemon Quelltext Verzeichnis entpackt werden:

brickd-2.2.2-uwp-beta1
-> src
   -> brickd
      -> client.c
      -> ...
   -> daemonlib
      -> daemon.c
      -> ...

Zuletzt src\brickd\brickd_uwp.sln in Visual Studio 2015 öffnen und das Projekt kompilieren und starten. Brick Daemon sollte jetzt auf Windows 10 IoT Core laufen.

https://www.tinkerforge.com/static/img/_stuff/brickd_uwp_beta1_700.jpg

Beta-Status

Dies ist eine Beta Version, da momentan noch ein größeres Problem vorhanden ist: die automatische Erkennung von USB Geräten funktioniert nicht für alle Bricks korrekt.

Die Windows.Devices API für den Zugriff auf USB Geräte setzt voraus, das jedes USB Gerät eine DeviceInterfaceGUID zugewiesen hat. Normalerweise funktioniert dies von sich aus für alle Bricks, aber Windows 10 IoT Core (zumindest Versionen 10.0.10586, 10.0.14295 und 10.0.14376) scheinen einen Bug zu haben, der dies für alle Bricks außer dem RED Brick behindert. Es ist nicht klar, warum der RED Brick von diesem Problem nicht betroffen ist.

Daher ist für alle Bricks außer dem RED Brick ein manueller Eingriff in die Windows Registry nötig, damit sie von der Windows.Devices API erkannt werden. Folgenden Schritte müssen für jeden Brick einmal ausgeführt werden:

Als ersts den Brick per USB anschließen, dann mit Power Shell eine Verbindung zu Windows 10 IoT herstellen und den folgenden Befehl anpassen und ausführen:

reg add "HKLM\System\CurrentControlSet\Enum\USB\VID_16D0&PID_063D\6K9mW5\Device Parameters" /v DeviceInterfaceGUIDs /t REG_MULTI_SZ /d "{870013DD-FB1D-4BD7-A96C-1F0B7D31AF41}"

Dies fügt die fehlenden DeviceInterfaceGUID für einen Brick mit der UID 6K9mW5 hinzu. Um die DeviceInterfaceGUID für deinen Brick hinzuzufügen muss im Befehl 6K9mW5 durch die UID deines Bricks ersetzt werden.

Nach einem Reset des Bricks sollte Brick Daemon ihn jetzt finden. Es kann allerdings vorkommen, dass der reg add Befehl aus unbekanntem Grund hängt. Falls dies passiert muss Windows 10 IoT Core neugestartet und der Befehl erneut ausgeführt werden.

In unserem Forum gibt es einen Thread zu diesem Thema.

Der zweite Teil befasst sich dann mehr mit den technischen Details und den Problemen Brick Daemon für Windows 10 IoT Core zu portieren.