borg

Sorry, wird noch ein wenig dauern . Die anderen Probleme die ich gerade am versuche zu fixen lassen sich leider nicht so gut reproduzieren, dadurch dauert es so lange.

Komisch. D.h. es läuft einfach weiter nach einem Timeout und funktioniert dann auch wieder? Ist das Python Skript groß, kann ich das hier evtl ausführen zum reproduzieren?

Erstaunlich wie gut das mit DC Motoren funktioniert . Ich hätte gedacht, dass die Positioniergenauigkeit nach ein paar cm dahin ist.

Kannst du einmal den Teil des Source Codes der nicht funktioniert hier posten?

Ich bin dran, solche Sachen die sich nur alle paar Tage reproduzieren lassen sind leider wirklich schwer zu debuggen .

Extensions müssen über über dem Master des Stapels stecken, sonst funktioniert das elektrisch gar nicht (Die Extensions shiften immer Signale nach oben durch). Wir sollte vermutlich "RS485 Extension Master" in der Doku schreiben?

Schwer zu sagen, 2 Drähte klingt nach einem DC Motor. Kannst du mal ein Foto von dem Motor machen? War in dem Drucker denn auch ein Inkrementalgeber drin (etwas, was die zurückgelegte Entfernung mitmisst)?

The PTC Bricklet will be able to read out a Pt100 and Pt1000 sensor with 2, 3 and 4 wire measurements. These temperature sensors usually measure from -200 to +800°C, so the Temperature Bricklet doesn't even compare to that .

We try to choose a name that is most intuitive. ResistanceBricklet would not be intuitive for a Poti Bricklet, i think. AirPressure Bricklet instead of Barometer Bricklet would be OK, but we thought that most people know that a barometer can measure height (which the Barometer Bricklet can too). And for things like the Distance Bricklet it would be hard to use a name of the device: GP2Y0A41 Bricklet, ugh .

Du kannst mit beiden Brickv beide Brick Firmwares flashen, aber nur mit dem passenden Brickd/Brickv die Bricklet Plugins (das geht ja über den Brick). Du musst in dem Fall natürlich das Bricklet anschließen, nachdem das Brick gestartet hat. Damit das falsche Plugin nicht auf dem Brick ausgeführt wird.

Inwiefern? Gibt es einen Timeout? Also du rufst einfach alle 5 Minuten einen Getter auf? Oder wie kann ich das nachstellen?

In der Theorie, wenn die Daten der IMU absolut perfekt wären, wäre das möglich. In der Praxis sind die Timings über USB nicht gut genug. D.h. wenn du zwei Nachrichten mit IMU Daten bekommst, weißt du nicht auf die ns genau wie weit die Messzeitpunkte auseinanderliegen. Je nachdem wann der gemessen wurde und das Betriebssystem per USB gepollt hat, kann eine Messung von außen um bis zu 2ms daneben liegen. Das ist leider viel zuviel .

Ich befürchte das ist nicht möglich. Du könntest dir die Werte mit hoher Frequenz holen und dadrüber mitteln. Das Rauschen selbst könnte man nur durch bessere Sensoren verringern, dann wäre das IMU Brick aber nicht mehr bezahlbar .

Mh, bei mir gehts. Edit: Ah, mit Python3 kann ich das reproduzieren. Komisch, dann müssen die Python bindings mit der IO16/IO4 noch nie richtig funktioniert haben . Gucke ich mir gleich an, ist vermutlich mal wieder so ein byte vs char gefummel.

Das ist leider gewachsen, im alten Protokoll konnten wir an der Stelle nur die 50 Byte Nutzdaten übertragen. Das WIFI Modul könnte Passwörter bis Länge 64. Im neuen Protokoll haben wir allerdings 64Byte für den Payload, was genau für ein 64 Byte Passwort passen würde. Allerdings übergeben wir bei set_wifi_encryption key index, eap options und andere Dinge, wodurch der Payload wieder nicht reicht . Das einzige was mir dazu einfällt: Wir könnte die API um ein set_long_wifi_password erweitern. Dann müsste man natürlich immer erst set_wifi_encryption mit einem "Dummy-Passwort" aufrufen, um die Art der Verschlüsselung vorher zu setzen. Hat irgendwer eine bessere Idee? Sonst würde ich das denke ich implementieren. Bin sowieso gerade dabei am WIFI Code rumzufummeln.

Welches Beispiel führst du aus? Gibt es keine Timeout oder sowas? Hast du die korrekte UID benutzt (im Beispiel ausgetauscht)?

But you can connect to the IP of the WIFI Extension and do the Bricks/Bricklets that are connected to the Master Brick show up, right? If that is the case, i highly suspect that it is a problem with the timing of the status refresh. Since the refresh makes the WIFI module unresponsive for a small amount of time. I took a look at the WIFI module datasheet. We could try to get the RSSI from another command that does not have so much overhead and do the rx/tx count ourself. All of the other information must only be obtained on connects/disconnects and not every time the getStatus is called. We will try to make a firmware that works this way, that you can test.

No worries, if it is broken we will of course replace it. It is just so unlikely that the 5V rail isn't working. Can you measure the voltage of pins in the green connector? And are you using the black connector for input (Black is input, Green is output) ?

Hattest du jetzt 2.0.1 auch schon getestet?

Ui, ich hab mit Hilfe deines Codes einen potentiellen Buffer Overflow im WIFI Extension Code gefunden. Ich konnte das zwar nicht so gut reproduzieren, allerdings wird dies trotzdem mit hoher Wahrscheinlichkeit dein Problem gewesen sein. Vielen Dank für die Hilfe !

Firmwares: Master Brick 2.0.1 Fix Buffer Overflow in WIFI Extension Code Download Firmwares: Master Brick

Firmwares: Master Brick 2.0.1 Fix buffer overflow in WIFI Extension code Download Firmwares: Master Brick

Mhh, läuft bei mir erstmal soweit durch. Wie hast du das genau zusammengesteckt (welches Bricklet wo, welche Bricks wie aufeinander)? Tritt das Problem auch auf, wenn du keinen Servo am Servo Brick angeschlossen hast?

Gucke ich mir direkt morgen früh an!

You interpreted the function of the Step-Down Power Supply correctly. The way you are describing it, it sounds like the 5V rail isn't working (which is used to power the Bricks). Can you check if the Board-To-Board connectors are connected correctly? We do test the 5V rail of each Step-Down Power Supply, so i don't understand why it wouldn't be working.