borg

Das Internet hier ist übrigens auch gut: Da dauert das RED Brick Image hochladen jetzt keinen ganzen Tag mehr .

Bei solchen Sachen einfach Bescheid sagen, wir stecken das dann in einen kleinen Luftpolsterumschlag und schicken es hinterher. Alternativ einfach bei einer Bestellung als Kommentar dazu schreiben was passiert ist, dann legen wir das defekte Teil auch nochmal dazu.

Laser Cutter + Wasserkühler + Absaugung/Filteranlage

Na, das täuscht im Video. Im "Büro 3" kann man Problemlos noch 3 weitere Schreibtische reinstellen, der "Konferenzraum" ist nicht wirklich notwendig und oben wo der Serverschrank steht könnte man natürlich auch Büros machen. Ich denke wir können hier Problemlos die nächsten 10 Mitarbeiter unterbringen. Es sieht im Video alles ein bisschen kleiner aus als es ist, ich hätte wahrscheinlich mit weniger Weitwinkel oder so aufnehmen sollen .

Wie ihr vielleicht schon mitbekommen habt sind wir in den letzten 2 Wochen umgezogen. Unsere neue Adresse lautet: Tinkerforge GmbH Zur Brinke 7 33758 Schloß Holte-Stukenbrock Die alte Adresse gehört auch noch uns, daher braucht ihr euch bei Rücksendungen, Bestellungen per Brief o.ä. keine Gedanken machen, die kommen auch an wenn Sie an die alte Adresse geschickt wurden. Ich habe gestern Abend einen kleinen Rundgang aufgenommen. Es ist noch nicht alles fertig eingerichtet, aber man kann schon einen guten Überblick bekommen wie das jetzt aussieht hier . An dieser Stelle auch nochmal Entschuldigung für etwaige Verzögerungen, wir haben hier spätestens Ende der Woche wieder alles am laufen. Dann können wir auch wieder mit voller Effizienz arbeiten .

Denkbar wäre es. Es ist allerdings schwieriger zu implementieren als beim Stepper Brick, da es keine Schritte gibt. Die Bewegungen beim Sero Brick sind abhängig von der PWM-Periode, welche Analog eingestellt wird. Daher ist es relativ Aufwand auszurechnen wann ich mit dem Debeschleunigen anfangen muss. Ich schreibe es mir mal auf die TODO-Liste mir das genauer anzugucken, versprechen kann ich allerdings nichts .

Ich befürchte das ist das normale Rauschen der Sensoren die auf der IMU verwendet werden.

Das LCD20x4 ist etwas ganz anderes als diese OLEDs, das wird ganz anders angesprochen . Nicht zu vergleichen. Der Zugriff auf die OLEDs ist Pixelweise, da kannst du ganz beliebig drauf Rendern wie du möchtest. Laut API kann man die OLEDs sogar dimmen, habe ich aber noch nicht getestet.

Das Große wird 4x4cm haben (man kann es also einfach direkt oben auf einen Stapel schrauben). Das kleine soll so klein wie möglich werden. Taster-Eingänge sind nicht möglich, da wir alle Pinne des Bricklet-Steckers für die Kommunikation mit den OLEDs benötigen.

Bestückung ist Anfang nächste Woche, danach müssen wir dann noch Fotos machen, testen und eintüten. Es wird also so langsam .

Ich befürchte dann musst du den IMU Brick einschicken, wir gucken uns das dann an und schicken falls ein defekt vorliegt einen neuen IMU Brick raus. Einen Versatz von 30° sollte es nach Kalibrierung nicht geben.

Ja, die API dafür ist noch nicht veröffentlicht. Die Bindings nur für die eine Funktion zu veröffentlichen hätte sich nicht gelohnt, kommt dann zusammen mit den neuen Bricklets.

Hast du vielleicht einen Renesas/NEC USB 3.0 Controller? Die haben einen Bug in älteren Treiberversionen, siehe hier: http://www.tinkerforge.com/de/doc/FAQ.html#eines-meiner-bricks-wird-im-brick-viewer-nicht-angezeigt

Auf der Sero Brick Leiterplatte, neben der Stiftleiste, ist eine kleine Legende. Aber in der Dokumentation können wir das natürlich zusätzlich noch erläutern.

Die Antwort die ich auf 2) gegeben hatte war falsch (ist jetzt korrigiert)! Das war ein Fehlverständnis meinerseits, Sorry! Ich streiche das "pro Phase" aus der Dokumentation einfach komplett raus, es verwirrt nur. Und die maximale Drehzahl hab ich auch nochmal getestet. Unter Last (D.h. ich Versuche den Schafft mit aller Kraft festzuhalten aber er dreht weiter) erreiche ich: * 0.4A@24V: 19000 1/8 Schritte * 0.4A@32V: 30000 1/8 Schritte * 0.4A@35V: 35000 1/8 Schritte Bei je 1000 Schritten mehr kann ich den Schafft festhalten.

Wenn der Master im Bootloader-Modus ist, leuchtet keine LED. Das ist schon OK so. Du musst dann unter Update/Flashing den passenden Seriellen Port auswählen und kannst dann die neue Firmware draufflashen.

Dafür kannst du natürlich in den brickd Source Code gucken: https://github.com/Tinkerforge/brickd/blob/master/src/brickd/usb.c https://github.com/Tinkerforge/brickd/blob/master/src/brickd/usb_transfer.c Ist aber nicht ganz so einfach wie per TCP/IP einen Socket zu öffnen .

Also wenn du mit 2 Sekunden pause zwischen jedem Schritt rechnest hast du in gewisser weise schon Schritt -> Pause -> Schritt etc. Wenn du eine absolut kontinuierliche Bewegung haben willst solltest du vermutlich versuchen sowas wie 1000 Schritte/Sekunde zu erreichen. Da bräuchtest du dann aber natürlich noch eine heftige zusätzliche Untersetzung.

Was ist mit dem Industrial Quad Relay? https://www.tinkerforge.com/de/shop/bricklets/industrial/industrial-quad-relay-bricklet.html

1,5kg Belastung geht locker. Der Schrittmotor sollte problemlos sowas wie 20000 Schritte/Sekunde machen können mit dem Stepper Brick. Oder was meinst du mit "Grenze des Motors"?

Ja, die Monochromen 128x32 von Adafruit oder 96x16 von Yoctopuce wären ganz gut als Brickklet denke ich. Wobei ich aktuell eher zu etwas tendieren würde was mehr quadratisch ist. Wichtig dabei ist das die wirklich nur "an oder aus" haben pro Pixel, dadurch hat man 1 bit pro pixel anstatt 24 bit die man bei einem RGB Display hätte. Da ist die Datenmenge natürlich signifikant geringer .

Ich würde da auch auf jeden Fall einen Schrittmotor nehmen. Dort kannst du dir dann (entsprechend deiner Untersetzung) genau ausrechnen wieviel Grad pro Schritt gedreht wird. Dieser Schrittmotor hätte von sich aus schon eine Untersetzung von 1:27 https://www.tinkerforge.com/de/shop/accessories/motors/stepper-motor-with-gearbox-27-1-594nm.html. Du würdest damit pro 1/8 Schritt 1.8/(8*27) = 0.0083° drehen. Das entspricht 43200 Schritte pro voller Umdrehung, also exakt ein Schritt pro 24*60*60/43200 = 2 Sekunden. Ist das vielleicht schon genug Auflösung? Alternativ könntest du da natürlich nochmal eine Untersetzung hinterbauen.

@Nic: Was für eine Wunsch-Auflösung sollte das OLED Display denn haben? Das Problem dabei ist die Datenmenge. Wir können maximal 1000 Nachrichten pro Sekunde mit maximal je 64 Byte verschicken. Das macht also 64000 Byte pro Sekunde. Zum vergleich: Ein 640x480 RGB Display welches du mit 30Hz aktualisieren möchtest benötigt 640*480*30*3 = 27648000 Byte. Das sind 3 Größenordnungen mehr Daten als wir liefern können. Das übertragen eines kompletten Bildes auf das Display würde 640*480*3/64000 = 14 Sekunden dauern. So ein 64x32 schwarz/weiß Display wäre vielleicht möglich: http://www.buydisplay.com/default/0-49-inch-oled-display-module-64x32-pixel-ssd1306-i2c-white-on-black Aber stellst du dir sowas vor unter einem OLED Display?

Wenn die Master Bricks aufhören zu arbeiten, schmeißt dein Programm dann eine Exception o.ä.? Sind die Master Bricks dann gar nicht mehr ansprechbar? Oder was genau bedeutet "es werden keine Sensordaten mehr zurückgegeben"? Ansonsten ist es definitiv einen Versuch Wert die Master Brick Firmwares auf 2.3.3 zu aktualisieren. Interessant wäre es auch zu wissen ob die Abstürze mit dem Schalten der Dual Relays zusammenhängen oder damit nichts zu tun haben und die Störung von extern kommt.

zu 4) nochmal: Nach unseren Tests erreichst du am meisten Leistung mit einem Synchronous Rectification aktiviert und einem Decay von 10000, was für den Decaywert bereits die Standardeinstellung ist. Das kann aber sicherlich von der Last abhängen die der Motor zu bewältigen hat. Die Geräusche im Stillstand werden tendenziell angenehmer desto höher der Decaywert ist.